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

menuclear
ホーム > ブログ > 工藤 武久の記事一覧 > 【第18回】計画が先か?リスクが先か?


【第18回】計画が先か?リスクが先か?


ご訪問ありがとうございます!          < 前回 | 目次 | 次回 >

前回は「発注側と受注側」がそれぞれの立場でプロジェクト計画書を作成し、Win-Winの関係を築けるようにすり合わせを行った上で、リスク・マネジメントもそれぞれで行う必要があると結論づけました。プロジェクト計画書はしっかりしたリスク・マネジメントを行うための重要な軸になると言えます。
しかし、私はプロジェクトマネジメント支援を行う中で、「リスクは計画のインプットである!」というセリフを良く使います。

 

【 プロジェクト計画書・目次の順序 】

~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~
プロジェクト計画書の目次を見ると、リスクに関する記述は最後の方に出てくることが多いと思います。そのプロジェクト計画書を作成する際、過去の良くできたプロジェクト計画書や組織としての標準的な計画書をベースとして作成することが多いと思います。

この目次の順序に従って、プロジェクト計画書の雛形を元に、今回のプロジェクト用に書き換えて行く場合、プロジェクト・リスクについて考えるのは後に回されることになります。プロジェクトの立上げ段階では、プロジェクトメンバーをかき集めたり、作業場所やPC等のプロジェクト環境を準備したり、プロジェクトマネージャーは超多忙になることが多いので、計画書の骨格部分を組み立てるのに精一杯で、先々に備えるためのリスクへの対応が後回しにされてしまうことが懸念されます。

 

【 リスクは計画のインプットである! 】

~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~
はっきり言います。それは絶対にやってはいけません!プロジェクト計画書を書いたことのある方ならわかると思いますが、一度組み立てた計画を手直しするのはたいへん労力がかかるものなのです。新たなプロジェクトを計画する作業は、複雑なパズルを解いていくようなものなので、一度全体を組み立ててしまってから、プロジェクト目標に影響を与えるリスクへの予防策を一生懸命考えても、後から計画に組み込むのが難しくなります。

多くのプロジェクトでリスク一覧表が作成されているにもかかわらず、それがうまくプロジェクト運営に生かされない原因はこの辺にあると、私は考えています。一度組み立てた計画に対して、後付けで考えたリスク予防策を組み込もうにも、それを行うためのリソースや期間が残されていません。一度組み立てた計画はプロジェクトとして必須のものですが、まだ起きるかどうかもわからないリスクへの対応はどうしても優先順位が下がり、余裕があればやることになってしまうのです。

前回ご紹介した「仕様変更多発」リスクのように、プロジェクト実行段階で顕在化したリスクの発生時対策も、本来実施すべき抜本的な計画の見直しは暗に避けられ、いつまでも顕在化したかどうかあいまいにしたままにされてしまいがちです。(※1)

そうならないためには、「リスクは計画のインプットである!」というセリフを肝に銘じ、リスク予防策を全て計画に組み込み、リスクが顕在化した時の発生時対策による計画変更を必ず実施するという強い意志を持ってほしいのです。

実はPMBOK第4版のリスクの定義を見れば、その理由が明確にわかります。プロジェクト・リスクは「プロジェクト目標に影響を及ぼす」ものなので、その対応策がプロジェクト計画に影響するのは当たり前のことなのです。(※2)

 

【 計画が先か?リスクが先か? 】

~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~
ここまで読み進んで頂いた方は、今回のブログテーマである「計画が先か?リスクが先か?」という質問に対する私の答えは「リスクが先」と主張していると感じていると思います。しかし、それはあくまでもプロジェクト現場での実務を想定した主張であり、理屈を語るうえではもう少し慎重に考える必要があります。

当ブログの「【第12回】プロジェクト・リスクとは何か?」で登場した、成果物出来高と時間の二軸によるプロジェクト・モデルを思い出してください。このモデルを使って、私はプロジェクト目標やプロジェクト計画が基準になって、目標や計画とのギャップが生まれるかもしれない不確実性のことをリスクと定義しました。つまり、この定義によれば、プロジェクト目標や計画が定まらない限り、リスクが定まらないということを示しており、この時は明らかに「計画が先」だと主張していたように見えます。(※3)

そりゃそうですよねえ。プロジェクトの目標が定まっていなければ、成功も失敗も無く、つまりリスクなど存在しないはずです。何をしたいかが決まっていないのに、それが実現できるかどうかという不確実性を語ることはできません。ということは、やはり理屈上は「計画が先」というのが正解ですかねえ。。。

という感じでグルグルと思考をめぐらしたあげく、現段階での私の結論は次の通りに落ち着きました。

「プロジェクト目標を掲げた(計画を策定した)瞬間、プロジェクト・リスクも同時に存在することになる!」

すなわち、

「計画とリスクは、表裏一体である!」

もはや「計画が先か?リスクが先か?」という質問は意味をなさないのです。計画を検討する際には必ずリスクも一体となって検討する必要があり、逆にリスクを検討する際には計画への影響をセットで考えないといけないということです。

少し理屈っぽい話になってしまいましたが、ご納得頂けたでしょうか?

それでは次回もお楽しみに!          < 前回 | 目次 | 次回 >

工藤武久

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

※1 「【第17回】それは誰のリスクか?」

※2 「【第11回】超ハイリスク?甲子園への道・プロジェクト!」

※3 「【第12回】プロジェクト・リスクとは何か?」

| 目次

採用情報
PM-waigaya
PM-WaiGaya
コンサルタントのトーク動画
PM Weekly Talk
PM Weekly Talk
コンサルタントが語る「PMBOK®12 の原理・原則」

Profileプロフィール

Avatar photo
工藤 武久
■株式会社アイ・ティ・イノベーション  ■コンサルティング本部 - 東日本担当 ■学歴:早稲田大学 - 第一文学部卒業 ■メーカー系のシステム子会社にて、主に官公庁向け大規模システム開発プロジェクトに、SE、PMとして携わる。立ち上げから運用保守フェーズに至るまで、システム開発プロジェクトの幅広い実務経験を重ねた。 ■2007年より株式会社アイ・ティ・イノベーションにおいて、大規模プロジェクトにおけるプロジェクトマネジメント支援や品質管理支援等のコンサルティングを手がける。 ■PMP、情報処理技術者試験(プロジェクトマネージャ、システム監査技術者他)など。 ■Twitter:https://twitter.com/iti_kudot  ~・~・~・~・~・~・~・~・~・~ ■ ブログランキングに参加しています! ◆人気ブログランキングにほんブログ村 ↑是非応援(クリック)お願い致します↑ ~・~・~・~・~・~・~・~・~・~ ■主なタグ:統合, スコープ, タイム, コスト, 品質, 人的資源, コミュニケーション, リスク, 調達, ステークフォルダ

Recent Entries最近の記事