コラム
グローバル化は設計・製造の仕組みを見直すチャンス
【第20回】隠れているプロジェクト全体の問題を見極める
株式会社RDPi 代表取締役 石橋 良造
2009.03.26
図57はプロジェクト構造軸からシステムサブグループだけを選択して、アクティビティ(開発工程)ごとの工数推移をグラフにしたものです。図55はプロジェクト全体のアクティビティごとの工数推移でしたが、プロジェクト構造軸を適切に設定しておくことでこのように特定のサブグループについて同様のグラフを作ることができるのです。
さて、前述したようにシステムサブグループは基本アーキテクチャ設計、すなわち、システム設計に工数を割くべきなのですが、図57を見ると、システム設計をやっていないことがわかります。ほとんどゼロです。その代わりに工数を割いているのはプロジェクト管理とシステムテストであることがわかります。グラフに示している期間はプロジェクトの前半段階であり、システムサブグループが本来やるべき作業は構想やシステム設計のはずですから、プロジェクトの責任者としては放ってはおけない状況だと言えるでしょう。
実際に事情を確かめたところ、プロジェクトリーダーは対外的な交渉や調整で忙しく、製品全体を見ているシステムサブグループがメンバーを 10 人程度抱えているプロジェクト内の管理作業をやらざるを得ない状況になっていることがわかりました。アーキテクチャという技術的なことだけでなく、プロジェクト管理面でもメンバーから頼られているためにプロジェクト管理の工数が多くなっているのです。
そして、システムテストが多いのは、規格認定試験を行う時期が迫っており、そのための環境整備や動作確認などに工数をとられているということでした。予定しているリリース時期から逆算するとこの時期に規格認定試験を受けることになるのはわかっていたのですが、その準備や対応に予想以上に工数がかかっているというわけです。
システムサブグループはこのような事情を抱えているのですが、結果的にシステムサブグループは本来業務である構想やシステム設計に工数を割くことができず、目の前の、半ば場当たり的な作業に追われている状況になっていることは間違いありません。