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

ご訪問ありがとうございます！　　　　　　　　　　＜　前回　｜　目次　｜　次回　＞

夏の甲子園も大詰めを迎えています。9回裏ツーアウトからの逆転サヨナラ劇などを見ていると、もしかすると野球の神様が感動的なシナリオを準備しているのではないかと思うこともあります。思わぬ逆転負けをしたチームからすると、ここまで優勝のために頑張ってきたのに、優勝のためのシナリオがもろくも崩れ去る瞬間のように感じるでしょう。

「スポーツは筋書きの無いドラマ」と良く言われますが、やっている人たちから見ればそんなことは無いと私は思います。つまり、甲子園優勝を目指すチームは優勝のためのシナリオを必ず描いて大会に臨んでいるはずだし、9回裏ツーアウトランナー無しの負けムード漂うチームの選手たちは、そんな中でも逆転サヨナラのシナリオを思い描きながらプレイしているはずです！

そうでなければ、甲子園優勝も勝ち取れないだろうし、奇蹟の逆転サヨナラ劇も起きるはずは無いのです！

【　ステアリング・コミッティとは？　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
前回　【第９２回】発掘！大規模プロジェクトの「あるある」会議事情　においても登場したステアリング・コミッティ（以下ステコミ）とはどんなものか、少しご紹介します。前回の会議体定義の中で、ステコミは、「重要な意志決定、プロジェクト全体リスク評価」を行う会議体と定義しました。あらためてネット上でステコミについて調べてみましたが、主に大規模プロジェクトにおいて、現場だけでは意志決定が難しい状況を解消するために、客観的な立場で意志決定を行うための機関というニュアンスの説明が多いようです。

確かに、大規模プロジェクトやプロジェクトの集合体であるプログラムの場合は、ステークフォルダ間での利害関係が発生することも多く、その利害を調停しながら重要な意志決定を行う機関として、ステコミが重要な位置づけとなることはわかります。しかし、実際に私がご支援させていただいたプロジェクトの中には、それほど大きなプロジェクトでは無くても、ステコミを定期的に開催していることが多いと感じています。

そこでの目的は、ステークフォルダ間の利害調整ということよりも、経営層も含めたプロジェクト内外の重要なステークフォルダに対して、プロジェクトの状況や課題・リスクをプロジェクトマネージャが報告し、それらの課題・リスクへの対応方針を示して、承認を得る場という意味合いの方が強いと感じます。要は、ステコミがプロジェクトを引っ張るという構図ではなく、プロジェクトマネージャのプロジェクト運営方針をステコミでお墨付きをもらうという関係性の方が多いのではないかと感じます。

そりゃそうですよね。多くのステコミメンバは、月に1回1時間程度のステコミ開催時しかプロジェクトの状況を把握できないのに、プロジェクトの最終結果に対して重要な意志決定を主体的にできるはずはありません！

そこでは、必ずプロジェクトの状況を一番深く把握しているはずのプロジェクトマネージャが、ステコミメンバが理解しやすいようにプロジェクト状況と今後の運営方針をしっかりと主体的に報告することで、はじめてプロジェクトとしての意志決定が可能になるはずです。

逆に言うと、プロジェクトマネージャがプロジェクトの状況を把握できず、どのようにプロジェクトを引っ張っていくかという意志が無いままステコミに判断を仰ぐという姿勢では、ステコミメンバがそれぞれの勝手気ままな考え方で、プロジェクトの運営について一貫性の無い意志決定が行われることによって、かえってプロジェクトが迷走するという結果が目に見えています。

そのようなプロジェクトマネージャは「ステコミ決定に従ったんだからプロジェクトが迷走しても仕方ないよな。。。」と、逃げ道を探しているのかもしれません。。。

【　ステアリング・コミッティ報告内容　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
では、具体的にステコミでどんな内容を報告するのか？私の経験を基に整理した内容を図１に示します。「私の経験を基に」と書きましたが、ステコミを実施する各組織の状況に応じて、また、担当するプロジェクトマネージャやステコミメンバの意向に応じて、報告内容は様々なので、これまでの経験を通じて標準的には、こんな感じの報告内容にすべきという思いを整理したものととらえてください。

プロジェクトマネージャが、ステコミメンバに意志決定を求めるということなので、まずは何を意志決定してほしいかを示すことが重要になります。中には、淡々とプロジェクト状況を説明するだけのステコミもあると思いますが、せっかく意志決定ができるステコミメンバの貴重な時間を使うことになるので、しっかりと意志決定をしてもらうように促す必要があります。

