DX(デジタルトランスフォーメーション)推進コンサルティング 株式会社アイ・ティ・イノベーション

新年明けましておめでとうございます！　　　　　　　　＜　前回　｜　目次　｜　次回　＞

年末年始には、去る年を振り返り、新年の抱負を考えるのが常です。プロジェクトマネジメントでも、過去に起きた失敗事例を振り返り、次のプロジェクトに備えるリスク・マネジメントが最も大事だということは言うまでもありません。

さて、今回は特に大規模プロジェクトをコントロールする上で気を付けなければいけない勘所を、何度も映画化されるほど有名なタイタニックの沈没という失敗事例と重ねながら考察してみたいと思います。（※１）

【　タイタニック沈没のストーリー　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
まずは、簡単にタイタニックの沈没事故を振り返ります。ここではあまり細かな事実というよりは、だれもが知っているような映画のストーリー程度です。でも、その中にもよくよく考えれば、大規模プロジェクトのコントロールのポイントが読み取れるのです！

タイタニック沈没のストーリー（ウィキペディアなどを参考に要約）

＜氷山との接触＞
当時史上最大級であった豪華客船タイタニックの処女航海中、見張り員が巨大な氷山の姿を発見。航海士は衝突回避を試みたが、氷山の横を擦るように衝突してしまう。タイタニックの船底は二重底になっており、船体も防水隔壁で16の区画に区分され、たとえ浸水しても簡単には沈没しない「不沈船」のはずだった。衝突の衝撃は船の上部では小さかったため被害が少ないと思われたが、衝突の衝撃により船体を接合するリベット（金ネジのようなもの）が広い範囲で抜け落ち、その結果生じた隙間から海水が浸水し、結果的には沈没に至る。

＜沈没船からの非難＞
沈没が差し迫ったタイタニックでは、乗客を救命ボートに乗せて避難をし始めたものの、そもそも定員分の救命ボートを備えておらず、船上はパニック状態と化してしまう。避難誘導の要領も悪く、定員の半数も満たないまま降ろした救命ボートもあり、結局1500名近い乗員乗客が取り残されたまま沈没。

＜沈没後の救助活動＞
定員に満ちていない救命ボートもあり、すぐに助けに向かえば多くの命を救える可能性は残されていた。しかし、助けに行くと多くの生存者がボートにしがみついてボートが転覆することを恐れたため、たった1艘しか救助に向かわなかった。そのボートが救助に向かった時には沈没から30分は経過しており、既に手遅れであった。
沈没から2時間後、近くを通りかかった客船が救助船を出し生存者を捜索し、まだ海に浮かんでいた2名の生存者を救出した。

【　大規模プロジェクトとは？　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
さて、私がシステム開発のプロジェクトに携わるようになってから、まだ２～3年目のころ、何人かの先輩方と飲みに行ったときに大規模プロジェクトのコントロールについて、熱く議論を戦わせたことを今でも覚えています。

そのとき私は、小規模プロジェクトと大規模プロジェクトのマネジメントは大きく異なると考えていました。しかし、あるベテランの方が「大規模プロジェクトは小規模プロジェクトの集まりだから、基本的にやるべきことは同じ」という主張を持っていて、これじゃまったく議論にならないと感じていました。

ここで、ひとくちに大規模プロジェクトといっても、読者の皆様とイメージが合わないかもしれないので、ざっくりですが、今回のブログで取り上げる大規模プロジェクトの特徴を概ね次のように置いてみます。（※２）

＜大規模プロジェクトの特徴＞
・　開発コスト＝５億円以上（要は、かなり高い）
・　スケジュール＝1年以上（要は、かなり長い）
・　プロジェクトメンバー数（ピーク時）＝100人以上（要は、かなり多い）
・　関係する組織の数（ピーク時）＝５社以上（要は、かなり多い）

だいたい私の考えている大規模プロジェクトのイメージはつかめたでしょうか？
「大きい」という表現は相対的なものであり、普段扱っているプロジェクトに対して、コストやスケジュールや体制がかなり大きく、普段とは違うレベルの気遣いが必要になると受け止めていただければ良いと思います。

私が考える大規模プロジェクトの特徴をもっと端的に言うと、次のように表現できます。

「どんなに優秀なマネージャでも、一人で全部を見切ることができないほどのプロジェクト」

逆に言うと、先にあげた特徴をすべて満たしていなくても、一人で全部を見切れない場合には、大規模プロジェクトとして扱う必要があるということです。

一般的に大規模プロジェクトをコントロールするためには、コントロール可能なサイズにプロジェクトを分割することが必要と言われます。もちろんその通りなのですが、大規模プロジェクトを数十の小規模プロジェクトに分割した場合、分割されたプロジェクト間でさまざまなコミュニケーションやコンフリクトが発生することになり、そう単純には行かないことは容易に想像できます。

それに、小規模とはいえプロジェクトが数十あるということは、それぞれにプロジェクトをしっかりコントロールできるマネージャとリソースが必要となるので、常にリソース不足や人材育成が課題となっている組織においては、体制を組むことを考えるだけで大問題となってしまいます。

【　タイタニックから学ぶ大規模プロジェクト・コントロールの勘所　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
では、タイタニック沈没のストーリーから読み取れる、大規模プロジェクト・コントロールの勘所を３つ取り上げます。

