Club-Zコラム第17回

印刷用表示 | テキストサイズ 小 | 中 | 大 |


clubZ_info_renewal.jpg

| HOME | コラム | グローバル化は設計・製造の仕組みを見直すチャンス | 第17回 | P1 |

更新日 2016-01-20 | 作成日 2007-12-03

コラム


グローバル化は設計・製造の仕組みを見直すチャンス

【第17回】ソフト作業成果物による進捗管理は相互の関連づけでパワーアップ!

株式会社RDPi  代表取締役 石橋 良造


2008.12.18

執筆者プロフィール
九州大学卒業後、日本HP入社(入社当時はYHP)。電子計測器、半導体計 測システムの研究・開発に従事した後、社内の開発製造革新プロジェクトで、 電気・電子設計およびソフトウェア開発のための統合システムを企画,開発。
この間に、日本HPにおけるソフトウェア・プロダクティビティ・マネジャー を兼務。日本HPの会社分割によりアジレント・テクノロジーに移籍した後、 この経験をもとに社外に対してコンサルティングを実施。その後、株式会社 RDPi を設立。 これまでに、家電、通信、電子機器、自動車業界に数十社の実績を持つ。ビジネスコンサル系とは一味違った開発現場やツールにも精通するコンサルタント。
著書(共著)に「デザイン プロセス イノベーション」「ザ・チェンジ」(どちらも日経BP)。また「日経ものづくり」での連載や「ソフトウェア開発環境展」専門セミナーなどのセミナーも多数実施している。

●Email :  ishibashi@rdpi.jp
●株式会社 RDPi : http://www.rdpi.jp/
●著書 : book1.JPGbook2.JPG


前回は、計画時の見積もり精度を上げるための基準モデルと、進捗を見える化するための基本ツールである基本メトリクスセットのひとつ、作業成果物メトリクスについて解説しました。前回はハードウェア開発中心の解説でしたので、今回はソフトウェアの成果物メトリクスについて解説したいと思います。

ハードウェア開発の場合、設計部門は、購買や生産管理、工場技術、製造など多くの関連部門との関わりを持つ必要があるため、ある意味強制的に進捗や設計内容を整理しおく必要がありますし、回路図や基板などのモノを見ればだいたいの状況はわかります。したがって、進捗はある程度把握できるものです。一方、ソフトウェア開発の場合は、技術部門だけで一通りの開発作業ができてしまうことや、ハードウェアを組み合わせて動かしてみないと確認が難しいことなどから、進捗や設計内容はブラックボックスになりがちです。したがって、意識的に進捗を見える化して外部に伝えることが重要です。

このような要求に応えるために、すでに多くのソフトウェア開発現場では作業成果物を使った進捗の見える化を行っています。たとえば、プログラム・ステップ数は多くのところで収集され、進捗指標として利用されています。そういう意味では、ソフトウェア開発における作業成果物メトリクスはなじみのある考え方ですが、確認のためそのポイントを整理しておきましょう。図47 をご覧ください。

column_20081218_1.JPG

この中で、「作業量との相関があること」というのは、あまり意識していない場合があります。たとえば、ほとんどのソフトウェア開発現場で収集しているプログラム・ステップ数は、作業量との相関が高いことがわかっているから指標として使われているのです。しかしながら、ステップ数に対して複雑なカウント方法や計算を行っているところに出会うことがあります。流用の場合には流用元の関数全体のステップ数にある係数を乗じて加算するとか、開発中に削除したプログラムについてもそのステップ数にある係数を乗じて加算するとか、これらの係数もいろいろと場合分けされているとか、いろいろと手の込んだ方法をとっているところがあります。

理由を聞くと、「削除しているプログラムも作業の結果なのだからカウントするべきだ」というような説明があり、一見すると論理的根拠のある計算方法のようにも思えるのですが、ここで問題なのは、このような計算方法にすることが妥当かどうかを検証していないことです。工数などの実際の作業量との相関が高いかどうかを検証した上で、計算方法が妥当かどうかを判断する必要があるのです。ただ多くの場合、複雑にしてもその相関が高くなることはまれです。