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

   続きを読むには・・・


この記事の著者

石橋 良造

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

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


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

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

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

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


オープン・イノベーションを社内で実現する方法  研究テーマの多様な情報源(その29)

1.自社のコア技術を外部に発信する理由    前回のその28に続いて解説します。それでは、まず自社のコア技術を外部に発信する理由は何なのでし...

1.自社のコア技術を外部に発信する理由    前回のその28に続いて解説します。それでは、まず自社のコア技術を外部に発信する理由は何なのでし...


新規事業に本気にならないのは誰のせいか~技術企業の高収益化:実践的な技術戦略の立て方(その35)

   【目次】 ▼さらに深く学ぶなら!「技術マネジメント」に関するセミナーはこちら! ▼さらに幅広く学ぶなら!「...

   【目次】 ▼さらに深く学ぶなら!「技術マネジメント」に関するセミナーはこちら! ▼さらに幅広く学ぶなら!「...


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

もっと見る
成功体験が重荷となる製品開発プロセス(その2)

◆ 解決策    成功体験が重荷となる製品開発プロセス(その1:現状の課題)では、スマートフォンで起きていることを例にして、従来の組み込みソ...

◆ 解決策    成功体験が重荷となる製品開発プロセス(その1:現状の課題)では、スマートフォンで起きていることを例にして、従来の組み込みソ...


‐企業内に発生している問題点を徹底的に追求 ‐  製品・技術開発力強化策の事例(その3)

 前回の事例その2に続いて解説します。企業内では解決が容易でない様々な問題が生じています。しかし、これらの問題解決に取り組まない限り、競争に勝つことが出来...

 前回の事例その2に続いて解説します。企業内では解決が容易でない様々な問題が生じています。しかし、これらの問題解決に取り組まない限り、競争に勝つことが出来...


成功体験が重荷となる製品開発プロセス(その1)

◆ 現状の課題    スマートフォンの開発マネジメント支援を行った経験から、従来の製品開発のやり方を踏襲した改善では問題の根本解決は難しいと...

◆ 現状の課題    スマートフォンの開発マネジメント支援を行った経験から、従来の製品開発のやり方を踏襲した改善では問題の根本解決は難しいと...