プロジェクトの問題を見極める1 プロジェクト管理の仕組み (その23)

更新日

投稿日

 進捗管理のための基本メトリクスセットのひとつである開発工数メトリクスについて解説していますが、前回は、プロジェクト構造(WBS)軸とアクティビティ軸のそれぞれの視点で開発工数メトリクスをグラフ化した例を紹介しました。少しおさらいをしておきましょう。
 
R&D
図54. プロジェクト構造軸 工数推移
 
 図54のプロジェクト構造軸ごとの工数推移では、プロジェクトを構成しているサブグループ(ブロック)の工数の動きを把握することができ、機構サブグループ(ME)が最も早くから開発着手していたことや、開発初期段階である現時点では全体アーキテクチャ設計を担当しているシステムサブグループ(System)が開発作業の中心となっていることがわかりました。
 
R&D
図55. アクティビティ軸 工数推移
 
 図55のアクティビティごとの工数推移では、開発工程ごとの時間の使い方を見ることによって開発が適切に進んでいるかどうかを見ることができました。プロジェクト構造軸のグラフでは、システム設計である全体アーキテクチャを担当しているシステムサブグループがもっとも多くの工数(40 %程度)を使っていたのですが、アクティビティでみるとどの週もシステム設計は多くても 20 % 程度であり、基本設計や詳細設計にも同じくらいの割合で工数を使っていることがわかりました。システム設計が完了する前から基本設計や詳細設計に着手しており、システム設計の手戻りになる危険が高いと考えることができました。従って、もし、あなたがプロジェクトの責任者であれば、基本アーキテクチャを設計すべきシステムサブグループについての詳細と、基本アーキテクチャ設計が含まれるシステム設計についての詳細を確認するだろうと思います。そこで今回は、プロジェクト構造軸におけるシステムサブグループとアクティビティ軸におけるシステム設計を中心に開発工数メトリクスを使って、より詳細な状況分析をしてみましょう。
 
R&D
図57. システムサブグループのアクティビティ軸工数推移
 
 図57はプロジェクト構造軸からシステムサブグループだけを選択して、アクティビティ(開発工程)ごとの工数推移をグラフにしたものです。図55はプロジェクト全体のアクティビティごとの工数推移でしたが、プロジェクト構造軸を適切に設定しておくことでこのように特定のサブグループについて同様のグラフを作ることができるのです。さて、前述したようにシステムサブグループは基本アーキテクチャ設計、すなわち、システム設計に工数を割くべきなのですが、図57を見ると、システム設計をやっていないことがわかります。ほとんどゼロです。その代わりに工数を割いているのはプロジェクト管理とシステムテストであることがわかります。グラフに示している期間はプロジェクトの前半段階であり、システムサブグループが本来やるべき作業は構想やシステム設計のはずですから、プロジェクトの責任者としては放ってはおけない状況だと言えるでしょう。
 
 実際に事情を確かめたところ、プロジェクトリーダーは対外的な交渉や調整で忙しく、製品全体を見ているシステムサブグループがメンバーを10人程度抱えているプロジェクト内の管理作業をやらざるを得ない状況になっていることがわかりました。アーキテクチャという技術的なことだけでなく、プロジェクト管理面でもメンバーから頼られているためにプロジェクト管理の工数が多くなっているのです。そして、...
 進捗管理のための基本メトリクスセットのひとつである開発工数メトリクスについて解説していますが、前回は、プロジェクト構造(WBS)軸とアクティビティ軸のそれぞれの視点で開発工数メトリクスをグラフ化した例を紹介しました。少しおさらいをしておきましょう。
 
R&D
図54. プロジェクト構造軸 工数推移
 
 図54のプロジェクト構造軸ごとの工数推移では、プロジェクトを構成しているサブグループ(ブロック)の工数の動きを把握することができ、機構サブグループ(ME)が最も早くから開発着手していたことや、開発初期段階である現時点では全体アーキテクチャ設計を担当しているシステムサブグループ(System)が開発作業の中心となっていることがわかりました。
 
R&D
図55. アクティビティ軸 工数推移
 
 図55のアクティビティごとの工数推移では、開発工程ごとの時間の使い方を見ることによって開発が適切に進んでいるかどうかを見ることができました。プロジェクト構造軸のグラフでは、システム設計である全体アーキテクチャを担当しているシステムサブグループがもっとも多くの工数(40 %程度)を使っていたのですが、アクティビティでみるとどの週もシステム設計は多くても 20 % 程度であり、基本設計や詳細設計にも同じくらいの割合で工数を使っていることがわかりました。システム設計が完了する前から基本設計や詳細設計に着手しており、システム設計の手戻りになる危険が高いと考えることができました。従って、もし、あなたがプロジェクトの責任者であれば、基本アーキテクチャを設計すべきシステムサブグループについての詳細と、基本アーキテクチャ設計が含まれるシステム設計についての詳細を確認するだろうと思います。そこで今回は、プロジェクト構造軸におけるシステムサブグループとアクティビティ軸におけるシステム設計を中心に開発工数メトリクスを使って、より詳細な状況分析をしてみましょう。
 
