作業要素の進捗分析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です。
 
 

   続きを読むには・・・


この記事の著者

石橋 良造

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

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


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

もっと見る
知識・経験を関係性で整理する 普通の組織をイノベーティブにする処方箋 (その71)

 今回からKETICモデルの「思考」の中の、「知識・経験を関係性で整理する」について解説をします。前回までに解説した時系列や物理量などで整理した要素を...

 今回からKETICモデルの「思考」の中の、「知識・経験を関係性で整理する」について解説をします。前回までに解説した時系列や物理量などで整理した要素を...


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

 前回は形式知の問題点の解説しましたが、今回はイノベーションを起こす上で必要となる5つの要素についてです。 ◆関連解説『技術マネジメントとは』 &nb...

 前回は形式知の問題点の解説しましたが、今回はイノベーションを起こす上で必要となる5つの要素についてです。 ◆関連解説『技術マネジメントとは』 &nb...


トヨタ発のフロントローディングとは。方法やメリット・落とし穴を解説

【目次】 製造プロセスにおける設計部門を中心とした業務を表す開発の初期段階であるエンジニアリングチェーンエンジニアリングチェーン( ...

【目次】 製造プロセスにおける設計部門を中心とした業務を表す開発の初期段階であるエンジニアリングチェーンエンジニアリングチェーン( ...


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

もっと見る
技術者の逆襲:イノベーションの必要性とは

  ◆ 現場からのイノベーション  最近、様々な場所でイノベーションという言葉を聞きます。普通の技術者にとって、イノベーションは技術革新や技術によって...

  ◆ 現場からのイノベーション  最近、様々な場所でイノベーションという言葉を聞きます。普通の技術者にとって、イノベーションは技術革新や技術によって...


設計部門の仕組み構築(その1)

【設計部門の仕組み構築 連載目次】 1. 設計部門の仕組み構築 2. 設計部門の仕組み構築(解決すべき根本原因) 3. 設計部門の仕組み構築(具...

【設計部門の仕組み構築 連載目次】 1. 設計部門の仕組み構築 2. 設計部門の仕組み構築(解決すべき根本原因) 3. 設計部門の仕組み構築(具...


技術資源の有効活用: 事例紹介 (その2)

 TRM(Technology Resources Management)事例その2は、建築物の防食事業を営む企業の取り組みをご紹介いたします。   ...

 TRM(Technology Resources Management)事例その2は、建築物の防食事業を営む企業の取り組みをご紹介いたします。   ...