Scribble at 2024-06-12 23:17:29 Last modified: 2024-06-13 13:01:50

いやぁ、出勤した帰りにジュンク堂の金融コーナーで見つけて買ってきたんだけど、システム開発してる者にとってはスラスラと読める内容で（おおよそ executive summary というレベルの水準で書かれているので）、ケース・スタディとしては有益だった。簡単に言えば、この手の大規模なシステム障害には多くの、そして異なる種類の問題があって、色々な経緯や原因で忍び込むことがあるため、やはりシステムを設計したり運用の手順を作る者にとっては、これまた色々な意味での視野狭窄がリスクとなるし、官公庁から指摘されたような事なかれ主義を始めとする社風だとかメンタリティについても、改める権限がないならないで、運用者や決裁権者がどう考えたり行動するかを分かったうえで、敢えて言えば「そういう人たち専用」のシステムや手順を作らないといけないのだ。

常々のこととして、またもや富士通が絡んでいる案件なのだが、もちろんこの場合は富士通だけの問題ではなかった。IBM やら NEC やら日立やら NTTDATA やら、国内で事業を展開する錚々たる SIer が揃って加わった案件だ。一次請けだけでも100社に近い（末端の下請けも含めると全体では1,000社を超える）巨大プロジェクトである。残念ながら炎上案件の常連であるアクセンチュアは入っていない。皮肉はともあれ、こうした、まさしく「IT ゼネコン」の名に相応しい JV のような状況で開発し、SOA などというお粗末なスローガンを振り回して出来上がったのが、MINORI という2019年に稼働を始めたシステムであった。本書は、この MINORI の開発・運用において起きた幾つもの問題を指摘し、システムだけではなく運用や監視、それから経営の問題にも踏み込んでいる。

僕は、いくら電通・博報堂案件のシステム開発に長らく携わってきたとは言っても、MINORI の規模の案件で設計や開発実務あるいは運用や監視を担当したことはない。したがって、この規模になると、そもそも勘定系の基幹システムという仕様そのものが多くの知見や経験を要するソフトウェア・アーキテクチャであるし、MINORI は SOA と称して機能ごとのシステムを別の SIer が開発し、それらを「疎結合」と呼ばれるネットワーク型のメッセージングで連結し連携させるようになっていた。これは、教科書的には一つのブロックで起きた問題が別のブロックに波及しないようなリスク対策を目的としているアーキテクチャなのだが、これまた教科書的な理解だとそこまでの浅い理解でしかシステムを設計できないという、ただの概念的なオモチャになるという欠点もある。そもそも、複数のシステムを疎だろうと密だろうと連携させている時点で影響がゼロで済むわけがないのだ。したがって、何を、どうやって、どこまで連携させるかという設計において、疎結合と密結合は区別されるだけなのであって、単純に別々のサーバで別々のシステムを実装すれば安全だなんていう発想をしていたのであれば、はっきり言って専門学校レベルのシステム設計である。もちろん、いくら何でもそういうことはないだろう。

あと、読んでいて気になるのが、もちろんサービスを提供するシステムなのであるから当然だと言われればそうかもしれないが、やはり「止める」という決断をどこかでするべきだろうと言いたい。これはもちろん頭取の責任であり、権限であり、要するに頭取はそのためだけにいると言ってもいい。今回の事案では、経営陣からコスト削減の圧力だけが命令されていて、そのせいでネットワーク・カードやストレージを減価償却の法定年数どころではない10年以上にわたって使い続けるような状況だったという。弊社のような大して利益の出ていない中小企業でも減価償却の法定年数を考えてパソコンなどを買い替えているというのに、少なくとも赤字ではない銀行でサービスの鍵となるシステムで設備の更新を怠るのは困る。

なお、第４章の金融庁による分析の話は、もちろんいまこうして書いているように部外者として眺めた場合の批評も必要ではあるけれど、或る意味では金融庁も日本の金融システムを担う銀行と同じコミュニティにいるわけなので、同じ程度にしかものごとを眺められないというリスクがあると思うんだよね。つまりは、金融屋だとか、勘定系システムしか知らない人に特有の偏見とか基準というものも、こういう事故の原因になっている可能性があるわけなので、やはり別の業界で監査しているところが見たほうがいいと思う。まぁ実際には、銀行の内部を金融庁でもない監査会社がどれほどの権限で見られるかという限界はあろうから、それはそれで別のリスクがあるんだろうけどね。もちろん、金融系の業務知識を十分に知らないことによるリスクもある。なので、金融庁と他の業界の監査機関とでチームを組むとか、そういうことも金融庁じたいが検討すべきではないかと思う。たとえばね、「コンプライアンス意識の不足」とか、「品質第一にせよ」とか、「事前の準備ができていない」とか、そんなもん専門学校の学生でも言えるんだよ。そうじゃなくて、銀行の勘定系システムの監視や状況判断だっていうのに、そもそもそれに IT を活用しておらず、上司に問題をエスカレーションするのに紙へ印刷して手渡すとか、おいおい、いまどき町工場でもそんなことしてねーよという話なんだよね。まぁ、単行本が今回の文庫本となった際に増補された内容では、いやぁ AI をだね、Splunk のログ解析サービスも一緒に導入してるらしいんだけどね（危機管理担当、河本氏の解説による。ちなみに親戚じゃないよ）、いやぁ大丈夫かな。Splunk って、いちおう海外企業だしねぇ。基幹系システムのログって、監査ログだけじゃないんだろうから、たとえばトランザクションのログだったりすると、扱い方によってはインサイダー取引にも活用できちゃうわけだし。