設計部門と組織政治の影響(その3)

更新日

投稿日

 

◆政治的要因の検討で決まるスケジュールの確度・精度

 
 日程を決めるときには、仕組み構築のロジックやシステム化の技術的な側面だけではなく、組織や人を含めた大局的な視点が必要になります。これを政治的要因の検討が必要だと表現しているわけです。もうお気づきの方も多いと思いますが、これは、『リスク管理』を行うということです。リスク管理とは、図26のような仕組みから成り立っています。
 
               R&D
図26.リスク管理の概要
 
A. 想定外のイベント(リスク)を可能な限りリストアップし、その一つひとつに対して、リスクが顕在
   化する可能性、顕在化したときの影響度合いなどを評価して、リスクの重大性を分析する。

 

B. 個々のリスクに対して、顕在化しないための予防策と、顕在化した後の影響を軽減するための対応策
   を検討する。
C. リスクの状態を継続的に監視する。
 
 今回の政治的要因の検討というのは、ここでいうAとBを実施することに他なりません。このように書くと、リスク管理は、「すでに仕組み化できて、今回のようなことは実施している」という反応が多いかもしれません。しかし、「リスク管理シートを作って管理しています」「進捗会議でリスク管理をやっています」というように「リスク管理」という単語を使っているだけで、リスク管理をやっていると考えている組織が非常に多いのが現実です。「リスク管理」がマジックワードになってしまい、この言葉を使うと思考停止状態になっているのです。
 
 リスク管理ができている組織というのは、次のようなことを実施しています。リスクを洗い出してその重大性を評価し、事前の予防策、事後の対応策を文書化(一元管理)し、進捗会議で定期的にアップデートする。しかし、このようなリスク管理の仕組みは課題管理とは何が違うのでしょうか。課題管理は問題が起きた後の管理で、リスク管理は問題が起きる前の管理という違いはありますが、管理手法としての違いはほとんどないため課題管理として、ひとつにしても良いくらいです。実際、課題とリスクと一緒に管理していることも少なくありません。
 
 リスク管理は、想定外のことを極力なくすことが目的です。何が起きても想定の範囲内なので、右往左往せず落ち着いて計画通りに対応できる準備をしておくためのものです。したがって、リスクを計画に反映できているかどうか、そして、その計画を関係者の間で共有できているかどうか重要です。つまり、リスク管理を実施することが、計画の精度や確度を保証することにつながっていないと意味がありません。では、リスクを計画(スケジュール)に反映させるとはどういうことでしょうか。図27により、解説します。
 
                     R&D
図27.プロジェクトの流れを変えるものがリスク
 
 リスクが顕在化すると計画していた通りには進まないため、システム化なり仕組化なり、プロジェクトの流れが変わってしまいます。リスクが顕在化するポイントはプロジェクトの流れ(進み方)の分岐点ということです。一連のリスクによりいくつもの分岐が存在し、プロジェクトの進み方には何通りもの可能性があります。図27では、このプロジェクトにはリスクのために7通りの進み方が存在することがわかります。
 
 図27は単純化しており実際はもっと複雑ですが、重要なのは、リスクはプロジェクトの進み方を変えるものであり、プロジェクトの進み方としてどのような可能性があるのか、そして、その可能性を考慮して計画(スケジュール)を立てるということです。図27ではリスクにより7通りのプロジェクトの進み方があること...
 

◆政治的要因の検討で決まるスケジュールの確度・精度

 
 日程を決めるときには、仕組み構築のロジックやシステム化の技術的な側面だけではなく、組織や人を含めた大局的な視点が必要になります。これを政治的要因の検討が必要だと表現しているわけです。もうお気づきの方も多いと思いますが、これは、『リスク管理』を行うということです。リスク管理とは、図26のような仕組みから成り立っています。
 
               R&D
図26.リスク管理の概要
 
A. 想定外のイベント(リスク)を可能な限りリストアップし、その一つひとつに対して、リスクが顕在
   化する可能性、顕在化したときの影響度合いなどを評価して、リスクの重大性を分析する。

 

B. 個々のリスクに対して、顕在化しないための予防策と、顕在化した後の影響を軽減するための対応策
   を検討する。
