作業要素の進捗分析2 プロジェクト管理の仕組み (その19)

更新日

投稿日

  前回のその18:作業要素の進捗分析1に続いて解説します。
 
 図50は製品構造の観点から管理単位にブレークダウンした例です。製品がどのようなモジュールから成り立っているかを示しているのでモジュール構造ということができます。製品構造の観点からのブレークダウンは、適切なモジュール構造となるような管理単位に分けるということになります。適切なモジュール構造は、個々のモジュールが実現している機能がそのモジュール内では強い関連を持っていて、他のモジュールとのつながりはシンプルなインタフェースやプロトコルで表現できるという特徴を持っています。図50 は簡略化した内容ですが、「Start」や「Stop」などのシンプルなコマンドだけでモジュールがつながっており、そのコマンドで実行されるモジュール機能は、図では書いていませんが、モジュール名に関係した機能を集めたものになっています。
 
R&D
図50.製品構造から見た分類
 
 そして、適切なモジュール構造がそのままプロジェクトにおける管理単位(進捗管理の単位)となっているのが理想的なプロジェクト体制なのです。この例の場合、プロジェクトが図51に示すようなチームに分かれているのが理想となります。もちろん、実際のプロジェクトでは、評価チームや部品管理チームなど、図51に示す以外にも様々なチームを必要とすることはありますが、基本的なチーム編成が製品のモジュール構造に合っているということです。
 
R&D
図51.製品構造に合わせた開発体制
 
 そもそも適切なモジュールというのは、実現する機能が固まっていて他のモジュールとの関係がシンプルになっているという性質を持っているのですから、開発を行うチームとしてもそれに合わせるのが都合が良いはずです。さらに、このチームが電気・電子担当、機構担当、ソフト担当の混成チームになっていれば、よりよい体制になります。このレベルを実現するのは相当大変です。
 
 作業要素メトリクスとして機能させるには、このようにプロジェクト全体をいくつかのチームに分解して、それぞれのチームの開発作業が開発スケジュール上で区別さ...
  前回のその18:作業要素の進捗分析1に続いて解説します。
 
 図50は製品構造の観点から管理単位にブレークダウンした例です。製品がどのようなモジュールから成り立っているかを示しているのでモジュール構造ということができます。製品構造の観点からのブレークダウンは、適切なモジュール構造となるような管理単位に分けるということになります。適切なモジュール構造は、個々のモジュールが実現している機能がそのモジュール内では強い関連を持っていて、他のモジュールとのつながりはシンプルなインタフェースやプロトコルで表現できるという特徴を持っています。図50 は簡略化した内容ですが、「Start」や「Stop」などのシンプルなコマンドだけでモジュールがつながっており、そのコマンドで実行されるモジュール機能は、図では書いていませんが、モジュール名に関係した機能を集めたものになっています。
 
R&D
図50.製品構造から見た分類
 
 そして、適切なモジュール構造がそのままプロジェクトにおける管理単位(進捗管理の単位)となっているのが理想的なプロジェクト体制なのです。この例の場合、プロジェクトが図51に示すようなチームに分かれているのが理想となります。もちろん、実際のプロジェクトでは、評価チームや部品管理チームなど、図51に示す以外にも様々なチームを必要とすることはありますが、基本的なチーム編成が製品のモジュール構造に合っているということです。
 
R&D
図51.製品構造に合わせた開発体制
 
 そもそも適切なモジュールというのは、実現する機能が固まっていて他のモジュールとの関係がシンプルになっているという性質を持っているのですから、開発を行うチームとしてもそれに合わせるのが都合が良いはずです。さらに、このチームが電気・電子担当、機構担当、ソフト担当の混成チームになっていれば、よりよい体制になります。このレベルを実現するのは相当大変です。
 
 作業要素メトリクスとして機能させるには、このようにプロジェクト全体をいくつかのチームに分解して、それぞれのチームの開発作業が開発スケジュール上で区別されている必要があります。簡単に表現すると、プロジェクト管理の基本単位が明確になっていて、その単位は製品構造との関連づけが明確になっているということです。これができていれば、製品構造上の必要な範囲(単位)で進捗を見ることができ、その範囲のチームメンバーおよび進捗責任も明らかです。
 
 次回は、作業要素の進捗分析3です。
 
 

   続きを読むには・・・


この記事の著者

石橋 良造

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

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


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

もっと見る
製品開発とコストダウン(その3)

◆コストダウンのための仕組み作り    コストダウンを容易に検討できる仕組みについて解説します。製品開発のステップをもう一度思い出して下さい...

◆コストダウンのための仕組み作り    コストダウンを容易に検討できる仕組みについて解説します。製品開発のステップをもう一度思い出して下さい...


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

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

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


思考パターン 普通の組織をイノベーティブにする処方箋 (その75)

 現在、関係性の種類を解説しています。前回は関係性の種類の一つ「原因と結果」の中の「逆ピラミッド(複数の原因→一つの結果)」が起こる3つの要...

 現在、関係性の種類を解説しています。前回は関係性の種類の一つ「原因と結果」の中の「逆ピラミッド(複数の原因→一つの結果)」が起こる3つの要...


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

もっと見る
開発部門の管理職が学ぶべきこととは

  今回は、新任の開発課長が学ぶべきこと、課長就任前に3週間で準備をすべきこと、さらには課長就任後に取り組むべきことについて解説します。 &...

  今回は、新任の開発課長が学ぶべきこと、課長就任前に3週間で準備をすべきこと、さらには課長就任後に取り組むべきことについて解説します。 &...


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

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

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


進捗の見える化:第2回 プロジェクト管理の仕組み (その11)

 進捗の見える化ですが、前回のその10に続いて解説します。今回考えるべきポイントは、可視化・見える化の方法です。図40 に示しているように、進捗管理では予...

 進捗の見える化ですが、前回のその10に続いて解説します。今回考えるべきポイントは、可視化・見える化の方法です。図40 に示しているように、進捗管理では予...