SIerで大規模案件にも携わってきた私が、みずほ銀行の苦闘を読んで改めて感じたこと

話題の書籍を読んだ。

システム開発に携わるエンジニアであれば、誰しもが知っているあのサクラダファミリアの裏話だ。

結論から言うと、一度でも金融機関を利用したことがある国民にとっては非常に身近なことで、裏話どころか実際に起きているノンフィクション事件であるのだから、そこらへんのアクション映画よりよっぽどスリルを味わえるストーリーだった。

この本を読み終えるまで、ワクワクとヒヤヒヤと、心臓に悪そうなドキドキでしばらく色々な考えが頭を巡った。私自身が感じてきた課題感だとか、それを解決したかったけれど難しかった状況だとかを思い出させられる。

本の内容をすべて書き出したいくらいにアドレナリンが放出される書籍だったけれど、（著作権的な問題で）そんなわけにもいかないので、今回は本を通して私が改めて感じたことを整理して共有したい。

システム障害とIT投資への決断

みずほ銀行は、2度の大規模システム障害を経て、ついにIT投資への決断に至ったという。（もちろん、システム障害が起きる前から既存システムの刷新プロジェクトは走っていたかと思うけれど、その進め方を大々的に見直すきっかけという意味での障害発生だった。）

これは銀行に限ったことでなく、大企業やステークホルダーの多い大規模な開発現場で起こりがちな問題といえる。

• システムの老朽化や人員の入れ替えにより引き継がれなかった課題が数年単位で後になって発覚する
• システム障害対応は初動が命だが、担当役員に深い知見がないために適切な判断ができない
• 何かが起こってしまってからでは遅いが、何かが起きなければ予算がおりない

本書の中で何度も繰り返し出てきた「四千億円を超えるシステムの再編成」という事実。このコストが適正であるかどうかは正直わからないけれど、金融機関の勘定システムは、それくらかけてでも失敗させてはならない業務システムの1つであることは間違いなさそうだ。

あるべき業務フローを考える

みずほ銀行が新システムにリニューアルしていくにあたって、大事にしたのは「要件定義はAsIsではなく、あるべき業務フローにフォーカス」したことらしい。

これは、大規模になればなるほど、運用関係者が多くなればなるほどムズカシイことだと思うので、ナイス決断だな〜と感心してしまう。

本書の中でも、「劇薬のスパルタ式要件定義に踏み切った」と振り返られている。

• 関係企業間で用語の認識統一をする
• 非システム部門にもシステムに関する教育を実施し、なるべく同じ目線で仕様検討できるようにする
• 上流工程で要件定義する際、現状のシステム仕様を踏襲しようとする考えを禁じる（思考が停止してしまうから）
• つながりの大きい処理をなるべく分割してコンポーネント化していく方向性で考える

用語の統一から行うのはまさに関係者が多いプロジェクトでは必須であるし、ドメイン設計をする上で非常に重要な要素だと思う。
実際に私も新規プロジェクトを進めるときは決まって用語のすり合わせを行うフェーズを設ける。

みずほ銀行も例外なく、未来の振込処理ひとつとってみても、「予約取引」という銀行もあれば「先日付」という銀行もあったなど、同じ処理に違う定義を使っている状況が多々あったようだ。

大規模開発の効率化手法

このシステム刷新に際して活用されたのは、いわゆるエンジニアがごりごりソースコードをプログラミングしていく開発ではなく、富士通などの大手SIerがもつ自動ソースコード生成システムのようなものだったという。

あるルールに沿って数式や日本語で記述すると、アプリケーションのソースコードを自動生成でき、テスト仕様書も吐き出してくれるらしい。

• 誰が使っても同じ構成のソースコードにすることで属人化を防ぐ
• ツールで生成された仕様書やツールを手動で調整しない
• ツールで思い通りにならない場合、上流工程での仕様そのものに無茶があるという前提で疑い設計を改善する

プログラミング好きなエンジニアからしたら、「コードが書けない」ことを理由に転職したくなってしまいそうな話ではあるが、これもまたひとつの正解なのかもしれない。生成されたコードの良し悪しより、銀行の顧客が不利益を被らない最善策でエンジニアリングしなければならないシーンは時として多いし正しい。

