クラウドが値上がりに転じる近未来と、DXブームの曲がり角

AWSに代表されるクラウドサービス、特にインフラ周りについては使えば使うほど値段が下がる神話があった。ハードウェアの性能が年々上がっていくから、性能当たりの値段が下がる。また、規模が拡大していくのでスケールメリットでハードウェアを入手するための値段が下がる。そんなロジックでもう１０年あまり業界は動いてきた。

一方で、ここに来ての円安で請求額が１．１、１．２倍と上がっていくことについては沢山のユーザーが経験済みだと思う。しかし、大事な事実を１つ思い出す必要がある。まだクラウド自体の、ドル建ての価格は値上がりに転じていないということを。円高になればまた日本に安定が訪れる、今はそんな状況である。

しかし、それはもう甘いと思う。まずはデータセンターの電気代は看過できない上昇となっている。

xtech.nikkei.com

電力料金の高騰がデータセンターの運営を直撃している。影響は施設内のラックを貸し出すハウジングで大きく、値上げが不可避な情勢だ。サーバーや一部設備も値上げ傾向にあり、付加価値型サービスにも影響が及ぶ恐れがある。

企業間の設備契約は年間契約が多いので、クラウド自体の値段に跳ね返ってくるまでには時間差がある。その時間的猶予ももはや限られると思われる。クラウドのリソース売上に対する電気代の比率がしきい値を超えれば、ついにドル建ての値段そのものの改定がやってくるのは間違いない。

その上である。サーバーの基本部品であるCPU自体の値上げをインテルが発表した。

gigazine.net

2022年7月14日、IntelがサーバーやPCのCPUをはじめとする主力商品やWi-Fi接続機器など、ほとんどの半導体製品の価格を2022年秋に引き上げる予定を顧客に通知したと報じられました。ある情報提供者は、価格引き上げ率は未確定でチップの種類により異なる可能性があるものの、少ないものでは数％、場合によっては10～20％の範囲になる可能性が高いと述べています。海外メディアのThe Registerは業界筋の話として、Intelの値上げは2022年10月から始まるとの見方を示しています。

クラウドベンダーは、値上げ前にハードウェアをある程度確保すると思われるが、しかし半導体不足で量的に限界はある。また、部品の値段が上がるのだから当たり前の用に保守費用も上がるだろう。

企業間取引は年間契約や長期契約も多く、時間差があるので今は安穏としていられるのである。この状況だと、2023年はどんなクラウドサービスでも値上げが起こるのは確定的と言える。

その場合に、更に波及するのが、SaaSの各種サービスの値上げとなる。こうやってどんどん連鎖していく。値上げ分は最後の最後はエンドユーザーが支払うことになる。SaaS内に含まれるベンダー側の人件費も上がっていく。負担はいつしかユーザーに転嫁しなければいけない。ここまでは机上でもわかる事実だ。

さて、円安とのダブルパンチでこの国のIT基盤はどうなるのだろうか。

いよいよ、リソース縮小、SaaS利用見直しの大号令がどの企業でもかかりそうな雰囲気である。DXが一度止まるとしたら、このインフレが契機になってもおかしくないと考える。DXは投資だから、と言っても予算には限界がある。

それは遠い将来ではなくすぐそこなのかもしれない。

古くなるソフトウェアと、人間の心

古いソフトウェアはメンテナンスされないので、セキュリティーホールになる。これがソフトウェアベンダーの言い分だ。

確かにその通りだが、裏目的もあると思う。

昔のソフトウェアを元気に使われたら、新しいソフトウェアが売れない。

消耗品だからこそ、次の商品が売れる。ただ、そもそもデジタルは古くならないのが特性だったのではないか。ストレージさえ移し替えれば、永遠の命を持つのではなかったか。

最近は、ソフトウェアベンダーもサブスクリプション化に躍起である。使い続ける限りお金を支払う体系は、会社が存続するために非常に都合がいい。

永遠に使えるソフトウェアなど作ってしまったら、そのソフトウェアを使っている限りソフトウェアベンダーにはお金が入らなくなってしまうではないか。

ソフトウェアが古くならないと、作り手が困るのである。

