野次馬的に気になったので読んだのですが、とても良かった。日本のITに携わる方は読んだ方がいいと思う。

正直この本の評価は分かれると思うのですよ。
現場のドタバタ感を生々しく記述するものではなく、主にみずほ銀行システム統合プロジェクトの経営層の責任とガバナンスや進め方といった、超上流の部分を切り取ったものでなんです。

でもその部分の欠落がソフトウェア開発とその後の運用で大きなトラブルを巻き起こすんだよ、という観点で見ると、あるある話の集大成になってます。

Melissa Perri の Escaping the Build Trap のアンチパターンとして読むとわかりやすい。ぜひ事例として取り上げてほしい。

現場のドタバタって結局上流がうまくいってないからドタバタすることが多いですよね。
そういう観点で見ると、避けるべき教訓がたくさん詰まっている。
みずほだけじゃないです。あちらこちらで同じことが起こっているけれども、たまたま問題が大きく表面化したのがみずほなんです。

本の構成としては最初に2012年以降の仕切り直しの進め方がどうだったかという話があり、次に2011年の東日本大震災の義援金振り込み集中によるシステムトラブル、次が1999年の銀行の統合時のシステム統合の顛末を説明しています。

が、ここでは時系列にあるある話を抜き出して思い出語りをしてみたいと思います。

2002/4、銀行統合時のシステムトラブルまでの経緯

そもそもビジネス部分がおかしかった。
本に書かれている戦略コンサルティング会社のコメントを引用。

米国でいくつも銀行合併を手伝ったが、今回は初めてのケースだ。なぜ統合するかという戦略が決まっていないからだ。

銀行統合の記者会見では「既存システムの統合で節約した分で戦略的なIT投資」と素晴らしいことを言っているのですが、本の内容からは今の組織のここに無駄があるから、どう統合するとこう無駄が省けるよ、という点がどうもなかったようなんですよね。
純粋に一つのシステムをより大人数で使ったら節約だよね? というノリかもしれません。

これで思い出すのが「デジタルトランスフォーメーションプロジェクト」。

デジタルトランスフォーメーションプロジェクトの支援に入った時に、何がどうなればこのデジタルトランスフォーメーションプロジェクトが成功なのかとお伺いするのですが、出てこないことが多い。
「サイロが」とか「組織の無駄を省いて」とか「働き方が」というキーワードは担当者から出てくるんですが、「今のままでは何がどうボトルネックになっているから、これこれを導入することでこういうことができる組織を目指したいんだ」というビジョンがないんです。

ビジョンがない場合と、ビジョンはあるが担当者に伝わっていない場合とがあります。

いずれにしてもこの場合

デジタルトランスフォーメーション = これこれの導入

になって、これこれを導入することが目的になってしまう。
結果としてボトルネックは新しいシステムの方にも移行されてしまい、結果デジタルトランスフォーメーション効果なかったね、という話になってしまう。

みずほの場合も統合のビジョンや統合後のビジネスモデルのビジョンがなかったか現場に共有されていなかったので、システム統合の方針策定では各銀行の持っている既存システムの機能的な比較になり、「とりあえずパッチ的につなぐ」という選択肢にならざるを得なかった。
結果的にビジネスモデルの不明瞭な部分によりソフトウェア開発が右往左往して品質の高いソフトウェアが作れなかったことが描かれています。

SI同士の機能比較バトルのやり取りがすごくリアルでした。こういうミーティング出たなあ〜と感慨深かったです。

2011/3 東日本大震災義援金

技術的負債により複雑化したシステム、すでにいろんなところがブラックボックス化しており、「理屈はわからないけど動いてるからいいよね」状態になった時にキャパシティを超えるようなシステム負荷がかかった時の典型的トラブルの話。

動いている既存機能の仕組みがわからないことのリスクが考えられていなかったというのはやっぱりあるある話。

