ソフトウェアメトリクス管理

ある電子機器メーカーでの事例を紹介する。市場は世界であり、海外も含めて競合が厳しい製品を開発している。一年ごとに普及モデルから高級モデルまでのほとんどのモデルを入れ替えるような新製品リリースを従来から行っている。しかし、近年、製品規模や機能が増大することによって定期的な新製品リリースへの対応が困難を極めており、開発要員を増やすだけでは対応できない状況になりつつあった。したがって、開発期間を伸ばすことなく生産性を飛躍的に向上させることが経営課題であった。

アセスメントした結果、必要な固有技術について十分な経験を持つ技術者は、十分とはいえないまでも必要な開発を担当できる程度にはいるがわかった。しかし、プロジェクト管理を任されているマネジメント担当者に技術職からの脱皮ができないままの人が多いことわかった。ヒアリングの中で、マネジメント担当から、「プロジェクト管理という仕事は何をすればいいのか、何が専門技術なのかがわからない。」「マネジメントというのは、個人的な人的ネットワークや力ずくで進めるものだ。」というような声が多く聞かれた。

そこで、プロジェクト管理を感覚的、属人的な世界から、多くのマネジメントが得意とする技術的な世界に移行するためのしくみとしてメトリクス管理を確立することにした。メトリクスによりプロジェクト管理も技術であることをわかってもらい、その技術力を積み上げることができるようなしくみ構築をめざした。実施計画は、メトリクスの収集から利用に至るサイクルを回すことができる基本的なしくみ作りに半年をかけ、その後、プロジェクトベースで運用を広げるというものにした。メトリクス管理は改善サイクルをどれだけ回すことができるかでそのレベルが決まってしまうため、なるべく早く運用を開始するような計画を作った。

以下に紹介する実例はソフトウェア開発にフォーカスした例となっている。これは、この製品において開発工数のソフトウェアとハードウェアの比率が約８：２となっており、まずはソフトウェア開発に絞ってプロジェクト管理のしくみを構築したからである。ハードウェア開発を含む場合でも基本的な考え方や進め方は同じである。

まず最初に実施したのは、開発工数をトラッキングするためのしくみ作りである。

開発標準はすでに存在していたが、決められた標準通りに開発作業を進めている人はいなかった。これは、開発標準自体が机上で考えられただけの内容で、実際の開発作業を通じた見直しが行われていなかったためだと分析した。そこで、プロジェクト・リーダーを集めて開発標準を見直し、現実的な開発工程を定義することからはじめた。この作業のポイントは、プロジェクトメンバーの役割を明確化し、その役割ごとに開発工程がどうなるのかを検証しながら現実的なあるべき姿を作ることである。また、ハード、ソフトのそれぞれと両方とで、どのタイミングでどのような評価を行うのかを整理することも重要である。

このような作業により、現状に合った（蛇足かと思われるが、現状通りという意味ではなく現実的なあるべき姿という意味である）開発工程を定義した。図（アクティビティコード）にどのような工程を定義したかだけを紹介する。それぞれの工程にアクティビティコードとよぶコードを割り当てている。この時点で、それぞれの工程での成果物（出力物）や工程終了条件なども定義したが、全体の作業フローも含め詳細は省略する。

次に、プロジェクト文書の書庫から過去プロジェクトの開発工数記録を引っ張り出した。過去のデータから開発工数に関する基準モデルを作るためである。記録はプロジェクトごとにまちまちな形式で残されているため、上記で定義した開発工程に合わせるには、当時のプロジェクト関係者へのヒアリングなども実施しなければならなかった。このような作業を通じて、工数のかけ方に特定の傾向が存在しないかを分析した。

開発を流用度で見た場合、全く新規といっていい製品開発と、50% 以上既存製品からの流用による製品開発とで開発作業が大きく違うことがわかったので、それぞれについて開発工数を分析した。その結果を図（開発タイプ別開発工数投入モデル）に示すが、流用をほとんど行っていない新規開発プロジェクトと、50 % 以上既存製品からの流用である開発プロジェクトとで工数投入パターンが違っているが、それぞれ開発工数投入にはパターンといえるものが存在していることがわかった。ここで作成したモデルは、過去データから作成したものであるために、事前に定義した前述のアクティビティコードに一致させることはできなかった。しかし、このように現状でできる限りのモデル化をすることはメトリクス利用を加速させる上で重要なことである。

このメーカーでは、この後、継続してアクティビティコードに従った開発工数収集を行い、より精度の高いモデルへと改善を継続している。同時に、デザインレビューの実施など、個別の改善活動についてもその基準モデルを作成している。たとえば、現状の開発工数の５％をデザインレビューに投入することにより、評価・テスト工数が 20 % 削減できるというようなモデルをパイロット実施を通して作成し、実際のプロジェクトに適用することよりその妥当性を継続して検証している。基準モデルの作成と検証のサイクルを繰り返すことによって、定量的に説明できる効率的な開発の進め方を継続して探求している。

次に、開発工程ごとの管理指標を定義した。管理指標を決めることと並行して、各工程での成果物（設計文書などの出力物）をフォーマットや内容について標準化を中期的な活動として進めた。さしあたって、コーディング工程とテスト工程について管理指標を決め、メトリクス管理のしくみを構築することにした。コーディング工程の管理指標は新規開発ステップ数、テスト工程の管理指標は不具合検出数とした。さらに、テスト工程については通常の開発工数の収集以外にテストケース作成時間など、さらに詳細な作業時間を収集することにした。

データ分析のためには専任の担当者を設け、データ分析とレポートを毎週繰り返した。この担当者はプロセス改善全般の担当者だが、活動の一つとしてメトリクス管理のしくみを確立するとともに、データ分析のノウハウを蓄積することをミッションとした。複数の関係者が片手間で行うのではなく明確な仕事として一人にアサインした方が効果的だと考えたからである。担当者は、実際にメトリクスを使ってプロジェクトを把握できることを証明するために、相当にがんばった。その結果、マネジャーからプロジェクトからの報告ではわからないことがレポートしてあったとの感想をしばしば聞いた。プロジェクトに直接関係しない立場からのプロジェクトに対する分析はマネジャーにとって非常に有効であることを理解してもらった。

分析担当者によるこの試みは約一年くらいで成果が現れたので、徐々に分析業務をプロジェクト・リーダーに移行していった。本来であれば、プロジェクトマネジメントの担当者がデータ分析を行うべきだからである。分析スキルはマネジメントスキルの一つである。

開発ステップ数を使ったレポートと分析例を図（開発ステップのレポート例）に示す。このレポートでは分析担当による分析結果を、プロジェクトに対する問題の指摘として表記している。プロジェクト・リーダーはこの問題に対する回答を記述するのがルールである。このような記録を残すことにより、プロジェクト終了後に開発を振り返ったときに、モデルの問題、分析の問題、対応の問題などを層別して議論することができるようになった。プロジェクトを後からでも振り返ることができる十分な記録が残ることも、メトリクス管理のメリットの一つである。

さらに、この、分析者とプロジェクトリーダーとの間のやりとりを含むレポートを、部長、部門長に配布した。これにより、プロジェクトの状況を実感できたというフィードバックをもらった。トップマネジメントは、プロジェクトメンバーが想像している以上にプロジェクトに対する理解はできていないものである。ここでのメトリクス管理のしくみはトップマネジメントからプロジェクトを見た場合のビジビリティを大きく向上させたといえる。