設計部門とリスク管理(その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のシナリオを作成することができます。
 
 今回はリスク管理をベースに、プロジェクトの進め方におけるシナリオ作成について解説しました。リスク管理マスターの状態からリスクをもとにしたシナリオの形にしておくことで、プロジェクトの実施パターンが明らかになり、関係者全員で共有することが容易になります。シナリオという具体的な形で共有できるので、関係者はそれぞれの役割に応じて必要な準備や対応をとることも容易です。そうすれば、リスクが顕在化しても右往左往することは大幅に減ることでしょう。
 
 次回は、プロジェクト管理を対象に、基本の仕組みをどのようにして進化・深化させるかについて解説します。
 
 

   続きを読むには・・・


この記事の著者

石橋 良造

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

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


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

もっと見る
新規事業部を作れば済むと思っていないか~技術企業の高収益化:実践的な技術戦略の立て方(その18)

   【目次】 今回は、経営者的なリソース配分の解説です。面白い商品・事業を生み出すのに、優秀な経営者はどのように...

   【目次】 今回は、経営者的なリソース配分の解説です。面白い商品・事業を生み出すのに、優秀な経営者はどのように...


テーマの評価 技術企業の高収益化:実践的な技術戦略の立て方(その6)

  ◆ 儲かるテーマをどう見極めるのか  今回は、研究開発テーマの評価についてです。この記事を読んでいただく事で、研究開発テーマの評価方...

  ◆ 儲かるテーマをどう見極めるのか  今回は、研究開発テーマの評価についてです。この記事を読んでいただく事で、研究開発テーマの評価方...


発展段階「期」について 普通の組織をイノベーティブにする処方箋 (その63)

   今回も、「思い付く」ための「知識・経験を整理するフレームワーク」の解説です。今回は、発展段階(「期」)ついて解説します。 ◆関連解...

   今回も、「思い付く」ための「知識・経験を整理するフレームワーク」の解説です。今回は、発展段階(「期」)ついて解説します。 ◆関連解...


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

もっと見る
開発者が意識したい1日のスケジューリング(午後~夜編)

  前回の記事では一日の業務を有意義なものにするため、就業前の朝の時間と午前中の脳がフレッシュなうちにアイデア創出やメンバーとのコミュニケ...

  前回の記事では一日の業務を有意義なものにするため、就業前の朝の時間と午前中の脳がフレッシュなうちにアイデア創出やメンバーとのコミュニケ...


サブシステムの開発目標 プロジェクト管理の仕組み (その41)

 前回までで、化粧品の自販機についてシステムの内部構造を決めました。システム内部構造は、システムを独立したサブシステムにブレークダウンしたもので、ブロック...

 前回までで、化粧品の自販機についてシステムの内部構造を決めました。システム内部構造は、システムを独立したサブシステムにブレークダウンしたもので、ブロック...


羽のない扇風機が創られた時の目標設定、横並び競争と何が違うのか?

【目次】 1. 福原流QFDは技術者の創造性を引き出す技法 私も含めて我々技術者の思考は知らず知らずにうちに技術手段のHOWを考え...

【目次】 1. 福原流QFDは技術者の創造性を引き出す技法 私も含めて我々技術者の思考は知らず知らずにうちに技術手段のHOWを考え...