みずほ銀行システム統合、苦闘の19年史 史上最大のITプロジェクトを読んだが、正直どこでも起こり得るし、実際に業界の身近な会社でも似たようなことは起こっています。またもっと視野を広げるとシステム開発に限らず、専門性の強い意思決定を経営陣とコミュニケーション取れずに失敗することはままあります。組織論として感じたことをまとめてみました。
企業の大きさに限らず起こり得ること
まず読んで思ったのがこれって企業の規模に限らず、どこでも起こっていることだよなあということ。もちろん結果としての影響の規模は桁違いだし、金融インフラという起こった際のクリティカル度もかなり高い案件であることは間違いない。ただ問題自体は実は身近でよく起こっている。
学びたいところ
僕たちが普段やっているwebアプリケーションの開発でも頭に入れておきたいなあというところをまとめてみた。
船頭を多くしてしまうこと、組織の区切りについて
みずほは３行の合併でできた銀行で勘定系のシステムももちろん別々だった。最初それぞれにリーダーをたて３行が横連携する形だったがそれだと全体最適を考えて設計できない。
難しそうだなと思うのはポストの兼ね合いもあることで一つにまとめたほうがいいとわかっていてもまとめるとポストも減るわけで自分のポストがなくなるであろう人は反対するし、一つにまとめる際もどこがまとめるのかなど政治的な要因が強かったんだろうなと思う。権限をもっていて、ある程度皆からの支持がなくなっても自分の立場が危うくならない人間が強制的に組織を変えられないときつい。
なぜ無理なスケジュールを立ててしまうのか？
これはみずほで実際に起こっていたかどうかわからないけど多くの現場で起こるのが経営陣と現場で事態の重さの認識が違うところで特に
- 技術負債
- 技術的な難易度
この辺の認識を揃えるのは難しい。これはシステム開発に限らず専門家でない人間に専門的な話を説明するのは難しいなと思います。（別に経営陣が物分りが悪いと行っているわけではない。逆にエンジニアたちは経営のことをなかなか理解できない）特に難易度や負債は同じ領域の人間でもブレる。また、あまりにも消極的な提案をすると自分の評価が落ちるんじゃないかという不安にも駆られる。おそらく我々の業界でもよくあるのが経営陣の耳障りのいい楽観的な提案を技術の責任者がしてしまうや、そもそも技術の責任者に権限がそこまでない場合である。これだと非現実的な計画が建てられてしまう。
経営陣がすべての分野を把握するのは可能なのか？
じゃあ経営陣はシステムに限らず、すべての領域を把握していないといけなのかというとそれは違うと思う。というより現実的ではない。適切な人間に権限を与え、その人間が消極的な提案をしてもいいという心理的安全性が必要なんだと思う。
自分の居場所を守ろうとする人たちにどう対処をするか？
みずほのケースで言うと最初から３行のシステムを統合するわけではなく、残しつつつなげるという形式をとったらしい。これが会社にとってベストな判断としてされたならいいが、実際にはベンダーの富士通が第一勧銀と密接につながっており、第一勧銀が富士通のメインバンクだったらしい。つまりシステムの数を減らして富士通の売上が減ると自社のメインバンクの業績が悪くなってしまうという本来考慮に入れては行けない部分をいれてしまっていた。こういうもともとの仕事をなくして居場所がなくならないように必要じゃない仕事を残してしまうって会社で起きがちだよなあと思う。これに関しては現場で解決するのは難しく、経営陣による決定と配置換えが必要だろう。そして新しい仕事と居場所を用意するのが大切。その変化に社員が対応できない可能性があるがそれは努力が足らない、もしくはその会社に合わなくなったと判断すべき。
まとめ：心理的安全性と組織設計が大切
この本を読んで思ったのは組織の設計と心理的安全性の確保で組織設計は
- 船頭を一つに集中する
- 経営陣が意思決定するべきもの、現場が意思決定すべきことを間違わない
かなと。そして下記のために心理的安全性が必要
- 組織の構造が変わるときにポストや居場所が無くなる場合がある。その際にちゃんとセカンドチャンスを用意する
- 経営陣は専門分野の責任者に信頼を示し、消極的な提案をしても評価を下げず、信頼するということをちゃんと表明する
なのかなあ。自戒もこめて。