品質管理とリスクヘッジ

大規模開発、特に金融機関におけるシステム開発には、品質管理の工程が不可欠だ。開発をしている工程より、テスト工程のほうがずっと長いことは珍しくない。

実際、みずほ銀行のサクラダファミリアと呼ばれたこのシステムでも、詳細設計〜製造までが約半年のスケジュールだったのに対し、総合テストや移行リハーサルが3年以上に及んでいる。

• 品質管理の監査部門を適切に機能させる
• 実際の業務フローに即したリハーサルの実施
• 負荷テストなど、正常系だけではなく異常事態発生時のマニュアル準備

みずほ銀行は、3.11の震災直後に義援金が殺到したことを引き金にして大規模システム障害が発生している。この時、システムの完全復旧までに10日もかかってしまった背景には異常系発生時の回避マニュアル（手動での運用手順など）が用意されていなかったことによる人的ミス多発などがあったらしい。

当時、いくつかの銀行統合などで監査部門が各銀行で分かれてしまっていたり、情シスの担当者が銀行間でコミュニケーションできていなかったなどの要因もあるらしく、いかにシステムに関する横の情報連携が大事か考えさせられる。

コミュニケーションとモチベーション維持の密接な関係

大規模プロジェクトでありがちなことの一つとして、「自分が一体どこの何を作らされているのかわからない、だからつまらない」というモチベーション低下がチーム内に蔓延するということがあると思う。

それこそプロジェクトマネージャーの腕が鳴る場面でもあるわけだけれど、ここまでステークホルダーの多い（関わったベンダーは1000社にもなるらしい）プロジェクトでは1人が頑張ったところで何が変わるわけでもなかったりする。

• プロジェクト名をきちんと名付け、決起会を実施する
• 大規模人数の会議では発言しやすいよう、質問を聞く時間で「長い間」をおくようにする
• チームを横断的に管理する組織（PMO）を設ける
• 開発チームから上流に相談や提案した課題に対しなるべく早く対策し、「ここで話せばやってくれる」という成功体験を積ませる

あまり本質ではないように思えるし、現代の効率化・省エネ社会では「決起会」みたいなことを嫌う風潮もあるけれど、こういった大規模プロジェクトでは横のつながりを意識する意味で人同士の交流は欠かせない。

みずほ銀行の新システム「MINORI」の開発プロジェクトは通称「三の二」と呼ばれていたらしい。こういった統一的に会話で交わされるプロジェクト名称は意外と重要で、同じ目標を見て今進んでいる！ことを体感するひとつの手法なのだと思う。（なぜ「三の二」なのかは書籍を読んでほしい）

そういった古臭いと思えるような仕組みにも、大事なことがいっぱい詰まってるし、でないと日本の生活インフラになり得るITシステムはこんなに発展していないだろう。

ミクロだけではなくマクロも

ちょっと興奮冷めやまず、といった感じでここまで感想を書き殴ってしまう形になったけれど、一言でまとめるならば「社会を動かすプロジェクトってめちゃくちゃカッコイイ」というゾクゾクした気持ち。

みずほ銀行と、書籍の出版関係者にはこうして公開してくれたことに感謝したい。自分では経験できないこのようなプロジェクトを本を通して擬似体験できるって素晴らしいことだなと思う。

個人的にも、元々はSIerにいて金融や証券といった数百人月という規模の開発に関わってきたことがあったので、その時に感じていた課題感とか、大規模プロジェクトでの難しさとか、それを解決したかった気持ちを思い出すことができた。

今の私は、どちらかというとベンチャーや小規模なチームでの開発をメインにしているけれど、最終着地点としてはまた大規模開発に携わりたいと思っているし、今の経験で得られている「小さく回していくコツ」みたいなものをヒントにしてSIerに持ち帰っていきたいとも思う。

自分の身近なことから、ミクロに考えることも大事だけれど、せっかくならもっともっと大きな視野でエンジニアリングしていきたい。

今日もどこかで、私たちの生活インフラを支える巨大なシステム開発が進められている。