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

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

前回はプロジェクト目標に「プラスの影響を与えるリスク」＝「好機」の具体例を紹介しました。「脅威」と「好機」に対してどのような対応戦略を立てて行くのかが、プロジェクトの成否を左右します。プロジェクトマネージャーの腕の見せ所です。
しかし、リスクへの対応戦略を立てる上で気をつけなければならないことがあります。それは「誰の視点でリスクを洗い出して、対応戦略を考えていくのか」ということです。

【　仕様変更多発リスクは誰にとってのリスクか？　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
当ブログの「【第１１回】超ハイリスク？甲子園への道・プロジェクト！」では、プロジェクト・リスク・マネジメントがうまく機能していない一例として、リスク一覧表に次のような記載がされていることをあげました。（※１）

既に顕在化したリスクに対して、予防対策の実施状況がいつまでも更新され続けている。たとえばよくある「仕様変更多発リスク」の「予防対策欄」に最新状況として以下のような記載がされているなど。

「　変更管理ルールを厳格に適用する。現在の仕様変更対応状況は以下の通り。
◆仕様変更総数　　　：５０件
（対応状況内訳）
・追加費用で対応　　：１０件（勝ち）
・無償で対応　　　　：１０件（敗け）
・次期開発回し 　　 ：１０件（勝ち）
・調　整　中　　　　：２０件
（今後の対応予定）⇒８月末までに全件（勝ち）になるよう調整する。　」

この例では、既に仕様変更が多発しており、「スケジュール」や「コスト」といったプロジェクト目標に影響を与えてしまっているのに、いつまでも予防対策として変更管理ルールの厳格な適用と仕様変更発生状況のモニタリングを続けています。そして、今後の対応予定も、個々の仕様変更発生に対してモグラたたき的な対応を続けようとしています。

本来ならば仕様変更多発リスクが顕在化したと判断して、たとえば次のような発生時対策を実施する必要があります。
・仕様変更多発の原因を追究（可能であれば原因の除去）
・今後どれくらい発生しそうかの見通し（見積り）を立てる
・その見通しをもとに、今後発生が予測される仕様変更への対応計画を立てる

この対応計画の内容は、どこまで対応するか、どの仕様変更を優先するか、取り込み範囲（スコープ）、対応スケジュール、コスト（バッファを切り崩すのか、追加予算とするか等）、誰が対応するか、デグレード対策等の品質確保をどうするか・・・などなど、いわば新たにプロジェクト計画を検討し、実行していくことと同等になります。仮にプロジェクト予算が底をついていても、どうしても仕様変更を取り込む必要がある場合には、本体側プロジェクトの開発スコープを見直すなど、大規模な計画変更が必要となる場合もあります。。。

しかし、この例の中でもっと気になる部分があります。それは、「勝ち」とか「敗け」と書かれているところです。いったい誰が誰に対して勝ったり敗けたりするのでしょうか？この例では、「追加費用で対応」が「勝ち」で、「無償で対応」が「敗け」となっているので、おそらく開発ベンダー（受注側）で記載されたリスク一覧であり、開発ベンダー（受注側）が発注側に対する「勝ち」「敗け」として記載していることになります。

【　問題認識の相対性理論とプロジェクト・リスク　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
当ブログ「【第３回】問題とは何か？」では、「見方や立場が変われば、問題が問題では無くなってしまう」という「気づき」のことを「問題認識の相対性理論」と私が呼んでいることを紹介しました。（※２）
そして、当ブログ「【第１２回】プロジェクト・リスクとは何か？」で紹介した、プロジェクト・モデルにおけるリスクの定義を見ればわかるように（※３）、プロジェクト・リスクは将来的にプロジェクト計画と実績に乖離が出る、つまり「プロジェクトにおける問題」となるものであり、「問題認識の相対性理論」があてはまるというわけです。

―――　ここで、プロジェクトマネジメント研修を受けてきたばかりの、新人Ｐ子さんからのするどい質問です。

