【「スゴ本」中の人が薦める】実際の炎上プロジェクトを通して学ぶ。ITエンジニアが修羅場をシミュレートできる3冊＋α

納期直前で致命的な不具合が発覚するとか、運用中に大きなトラブルに遭うといった状況で、リーダーやメンバーはどうすれば良いのか？ 実際に起きた炎上プロジェクトを通じて、修羅場をシミュレートできる本を3冊と報告書を1つ紹介する。

 

• keyboard_arrow_down はじめに
• keyboard_arrow_down プロジェクト初見殺し
• keyboard_arrow_down 最初にすべきこと：リカバリープランの策定
• keyboard_arrow_down お客の反応（否定、怒り、懐疑）にどう対応するか
• keyboard_arrow_down 「やらないこと」を決める
• keyboard_arrow_down みずほ勘定系基幹システムMINORIに見る修羅場
• keyboard_arrow_down 2021年2月のATMシステム障害の原因
• keyboard_arrow_down おわりに

ITエンジニアにとって、修羅場は「憑き物」だ。

誤字ではない。トラブルは付いて回るというより、憑いてくる。

納期直前になって致命的な不具合が発覚したり、システムのバグで業務運用がストップして報道されたりする大炎上から、そのドミノ倒しの発端となる些細なボヤまで、必ず、何かしら起きる。

「全てのタスクが遅滞なく進められ、問題が一切発生せず、完璧なリリースを迎える」なんてプロジェクトは存在しない。あるとするならば、そのプロジェクト自体を疑ったほうがいい。異常系テストをせず、運用フェーズでトラブルが多発するのがオチである（ソースは私）。

しかも、自分のせいではないトラブルがほとんどだ。

原因を紐解いていくと、安請け合いして勝手に納期を短縮する営業担当とか、前年比10％コスト削減という根拠のない押し付けをしてくる発注元とか、仕様書はないくせに変更だけ要求してくる担当とか、「バグにペナルティを課せば品質上がるんじゃね？」とかトチ狂ったことを言いだすPMとか、枚挙にいとまがない。

そういう輩が蒔いた火種がすくすくと成長し、思いもよらないところで炎上する。

しかも、こうした因果関係が見えてくるのは、全てが終わった後である。

諸悪の根源だったコンサルは契約満期でドロンしており、発注元と社内の両方に嘘八千を並べた営業は出てこなくなり、メンバーを鬱に追いやったリーダーはいつのまにかいなくなっている。そして誰もいなくなり、「どうしてこうなった」という思いを抱えた人だけが残される。

こうしたトラブルに対し、一人のエンジニアでやれることは限られている。

そういうヤバそうな修羅場プロジェクトから距離を置き、近寄らないようにする？

無駄である。なぜなら、いま働いている現場が、現場ごと巻き込まれるから。知らない間に決まっており、「決まったよ」という結果だけが伝えられる。上司の囁き「ちょっと2週間くらい応援に行ってくれ」で否応なしに火消しに行かされる（そして2週間で終わった試しがない）。

では、どうすればよいか？

そうした修羅場で何を見て、どう考え、どのように行動すればよいのか。「こうすれば必ず上手くいく」という処方箋は、もちろんない。だけど、「こうすると上手くいくことが多かった」という経験則みたいなものは、確かにある。

ただし、そうした経験則は、公に言語化されていない場合が多い。

通常は、炎上プロジェクトに投げ込まれた先で酷い目に遭いながら身につけるのがほとんどだ。運が良ければ、客先で激詰めされる先輩の受け答えを聞いたり、デスマーチを生き抜いたリーダーから心得集を渡されて、初めて「解決法にはセオリーがある」ことに気づく。

逆に、こうした予備知識やセオリーを知らないと、まず間違いなく大ダメージを喰らう。初見殺しと言っていい。「実体験で身につけろ」と言ってくる先輩もいるかもしれないが、耳を貸さなくていい。心や身体を壊したら元も子もないからだ。

「愚者は経験に学び、賢者は歴史に学ぶ」というビスマルクの言葉に従って、初見殺しの予備知識は、書籍で学ぼう。炎上プロジェクトで何が起きているのか、どうすればマシな方向に進めるのか、そして最も重要な、どうやって生き延びるのかが書いてある。

この記事を、修羅場の歩き方、いわば修羅場シミュレーターだと思って読んでほしい。

修羅場に投げ込まれたとき、最初にすべきことは何か？

目の前の火を消すこと。火元を探し出すこと。延焼を防ぎ、影響を最小限にすること。そもそもなぜ燃えているかを調べること。どれも合っているのだが、それらをするために、真っ先にすべきことがある。

状況を調べ、リカバリープランを策定することだ。

