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

   続きを読むには・・・


この記事の著者

石橋 良造

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

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


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

もっと見る
思い付くには何が必要か 普通の組織をイノベーティブにする処方箋 (その60)

   前回は思考の構成要素として、「その1:思い付く」と「その2:思い付いたことの発展」があるという話をしました。今回からは「その1:思い...

   前回は思考の構成要素として、「その1:思い付く」と「その2:思い付いたことの発展」があるという話をしました。今回からは「その1:思い...


普通の組織をイノベーティブにする処方箋 (その24)

 前回はKETICモデルの中の知識(Knowledge)の内、技術知識について解説しました。その中で、3Mや村田製作所のイノベーションの実現に向けての仕組...

 前回はKETICモデルの中の知識(Knowledge)の内、技術知識について解説しました。その中で、3Mや村田製作所のイノベーションの実現に向けての仕組...


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

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

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


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

もっと見る
技術系リーダーとして身に付けておくべきスキルとは

        企業の成長のためには、従来の事業の延長線上に留まることなく、積極的に新製品や新規事業の創出、...

        企業の成長のためには、従来の事業の延長線上に留まることなく、積極的に新製品や新規事業の創出、...


‐顧客の難しい要求に取り組む ‐  製品・技術開発力強化策の事例(その2)

 前回の事例その1に続いて解説します。顧客から難しい要求や相談があったとき、意欲的にその問題に取り組む企業がある。その取組みから他社では出来ないよ...

 前回の事例その1に続いて解説します。顧客から難しい要求や相談があったとき、意欲的にその問題に取り組む企業がある。その取組みから他社では出来ないよ...


擦り合わせ型と組み合わせ型 目指すべき開発体制とは(その1)

  【目指すべき開発体制 連載目次】 目指すべき開発体制とは(その1)擦り合わせ型と組み合わせ型 目指すべき開発体制とは(その2)日本企業文化を...

  【目指すべき開発体制 連載目次】 目指すべき開発体制とは(その1)擦り合わせ型と組み合わせ型 目指すべき開発体制とは(その2)日本企業文化を...