思い出すのは、
- パーツパーツで言えばわかってる人いるけど、これが組み合わさったシステム全体を見ている人いなかったよね?
- エラー発生した時の処理プロセスがなかったよね?

システム全体を見ている人いなかったよね問題

支援にお伺いして、機能単位だったりパッケージ単位の要件定義資料や設計書が出て来ることは多いけれど、システム全体、あるいはシステム同士が連携するなら連携の全体像の資料があることはあまり多くないです。
お伺いするとその場でホワイトボードで描いてくださることはあります。

ただ、このホワイトボードに描ける人が抜けると一気に全体像がブラックボックス化するんですよね。意外と資料が残っていません。
最終的にパーツのパラメータの話はできるけれど、「このAのシステムでこう入力したものをBで処理されてCに連携されたあと、Cで誰が何の目的のためにどういう使い方をするの?」に答えられる人が意外といないという状態になります。

エラー発生した時の処理プロセスがない問題

特に思い出すのはリリーストラブルの再発防止策の支援に入った時のこと。

リリースパッケージの本番適用時にトラブルが発生したので改善策の一つとして、パッケージ適用時にトラブルが発生した時のロールバックを考えてパッケージ作成をするべきだ、パッケージは要件までトレースできるようにするとリリースパッケージのトラブルの特定がしやすくなるしパッケージの内容も取捨選択しやすくなるので、ガバナンス強化した方が良いですよという話をした時だったと思いますが、本番適用前にパッケージ検証して望むから問題ないとコメントをいただきました。

まさにそこでエラーが発生してどの単位でトラブルが発生しているかわからなかったから大事になってお伺いしたはずでした。

そのほかにも運用に入ってから、サーバートラブルで起こる可能性のある現象が想定されていなくて、トラブルシューティング手順とエスカレーション手順が確立していなかったのでトラブルと認識されるまでに1週間近くかかったケースがありました。
その間ユーザーはエラーを見ながら騙し騙し使っていたのでした。

どれだけ検証してもシステムはトラブルが発生するものなので、発生しない！と言い切ってしまうのはNGだと思ってます。

2012年の仕切り直し

ここではいくつかすごいなと思ったやり方がありました。

- あるべき業務フローをユーザー部門に考えさせた
- 手厚いトレーニングと定着支援
- (2011年の顛末の最後として書いてありましたが) システム横断的なデータフロー図を作成した

あるべき業務フローをユーザー部門に考えさせた点が特に印象的で、これなかなかできないんですよね。
ビジネスプロセスリエンジニアリングのやり方として採用したのだと思います。

あるべき業務フローを考えさせなくてそのまま新システムに載せてしまったので、ボトルネックもそのまま移行されてしまったという失敗はどこでもやってます。
意外と業務フロー考えるって難しいらしく、「そもそもこの手順って何のためにやってるんだっけ?」がわからないままになっている業務って意外と多いようです。
なので要件と言われると、ユーザー部門の方々は今のアプリケーションのUIの使い方説明してくださるんですよね。
そのまま実装するとボトルネックがそのまま移行されてしまう。

やり方としてみずほのやり方はうまいなあと思いました。

まとめ

そのほかにも (パーツごとのプロジェクトマネジメント以外に) 全体の進捗を管理するプロジェクトマネージャーが必要だとか、さまざまな課題が書いてあり、上流の「しくじり先生」としてはいい教科書だと思います。

本のスタンスとして印象的だったのが、経営陣の問題だと言い切ったこと。

2011/3の経緯の締めくくりの文言が印象に残ってます。

みずほに限らず、経営トップにわかる言葉で話ができないなど、システム部門に問題があることは否めない。しかし、システム部門が何を言っているのか分からないのであれば、分かるように話すようにシステム部門を指導し、改革をするのは経営トップの任務である。

システム開発により課題が解決されなかったり、課題が出てしまうケースで、開発チームの外側にある責任って意外とあるんだよということがもっと認知されるといいなあ。