元富士通SEから見た東証のシステム障害 - 外注先に丸投げしないことの重要さ
10月1日の東京証券取引所の記者会見が素晴らしかったです。こんなにシステムのことを深く理解している人が東証という堅そうな組織（失礼）の経営層にいるのかーと驚きました。
Twitterに感想を書いたように、会見の質疑応答に応じる社長やCIOの言葉の端々から、東証側が主体的にシステムの開発や運用に関わってきたことが伝わってきました。実際のシステム開発は富士通がやっていたにせよ、求められる要件や実際のシステム構成をちゃんと理解して富士通側と対等に議論し続けてきたんだろうなあと感じます。
東証の記者会見見てる。質疑応答から、東証側のシステムに関する理解度の高さが伝わってくる。ベンダーに丸投げだと「富士通に損害賠償を請求します」となりそうなところ、東証側にベンダーと対等に話せるだけの技術者がいることで、お互いが近い目線に立って仕事できてるのよな。素晴らしい。
— gami@非エンジニアのためのエンジニアリング (@jumpei_ikegami) October 1, 2020
今回の東証の障害は、システムの外注やリスクに関して理解を深めるのにとてもいい題材に思えます。システムを外注し運用していくときの理想的なスタンスに関して、今回の一件から学べることは多そうです。障害によって生まれた社会的損失は痛いのでしょうが、それを無駄にせず多くの学びに変えていくためにも、この記事ではエンジニアじゃない方にもわかりやすいように「東証の何が素晴らしかったか」について説明したいと思います。
なお、今回の東証の障害について軽く知っていた方が理解しやすくなると思います。よく知らんという人は、予めこの辺の記事を軽く読むと良さそうです。
また、YouTubeで記者会見のアーカイブ動画も見られます。1時間以上あって長いですが、ぜひ一部だけでも見てみてください。
Twitterでエンジニアたちが驚きの声をあげた
東証の記者会見直後のTwitterを見ていると、エンジニア界隈の方たちによる「東証のCIOすごい」という反応がとても多かったです。
東証のCIOさん、めちゃくちゃすごい
— よだれいぬ@通勤は悪い文化 (@pabroff_freeze) October 1, 2020
ちゃんと各システムのことや構成についても細かい部分について理解して話されてるし、記者のレベルに合わせて単語も選んで具体的に説明しているし、この方どういう経歴なのだろう…
記者会見では、最初に簡単な説明を読み上げた後、質疑応答の時間が長く取られていました。用意された説明をなぞるだけであれば誰でもできますが、その後に記者からぶつけられた質問に対してもいわばアドリブでシステムに関するかなり詳細な説明をしていました。ここまでの詳細な説明は、開発や運用の意思決定にCIOをはじめとする東証側が日頃から主体的に関わっていないと難しいと思います。実際、東証の株式売買システムであるarrowheadについて書かれた富士通の記事には次のように書かれています。
プロジェクトの上流工程で徹底的にバグを出す方針を打ち出すとともに、「要件定義は東証」「設計は富士通」と責任を明確にしました。そしてプロジェクトに参画した東証のメンバー80人と富士通の技術者300人の一人ひとりが、上流工程でのバグ出しを着実に実践。その結果、下流工程で見つかるバグは前回の10分の1にまで減少し、十分なテストを経た後に新arrowheadを稼働させることができました。
特に、従業員数が約400名の東証側から80人ものメンバーがこのプロジェクトに参画していたというのは驚きです。
もしかしたら、「自分たちが使うシステムについて詳しい人が経営層にいるなんて、当たり前じゃないの？」と思う人もいるかもしれません。しかし実際には、システムの開発や運用をITベンダーに丸投げしてその中身はよく知らないという情シスや経営層が日本には多くいるとする言説が多いです。批判の内容を実際に見たい方は、Googleで「ベンダー 丸投げ」などと検索してみてください。
システムに問題があって経営陣が記者会見をするといえば、記憶に新しいのは2019年7月にあった7pay不正利用の件です。たとえばこの記事では、7pay側のシステム開発の丸投げ体質について批判的に書かれています。
「なぜ二段階認証を採用しなかったのか」と問われた際に、その判断の理由を説明できないと、ガバナンス上の疑義が生じる。経営陣はサービスやシステムの開発にあたって統制を効かせず、開発現場やITベンダーに丸投げしていたのではないかと疑われても仕方がない。
7payの一件では、セキュリティ上の問題から不正利用の被害が発生したというだけではなく、杜撰な管理体制が記者会見で明らかになったことで企業としての評判を大きく下げてしまいました。これは、システムの外注で生じるリスクを十分に軽減できていなかった結果です。東証と7payの差は、どこにあったのでしょうか？
なお、あなた自身がITシステムを発注する立場になくても、業務の中で何らかのシステムやサービスを使っているかと思います。そんな人にもリスクを軽減するために意識したいこと、今日からできる取り組みについてもこの記事で説明します。
外注せざるを得ない状況とは？
ちなみに、このnoteの先々週の記事では内製化の重要性について（かなりの分量で）書きました。
雑にいうと「内製化は素晴らしいので目指すべき」という話でした（雑）。その論調を踏襲すれば、東証も外注じゃなくてちゃんと内製化した方がいいように思えるかもしれません。
もちろんそれが理想ですが、現実的には次のような事情から内製化が難しく外注せざるを得ないという状況も多々あります。
・システム構築に技術的な専門性が高く求められる
・構築するシステムの汎用性が低く、既存のサービスやパッケージ製品の組み合わせでは要件を満たすことができない
・システムの規模が大きく、運用期間と比べて初期開発時やリプレース時にかかる工数がかなり大きい
・結果的に、システム開発に必要な全ての開発者を正社員として恒常的に抱えることが困難
たとえば東証の株式売買システムであるarrowheadの場合、公式サイトにあるように注文処理のスピードが約0.2msとかなりの要求水準が求められています。常にこのスピードを維持し続けるようなシステムを開発するには、通常のWebサービス開発と比べてもハードウェアの選定やシステムの設計などにかなり特殊な技術スキルが求められそうです。また証券取引所のシステムなので、世の中に流用できるシステムが多くあるようなものでもなく、規模としてもかなり大きくなります。そのような大規模高難易度のシステム開発を支える開発者を東証が常に正社員で抱えるというのは到底現実的ではありません。富士通のようなベンダーに開発部分を外注するというのは合理的な選択であると言えそうです。（ちなみに、東証の従業員数が2020年3月時点で420名なのに対し、2015年のarrowhead開発プロジェクトに関わった富士通側の技術者は300名らしいです。この人数比較だけでも、内製化がほぼ不可能であることが想像できます。）
もちろんある程度汎用的なシステムであっても、今の日本では優秀なエンジニアを採用するということ自体の難易度が高いので仕方なく外注せざるを得ない、といった状況はいくらでもあると思います。（そもそも経営層が内製化の重要性を理解している会社がどれだけ日本にあるかは怪しいですが。）
自分たちが使うシステムの中身を理解することがなぜ重要か？
前述した内製化に関するnote記事では、主に外注で発生するコストの話をしました。同様に、丸投げに近いような外注をしてしまうと「よくわからないけど不正利用されました」とか「よくわからないけどシステムが1日止まりました」といった状況に追い込まれるリスクを抱えることになります。7payの例でいえば、セキュリティ上問題のある仕様の決定を発注者側がスルーし続けた結果として、最終的に不正利用されサービス停止に追い込まれるほどの経営上のリスクにつながっていたわけです。7payの件に限らず、外注したシステムに関するトラブルに際して発注者側が「ベンダーに騙された！」というのは簡単ですが、「そんなに重要な意思決定を丸投げせざるを得ない無知なお前が悪いのだ」と言われたら、ビジネスの世界では何も反論できません。鬼滅の刃で言えば「生殺与奪の権を他人に握らせるな」、中島みゆきで言えば「おまえのオールをまかせるな」ということです。
東証のarrowheadの場合、富士通の事例記事によると「多い時には1日1億件以上、1分間で140万件にも達する注文を処理」しているそうです。東証のシステムは少し特殊かもしれませんが、一般的に事業の基幹となるシステムを稼働させるとなると、人間で置き換えたら数百〜数千人規模のチームを組成してその業務プロセスを組むようなものです。その1つの会社ができるレベルの大規模なチームの業務がどういうフローで行われどのようなリスク管理がなされているのかを経営層や管理職が理解するのは、内部統制の観点でいえば当然のことです。にも関わらず、それがヒトではなくITシステムに置き換わっただけで理解を放棄してしまうというのは、おかしな話です。
もちろん今回の東証の障害では、丸一日取引が止まってしまうという大変な事態になりました。しかし約15年もの間、終日停止せずに運用し続けてきたことがそもそも素晴らしいことです。また今回の障害についても、システム再起動をあえてしない決断を迅速に行い、件の記者会見で情報が正確にメディアに伝わったことで、大きな混乱もなく翌日には取引が再開されました。これも、東証の経営陣がシステムの中身を正確に理解し運用に向き合ってきた成果かと思います。
エンジニアを採用するか、自ら学習するか
ではシステムのあるべき姿やその実現方法を深く理解し、外注すべき状況でも丸投げせずに済むようにするには、一体どうすればいいでしょうか？
自社のITシステムを理解するのに必要な要素をものすごく単純化すると、「技術理解」と「業務理解」に分けられます。最初からこの2つを持っている人は少ないので、戦略としては「技術を理解している人に業務を教える」か、「業務を理解している人に技術を学んでもらう」かの二択になります。
前者を技術者の足りない会社でやろうとすると、エンジニアを社員として採用する必要があります。その人に業務知識をインプットした上で、外注プロジェクトをコントロールしてもらうわけです。しかし、この戦略には問題があります。それは、「そもそも技術理解が足りない会社が優秀なエンジニアを採用できるのか」という問題です。エンジニア採用市場において、自社に必要なエンジニア像を定義し採用プロセスの中でそれに合致しているかどうかを見極めるためにも、技術理解と業務理解の両方が必要になります。もしその採用自体を外注しようものなら、外注リスクを下げるために新たな外注リスクを抱え込むことになるでしょう。また、採用される側の視点として、「そもそも技術理解が足りないような会社に優秀なエンジニアが入社したいと思えるのか」という話もあります。いくら給料を吊り上げたところで、経営層が技術を理解していない会社で働き続けるのはエンジニアにとってはつらいことが多いです。これらの問題を突破する王道パターンは、「まず優秀なCIOやCTOを採用し、そこからエンジニア組織をつくっていく」というものです。（内製化の記事でも紹介したクレディセゾンCTO小野さんはまさにその動きをしているように見えます。）しかし優秀なCIO/CTO候補を見つけて口説くには一般的にかなり時間がかかるので、すぐに状況を改善するのは難しそうです。
ということで、必要ならエンジニア採用を進めつつも、現実的には「業務を理解している人に技術を学んでもらう」という活動を並行して進めることになります。
たとえば今回の記者会見で称賛を浴びた東証の横山CIOも、早稲田大学政治経済学部を卒業後に東証に入社されたようです。横山さんの経歴に関する公開情報は少ないですが、エンジニアとしてシステム開発に関わっていたというような情報はありませんでした。たとえば2012年に登壇されたイベントの講演者紹介は次の通りで、ガチガチの技術者であるような印象は受けません。
あらゆるクラスの投資家に多様な投資の機会を提供する東京証券取引所において、セカンダリマーケットに関わるマーケティング戦略の策定及び実行を統括している。
1986年4月、東京証券取引所に入所。ITビジネス部長を経て、2011年4月に営業本部設置と共に現職である執行役員マーケット営業部長に就任した。早大政経卒。
プログラミングやサーバー構築などに直接関わるなら話は別ですが、システム発注者側に求められる技術的な知識は範囲が限られます。社内に頼れる人がいなくても、ベースとなる知識を自習するすることはできます。その上で発注先のベンダー側に質問をぶつけ続けて知識を付けていけば、ベンダー側と対等に議論できるまでになるのは十分に可能だと思います。大切なのは、「ITのことはよくわからん」と匙を投げるのではなく、理解するのを諦めずに学習し続けることです。（それでも何から始めればいいかわからない場合は、僕にTwitter DMで相談してください。）
外注するときだけじゃない、システムを理解することの大切さ
今回メインで扱った経営レベルの話だけではなく、現場レベルであっても自分たちが使ってるサービスやシステムの中身を理解することは重要です。その主な意義は、次の記事に書いた通りです。
今回の記事で主に取り上げたリスク管理の観点でも、システム理解の重要性は同じです。システムの使用中にトラブルが起こったとき、その内部的な仕様やデータの扱われ方を理解していれば、自ら問題を切り分けて対処できるようになります。たとえばあるWebサービスが期待通りにデータを表示してくれないときにも、その原因は色々とあります。PCがインターネットにつながっていない、Webブラウザの挙動がおかしい、社内のネットワーク上で通信が遮断されている、データベース上のデータがおかしい、そもそもサーバーがダウンし応答を返していない、などなど。自分で原因を軽く調査し適切な対処ができるのであれば、問題解決までのスピードが早くなります。誰かに調査を依頼するにしても、問題の勘所を掴んだ上で適切な状況報告ができるようになります。システムを使う当事者であるあなたがシステムの中身を把握することで、業務が長時間止まってしまうリスクをなるべく避けることができるわけです。
あなたが今日からできる取り組みは、自分が業務の中で使っているシステムやサービスを1つ選んで、より深くその仕組みを学んでみることです。ドキュメントがあれば読んでみる。詳しい人が社内にいたら聞いてみる。そうして知識がついてくると、「もっとこういう運用はできないか？」などの提案ができるようになります。システムに対する不満を言語化して改善要望としてまとめられるようになるかもしれません。使いにくいシステムに愚痴を言うよりは、主体的にそのシステムの改善に関わる方が建設的です。1人でやり切るのが難しければ、社内勉強会を企画して仲間を集めることもできます。このように、あなた一人からでも変えられることはあるはずです。（もちろん、組織文化的にそれがどうしても難しければ、理解ある会社に転職するのも一つの選択です。そんなときも、システムを理解しようとした経験や得られた知識はきっと無駄にはなりません。）
なお、ITシステムの中身を理解するためには、そのシステム固有の知識だけではなく、「データベースとは？」、「冗長化とは？」、「HTTPとは？」、「JavaScriptとは？」といった汎用的なデジタルリテラシーがベースとして必要になります。そんなときは、『仕事を楽しくするデジタルリテラシー読本』という素晴らしいマガジンがあるのでぜひ定期購読してください。（宣伝）
実際に手を動かしながら実践的な内容が学べる「非エンジニアのためのエンジニアリング」というサイトもあります。（宣伝2）
以上！今回も楽しく仕事をするためのヒントが見つかったでしょうか？
ではまた来週。
ここから先は
仕事を楽しくするデジタルリテラシー読本
【初月無料】デジタル時代の歩き方について考えたことを発信します。ソフトウェアの時代とは何か。エンジニアの頭の中はどうなっているのか。NoC…
サポートをいただけると、喜びドリブンで発信量が増えます！初月無料のマガジン『仕事を楽しくするデジタルリテラシー読本』もおすすめです！