最低限、プロジェクト全体リスクの評価結果とその対応策として、そのままプロジェクト続行なのか、計画を手直しする必要があるのか、しっかりジャッジして頂いて、ステコミメンバにプロジェクトを他人事と思わせないようにする必要があります。（※１）

さて、一般的なアジェンダとしては図１に示す内容となりますが、プロジェクトの各段階においてメリハリをつけた報告をしないと、ステコミメンバを巻き込むことは難しくなります。プロジェクト進行の各段階で、経営層の方々が気にしそうなポイントをあらかじめ見繕ってステコミ報告を行うことが望ましいと考えます。

月に１回とはいえ、毎回毎回「今回のステコミではどんなことを報告しようか？」なんて、プロジェクトマネージャやＰＭＯが時間を費やしてしまっていてはもったいないので、図２に示すように、あらかじめこの時期にはこんな報告をしようと、カットオーバまでのステコミ・アジェンダを事前に考えておくことをおすすめします。

そうですね。これはプロジェクトが順風満帆に進んだ際のステコミ・アジェンダであり、プロジェクトマネージャが思い描くプロジェクト・シナリオ、当初計画通りにプロジェクトが進展した場合のシナリオということになります。（※２）

【　リスク顕在化を想定したプロジェクト・シナリオ　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
しかし、現実のプロジェクトはそんな無風状態で進むことは、まずありません。必ず、どんなプロジェクトでもその独自性に基づき、ひと山、ふた山あるはずです。「独自性に基づく山なんて、起きてみないとわからんじゃろ！」なんて、ベテランＰＭのＭ男氏のつぶやきも聞こえてきそうですが、本当にそうでしょうか？

「プロジェクトの失敗の原因は、企画・要件定義段階の超上流工程にある。」ということが言われて久しいのに、まだまだ対応が十分ではないというのが現状です。なかなか難しい課題であることはわかりますが、プロジェクトをスタートする段階で、企画が十分で無いとわかっていることも多いはずです。本来は、企画をしっかり実施してから要件定義以降のシステム開発プロジェクトに着手すべきなのは言うまでもありませんが、企画が十分かどうかわからないままプロジェクトをスタートせざるを得ないケースもまだまだあるのが現実のようです。

では、仮に企画が不十分なままスタートした場合に、プロジェクトをどうハンドリングしていくべきかという視点でプロジェクトのシナリオを想定してみたらどうでしょうか？
（※３）

この例では、要件定義以降で特に大きな課題が顕在化するだろうと思われる時点で開催されるステコミで、どんなことを報告し、意志決定してもらうかを想定したシナリオを描いています。

もちろんプロジェクトは生き物であり、このようなシナリオ通りに推移するわけはありません。しかし、甲子園での９回裏２アウトからの逆転劇は万に一つかもしれないけれど、あきらめずに道筋を作っていくという意志の力が無いと起こりえないのではないかと改めて認識させられました。

「どんな制約があっても、成功へのシナリオを描くことで、プロジェクトは成功に導ける！」

システム開発のプロジェクトも同様で、確かに制約事項や思い通りに行かないことが多い中で、単に流れに身を任せるのではなく、最終的にはこういう姿にするというシナリオをプロジェクトマネージャ自身がしっかり思い描くことで、なんとか道筋が見えてくるのではないでしょうか？

ステコミは、プロジェクトマネージャにとっても、定期的にプロジェクトの状況をしっかりと見定めて、自らの意志表明を行う機会として、重要なイベントであると考えられますね！

それでは次回もお楽しみに！　　　　　　　　　　＜　前回　｜　目次　｜　次回　＞

工藤武久

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

※１　プロジェクト全体リスクについては、当ブログの以下の回参照。
・【第１３回】個別リスクとプロジェクト全体リスクという二つの視点
・【第１４回】プロジェクト全体リスクのマネジメント具体例

※２　プロジェクト成功へのシナリオについては、当ブログの以下の回参照。
・【第５７回】プロジェクトの成功を演出せよ！
・【第７５回】すべてのプロジェクトは崩壊を運命づけられている？

また、工程完了判定、稼働判定については、当ブログの以下の回参照。
・【第３３回】工程完了判定基準にオフサイドトラップを仕掛けろ！
・【第３４回】カットオーバー・クライテリアとは何か？

※３　よくある失敗事例については、PMI日本フォーラムの講演資料から流用。
・　『なぜリスクマネジメントは形骸化してしまうのか？ ～ 実効性のあるリスクマネジメント定着化についての一考察 ～』