R&D
図57. システムサブグループのアクティビティ軸工数推移
 
 図57はプロジェクト構造軸からシステムサブグループだけを選択して、アクティビティ(開発工程)ごとの工数推移をグラフにしたものです。図55はプロジェクト全体のアクティビティごとの工数推移でしたが、プロジェクト構造軸を適切に設定しておくことでこのように特定のサブグループについて同様のグラフを作ることができるのです。さて、前述したようにシステムサブグループは基本アーキテクチャ設計、すなわち、システム設計に工数を割くべきなのですが、図57を見ると、システム設計をやっていないことがわかります。ほとんどゼロです。その代わりに工数を割いているのはプロジェクト管理とシステムテストであることがわかります。グラフに示している期間はプロジェクトの前半段階であり、システムサブグループが本来やるべき作業は構想やシステム設計のはずですから、プロジェクトの責任者としては放ってはおけない状況だと言えるでしょう。
 
 実際に事情を確かめたところ、プロジェクトリーダーは対外的な交渉や調整で忙しく、製品全体を見ているシステムサブグループがメンバーを10人程度抱えているプロジェクト内の管理作業をやらざるを得ない状況になっていることがわかりました。アーキテクチャという技術的なことだけでなく、プロジェクト管理面でもメンバーから頼られているためにプロジェクト管理の工数が多くなっているのです。そして、システムテストが多いのは、規格認定試験を行う時期が迫っており、そのための環境整備や動作確認などに工数をとられているということでした。予定しているリリース時期から逆算するとこの時期に規格認定試験を受けることになるのはわかっていたのですが、その準備や対応に予想以上に工数がかかっているというわけです。システムサブグループはこのような事情を抱えているのですが、結果的にシステムサブグループは本来業務である構想やシステム設計に工数を割くことができず、目の前の、半ば場当たり的な作業に追われている状況になっていることは間違いありません。
 
 次回は、プロジェクトの問題を見極める2を解説します。
 
 

   続きを読むには・・・


この記事の著者

石橋 良造

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

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


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

もっと見る
技術文書の品質管理(その4)技術文書の品質管理の必要性

  【目次】 今回は、技術文書の品質管理の必要性について解説します。   1. 製造業での品質管理 製造...

  【目次】 今回は、技術文書の品質管理の必要性について解説します。   1. 製造業での品質管理 製造...


情報コンテンツ 見えてきた、2030年の技術社会 (その4)

  【見えてきた、2030年の技術社会 連載目次】 1.  自動車業界のパラダイムシフト 2.  シェアリングエコ...

  【見えてきた、2030年の技術社会 連載目次】 1.  自動車業界のパラダイムシフト 2.  シェアリングエコ...


アイディアを共有する組織づくり 新規事業・新商品を生み出す技術戦略(その30)

        新規事業や新商品のアイディアをいかに発想するかについて紹介して参りましたが、今回はアイディア...

        新規事業や新商品のアイディアをいかに発想するかについて紹介して参りましたが、今回はアイディア...


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

もっと見る
製品開発部へのカンバン導入記(その2)

        前回からの続きです。前回は製品開発部がカンバンを導入するに至った簡単な経緯と、最初の問題点(...

        前回からの続きです。前回は製品開発部がカンバンを導入するに至った簡単な経緯と、最初の問題点(...


設計部門とリスク管理(その2)

【設計部門とリスク管理 連載目次】 1. リスク管理とは目標達成までのシナリオ作成 2. コンティンジェンシープランの注意事項 3. リスク管理...

【設計部門とリスク管理 連載目次】 1. リスク管理とは目標達成までのシナリオ作成 2. コンティンジェンシープランの注意事項 3. リスク管理...


手段としてのオープンイノベーション

【ものづくり企業のR&Dと経営機能 記事目次】 管理力より技術力を磨け 技術プラットフォームの重要性 手段としてのオープンイノベーション...

【ものづくり企業のR&Dと経営機能 記事目次】 管理力より技術力を磨け 技術プラットフォームの重要性 手段としてのオープンイノベーション...