PMプロの知恵コーナー
先号　　　次号

ゼネラルなプロ (150) （リスクマネジメントと失敗の構図）

向後　忠明　[プロフィール]　：4月号
　これまでのリスク対応はほとんどが提案や契約時のものが多かったと思います。このことからプロジェクトライフサイクルの中でリスクはプロジェクト開始時点からその多くを何らかの形（除去、移転、提言及び受容）の区別で処理できます。そこで今月号はリスクマネ―ジメントの観点からのリスクマネジメントサイクルについての話及びリスク事例とその対応について、契約の問題も含め実際に遭遇した事例について具体的に話を進めていきたいと思います。

  1. リスクマネジメントサイクル
    　リスク管理はプロジェクトの成功の根源であることは誰でも思うことです。これを軽視するとプロジェクトの失敗の構図に陥ることになります。
    　このようなことにならないように、これまでリスク対応策について述べてきました。
    　しかし、リスクマネジメントはその都度の対応策では不十分です。マネジメントということであれば必ずマネジメントサイクルがあります。
    　これまでの説明からも分かるように下記に示すプロジェクト活動のサイクルによりリスク情報の登録、整理を通してのブラッシュアップによってリスク対応能力の向上を図る必要があります。

  1. ① リスク情報の整理（プロジェクト記録と関連するリスク集そしてそこから得られた個人ノウハウ）
  2. ② リスク情報の利用方法と手順の整理
  3. ③ 実プロジェクトへの適用（契約書やプロジェクト計画書への反映）
  4. ④ リスク情報の監視と課題処理
  5. ⑤ プロジェクト完了報告と新しいリスク情報の整理と①へのフィードバック

　しかし、リスク内容はプロジェクトライフサイクルの各フェーズで異なってきます。
　そして、リスク源の特定はリスクとなる現象や事象によりその特定にはプロジェクトを差配する人の能力とプロジェクト実践経験に比例し、その特定には熟練を要します。

　以下にリスクマネジメントサイクルとその流れを次ページにしてみました。

リスクマネジメントサイクルとその流れ

　しかし、リスクはなかなか気が付かずに見過ごし、後にその現象が見られた時には「時すでに遅し」といった場合が多くみられ、小さい事象でも見逃すと大きな問題となることがあります
　気づいていれば事前に対策を立てられるがリスクマネジメントサイクルでのリスク情報の整理があってもなかなかプロジェクトの本当のリスクに気がつかず見過ごしてしまうことがあります。また、リスク情報を無視して自己流でのプロジェクト運営をすることにより問題を大きくしてしまうケースもあり、それを少しでも防げる事例を一部のものであるが、著者の多くのプロジェクト経験から今後のプロジェクト実行者の参考になればと思い、多くの事例とその対応そしてそのリスクの影響度について参考に各フェーズ毎に纏めてみました。

　なお、リスク対応としてその除去の程度を以下の4項目に分けて示してみました。
A ： 原因の除去、特定脅威の回避
B ： リスク事象の移転
C ： リスク影響の軽減と分担
D ： リスク影響の受容

　なお、ここに示す例はリスク源の一部であり、読者諸氏の今後の各種プロジェクトでのリスク情報をここに追加することにより、さらに充実したリスク情報源となるでしょう。
1．内的リスク：（プロジェクトチームが統制し影響を及ぼすことのできる範疇のリスク）

1 ）顧客要求関係（顧客原因によるリスク）
 a ) 実現根拠のない提案または口頭/簡易な引き合いによる依頼。

  • 当て馬？予算取り参考見積？等お客の目的を確認し、周辺情報を含め、プロジェクト情報を取り判断する。（営業活動の重要な部分）
  • 営業確認後、営業とSEによる要求内容の確認（顧客の要求を引き出すにはプレゼンテーション等を利用し、顧客担当との質疑応答などが効果的）
  • 提案書は自社の考え（仕事の範囲（SOW)、仕様、スケジュール、提案コスト及び契約条件等）明確にして提出：紙一枚の要求でも営業情報とPJの内容によっては誠意を持って対応）

 A
 b ) 納期遵守不可（現実的計画とスケジュール）

  • 自社の出来る納期を提案。不可なら提案中止


 A
 c ) 予算固定で機能要求増大

  • 予算に合った機能にて提案。（お客要求機能の場合に従った予算も代替案で提出）

 C
 d ) 要求内容と自社資源のミスマッチ

  • 要求内容に合った自社人的資源及びアウトソーシングの双方を考慮した体制。
  • エンジニアリング技法に習熟したPMの選抜

 B
Note ： エンジニアリングとはニーズまたは顧客要求に柔軟に対応し、ソリューションを行うことができる複合技術適用技術。

 e ) 要求内容（設計のインプット）が明確でない提案

  • 実費精算方式などの契約にする。仕様が固まってから一括請負方式にする。一括請負を要求されたら、技術・商務的前提条件をつける。
  • 企画（要件分析及び定義）段階、コンサルティングとその後のPJ実行段階に分ける提案

 B
 f ) 根拠の無いディスカウント又は指値

  • 主に、契約交渉時に発生する事象であるが、その都度積算根拠を示し、対応。無理なら要求内容を変更しての代替案を出す。それでもだめなら撤退。

 A
orB
 g ) 見積期限の短い提案

  • 期限延長を申し入れる。（無理な見積は怪我の基）
  • 習熟した定型PJであればできる限り提案書や付属技術書のパターン化で対応

 B
 h ) 要求事項の取り違えまたは確認不足

  • 最終提案前のレビュー及び契約前の確認を怠らない（この時点を過ぎてからの発見の場合は顧客交渉となる。

 C
 i ) 頻繁な変更･追加要求

  • 契約書での変更・追加に関する条件確認そしてこれに基づく顧客との交渉と文書での確認
  • 提案段階なら提案書及び契約条件に提案コストの前提条件（SOW、技術仕様、スケジュール等）及契約条件を明確に示す。

 B
 j ) 赤字及びハイリスク案件

戦略的営業案件

  • インキュベーション又は次の大規模案件の布石を除いては撤退）
  • 提案時点でのコスト回収を含む将来展望を示しプロジェクト審議会にて審議。その後トップへのエスカレーション又は報告。

 A
 k ) 顧客PJ体制の不明確さ

  • プロジェクト遂行手順において体制を含めて情報のやり取りに関する規定を明確にし、顧客確認を取る。
  • 特に体制ではキーパーソンおよび各担当の確認
  • 顧客側決定権限のある上位者の参加確認

 D

次月号は提案書の作成と契約関連について述べていきます。
ページトップに戻る