絶賛炎上しているのだから、スケジュール通りに行っていないだろう。品質はボロボロか、もしくは品質がどうなっているのかすら把握できていないだろう。だから、プロジェクトを立て直すために追加コストがどれくらいになるのか、答えられない。

答えられないのであれば、発注側である客も判断がつかない。

どんな判断かというと、スケジュールありきでサービスや機能を切り詰めてもカットオーバーを死守するのか、動くレベルまで品質を上げることに注力するのか、あるいはそれまでに突っ込んだ予算はサンクコストとして切り捨て、仕切り直しするのか、判断できない。

状況が分からないから判断がつかない、判断できないから打ち手がない。打ち手がないからリカバリーできない……といった悪循環に陥る。

これを打破するために、最初に状況を調べてリカバリープランを策定する必要がある。個々の火消しは、その方針に沿って進めればよい（というか、リソースが限られているからそうするしかない）。

この、リカバリーマネジメントに特化したのが、『問題プロジェクトの火消し術』（長尾清一、日経BP）になる。

『問題プロジェクトの火消し術』長尾清一、日経BP

「火を消せ」と怒り狂う客を相手に、どうやって状況調査の承認を得るのか。問題を特定するための仮説検証とは何か。ユーザー側にリカバリープランを承認させるためのハードルと乗り越え方は何か……などなど、生々しいネタが詰まっている。

本書が優れているのは、具体的にどのように話を持っていけばよいかが、そのまま書かれているところだ。

例えば、悪いニュースを早めに小出しに報告する「フット・イン・ザ・ドア」のテクニックだ。

初期診断で現場の✕✕がおかしいので、本質的に何がおかしいのか、原因は何か、アクションは必要なのかを検討するための調査が必要です。調査によって解決策は必ず見つかります。

ユーザー側は、問題の否定、怒り、懐疑など、様々な反応を示すだろう。

「何やってたんだ！ 今まで順調だと報告されていたのに！」「すぐに問題を解決しろ！納期は守れるんでしょうね？」「君たちの問題でしょ、面倒なことに巻き込まないでほしい」など、読んでるこっちの胃が痛くなるようなセリフが並んでいる。

そして、ユーザー側のそれぞれの反応に対し、使うべきセリフ・手法が紹介されている。私も使わせてもらったキラーワードがこれだ。

・目の前のトラブルだけを対症療法的にモグラ叩きしても、根本原因を取り除かない限り、問題はなくならず、結局同じ現象の繰り返しになります
・問題の本質を特定しないと状況は一層悪化し、結果的にシステム導入の本来の目的を満たせないことになりかねません
・（いったんユーザの怒りを受け止めた上で）これ以上の遅れを出さないためにも、先入観で問題を決めるのではなく、調査をした上で、対策を検討する必要があります
・どちらの責任といった犯人探しではなく、お互いが満足する結果に導くために、ぜひご協力ください

修羅場一日目から使えるのはこれ。

考えられる原因としては、①バグ、②設計ミス、③スキル不足、④仕様上の解釈の相違、⑤お客様からの仕様変更、⑥予期せぬリスクの顕在化がありますが、④⑤⑥は当社だけで原因を特定し、解決策を導くことができません。お客様との共同作業が必要になるため、どうかご協力をお願いします。

お客を巻き込まない限り、プロジェクトのリカバリーはおぼつかない。それを理解してもらうためのセリフだ（私は、ホワイトボードに書き出しながら説明したことがある）。

首尾よく調査に取り掛かり、問題の本質を見極めたとしよう。では、リカバリープランを策定するために次は何をすれば良いのか。もちろんお客だけでなく、社内での合意も必要になる。

まず、対策の優先順位をつける基準を決め、スケジュール、コスト、品質、リソースのバランスを取りながら要件を絞り込んでいく。

リカバリープランで最も重要なことがある。修羅場を潜り抜けてきた人は口を揃えて言うが、『プロジェクトのトラブル解決大全』（木部智之、KADOKAWA）に最もシンプルに書いてある。

リカバリープランで必ずやるべきことは、「やらないことを決める」です。

『プロジェクトのトラブル解決大全』木部智之、KADOKAWA

これ、超重要なのだが、できないリーダーがいる。プロジェクトが炎上している時点で、すでに時間と予算というリソースは費やされている。だから、何かを犠牲にしなければゴールまで辿り着けないことは確定している。

にも関わらず、「上層部の意向で」とか「すべて最優先にせよとのお達し」という理由で無理なプラン吞んでしまうPMがいる（その時点でリカバリーの失敗が確定する）。

「これはやらない」の「これ」を決めるのは、リーダーの仕事だ。リーダーが「ノー」というときに、プロジェクトが前に進むのだ。

とはいえ、「やること」「やらないこと」を、リーダーが勝手に決めていいわけではない。もちろん整理して合意を取る必要があるのだが、そのための方法が『解決大全』に書いてある。