ソフトウェア自体は消耗品ではないが、消耗品になるような実装をわざとしている、ということだ。

しかも、この実装をするタイミングが、サポート期間内である。未来になったら使えなくなる仕組みを埋め込んでおく。

食べ物で言えば、期間が過ぎたら毒になるように器に仕組みを設けておくのだ。腐った食べ物を食べると有害だからという理由で。

ソフトウェアを作るのも人間だ。だから「ソフトウェア心理学」という分野があってもいいんじゃないか、と思う。ソフトウェア自体はデジタルで古くならないのに、人間がこれを作るときに、古くなることを一生懸命実装するのである。

・ある時刻を過ぎると、起動すらしなくなる

・勝手に削除される

・未来のOSのバージョンの場合インストールを絶対にできなくする

・新しいバージョンでは、古いバージョンと連携できなくする

・しばらくはアップグレードを許すが、ある時期からそれすら許さなくし、削除しかできなくする

各社、手を変え品を変え、「古くなった」という実装をするのである。

サポート切れと言いながら、サポートとは、手助けしたり話を聴いてくれるという意味ではないのである。サポート切れを境に古くなるプログラムが起動するのだ。そしてさらに古くなると起動すらできなくなる、というところまで、昨今のソフトウェアはきっちり実行する傾向にある。

繰り返すが、表面上はセキュリティー事由である。サポートしていないソフトウェアが流通すると攻撃に使われるので、企業として息の根を止めなければならぬという理由である。

一方で、ビジネス上の裏の理由は、非常に、非常に強い。使えているのにバージョンアップせい、と言う。いや何も問題なく使えてるんだから、使わせてくれよ、と。保守料払うからと。いや、保守するから代わりにバージョンアップして、との一点張りである。ソフトウェアベンダーも、古いバージョンをだらだらサポートしていると、新しいバージョンも含めてコードの範囲が広がり過ぎ、コストがかかってしまうのだ。

ソフトウェアは、機能アップや新しいOS、ミドルウェア、ライブラリーへの対応も含めてどんどんアップデートされるものなので、そういう意味では古くなる。これが実質的な古さ。一方で、古さを演出するための人工的な古さの実装。

一方で、将来はどんなアップデートをするか決まっていないことを考えると、「古さの演出」の方が先なのだ。これは面白い話ではないか。自分を破壊するコードを、将来に向けて書くのだから。

Windows 2000時代のフリーウェアでWindows 11でも動いてしまうソフトウェアがVectorなどに落ちていることを考えると、案外この「古さの演出」実装は最近のものであり、人間心理の変化が理由なんじゃないかな、と思う。

人間じゃない何かがソフトウェアを作ると、もしかしたら古くならないソフトウェアを作るのかもしれない。

大企業、セクショナリズムの特徴とそのデメリット

私は大企業に勤めたことがないのだが、大企業とお付き合いすることはある。中小企業と大企業は、全く違う。もう、全部。どっちが正しいという話ではなく、別物だ。

最も感じるのはセクショナリズムだ。

ビジネスは、

・セールス
・製造
・カスタマーサポート
・技術開発

この４段階で成り立っている。で、最近は、いろんなバズワードで表現され、意味が拡散しているるところまでは現代の常識である。

そのうえで各４段階、それぞれ細分化される。例えばセールスと言ったって、以下の分野がある。

・マーケティング
・広告
・プリセールス
・営業
・アフターセールス

売るものが手元にあるとして。まずどうやって潜在顧客に「こういう商品があるよ！」と届けるかを考えなきゃいけない。知らなきゃ買えないんだから。そして、潜在顧客の数がどれぐらいいて、お金をどれくらい支払う気があるのか。マーケットを調べるのがマーケティングの仕事。まだこの時点では具体的な顧客とは会えていない。

その後、ターゲットになるマーケットが決まったら広告を落とす。全国民に知ってもらうにはテレビで延々とCMを流せばいいが、これがお金がかかってしようがない。また、若者はテレビを見ないそうなので、若者がターゲットならネットの方がいい。などなどの広告の仕事。

