【必要最小限の手間で行う開発の見える化 連載目次】
- 1、必要最小限の手間で行う開発の見える化
- 2、工数メトリクスでわかるプロジェクトの振る舞い
- 3、工数メトリクスで進捗遅れの原因を知る
- 4、遅れのはじまりと今後の影響がわかるタスク・メトリクス
- 5、作業の進捗や品質がわかる作業成果物メトリクス
- 6、不具合メトリクスによる進捗管理や根本原因分析
- 7、基準モデルはどこにも必ずある成功パターン
1. 不満ばかりの進捗管理
「全体の状況がわからない」
「進捗を把握するには結局ヒアリングするしかない」
「結局問題が大きくなってからしか対応できない」
これらは、進捗管理をしているリーダーやマネジャーからよく聞く不満です。一方、メンバーからも次のようなリーダーやマネジャーに対する不満があります。
「いつもスケジュールしか見ていない」
「とにかくスケジュールを守れとしか言わない」
「遅れそうだといっても真剣に話を聞いてくれない」
このような不満を生んでいるのは、開発は不確定要因が多いにもかかわらず開発の見える化が不十分で、進捗管理が機能していないからです。以下では、進捗管理を中心に、開発の見える化のためのメトリクス管理について紹介したいと思います。
2. メトリクス管理とは
メトリクスとは、管理対象を測定して定量化することであり、メトリクスによる進捗管理は、開発の状態を把握できる定量化したデータを使って、複眼的、複合的に開発を可視化し、適切な判断をするための仕組みです。
ただし、メトリクス管理の運用には、データ収集に必要以上に手間がかかる、十分な効果を発揮できないなどの問題も多く、必要最小限の手間で効果的なデータの収集と分析の仕組みが重要です。そこで、ヒューレット・パッカードでの製品開発から現在のコンサルティングまでの経験をもとに、メトリクス管理に必須だと考えられるものを実践的メトリクス管理としてまとめました。
それは、次の3つの手法で構成されています。
・2軸管理（Product & Activity）
・基本メトリクスセット
・基準モデル
3. 2軸管理（Product & Activity）
図1．2軸管理（Product & Activity）
2軸管理は柔軟な分析を可能にするためのデータ収集のしくみであり、「プロダクト」と「アクティビティ」という2つ軸でデータ収集するというものです。
アクティビティ軸は、開発活動がどの作業工程のものなのかをあらわすための軸です。開発作業が、調査、計画、設計、実施、評価というような開発工程（作業工程）のどこに相当する活動なのかを明らかにします。
一方プロダクト軸は、開発の最終成果物におけるどの部分を対象にした作業なのかをあらわす軸です。製品開発の場合は、システム構造図やブロック図などで表現された製品全体の中のどの部分の作業なのかを特定することになります。
4. 基本メトリクスセット
基本メトリクスセットとは、進捗管理のための必要最小限の測定項目（指標）です。やみくもなデータ収集を避けるために、これだけ取っておけば開発作業を知るのに十分だと言えるデータを示しています。
図2に示しているように、基本メトリクスセットは、開発プロジェクトへの入力である工数と、開発プロジェクトが出力するタスク（作業要素）、作業成果物、 不具合・課題の4つのメトリクスのことです。開発プロジェクトの入力と出力のこの4つを測定すれば、開発の進捗を効率よく、効果的に把握することができるようになります。
図2 基本メトリクスセット
工数は、メンバーがどの作業にどのくらいの時間を使ったのかを測定したものです。開発においてもっとも重要なリソースは開発にたずさわっているメンバーであり、工数はメンバーがどのような時間の使い方をしているのかを示す重要な情報です。タスク（作業要素）は、スケジュール表で矢印などであらわされている実施する作業を測定したものです。作業成果物は、設計書などの開発を通じて作成される成果物を測定したものです。不具合・課題は、開発中に発生した不具合や課題です。タスクと作業成果物は規模や作業量、不具合・課題は品質をあらわす指標ですので、QCD の観点からも全体としてバランスのとれた指標になっています。
時間や手間をかければもっとたくさんの種類のデータを収集するができますが、開発そのものが高い効率性や生産性を求められているのですから、プロジェクト管理も効率良く実施する必要があります。まずは基本メトリクスセットで示している4つのメトリクスをしっかりと収集、分析できる仕組みを作ることが、効率のよい総合的な進捗管理を可能にします。
5. 基準モデル
図3 工数比率基準モデル
基準モデルとは、精度の高い見積もりを可能にする型、もしくは、テンプレートで、開発組織の実績を元に作成します。たとえば、工数見積もりのために、失敗したり中止になった...
図3の基準モデルの隣にあるのは、大幅に開発遅延したなどの失敗プロジェクトを集めて平均をとった工数比率です。基準モデルと反対の失敗モデルとよんでおきましょう。分析に工夫が必要なのですが、どのような開発組織でも、このように成功パターンと失敗パターンを作ることができます。
基準モデルは、その組織での成功パターンですから、この基準モデルに示した工数比率となるように開発プロジェクトを計画し、実行できるようにマネジメントすることを目指すことになります。
今後数回に分けて、実践的メトリクス管理の詳細を、事例を交えながら紹介していきたいと思います。次回は、工数メトリクスでわかるプロジェクトの振る舞いです。