設計部門と組織政治の影響(その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通りのプロジェクトの進み方があることを示していますが、この一つひとつを「シナリオ」と呼びましょう。プロジェクトのシナリオを明らかにしてスケジュールとして具体化することが、リスクをスケジュールに反映させるということです。
 
 次回は具体的な例を使って、シナリオとスケジュールについて解説します。
 
 

   続きを読むには・・・


この記事の著者

石橋 良造

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

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


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

もっと見る
開発中こそ気づきを記録する 新規事業・新商品を生み出す技術戦略(その32)

        今回は開発中にやっておくべき「気づきメモ」について解説します。    開発が始...

        今回は開発中にやっておくべき「気づきメモ」について解説します。    開発が始...


クレーム率シングルppmをゼロに(10) 【快年童子の豆鉄砲】(その65)

  【連関図法で把握した原因に対する対策のまとめ】 【この連載の前回:【快年童子の豆鉄砲】(その64)へのリンク】 【連載記事】・新Q...

  【連関図法で把握した原因に対する対策のまとめ】 【この連載の前回:【快年童子の豆鉄砲】(その64)へのリンク】 【連載記事】・新Q...


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

        今回は、前回から引き続き「どう強みを未来志向で設定するのか」を解説します。前回は「将来に向か...

        今回は、前回から引き続き「どう強みを未来志向で設定するのか」を解説します。前回は「将来に向か...


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

もっと見る
システム設計1 プロジェクト管理の仕組み (その33)

 コンサルタントとして多くの開発現場に入ると、普段使っている単語、もしくは意味しているものが開発現場によって想像以上に違うことを実感します。たとえば、「レ...

 コンサルタントとして多くの開発現場に入ると、普段使っている単語、もしくは意味しているものが開発現場によって想像以上に違うことを実感します。たとえば、「レ...


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

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

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


仕組みの見直しに成功する組織1 プロジェクト管理の仕組み (その25)

 この連載では、仕組みの見直しをテーマに様々な考え方や事例を紹介しているわけですが、実際にコンサルタントして仕組みの見直しに取り組んだ組織の中には成功して...

 この連載では、仕組みの見直しをテーマに様々な考え方や事例を紹介しているわけですが、実際にコンサルタントして仕組みの見直しに取り組んだ組織の中には成功して...