そして、問い合わせが来る。で、すぐ買う！となればいいけど、いやいや、買って大丈夫ですのん？、という話もある。だって、せっかく買ってもらっても顧客が使いこなせなかったら、もう次には来ないよね。この買う前の営業活動がプリセールス。プリセールスのタイミングで、いや・・実はこれも困っててね・・、ああそんな商品あるの、いいね、と購買行動を促進する役割もあるよね。

で、ちゃんと売る際には、営業担当がきちんとつく。お金とモノやサービスの交換には、法律や経理も絡むので、専門知識が必要だ。だから営業と言う仕事は、転職しても存分に活躍しやすい。「売るものがあれば何でも売るよ」と、営業の人から言われたことがある。

そして売った後。一度売って放っておくのはもったいない！。だって使ってくれる顧客は、一番商品に詳しくなる、むしろ作った自社よりも。だからいろいろ雑談の中で改善要望が出てきたりして、次世代の商品開発にフィードバックしたり、もしくは新しい案件が創出できたりする。

という具合に、ただ営業だけ切り取っても、いくつものフェーズがあり、これらを連動してこそビジネスが成長する。

するのだが、大企業は、これ一つ一つにチームがいる。

そりゃ、大企業なだけに顧客の規模も数も半端なく、さばくためには分業化は絶対必要だ。

ところが、中小企業は、全部、一人がやることもザラである。

むしろ、営業も製造もカスタマーサポートも技術開発も、全部やることだってある（全部のフローの中の一部かもしれないが）。

中小企業にいて、大企業の方と話すと、すごく一部分はめちゃ詳しいけど、枠を外れると途端に動けなくなるときが散見される。

ある打ち合わせで顧客と、大企業と話をしたとき、大企業側がたくさんのメンバーを連れて来て驚いたことがある。顧客一人、私一人、そして大企業たくさん。

そう、セクショナリズムだけに、大きな話題をしようとすると、それぞれのセクションから人をそれぞれ連れてこないといけないらしい。

ただ、現場の顧客としたら、セクションなんて知ったこっちゃないというのが感想なんだよね。話が飛んだ瞬間に、話す人が飛んだり、「今日はその担当連れてきてないです」とかって、なかなかの地獄。

大企業も、この通り小回りがきかないので、顧客に近しい、中小規模のパートナー企業に入ってもらって、営業活動を代理してもらうというのが今のベストプラクティスになっている。いやほんと。

どんな大企業も、「これからはパートナービジネスを拡大する」って言ってるのそういうことだから。直接、エンドユーザーとつながるのは、相当大規模のビッグユーザーだけに限るようになっているのがトレンドだ。

大企業は、大企業として存在し続けるのはほんとにすごいことで、そのための組織論だからセクショナリズムが今後も変わることはないと思う。ただ、明らかにひずみはある。社会人として、限られたセクションに長年居続けると言わずもがな・・と思う。

テクノロジーブームの終焉

日本IBMが次世代のITアーキテクチャーを発表したと聞いた。

japan.zdnet.com

　日本IBMは7月14日、現実とデジタルが融合するとした次世代のITアーキテクチャーを発表した。11業種を対象にしており、各業界でのユースケースの具現化に取り組むとしている。

具体的にはこの記事のことを指す。

www.ibm.com

まず、この話題で出てきた、アーキテクチャーの図を上記記事から転載する。

この図を見て思ったのが、ずいぶんテクノロジー自体が抽象化したこと。2010年代でこういった図が出てくるとき、テクノロジーそのものが無数に散らばっていることが多かった。仮想化技術、クラウド、ビッグデータ、OS、ミドルウェア、コンテナ、そこからRPAやAIに発散していった技術が無数にあり、当時はこんなに広い領域をどうやってカバーするべきかどうか悩んだものだ。

当時は、「テクノロジーファースト」と言ってもよかったと思う。イベントがある度に参加者は盛り上がり、これで世界は変わると酔いしれていた。それを何度となく繰り返したこの業界だが、私が思うについに出すものも無くなったのではないか、と思う。いくらテクノロジーを繰り出したところで、もう出しているサービス自体が競合になる。自らが作り出したレッドオーシャンではないかと思うのだ。

過去の優れた製品が、製品企画において競争相手となってしまう。そりゃ、無数に出していればいつか飽和する。どこかで整理しなければいけない。目的は有限であり、ニッチをいくら作っても、ユーザーはどれを使えばいいか迷うばかりである。