１．方向転換には時間がかかることを踏まえて舵取りする

タイタニックはその船体が大きいことから、氷山を見つけてから衝突回避行動を起こしてもすぐには方向転換できずに結局は氷山に接触してしまいます。

大規模プロジェクトもこれと同じです。往々にして大規模プロジェクトは開発のスコープや開発方法などが柔らかい状態でスタートすることが多いと思います。要件定義を進めてみないと結局どんなシステムを構築すべきかが明確にならないため、とりあえず先に進めて要件定義完了後に全体計画を見直すというアプローチをとることがあります。

しかし、要件定義を完了する段階では、既に分割したいくつもの小規模プロジェクトは、以降の外部設計やテスト工程に向けて、独自にそれぞれ走り始めている（たとえば開発ベンダー選定、予算確保、ユーザへのリリース予告など）可能性があり、この段階で全体計画を見直すことはかなり難しい状況になっていることが多いのが実情です。

計画の見直しがいくつかの小規模プロジェクトに限定されているならば、それほど混乱もなく立て直しが可能かもしれませんが、数十の小規模プロジェクト全てをたばねて計画変更することはかなりの期間が必要であり、強力なトップダウンによる強制力も必要となります。

このような状態を回避するためには、要件定義前のシステム企画段階をしっかり実施しておくことが重要であり、仮に要件定義後に全体計画の見直しを行う可能性がある状況であれば、全体計画見直しに必要な期間（バッファ）をあらかじめ確保し、関係するステークフォルダとも計画見直しの段取りをあらかじめ合意しておくなどの備えが必要です。

２．主要リスクへの対策をより具体化し、合意する

タイタニックは「不沈船」と呼ばれるくらいハード面でのリスク予防は図っていたものの、万が一沈没した場合のリスク発生時対策について具体化されず、避難訓練も実施していませんでした。

仮に小規模プロジェクトで不測の事態が発生した場合は、大規模プロジェクトに比べて影響範囲は限定されるために、比較的その場の判断で事態の収拾も行うことができます。ベテランＰＭのＭ男氏が良く言うように、とりあえず先に進めて何か問題があったらその時にタイムリーに対応すればよいという古い考え方で対応できるのは影響範囲が限定される小規模プロジェクトの場合です。（※３）

大規模プロジェクトのコントロールに際しては、プロジェクト目標の達成に致命的な影響を及ぼす可能性のある具体的なリスクをピックアップし、その予防策を実施するだけでなく、仮にそのリスクが顕在化した場合の具体的なリカバリーシナリオを立て、関係するステークフォルダ間でしっかりと合意しておくことが大切なのです。

３．疑心暗鬼によるセクショナリズムを排除

タイタニック沈没後、救命ボートで非難した人たちは、取り残された乗員乗客を助けに戻りませんでした。助けに戻れば、巻き込まれることで助かる命も無駄になってしまうという疑心暗鬼に陥っていたのではないでしょうか？

複数の組織が関係する大規模プロジェクトでは、ひとたびデスマーチ化の兆しが見えると、各組織が自組織への被害を最小限に食い止めるための行動を起こすことになるので、ますます事態が悪化することになります。

このようなセクショナリズムを排除するためには、不測の事態が起きたときにどのような行動をとるか、つまりリスク発生時対策を明確にして各ステークフォルダ間で合意しておくとともに、各組織のそれぞれの事情をできるだけオープンにして、腹を割った本音ベースでの組織間のコミュニケーションを行えるような関係を日ごろから構築しておく必要があります。（※４）

まあ、なかなかそう思うようにいかないのが、大規模プロジェクトではありますが。。。

それでは本年もよろしくお願いします！　　　　　　　＜　前回　｜　目次　｜　次回　＞

工藤武久

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
応援してくださる方は、クリックよろしくお願いします！
◆　人気ブログランキング
◆　にほんブログ村
～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～

※１　タイタニックについては、以下参照。
・「タイタニック (客船)」『フリー百科事典　ウィキペディア日本語版』
2016年12月30日 (金) 06:05 UTC https://ja.wikipedia.org/wiki/タイタニック (客船)
・「タイタニック (1997年の映画)」『フリー百科事典　ウィキペディア日本語版』
2017年1月4日 (水) 07:17 UTC https://ja.wikipedia.org/wiki/タイタニック (1997年の映画)

※２　システム開発を行う組織においては、「大規模」という要素だけではく、対象となるシステムの特性（基幹システムの再構築なのか、新規事業立ち上げのための戦略的なシステム構築なのかなど）などに応じて、プロジェクトマネジメントの実施内容を取捨選択する取り組みが効果的です。なお、ここで示す「大規模プロジェクトの特徴」は、あくまでも筆者感覚値であり、実業務においては各組織の状況に応じて、明確に定義すべき内容であることに留意してください。当ブログの以下の回も参考に。
・【第６９回】プロジェクト・プロファイリングと品質マネジメント戦略

※３　Ｍ男氏が登場する回は、以下を参照
・Ｐ子さんの一覧

※４　発注側と受注側のWIN-WINの関係性については、当ブログの以下の回も参照してください。
・【第１７回】それは誰のリスクか？