C. リスクの状態を継続的に監視する。
 
 今回の政治的要因の検討というのは、ここでいうAとBを実施することに他なりません。このように書くと、リスク管理は、「すでに仕組み化できて、今回のようなことは実施している」という反応が多いかもしれません。しかし、「リスク管理シートを作って管理しています」「進捗会議でリスク管理をやっています」というように「リスク管理」という単語を使っているだけで、リスク管理をやっていると考えている組織が非常に多いのが現実です。「リスク管理」がマジックワードになってしまい、この言葉を使うと思考停止状態になっているのです。
 
 リスク管理ができている組織というのは、次のようなことを実施しています。リスクを洗い出してその重大性を評価し、事前の予防策、事後の対応策を文書化(一元管理)し、進捗会議で定期的にアップデートする。しかし、このようなリスク管理の仕組みは課題管理とは何が違うのでしょうか。課題管理は問題が起きた後の管理で、リスク管理は問題が起きる前の管理という違いはありますが、管理手法としての違いはほとんどないため課題管理として、ひとつにしても良いくらいです。実際、課題とリスクと一緒に管理していることも少なくありません。
 
 リスク管理は、想定外のことを極力なくすことが目的です。何が起きても想定の範囲内なので、右往左往せず落ち着いて計画通りに対応できる準備をしておくためのものです。したがって、リスクを計画に反映できているかどうか、そして、その計画を関係者の間で共有できているかどうか重要です。つまり、リスク管理を実施することが、計画の精度や確度を保証することにつながっていないと意味がありません。では、リスクを計画(スケジュール)に反映させるとはどういうことでしょうか。図27により、解説します。
 
                     R&D
図27.プロジェクトの流れを変えるものがリスク
 
 リスクが顕在化すると計画していた通りには進まないため、システム化なり仕組化なり、プロジェクトの流れが変わってしまいます。リスクが顕在化するポイントはプロジェクトの流れ(進み方)の分岐点ということです。一連のリスクによりいくつもの分岐が存在し、プロジェクトの進み方には何通りもの可能性があります。図27では、このプロジェクトにはリスクのために7通りの進み方が存在することがわかります。
 
 図27は単純化しており実際はもっと複雑ですが、重要なのは、リスクはプロジェクトの進み方を変えるものであり、プロジェクトの進み方としてどのような可能性があるのか、そして、その可能性を考慮して計画(スケジュール)を立てるということです。図27ではリスクにより7通りのプロジェクトの進み方があることを示していますが、この一つひとつを「シナリオ」と呼びましょう。プロジェクトのシナリオを明らかにしてスケジュールとして具体化することが、リスクをスケジュールに反映させるということです。
 
 次回は具体的な例を使って、シナリオとスケジュールについて解説します。
 
 

   続きを読むには・・・


この記事の著者

石橋 良造

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

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


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

もっと見る
位置関係-2 普通の組織をイノベーティブにする処方箋 (その105)

   現在、KETICモデルの中の「知識・経験を関係性で整理する」を解説しています。前回からは、KETICモデルの中の空間的な「位置(関係...

   現在、KETICモデルの中の「知識・経験を関係性で整理する」を解説しています。前回からは、KETICモデルの中の空間的な「位置(関係...


製品開発における失敗と戻り工程の考え方

    今回は新商品開発における成功度と成功しなかったときの戻り工程についてお伝えします。   まずは顧客価値創...

    今回は新商品開発における成功度と成功しなかったときの戻り工程についてお伝えします。   まずは顧客価値創...


、技術マーケティングとは 技術企業の高収益化:実践的な技術戦略の立て方(その8)

  ◆ お肉屋さんに学ぶ技術マーケティング  今回は、技術マーケティングについて解説します。技術戦略を固定観念にとらわれることなく合理的...

  ◆ お肉屋さんに学ぶ技術マーケティング  今回は、技術マーケティングについて解説します。技術戦略を固定観念にとらわれることなく合理的...


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

もっと見る
プロジェクトの計画策定 プロジェクト管理の仕組み (その3)

 前回のその2:CMMIの要件管理に続いて、プロジェクトの計画策定について解説します。CMMIでは次のことができている必要があります。   ...

 前回のその2:CMMIの要件管理に続いて、プロジェクトの計画策定について解説します。CMMIでは次のことができている必要があります。   ...


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

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

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


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

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

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