あくまでもテクノロジーはツールであって、目的として誰に何を届ければいいか。そのためにどのテクノロジーを選択すべきか、と考えるとこれだけシンプルにまとまってしまうのかという発見だ。かつ、それぞれのテクノロジーはロックオンしていない。どこかのベンダーの何かの製品というわけではない。それぞれのテクノロジーにどのベンダーのソフトウェアやサービスを使うかは自由で、それより、どうやって各業界が必要とするソリューションを実装するか、それをまとめたのがこの図ということだ。

2010年代はまさにコロナが起こる前、今や旧世代の記憶になってきたが、いたるところでテクノロジーイベントが行われ、プレゼン資料が毎日どこそこで乱れ飛び、それを読んでいるだけで勉強になったものである。ここ最近、減ったと思わないか。これは、テクノロジーで遊ぶことより、どう実装するか。いわゆるDXに世間の関心が移ったことを意味すると思う。百花繚乱だったテクノロジーやサービス群もだんだんとデファクトスタンダードが決まってきて、わざわざ新興が新しいものを作らなくなってきた。Web3やメタバースのような「今は誰も手にできていないけど将来すごいヤツ」の話が増えてきた。おそらく現在のアーキテクチャー上で何かテクノロジーを突っ込んでも、もう戦いにならないことを示していると思う。

技術者としては、けっこうつまらない時代になったんじゃないかと思う。役に立つかどうかは置いといてワクワクするプロダクト、というのが2010年のキーだったからだ。今はワクワク？、それで食べれるの？、という時代だ。

ああ、あれはブームだったんだな。そう思わざるを得ないこのニュースであった。

元請にずっといたらわかる、ITエンジニアが不足する理由

もともと、SESで元請のオフィスに長く常駐し、そこから転職して元請側に来た私はわかる。どうにも、元請にいると技術が偏る。当然特定顧客やサービスが決まっていて、そこから要件も似かよってしまうからだ。

世の中、ITエンジニア不足とは言うけど、原因は退職にあると思う。簡単に退職できないようなロックオンをするのが日本企業は上手だった。年功序列に終身雇用。ただIT業界の場合は持っている技術を他の会社にも転用しやすいので、転職しやすい。もしくは、現場を転々とするような、SES、派遣、フリーランスなどの形態もあり、同じ現場に拘束されたくない人はあえて選ぶ。

元請以外にも、SaaSなどを提供する事業会社でも同じだろう。何しろ逸脱することが難しくなる。逸脱すると新規事業扱いとなるが、ここで新規のことをやるためには、新しい分野を外から持ってこないといけない。しかし、会社の中にいて外の情報を持ってくることがどれだけ大変なことか。IT系イベントが開かれると、こんなに人が来て日本の会社は大丈夫かとなるが、おそらく会社の中にいても何も新しいものが出てこない、という衝動が起因していると思う。

現場に縛られないと、多くの経験が積める。ただ、この表現には少し語弊がある。職務経歴書が華やかになる。いろんな技術分野を記載できる。一つのことを長くやるのは価値があることだと思うが、転職時に採用担当者は、職務経歴書を文字列でクエリーするのである。たくさんのことを書けたほうが物理的に引っかかる。つまり、経験があるように見えやすいのだ。

まるで、同じ場所に長くとどまると経験が積めないようだが、実際は違う。元請や事業会社は直接、顧客とつながってビジネスそのものをITで解決するので、ITそのものではなくビジネスとの関わりが学べる。成功経験や失敗経験がビジネスそのものに直結するため、どんな課題をITで解決するかという視点に対して学びを深めて行くことができる。

一方で、現場を転々とするようなシステムエンジニアの場合、業務そのものではなく手段としてのITに専念できる。IT自体に特化することも一つの生き方である。当然、古い技術や人気のない技術、もしくは競争相手が多くて単価が上がらない技術にこだわってしまい、仕事がなくなっていくリスクもある。また、業務側・ユーザー側と距離ができるので、ビジネス感覚は磨きにくくなる。

