設計部門とリスク管理(その3)

更新日

投稿日

【設計部門とリスク管理 連載目次】

 

◆リスク管理とは目標達成までのシナリオ作成

 
 リスクの洗い出しと、予防策およびコンティンジェンシープランの検討後に検討結果はひとつの管理表(リスク管理マスター)としてまとめておきましょう。
 
 リスクはプロジェクトの流れ(進め方)が分岐するポイントであり、リスク管理マスターには個々のリスクに対するアクションがもれなく記述されているわけですが、プロジェクト全体の流れがどうなるのかはわかりづらい状態です。これを、シナリオを使ってわかりやすくしたいと思います。では、シナリオ作りに取りかかりましょう。
 
 一番単純なシナリオは、リスクが何も発生しないケースです。コンティンジェンシープランを全く実行しない場合ですからベストケースとよびましょう。ひとつもリスクが顕在化しないというのは、ほとんどあり得ない状況ですから「ドリームケース」とよぶのが妥当だと思いますが、マネジャーやプロジェクトリーダーの多くは、がんばれば何とかなると考えていることが多いものです。ここでは、彼らの意志を尊重してベストケースとよぶことにしましょう。
 
 次に、ベストケース以外のシナリオを考えます。単純に考えると前回の図27で説明したように、分岐であるリスク(分岐)の数に応じたシナリオが存在することになりますが、実際のプロジェクトでのリスクは図27よりもかなり多くなるのが普通ですから、リスクをそのままシナリオにするのは現実的ではありません。そこで、期限に注目してシナリオを整理します。
 
                R&D
図27.プロジェクトの流れを変えるリスク
 
 製品開発に代表される、製造業におけるプロジェクトのほとんどは、決められた期限までにリリースすることが最優先です。実際、コンティンジェンシープランは期限が関係しているものがほとんどのはずです。予防策の実施をやめる期限、リスク発生と判断するかどうかの最終期限、コンティンジェンシープランとして挙げているアクションの実施期限など、何かしらの期限が存在していると思います。これらの期限に注目すると、多くの場合2~3個に集約することが可能です。
 
 前回の図29の例では、P1 の対応判断を6月末に行うこと、C1 の対応期限が10月末であることがわかります。下記の図30は、他のリスクについても整理すると、6月(期限1)と 10月(期限2)に期限が集約されたことを示しています。
 
               R&D
                                   図29.予防策とコンティンジェンシープラン
 
               R&D
                                      図30.期限に注目したシナリオの整理
 
 期限1では、新規デバイスをあきらめて既存デバイスを採用するための再設計を行うとか、評価を2段階に分けて仮リリースを設けるとか、いくつかのコンティンジェンシープランを実施します。そして、これらの対策実施によりリリースはベストケースよりも1ヶ月遅れます。これをノーマルケースとよびましょう。
 
 同様に期限2では、顧客から機能の追加・変更要求があり、その対応のために別チームで評価を並行実施するとか、プロジェクトを別事業部に移管する作業を行うなどの対応が完了確認を行うなどいくつかのアクションを行います。その結果、リリースはベストケースよりも3ヶ月遅れます。これはワーストケースとよびましょう。
 
 以上のように、期限1、期限2のタイミングでいくつかのアクションの実施や実施完了の判断を行うことで、リリース日程や機能、必要リソースなどが異なる、ベストケース、ノーマルケース、ワーストケースという3通りのシナリオに整理することができたわけです。実際のプロジェクトではもっと多くのリスクが存在するわけですが、同じ考え方で2~3のシナリオを作成することができます。
 
 今回はリスク管理をベースに、プロジェクトの進め方におけるシナリオ作成について解説しました。リスク管理マスターの状態からリスクをもとにしたシナリオの形にしておくことで、プロジェクトの実施パターンが明らかになり、関係者全員で共有することが容易になります。シナリオという具体的な形で共有できるので、関係者はそれぞれの役割に応じて必要な準備や対応をとることも容易です。そうすれば、リスクが顕在化しても右往左往することは大幅に減ることでしょう。
 
 次回は、プロジェクト管理を対象に、基本の仕組みをどのようにして進化・深化させるかについて解説します。
 
 
...

【設計部門とリスク管理 連載目次】

 

◆リスク管理とは目標達成までのシナリオ作成

 
 リスクの洗い出しと、予防策およびコンティンジェンシープランの検討後に検討結果はひとつの管理表(リスク管理マスター)としてまとめておきましょう。
 
 リスクはプロジェクトの流れ(進め方)が分岐するポイントであり、リスク管理マスターには個々のリスクに対するアクションがもれなく記述されているわけですが、プロジェクト全体の流れがどうなるのかはわかりづらい状態です。これを、シナリオを使ってわかりやすくしたいと思います。では、シナリオ作りに取りかかりましょう。
 
 一番単純なシナリオは、リスクが何も発生しないケースです。コンティンジェンシープランを全く実行しない場合ですからベストケースとよびましょう。ひとつもリスクが顕在化しないというのは、ほとんどあり得ない状況ですから「ドリームケース」とよぶのが妥当だと思いますが、マネジャーやプロジェクトリーダーの多くは、がんばれば何とかなると考えていることが多いものです。ここでは、彼らの意志を尊重してベストケースとよぶことにしましょう。
 
 次に、ベストケース以外のシナリオを考えます。単純に考えると前回の図27で説明したように、分岐であるリスク(分岐)の数に応じたシナリオが存在することになりますが、実際のプロジェクトでのリスクは図27よりもかなり多くなるのが普通ですから、リスクをそのままシナリオにするのは現実的ではありません。そこで、期限に注目してシナリオを整理します。
 
                R&D
