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

   続きを読むには・・・


この記事の著者

石橋 良造

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

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


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

もっと見る
製品設計におけるトレードオフのコントロール(その1)

 製品設計におけるトレードオフのコントロールを、今回と次回の2回に分けて解説します。   1.トレードオフを意識しながら製品設計するとは  製品...

 製品設計におけるトレードオフのコントロールを、今回と次回の2回に分けて解説します。   1.トレードオフを意識しながら製品設計するとは  製品...


影響を当える関係とは 普通の組織をイノベーティブにする処方箋(その93)

   現在、KETICモデルの中の「知識・経験を関係性で整理する」を解説しています。今回は、下記の「関係性の種類」の中の「(3)包含」につ...

   現在、KETICモデルの中の「知識・経験を関係性で整理する」を解説しています。今回は、下記の「関係性の種類」の中の「(3)包含」につ...


目的達成と自分の成長 普通の組織をイノベーティブにする処方箋 (その82)

 現在エドワード・デシの4段階理論に基づき、外発的動機付けから内発的動機付けを誘引する4つの段階を解説しています。 ◆関連解説記事『技術マネジメント...

 現在エドワード・デシの4段階理論に基づき、外発的動機付けから内発的動機付けを誘引する4つの段階を解説しています。 ◆関連解説記事『技術マネジメント...


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

もっと見る
作業要素の進捗分析1 プロジェクト管理の仕組み (その18)

 連載で、進捗管理に利用する基本メトリクスセット(図41)について解説を続けています。前回はソフトウェア開発における成果物メトリクスについて解説しました。...

 連載で、進捗管理に利用する基本メトリクスセット(図41)について解説を続けています。前回はソフトウェア開発における成果物メトリクスについて解説しました。...


開発者が意識したいスケジューリングのコツ(朝~午前編)

先日、ある開発リーダーからこんな相談がありました。「一日のスケジューリングをしても、当日になると急な会議やら雑務が入ってしまって仕事が進まないんだよ。...

先日、ある開発リーダーからこんな相談がありました。「一日のスケジューリングをしても、当日になると急な会議やら雑務が入ってしまって仕事が進まないんだよ。...


進捗管理の精度を上げる:第1回 プロジェクト管理の仕組み (その13)

 前回は進捗管理の基本的な考え方を紹介しました。今回は、この考え方にしたがってどのような方法で実際に進捗を把握できるのかを紹介したいと思います。具体的な話...

 前回は進捗管理の基本的な考え方を紹介しました。今回は、この考え方にしたがってどのような方法で実際に進捗を把握できるのかを紹介したいと思います。具体的な話...