一言にITエンジニア不足と言ってもいろいろな見方があるが、少なくとも元請においては、人材の流動性を上げていかないと人が外に出るばかりである。会社において全ての人が主流派ではいられないので、主流派を目指して外に出るのは合理的だと言わざるを得ない。会社内の配置転換などでキャリアを広げられれば一番いいが、案外活躍している人ほど外に行くものである。だから、年中、人が人がと言っている。私も。

何とかかんとか、あまり仕事が変わらない現場を少ない人手でやりくりしながら、こうなったら未経験でもいいからポテンシャルのある人を採用し育て上げる、みたいなことをスタンダードに考えないといけない。今後、人々のスキル志向が高まり、就社精神のような、ネットの人々に笑われるような概念がいよいよ収束していくのであれば、ITエンジニアが固定技術や固定サービスに縛られないような働かせ方が重要になっていくと思われる。

この会社にいたら、ずっとこれやんなきゃいけないの、っていう感覚はITエンジニアには死活問題になるのだから。

IT業界の「技術がある／ない」論争

IT業界の「技術がある／ない」論争は年中Twitterでくすぶり続けている。

・SIerは技術がある／ない
・Web系は技術がある／ない
・元請SEは技術がある／ない
・ユーザー側のSEは技術がある／ない

この、技術があるとかないとかって、何を言っているんだろうかといつも思う。技術って何？。

資格を取ることが技術という人はいるけれど、仕事で使わない資格をいくら取っても直接は役に立たない。資格は技術を伸ばすツールではあるけど、資格手当をもらうことと技術そのものが、完全にリンクしているところを見たことがない。

資格を取らなくても仕事ができる人はたくさんいるし、資格を取っても仕事ができない人もいる。

ある仕事において、資格を条件づけたとして、全然仕事が進まない場合は資格関係なく、できそうな人をアサインし、できちゃった、みたいなことも起こる。

資格の議論は技術の話とは切り離したい。

わかりにくいこの「技術」という概念に対し、「仕事」はわかりやすい。あいつは仕事ができる。もしくは、あいつは仕事がすごくできる。

仕事ができることについて、技術はあったほうがいい。しかし仕事をサポートする技術と言ったときには、かなりその内容が限定されるのではないか。いくつかの技術要素の組み合わせと、後はコミュニケーション能力や責任感、行動力みたいなものも強く関係してくる。技術の深さを求められることもあれば、広さも必要だったりするし、仕事によって全然違う。

また、「仕事ができる」と「仕事がすごくできる」みたいな高い次元の話になったとき、それが技術の有り無しではなく、経験や勘、度量みたいなものもすごく関係してくると思っている。

これは、「技術」は教育によって誰にでも反復可能とされているのに対し、その人しかできない部分、その人しかできないよね、みたいな達人芸は教育だけではどうしようもないんじゃないかと思っている。

話を戻す。立場によって、個人に技術が有るとか無いとか言う話。

技術の有り無しは所属会社に関係しないんじゃないか。特にIT系は技術がオープンで会社に関係なく学べる内容が多い。どんな立場でも入手可能だ。とすれば、技術があるだのないだのではなく、単に経験や立場の問題だけの話じゃないかと思う。SIerだろうがWeb系だろうが、元請けだろうが下請だろうが、ユーザーだろうが委託だろうが、技術うんぬんではなく、経験の問題では？と思う。その会社、その立場でしか経験できないことを、言っているのか。

とすれば、技術ではなく、「その分野の仕事ができるか」と言い換えたほうがいいのだろう。その仕事がしたいのにできないのは、技術の問題ではなく、単なる立場の差だけなんじゃないか。SIやりたきゃSIerが一番仕事ができる。元請の立場は元請が一番できる。Web系は・・ユーザー系は・・。もうそれだけの話だ。

だから、Twitterを見ていても、もしその仕事をやりたいなら、技術どうこうじゃなく転職を試みるべきだとは思う。対岸にいて「私の方ができるのに」は机上の空論すぎる。きっとその仕事に近づけない原因は技術ではなく、経験不足によるものであり、経験不足はその場に行かないとどうにもならないのでは。

そういう視点で転職を考えていくべきではないか、と思う。年収うんぬんより前に。

ああ手順書よ お前は本当に味方なのか