やるべきタスクを重要度で並べる。これは何が何でも並べよという。「〇〇と△△は同じぐらい重要」なんてものはない。「これが実現しなければサービスインできない機能はどれか？」や「それはクリティカルパス上にある火種なのか？」といった質問を投げながら並べる。

これは、客先でも社内調整でも同様だ。それぞれに事情があるのは百も承知で、その事情も加味して順位を付ければいい。重要なのは、順番をつけることなのだから。

その上で、下位10％をバッサリと切り落とす。そして、残ったものを、いつ実現し、どの順番に着手するかの検討を始めるのだ。

ここまで、火事場プロジェクトの歩き方を紹介してきた。

今度は、そうした修羅場を「外側」から見てみよう。経営層がどのようにプロジェクトを把握しており（あるいは把握しておらず）、それが「内側」の現場に、どのような悪影響となるのか。

その最高の教材が、MINORI（みずほ勘定系基幹システム）になる。

4,000億円という巨費を投じて、富士通、日立製作所、日本IBM、NTTデータを筆頭に1,000社のSIerを巻き込み、8年かけて要件定義から設計開発・テストを進め、2年かけて移行した。東京スカイツリーが7本建つ、別名「IT業界のサグラダファミリア」だ。

このプロジェクトを「外側」からレポートしたのが、『みずほ銀行システム統合　苦闘の19年史』（日経コンピュータほか、日経BP）である。

『みずほ銀行システム統合　苦闘の19年史』日経コンピュータほか、日経BP

みずほFG（ファイナンシャルグループ）は、第一勧業銀行、富士銀行、日本興業銀行の3行を統合させたグループとなる。各行バラバラだったシステムを刷新し、勘定系システムを一本化することは発足以来の悲願だった。

グループ発足からMINORI運用まで、足かけ19年かかったことになる。なぜ、これほどまでに長引いたのか、そして何度も絶望的と報道されながらも、どうやって成功まで導いたのかをレポートしたのが本書になる。

基本的に、日経コンピュータの取材による記事をまとめたものになる。インタビュー先は「発注側の」広報や経営層のため、プロジェクトの現場は見えない。

もちろん、PMやリーダー格へのヒアリングもあるけれど、広報がしっかり隣席していると思われるので、めったなことは言えないだろうし書いていない。総じて「大変だったけど頑張りました」という苦労話に終始している。

それでも、これだけ巨大だと、修羅場の火種（というより爆薬）は、部屋の中の象のようにはっきり見える。

例えば、統合方式について。統合する「母体」となる主なシステムは、以下の3つになる。

・みずほ銀行の勘定系システム「STEPS」
・みずほコーポレート銀行の「C-base」
・みずほ信託銀行「BEST」

普通ならこの場合、「片寄せ」になる。どれか一つのシステムに「寄せて」統合させることで、開発コストや移行リスクを下げようとする。ところがMINORIは、旧システムから一切を引き継がず、一からつくり直す完全な新規開発だったという。

旧行のパワーバランスを取るための政治的判断とされているが、修羅の道であることがどれだけ認知されていたかは、書かれていない。

容易に想像がつくが、要件定義が難航することになる。母体となるシステムをつくった人はおらず、そのシステム要件や設計書もメンテされているか覚束ない。「あるものが全て」「今の動作が仕様」という状態だ。

そして、普通なら、今あるものから要件をリバースしようとするだろう。なぜなら、それが「正しい」のだから。今まさに動いている業務フローや手順書、残された仕様書をかき集め、現状把握から始めるのがセオリーだ。

しかし、経営層からストップがかかる。「アズイズ（As-is）の全面禁止」である。現状を把握して、「あるべき姿（To-be）」とのギャップを埋めるやり方を捨てている。

理由は、「アズイズ」という言葉が独り歩きし、ユーザ部門が「現状のままで良い」、「業務を変えずにシステムで効率化してくれ」という要求を押し付けるために使われるようになることを恐れたからだ。現在の業務をろくに調べもせず、「アズイズでよろしく」――これを変えるため、アズイズを全面禁止にする。

代わりに、ユーザー部門に、最初から「あるべき姿」を考えよという命令が出される。

銀行業務を棚卸して、あるべきフローを描かせる。そうすることで、なぜその業務を行っているかを考え、全体の中での位置づけを検討するようになる。「前からやってたから」「そう引き継がれたから」という発想から離れ、「そもそもその業務は何なのか」と考えさせるための、アズイズ禁止令なのだ。

そして、これも容易に想像がつくが、要件定義が難航する。

あたりまえだ。現業に詳しい人、すなわち実務者が、どんな要件が「あるべき」かなんて分からないだろう。「考えろ」と命令されたって、一朝一夕に身につくものではない。

