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

更新日

投稿日

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

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

 
 前回のその1に続いて解説します。 図27のように、プロジェクトの流れを変える種々のリスクに対して予防策とコンティンジェンシープランを計画する作業は、今回のテーマであるプロジェクト・シナリオに強く関係しますので、詳細を解説します。
 
              R&D
  図27.プロジェクトの流れを変えるリスク
 

1.予防策を検討するときの注意点

 
(1) 何をするのかを具体的に記述する
 
 「常に状況を把握する」「定期的に報告を受ける」というような抽象的なアクションではなく、リスクを発生させないためにできることや、リスク発生に備えてやっておくことを具体的に記述します。たとえば、「○○の測定値に対する目標値とその実績を毎週報告させる」「毎週、目標達成できない場合は××部長とのレビュー会議を開催する」などです。
 
(2) 予防策を実施する期間、期限を明確にします
 
 リスクが顕在化する時期を明確にすることは困難ですが、リスク対応の期限を明確にして、その期限までに変化がなければリスクが顕在化したと考えて対応をとった方が良い場合が多いでしょう。判断を引き延ばすことがないように期限を設定します。
 
(3) 複数の予防策を検討します
 
 リスクは発生しないのであればそれに越したことはないのですが、重大なリスクほど、顕在化したときは多大な手戻り作業が発生することになるため、できるだけ多くの予防策を実施できるようにしておきましょう。
 

2.コンティンジェンシープランの注意事項

 
(1) 何をするのかを具体的に記述します
 
 「○○についての仕様変更」「次の試作で対応」というような抽象的なアクションではなく、「○○についての測定結果をもとに出力電流優先と安定時間優先の選択を行う。そのための基礎データを事前に収集・整理しておく。」というように、具体的な記述にします。
 
(2) 実施する期限を明確にします
 
 コンティンジェンシープランはリスク発生後に行うアクションです、その実施には期限(有効期間)が存在する場合があります。たとえば、追加の試作をコンティンジェンシープランとするときでも、1ヶ月しか、リリースを遅らせることができない場合があるでしょう。このような場合は追加試作のためのアクションは期限を意識したものになります。
 
(3) 予防策が実施できない場合の対応を検討します
 
 予防策が実施できない状況に陥った場合、追加の対策を実施する必要があります。このような追加対策もコンティンジェンシープランとして記述しておきます。ちなみに、予防策が実施できない状況に陥った場合、コンティンジェンシープランを前倒しで実施した方が手戻りを必要最小限に抑えることが多いようです。
 
(4) 予防策が機能しない場合の対応を検討します
 
 予防策がリスクの発生を抑制する効果がほとんどないことがわかったときに、どのようなアクションをとるのかを決めておきます。予防策を形式的に実施するだけになる状況を避けるためです。
 
(5) 複数の視点で対応を検討します
 
 品質、費用、リソース、納期などはもちろん、コミュニケーション方法や根回し方法など様々な視点からコンティンジェンシープランを検討することが重要です。リスクが顕在化したときには次々と対応をとる必要があることが多く、対応方法の選...

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

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

 
 前回のその1に続いて解説します。 図27のように、プロジェクトの流れを変える種々のリスクに対して予防策とコンティンジェンシープランを計画する作業は、今回のテーマであるプロジェクト・シナリオに強く関係しますので、詳細を解説します。
 
              R&D
  図27.プロジェクトの流れを変えるリスク
 

1.予防策を検討するときの注意点

 
(1) 何をするのかを具体的に記述する
 
 「常に状況を把握する」「定期的に報告を受ける」というような抽象的なアクションではなく、リスクを発生させないためにできることや、リスク発生に備えてやっておくことを具体的に記述します。たとえば、「○○の測定値に対する目標値とその実績を毎週報告させる」「毎週、目標達成できない場合は××部長とのレビュー会議を開催する」などです。
 
(2) 予防策を実施する期間、期限を明確にします
 
 リスクが顕在化する時期を明確にすることは困難ですが、リスク対応の期限を明確にして、その期限までに変化がなければリスクが顕在化したと考えて対応をとった方が良い場合が多いでしょう。判断を引き延ばすことがないように期限を設定します。
 