技術的な作業をするときに、他人でもできるようにと、手順書を作る。

もういっぱい手順書を作った。でも、手順書なんて作らなくても作業はできる。

だから、むしろ作業しながら手順書を作ることも多い。

たくさん、たくさん手順書を作った。

そして、メンバーにもたくさん手順書を作らせた。自分ですら自分がやったことを忘れるから、作業ログ的に手順書を書いてね、と伝えた。

たくさんたくさん手順書が積み重なった。

繰り返すが、私自身は手順書がなくても作業はできる。誰かのために作った。

けど、メンバーは残らない。

私が作った手順書がメンバーに利用される前に、いろんな理由でメンバーが変わる。

手順書は残る。メンバーは変わる。

新しいメンバーが手順書を使う前に、まずはITの基礎を固めなくてはいけない。

手順書を真似しても、なぜそんな手順なのかを理解できるかはまた別の話だ。

新しいメンバーもまた手順書を作る。

古い手順書を模倣して。

そしてまた、手順書が作られていく。

私もまた、手順書を作っていく。

積もっていく手順書。

でも、メンバーは積もらない。

この手順書ってやつはなんなんだろうか。

手順書を作れば属人化しないというが、そんなことはないな。

むしろ、属人化できるならまだいい。

属人化できるスキルがそのメンバーにあるから。

もはや、属人化できるようなメンバーが集まらぬ。

教育した後、定年まで働いてくれるならまだいいが、そんな時代じゃない。

じゃあ配属して、手順書があるから、君の担当ね、なんてシステムあるのだろうか。

手順書は何をしてくれるのだろうか。

どうも最近は、手順書を信用していない。

システム運用をしていくうちに、システムの内部が新しくなって手順書がそのまま使えなくなることも多く体験した。

だから、作業をしながら、変わった点は新しい手順書に反映させていく。

反映させるんだけど、次にまたやったらまた違う。

この対応をするためには、やっぱりITの知識が基本になる。

いきなり未経験にはできない。

だから、手順書なんて、参考程度である。

ただ、未経験ほど手順書から離れられず、違った結果が返ってきて固まるのである。

ああ手順書。

お前は何者なんだろう。

私が書いた手順書は、誰にいつ読まれるのだろう。

というか、誰か読める人がいずれ現れるのだろうか。

じゃあ、どうやって技術はメンバーに伝えればいいの？。

お前は本当に味方なのか。

多分、考古学のように、残った文書を、手順書なども含めて後から詳しい人が読み込み、そして理解していくのだろう、きっと。

それか、システムのほうが朽ちていくか。

手順書なんて、そんな価値ぐらいしかないものなのである。

「なぜIT屋はつぶれないのか」という有料記事を書きました

「なぜIT屋はつぶれないのか」という有料記事を、noteに書きました。

note.com

IT業界に入って思ったこと‥と言ってももう何十年も前の話ですが、こんな業界、すぐつぶれるだろ、と思ったものです。

業界に25年いて、ようやくつぶれない理由が明確になるというのも息の長い話ですが、まとめてみたかったので、できてよかったです。

ノリで就職した場所がIT業界でしたが、当時はどんよりしてたのに、今デジタルブームでこんな状況なのが信じられない感じです。

japan.zdnet.com

こちら、今日のニュースですが、このタイトルってちゃんと頭使わないと意味がわからないです。

「デジタル前提のIT構造」

デジタルってITだし、ITってデジタルじゃないの？って。

これ違うんですね。これまではこうでした。

「業務前提のIT構造」

業務やってる人が一番偉かったんです。業務を理解してデジタルに落っことす。落っことされた先にインフラエンジニアがいて・・というのがこれまでの世界観でした。

ところが、これが変わります。デジタルで業務をどう改革するか、いわゆるDXの観点から業務自体の変革をデジタルが迫っています。

今までの業務はわかった。でもそれじゃ、いつまでも古いビジネスだ。外国のデジタルビジネスに取って食われるかもしれない。業務をデジタル前提にしないとだめだ。

この発想こそ業務の先にデジタルがあり、デジタルこそ業務である、という話。

こういうこと自体が大転換だという話です。そして業務の下請けだったITが、業務自体を制圧する瞬間でもあります。

