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

   続きを読むには・・・


この記事の著者

石橋 良造

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

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


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

もっと見る
技術系ビジネスリーダー養成とは 【連載記事紹介】

  技術系ビジネスリーダー養成の連載全てが無料でお読みいただけます!   ◆こんな方におすすめ!=技術者がリードすべき重要な...

  技術系ビジネスリーダー養成の連載全てが無料でお読みいただけます!   ◆こんな方におすすめ!=技術者がリードすべき重要な...


強みは未来志向で設定 普通の組織をイノベーティブにする処方箋 (その46)

        前々回からKETICモデルのK(Knowledge)の知識の3つの要素の内、「自社の強み」を...

        前々回からKETICモデルのK(Knowledge)の知識の3つの要素の内、「自社の強み」を...


ものづくり企業のR&Dと経営機能【厳選記事紹介】セミナーもご紹介

  ◆ものづくり企業のR&Dと経営機能 ものづくり企業のR&D現場において、管理手法の導入が活発です。古くは、QC、QF...

  ◆ものづくり企業のR&Dと経営機能 ものづくり企業のR&D現場において、管理手法の導入が活発です。古くは、QC、QF...


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

もっと見る
製品開発部へのカンバン導入記(その1)

        最近ビジネスの世界では、カンバンを使ってプロジェクトを管理しようとする動きがとても強いようで...

        最近ビジネスの世界では、カンバンを使ってプロジェクトを管理しようとする動きがとても強いようで...


スケールド・アジャイル・フレームワーク (SAFe) の導入開始

        はたして僕が勤める企業はスケールド・アジャイル・フレームワーク (SAFe) を上手く導入で...

        はたして僕が勤める企業はスケールド・アジャイル・フレームワーク (SAFe) を上手く導入で...


システム設計6 プロジェクト管理の仕組み (その38)

◆システム設計は仮説と検証の繰り返し     前回は、システム(ここでは製品も含めてシステムと呼ぶことにします)に必要とされる要件を漏れなく...

◆システム設計は仮説と検証の繰り返し     前回は、システム(ここでは製品も含めてシステムと呼ぶことにします)に必要とされる要件を漏れなく...