(3) 複数の予防策を検討します
 
 リスクは発生しないのであればそれに越したことはないのですが、重大なリスクほど、顕在化したときは多大な手戻り作業が発生することになるため、できるだけ多くの予防策を実施できるようにしておきましょう。
 

2.コンティンジェンシープランの注意事項

 
(1) 何をするのかを具体的に記述します
 
 「○○についての仕様変更」「次の試作で対応」というような抽象的なアクションではなく、「○○についての測定結果をもとに出力電流優先と安定時間優先の選択を行う。そのための基礎データを事前に収集・整理しておく。」というように、具体的な記述にします。
 
(2) 実施する期限を明確にします
 
 コンティンジェンシープランはリスク発生後に行うアクションです、その実施には期限(有効期間)が存在する場合があります。たとえば、追加の試作をコンティンジェンシープランとするときでも、1ヶ月しか、リリースを遅らせることができない場合があるでしょう。このような場合は追加試作のためのアクションは期限を意識したものになります。
 
(3) 予防策が実施できない場合の対応を検討します
 
 予防策が実施できない状況に陥った場合、追加の対策を実施する必要があります。このような追加対策もコンティンジェンシープランとして記述しておきます。ちなみに、予防策が実施できない状況に陥った場合、コンティンジェンシープランを前倒しで実施した方が手戻りを必要最小限に抑えることが多いようです。
 
(4) 予防策が機能しない場合の対応を検討します
 
 予防策がリスクの発生を抑制する効果がほとんどないことがわかったときに、どのようなアクションをとるのかを決めておきます。予防策を形式的に実施するだけになる状況を避けるためです。
 
(5) 複数の視点で対応を検討します
 
 品質、費用、リソース、納期などはもちろん、コミュニケーション方法や根回し方法など様々な視点からコンティンジェンシープランを検討することが重要です。リスクが顕在化したときには次々と対応をとる必要があることが多く、対応方法の選択肢を数多く持っていることは安心につながります。
 
 上記のように、『予防策とコンティンジェンシープラン』を考慮することは、時間の掛かる作業です。しかし、ここでしっかりと検討してあれば、プロジェクトが始まった後で何が起こっても『冷静に対応』できるようになります。
 
 次回は、リスク管理マスターについて解説します。
 
 

   続きを読むには・・・


この記事の著者

石橋 良造

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

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


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

もっと見る
大学へのマーケティング 新規事業・新商品を生み出す技術戦略(その51)

        今回は新規事業のアイディアを出す上で、マーケティング対象となりえる大学へのアプローチについて...

        今回は新規事業のアイディアを出す上で、マーケティング対象となりえる大学へのアプローチについて...


段取り力で差がつく設計ルール 新規事業・新商品を生み出す技術戦略(その31)

        今回は開発、設計の「ルール」についてです。    既存の商品設計には当たり前で...

        今回は開発、設計の「ルール」についてです。    既存の商品設計には当たり前で...


自社の存在意義とは 普通の組織をイノベーティブにする処方箋 (その111)

   前回は企業でイノベーションを起こすには、「自社の存在意義」を徹底して問い直すこが重要であるという解説をしました。しかし、「自社の存在...

   前回は企業でイノベーションを起こすには、「自社の存在意義」を徹底して問い直すこが重要であるという解説をしました。しかし、「自社の存在...


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

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

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

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


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

 前回でシステム設計の位置づけが明確になったと思いますので、次に、多くの開発現場で起きているシステム設計の問題について考えてみたいと思います。次のようなこ...

 前回でシステム設計の位置づけが明確になったと思いますので、次に、多くの開発現場で起きているシステム設計の問題について考えてみたいと思います。次のようなこ...


IoT 時代の製品開発とは - カギとなるデータ指向とシステム設計 -

   今回は、BtoB のビジネスをベースにハードウェア開発を中心としていたメーカーが IoT に対応した製品開発にシフトする際のカギとなるデ...

   今回は、BtoB のビジネスをベースにハードウェア開発を中心としていたメーカーが IoT に対応した製品開発にシフトする際のカギとなるデ...