ということで、ますますこの業界、つぶれることはありえないなということで、先に先に進んでいくことになります。

有料記事には「なぜつぶれないか」ということを多面的に書いてあります。週末にお時間があればお読みください。

システム障害の説明責任と、現場の統制

経験をふまえて言っておくと、対外的な説明と、社内的な事情はだいたい乖離している。社内的にはわかっていることは積み上げられているが、まとまってはいない。それらの情報をいかに対外的に表現するか。技術トップがシナリオをいくつか作り、経営層へ提示する。経営層が顧客の立場から納得できるか、そして開示したことで法的な問題へ発展しないか弁護士の意見も聴いたうえで、社外報告書のかたちを決めていく。

今回のKDDI記者会見や去年の東証記者会見の際にも、トップの説明がスマートで世間の支持を集めたが、これはトップが優秀であること以外にも要素がある。記者が何を質問するかなど専門家にはお見通しである。想定問答が相当丹念に練られている。記者会見で露わになったのは想定のほんの一部である。だからこそあれだけ、余裕のある返しが成立する。

ただ、第一報としての会見は問題ないが、今後である。きっと、世間の大部分は復旧したことで関心を無くす。どうせ言いたいだけである。普通のサービスレベルが戻ったら、ロジックなんてどうでもいい。でも二度と起きたら許さないからな、って。そして残るのは専門家だ。このまま最終報告があやふやだったら再度起こるじゃないかと。マスコミもテック系の担当者だけ残る。復旧以降である程度の時間を使い、現場が確信を得るまで状況を確認し、再発防止対応が終わってから、最終報告書を作り上げる。このときに、第一報で余計なことを言っていると、つじつまが合わなくなるので、第一報の段階から慎重さが必要なのは言わずもがなである。

ここまでのプロセスで、大企業なら説明、資料作成、技術調査、まで分業で分かれていて問題ないだろうが、問題は中小企業である。全部を数人、いや、一人でやっている場合もある。そのとき、以下の状態となる。

・技術的に調べられるのは自分だけであり、復旧に向けて努力している。

・説明できるのは自分だけであり、報告に向けて努力している。

・社外的なストーリーを考えられるのは自分だけであり、納得感のあるストーリー作成に向けて努力している。

・経営層に説明できるのは自分だけであり、説明に努力している。

いくら努力すればいいのか、技術調査を行おうとしても、営業担当や顧客から説明を求められ、そこに役員登場。詰むのである。

こう言ったことにならないために、非常時の体制とプロセスは常にアップデートしなければいけない。誰かに過度に依存すると物事が進まなくなる。責任を決めておかないと、誰かがやっているだろう、となり、統制が取れなくなる。

昨日の記者会見を思い出しても、本当は知っていることと、ここで話していいこと。そして誰がどの立場で話すか。きっちり分けられていて素晴らしいと思った反面、実際のところ、はまた違うんだろうな、という感想しかなく、ちょっと見ていて苦しくなった。少し、大企業がうらやましくなったのも合わせて言っておく。

社内の真実と、社外的な説明が乖離するのも、仕方がない。きっと、本当のことは専門家にしかわからないからだ。第一報の段階だと、「過半の人に理解できるよう翻訳して話す」のが重要だからだ。その中で、本当に知りたいことがぼやけていく。

それに、実際に手を動かす技術者が関わり始めると、今、調べなきゃいけないこと、やらなきゃいけないことと、別のもう一つの事実を頭にいれなければいけなくなり、わけがわからなくなる。

だから、分業したほうがいい。技術者は技術だけやった方がいい。説明は説明専任の担当者がやったほうがいい。

ふと、そんなことを思った。

au通信障害に思う 基盤とソフトウェアの密接で難しい関係

auの障害の件、コアルーターの交換がトリガーになっているのに、記者会見のプレゼンの絵に掲載されていないので理解がしずらくなっているように思う。

発生事象概要 pic.twitter.com/EsNja9dLcp

— Munechika Nishida (@mnishi41) 2022年7月3日

クラウド運用の仕事をしていると、この「コアルーター」という言葉はよく出てきて、メンテナンスによる切り替え切り戻しの作業はクラウド事業者側でよくやってる。二台構成の場合は、以下のように実施する。