そこに、「あるべき」を謳うプロ集団・コンサルタントファームが入ってくる。かくしてユーザ部門＋コンサル集団のプロジェクトチームが出来上がる。そこで「要件定義」と称して、1年くらいかけて出力されるのは、何ら具体性のない「あるべき姿」になる。

要件に落とし込めていないため、「これをどうやって設計しろと？」という問答が繰り返されることになる。「あるべき業務フロー」になっているかもしれないが、それを担う部門は現実に存在しない（なぜなら理想像だから）。結果、そのフローを実施するユーザ権限の設計もできない……などなど、想像したくないことが現実になる。

さらに、想像せずとも分かるのだが、プロジェクトの終了日は契約上決まっているため、真ん中にある、設計・実装・テストの期間がすり潰されることになる。メンバーは走りながら要件を詰め、締め切りに追われながら実装することになる。結果、要件定義は後出しでどんどん積み上がり、最初に想定した量を大幅に上回ることとなる。

そして、プロジェクトの最後の部分に一番のシワ寄せがくる。すなわち全部をつなげて実機レベルで動作確認するテストだ。システムテストとか統合テストとか呼ばれているところだ。そこで出た不具合（たいていは性能問題）はシステムにとって致命的なため、先送りできず、何がなんでも解決しようとするはずだ。

結果、問題をクリアするための様々なリスクに目をつぶることになる。上述したリカバリープランの中で、「カットオーバーに必達ではないが、いずれ必ず解決しなければならない問題」が積み上がる。バックログの山である。

2021年2月28日に起きた、ATMにカードや通帳が取り込まれてしまう障害については記憶に新しい。

調査報告書によると、直接的な原因は、取引情報を保存しておくメモリ上のINDEX FILEの使用率が100％となったためとある。

システム障害特別調査委員会の調査報告書の受領について

『システム障害特別調査委員会の調査報告書』みずほファイナンシャルグループ、2021年6月15日 公表

ITエンジニアなら「オンメモリにするなら、きちんと容量計算をしてキャパシティを確保しておかないと」と考えるだろう。しかし、このINDEXは元々メモリに常駐しないファイルだったとある。

ところが、2017年11月にオンメモリにするよう、仕様が変更されている。

当時は性能試験の真っ只中で、定期預金システムのバッチ処理が予定時刻を突き抜けてしまい、翌日の業務に影響をきたす問題に直面していた。この手の処理は、たいてい夜半に処理を始めて、翌日の営業時間が始まるまでに終了させておく必要がある。

ところが、予想外に処理時間を必要としたため、業務を始められないことになる。これは非常にマズい。マシン性能の見積りは実施して、必要なキャパシティを積んでいるだろうが、後出しで積み上げられた要件が、性能問題として見えるようになったと考えられる。

時期は検収試験（ユーザー部門が主体で行う受入テスト）。本番業務に耐えられる品質かを担保するために、本番と同等のテスト環境を構築し、一連の業務を通しで行うテストだ。スケジュールの後がないし、ここまで来れば「待ったなし」の状況で、何がなんでも解決する必要がある。

そこで、業務で使うテーブルをメモリに常駐させることが提案される。

時期的に、マシンを新調する時間的余裕はないだろうから、これが妥当だと考えられる。提案は11月17日の性能WG（ワーキンググループ）で採択される。目の前の性能問題はクリアされることになるが、メモリ設計の問題は放置されることになる――5年後の2月28日になるまで。

メモリ設計の問題は氷山の一角だ。だが、修羅場がどのように生み出され、それがどうやって燃え上がり、爆発するかの好例となっている。

以上、修羅場をシミュレートする3冊＋アルファを紹介した。

『問題プロジェクトの火消し術』はリカバリーするために何が必要で、どうやって話を持っていけばよいかが、具体的に書いてある。そのまま使える言葉がゴシック体で強調表示されているため、なんならメールにコピペして使えるくらい生々しい。

『プロジェクトのトラブル解決大全』は修羅場でどう動けばよいのかがまとめられている。いわゆる「正解」があるというより、上手く動けるPMは、たいていこんな言動を取るという、ベストプラクティス集だと思えばいい。

『みずほ銀行システム統合』は、修羅場まっしぐらのアンチパターン集としてお薦めする。ここでは、「片寄せしないシステム統合」と「現状把握の禁止令」の2例しか紹介していないが、あなたが読めば、もっと出てくるに違いない。その答え合わせは、上述のシステム障害の報告書や、これから発生するトラブル報告から知ることができる。

これらを読みながら、「自分ならどう動く・話すだろう？」と考えると良いかも。できうることなら、一生涯、そんな目に遭いたくないものの、来るべき本番に備えて、予習だけはしておこう。経験で学んでいたら、命がいくつあっても足りない。初見殺しは、過去の修羅場で学ぼう。

次のプロジェクトの生存率を上げるために。