図27.プロジェクトの流れを変えるリスク
 
 製品開発に代表される、製造業におけるプロジェクトのほとんどは、決められた期限までにリリースすることが最優先です。実際、コンティンジェンシープランは期限が関係しているものがほとんどのはずです。予防策の実施をやめる期限、リスク発生と判断するかどうかの最終期限、コンティンジェンシープランとして挙げているアクションの実施期限など、何かしらの期限が存在していると思います。これらの期限に注目すると、多くの場合2~3個に集約することが可能です。
 
 前回の図29の例では、P1 の対応判断を6月末に行うこと、C1 の対応期限が10月末であることがわかります。下記の図30は、他のリスクについても整理すると、6月(期限1)と 10月(期限2)に期限が集約されたことを示しています。
 
               R&D
                                   図29.予防策とコンティンジェンシープラン
 
               R&D
                                      図30.期限に注目したシナリオの整理
 
 期限1では、新規デバイスをあきらめて既存デバイスを採用するための再設計を行うとか、評価を2段階に分けて仮リリースを設けるとか、いくつかのコンティンジェンシープランを実施します。そして、これらの対策実施によりリリースはベストケースよりも1ヶ月遅れます。これをノーマルケースとよびましょう。
 
 同様に期限2では、顧客から機能の追加・変更要求があり、その対応のために別チームで評価を並行実施するとか、プロジェクトを別事業部に移管する作業を行うなどの対応が完了確認を行うなどいくつかのアクションを行います。その結果、リリースはベストケースよりも3ヶ月遅れます。これはワーストケースとよびましょう。
 
 以上のように、期限1、期限2のタイミングでいくつかのアクションの実施や実施完了の判断を行うことで、リリース日程や機能、必要リソースなどが異なる、ベストケース、ノーマルケース、ワーストケースという3通りのシナリオに整理することができたわけです。実際のプロジェクトではもっと多くのリスクが存在するわけですが、同じ考え方で2~3のシナリオを作成することができます。
 
 今回はリスク管理をベースに、プロジェクトの進め方におけるシナリオ作成について解説しました。リスク管理マスターの状態からリスクをもとにしたシナリオの形にしておくことで、プロジェクトの実施パターンが明らかになり、関係者全員で共有することが容易になります。シナリオという具体的な形で共有できるので、関係者はそれぞれの役割に応じて必要な準備や対応をとることも容易です。そうすれば、リスクが顕在化しても右往左往することは大幅に減ることでしょう。
 
 次回は、プロジェクト管理を対象に、基本の仕組みをどのようにして進化・深化させるかについて解説します。
 
 

   続きを読むには・・・


この記事の著者

石橋 良造

組織のしくみと個人の意識を同時に改革・改善することで、パフォーマンス・エクセレンスを追求し、実現する開発組織に変えます!

組織のしくみと個人の意識を同時に改革・改善することで、パフォーマンス・エクセレンスを追求し、実現する開発組織に変えます!


「技術マネジメント総合」の他のキーワード解説記事

もっと見る
自社の存在価値 普通の組織をイノベーティブにする処方箋 (その112)

  知識や経験を整理するフレームワークとして、本質とそれ以外という区別があるという理解から、「本質とは何か」を解説しています。また、企業活...

  知識や経験を整理するフレームワークとして、本質とそれ以外という区別があるという理解から、「本質とは何か」を解説しています。また、企業活...


価値づくりの研究開発におけるオープン・イノベーション  研究テーマの多様な情報源(その17)

    1.「価値づくり」は自社の外から始まる   ◆関連解説『技術マネジメントとは』  前回のその16に続いて解説します...

    1.「価値づくり」は自社の外から始まる   ◆関連解説『技術マネジメントとは』  前回のその16に続いて解説します...


メンバーの個性を生かす 新規事業・新商品を生み出す技術戦略(その21)

        最近、宇宙飛行士である金井宣茂氏のインタビュー記事を読みました。記事のタイトルには『現場では...

        最近、宇宙飛行士である金井宣茂氏のインタビュー記事を読みました。記事のタイトルには『現場では...


「技術マネジメント総合」の活用事例

もっと見る
R&Dの価値創造力を高めるシンプルツール、iMapとは、

 技術経営とは、「企業の経営資源である技術を経営戦略の中核に位置づけ、顧客価値の創造へ向けて、その獲得・強化・活用を戦略的に行うことにより、継続的な企業の...

 技術経営とは、「企業の経営資源である技術を経営戦略の中核に位置づけ、顧客価値の創造へ向けて、その獲得・強化・活用を戦略的に行うことにより、継続的な企業の...


スーパーマンではなくプロフェッショナルな技術者に(その2)

【プロフェッショナルな技術者 連載目次】 1. 製品開発現場が抱えている問題 2. プロフェッショナルによる製品開発 3. 設計組織がねらい通り...

【プロフェッショナルな技術者 連載目次】 1. 製品開発現場が抱えている問題 2. プロフェッショナルによる製品開発 3. 設計組織がねらい通り...


手戻りのフィードバック・ループを小さくするとは プロジェクト管理の仕組み (その9)

 ソフトのモジュール作成(プログラム作成)は機能セット単位にスケジュールするのが基本となります。そして、機能セットごとのモジュール作成は、詳細設計、コーデ...

 ソフトのモジュール作成(プログラム作成)は機能セット単位にスケジュールするのが基本となります。そして、機能セットごとのモジュール作成は、詳細設計、コーデ...