***

① 副系のファームウェア、機器交換などメンテナンスを実施する

② 主系から副系に切り替える

③ 動作確認

（もし問題がない場合）

④-a  主系のファームウェア、機器交換などメンテナンスを実施する

④-b 副系から主系に切り戻す

④-c 動作確認・・・完了

（もし問題があった場合）

④-d 副系から主系に切り戻す（至急）

④-e 副系の戻しを行う（ファームウェアの戻し、あるいは機器戻し）

④-f 主系から副系に切り替える

④-g 動作確認

④-h 副系から主系に切り替える

④-i 動作確認・・・完了

***

と、なかなか大変なのである。

今回はコアルーターの交換ということで、①で実施し、②を行ったらそこで正常に動かず輻輳が起こり、その上で④-dを行い切り戻したけれども、今度は輻輳時のエラー多発のため大量の状態不整合がソフトウェア側に起こり、輻輳が止まらなくなった、と理解した。

ネットワークエンジニア的には戻すだけなのだが、一度異常が起こった上位のソフトウェアを正常に戻すためには、ソフトウェアエラーが連発する状況を食い止める必要がある。

端末がつながろうとするときに、セッションを管理するデータベース側と、VoLTE交換機の持っている情報で状態が食い違うために再送が発生し、それでネットワーク流量がいつもより数倍の状態が収まらないと会見ではおっしゃっていた。だから、物理的にネットワークの流量制限を行い、長期化したのだと。

この、ハードウェア基因で基盤の状態が急激に変わった際、ソフトウェア側で不整合が起こり正常性チェックが邪魔をして動作不良になる、というパターンは何度か経験がある。

往々にして、基盤側とソフトウェア側は、担当者も設計者も別である。

トリガーは基盤側なのでとても申し訳ないのだが、不具合がソフトウェア側に移るので基盤側にできることがない。今回では、できることはルート変更や流量制限のところぐらいである。しかし、そんなことをしても、そもそも大量に不整合がソフトウェアで生じている状態では、まずは「正しい状態」に近づけないといけない。

今回は、データベースとVoLTE交換機の状態をまず一致させないと、また再送のための輻輳が起こるのでソフトウェア側の修正が必要になる。しかし基盤側ではかたずを飲んで作業を待つしかないのである。

当初の情報ではVoLTE交換機の障害と聞いたがこれは違いそうだ。システム設計時に、基盤の不具合が基因してネットワーク帯域上で輻輳が起きた際に、大量にデータベースとVoLTE交換機の間に不整合が起こるとは想定していなかったか、想定していたとしても再送で復旧すると考えていたはずである。しかし、それをさばくことができなかった。だから今、半手動で作業を継続していると思われる。

今回の件、基盤側では機器交換の手順は、ごくごく一般的なものだったんだろうと思う。開発環境でも十分テストをした機器を入れたのだろうし、かつそれで問題が起きたから戻すのも適切に行われた。ただ、その短い間に起こった輻輳を契機にソフトウェア側がメタメタになってしまった。だから、恒久対策としては、輻輳が起こってデータベースとVoLTE交換機の間の情報が不整合が起こった時に、通信量を抑えるトランザクションを開発しなきゃいけないんだろうな、と思う。

もしくは、ソフトウェア側でこのような大量再送時の通信量急増に耐えうる帯域を基盤側で用意するか。しかし、それならどれだけ性能を高めれば起きなくなるかを算定するかは非常に難しい。本番の状況は、本番でしか起きないからである。

似たような仕事をしているので、いろいろとお気持ちがわかってしまう。使う人は、「使えない、何でこんなに復旧に時間がかかるのか。再発防止策をすぐに。」となるだろうが、特に基盤の性能問題と、それを超えた際のソフトウェア不具合というのは、運の悪さも手伝ってなかなか短期的に解決するのが難しい。

特に、4Gもサービスインから10年で、機器交換も今後たくさんあるだろう。なかなか舵取りも大変だ。

そうだ、「1:00～3:00の間、au携帯電話はメンテナンスのため停止します」ではどうか、ダメか。本当大変なシステムだと心底思う。