プロジェクトの問題を見極める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を解説します。
 
 

   続きを読むには・・・


この記事の著者

石橋 良造

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

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


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

もっと見る
嗅覚 普通の組織をイノベーティブにする処方箋 (その153)

  現在、イノベーション実現に向けての「思考の頻度を高める方法」を解説していますが、そのための2つ目の要素「同じ一つの行動をするにしても思...

  現在、イノベーション実現に向けての「思考の頻度を高める方法」を解説していますが、そのための2つ目の要素「同じ一つの行動をするにしても思...


研究開発部門がとるべきリーダーシップの型、新規事業・新商品を生み出す技術戦略(その97)

【この連載の前回、事業アイディアの企画を後押しする要素、新規事業・新商品を生み出す技術戦略(その96)へのリンク】 ▼さらに深く学ぶなら!「技術マネ...

【この連載の前回、事業アイディアの企画を後押しする要素、新規事業・新商品を生み出す技術戦略(その96)へのリンク】 ▼さらに深く学ぶなら!「技術マネ...


機能要件と非機能要件 設計機能(その5)

【設計機能 連載目次】 設計機能(その1)機能とは  設計機能(その2)設計上の機会損失  設計機能(その3)機能の分類&n...

【設計機能 連載目次】 設計機能(その1)機能とは  設計機能(その2)設計上の機会損失  設計機能(その3)機能の分類&n...


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

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

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

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


追求するのは擦り合わせ能力を活かすマネジメント(その3)

 前回のその2に続いて解説します。図15は製品開発(設計)における調整の仕組みを詳細化したものです。「可視化」「分析」「視点切り替え」3つの要素から成り立...

 前回のその2に続いて解説します。図15は製品開発(設計)における調整の仕組みを詳細化したものです。「可視化」「分析」「視点切り替え」3つの要素から成り立...


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

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

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