＜新人Ｐ子さん＞　：　「ちょっと待って！たしか、『問題認識の相対性理論』によるコンフリクトを避けるために、プロジェクト計画書にあるべき姿を具体的に書いて、みんなで合意しておけば良いって言ってませんでしたっけ？」（※４）

（痛いとこつくなあ・・・）そこが悩みの種なんです。いくらプロジェクト計画書を具体化して、ステークフォルダー全員が合意したとしても、どうしても「発注側と受注側」という組織の壁を取り除くことはできないのです。たとえて言えば、「ベルリンの壁」が取り払われたとしても、いまだに国家間の利害関係に基づく紛争が無くならないのと同じです。
特にプロジェクト・リスクは「コスト」への影響を扱うため、「発注側と受注側」の組織間の利害関係が直接出てきます。たとえば、仕様変更について、発注側のコストで対応するのか、受注側のコストで対応するのかによって、両組織のプロジェクト目標に対して、真逆の影響を与えてしまうのです。

＜新人Ｐ子さん＞　：　「ということは、『発注側と受注側』でプロジェクト目標が違うってわけ？いっしょに同じシステムを開発しているのに、『発注側と受注側』で目指すべき方向が違ってるって言うんですか！そんなんじゃ、プロジェクトの成功確率が上がらないのは当たり前じゃないですか！なに言ってるんですか！」

（たじたじ・・・）うーん。それはそうなんだけど。。。だからこそ、本当は「発注側と受注側」が、お互いに相手組織の事情をよく理解した上で、お互いが利益を得る、つまり、Win-Winの関係を築けるようなプロジェクト計画を立てる必要があるんです。そのためにも、「脅威」ばかりをリストアップしたリスク一覧だけではなく、お互いにメリットが出るような「好機」についてもリストアップしていく必要があると思います。。。

【　発注側と受注側のそれぞれでリスク・マネジメントを行う　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
少し歯切れが悪くなってしまいましたが、私のこれまでの経験上の結論をここでは示すことにします。「発注側と受注側」はあくまでも別組織であり、組織目標は別々に設定されていることは厳然たる事実です。たとえ同じシステムを開発するプロジェクトであっても、「発注側と受注側」のプロジェクト目標は異なると考えるのが自然です。従って、プロジェクト計画書もリスク一覧表も「発注側と受注側」が別々に作成して、マネジメントしていく必要があります。（※５）

もちろんプロジェクトの最終的なオーナーは発注側であり、発注側のプロジェクト計画書が前提となって、受注側のプロジェクト計画書が作成される必要があります。そして、お互いのプロジェクト計画書を持ち寄って、お互いのプロジェクト目標に対してWin-Winの関係が築けるよう、すり合わせによる事前合意を行うべきです。

「発注側と受注側それぞれでプロジェクト計画書を作成し、すり合わせることで、Win-Winの関係を構築しよう！」

ただし、特にお金が絡む部分については、残念ながら利害関係が生じざるをえません。その部分については、ある意味紳士協定により、お互いに「あこぎな商売」をしないように心がけ、「脅威」に関するリスク一覧表は別々に作成して、別々にリスク・マネジメントしていく必要があります。たとえプロジェクトマネジメントの大部分を受注側に委託していたとしても、リスク・マネジメントだけはプロジェクトの最終的なオーナーである発注側としても、しっかりと取り組む必要があります。

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

工藤武久

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

※１ 「【第１１回】超ハイリスク？甲子園への道・プロジェクト！」

※２ 「【第３回】問題とは何か？」

※３ 「【第１２回】プロジェクト・リスクとは何か？」

※４ 「【第４回】プロジェクトにおける問題とは何か？」

※５　ここではプロジェクト体制を単純化して「発注側と受注側」という構図で考えていますが、実際のプロジェクトにおいては、プロジェクト体制の組み方やプロジェクトの大きさ、役割分担や発注形態などによって、プロジェクト計画書の作成とリスク・マネジメントの取り組み単位が異なってきます。大切なのは、プロジェクトに携わるメンバーや組織は、それぞれの立場や背景を持っていることをよく考えた上でプロジェクトを運営していく必要があるということです。