メトリクス(評価指標) の測定は、ソフトウェア開発チームとマネージャーが製品の品質を高め作業の効率を上げるのに役立ちますが、プロジェクトや組織に合った適切なメトリクスを選択することが重要です。
この記事では、ソフトウェア開発メトリクスが重要である理由、プロジェクトとチームにとって最も効果的なメトリクスを選択する方法、そして広く採用されている代表的なメトリクスについて紹介します。
1. 適切なメトリクスを選択する方法
情報は、定量化することでより便利に使えるようになります。データを集計・測定することで、どのような時間と労力の投資が実際に成果を上げているか、そしてどのようにプロセスを改善するべきかを判断することができます。
ソフトウェア開発チームとそのマネージャーは、メトリクスを基準を用いて作業において何が重要であるかを測定し、その測定結果を基にチームの目標を設定し、メトリクスの時系列変化を観察します。ソフトウェア開発メトリクスを使って、ソフトウェア開発プロジェクトの成功に不可欠な生産性、効率、品質、およびその他のKPI(Key Performance Indicator) を測定することができます。
しかし、情報と測定量は多ければよいとは限りません。ソフトウェア開発プロジェクトによって生成されるデジタルデータの量を考えると、チームにとって情報が多すぎるという問題を抱えないようにすることが重要な課題です。どのソフトウェア開発メトリクスを使うかを慎重に検討し、チームの成功をもらたすメトリクスを選択し測定する必要があります。
また、一部のソフトウェア開発チーム、特にアジャイル方法論や他のリーン・プロセスフレームワークを採用しているチームの中には、メトリクスの使用に抵抗を感じるチームもあるでしょう。データの収集と測定というあまり生産的でない作業に多くの時間を費やしたくないためです。チームがメトリクスのための作業でつまづいたり、「バニティメトリクス(Vanity Metrics: サービス改善につながらない指標、意味のない指標)」に夢中になり時間をかけすぎるような場合、製品の質も士気も低下してしまう可能性があります。
そのため、選択したメトリクスで得た情報を理解し、それによりプロジェクトの状況を決定し、時間リソースの最適化ができるかどうかを常に確認してください。 定期的にメトリクスを見直し、チームにとって引き続き有効かどうかを判断します。もし以前選択したメトリクスが役に立たなくなっていると感じたら使うのをやめ、代わりに新しいメトリクスを試してください。
2. ソフトウェア開発メトリクスの分類
開発中の製品は、順調に完成に向かっていますか？ あなたのチームはどれだけうまく仕事を進めていますか？ そのような質問に答えるためのソフトウェア開発メトリクスは、大きく分けて2つのカテゴリに分類されます。
デリバリー・メトリクス:
スプリントの効率、プロジェクトのデリバリーまでのリードタイム、および、チームが作業を完了するまでの時間を左右するその他の要因を測定します。 これらのメトリクスは顧客満足度に影響を与えます。また、マネージャーはこれらのメトリクスを使用して、製品のリリース時期と内容を決定することができます。
テクニカル・メトリクス:
コードベースのソフトウェア開発メトリクスは、技術的な観点からのプロジェクトの堅牢性を測定するもので、製品を内部レベルで分析し、製品のパフォーマンスを把握するのに役立ちます。 バグ、セキュリティなどの要因は、このテクニカル・メトリクスを使用して測定されます。 通常これらのメトリクスは、ツール等を利用して自動的に測定されるようにします。 開発チームのリーダーと協力して、自動計測をどのように実装するのが最善か、検討してみましょう。
上記を踏まえて、どのメトリクスを選択するかはあなた次第です。 さまざまなソフトウェア開発チームのリーダーが、過去の経験則に基づいてメトリクスやその計測システムを選択しています。 選択するメトリクスは、その企業固有の価値観を反映している場合もあれば、チームが現在使用している一般的なフレームワークの一部である場合もあります。
たとえば、NotionのKevin Stiegerwaldは、製品マネージャーは「スピード、正確さ、品質、喜び」のより広い領域に焦点を当てるべきであると提唱しています。「計画、編成、制御、実装」という古典的な4つの管理値を使用してメトリクスを決定する人もいます。他には、 「在庫ベースのメトリクス」を使用して、財務的観点からパフォーマンスを測定する考え方もあります。
調査と検討を行った上で、あなたのチーム、プロジェクト、目標に合ったメトリクスを選択してください。
3. ソフトウェア開発メトリクスの例
Pluralsight社によれば、ソフトウェア開発において重要なメトリクスには以下のものがあります。
- 効率性…エンジニアが提供したコードのうち、生産的なものの割合です。
- 活動日…エンジニアの勤務日数のうち、プロジェクトにコードを提供した日数を活動日と呼びます。 会議の影響を受ける可能性があります。または、メトリクス自体の選択、測定、処理に時間がかかる場合は、かえって生産性を下げてしまう可能性があります。
- リードタイム…製品の開発の開始から顧客への納入までの期間です。
- チャーン…最近の作業に対して編集を行った、開発者自身のコードの割合を表します。 開発者が多くの編集を行っている場合、チャーンが高くなる可能性があります。
- インパクト…コードの変更がプロジェクトに及ぼす影響力の測定です。
その他の測定すべきメトリクスは、テクニカルおよびビジネス上の価値に基づいて特定のカテゴリに分類されます。以下では一般的なソフトウエア開発メトリクスのいくつかを例に挙げて、概要と測定すべき理由を紹介します。
アジャイル開発メトリクス
無駄なく合理化に進められるように設計されたアジャイルソフトウェア開発プロセスの速度が、メトリクスを測定することで低下してしまう可能性があるため、メトリクスの導入には賛否あります。ただし、多くのアジャイルチームは、アジャイルプロセスの哲学に沿って最適化された以下のようなメトリクスは有効であると感じています。
- バーンダウン: スプリント(一定の作業期間。通常は1, 2週間) 中に完了した作業量を測定します。 バーンダウンチャートは、チームでどれだけの作業が行われ、あとどれだけの作業が残っているかを示したものです。 エピックおよびリリースバーンダウンは、スプリントより長い間隔での作業の進行を俯瞰するものです。
- ベロシティ: ある開発チームが、1スプリント中に完了できる平均作業量です。将来のパフォーマンスと開発リードタイムに関する予測を行うために使用します。
- コントロール: コントロールチャートは、個々の問題のサイクルタイムを測定し、チームが問題に対処して修正するのにかかる時間の概要を示します。
生産性分析メトリクス
生産性分析メトリクスは製品配信のプロセスに関連し、以下が含まれます。
- リードタイム: コンセプト立案から実用的なソフトウェアを出荷するまでにどのくらいの時間がかかるかを示します。
- サイクルタイム: ソフトウェアシステムを変更して本番環境にデプロイするまでにどれくらい時間がかかるかを示します。サイクルタイムを使用することで、過去の経験に基づいた予測を行うことができます。
- 平均故障間隔（MTBF）・平均修復時間（MTTR）: どちらも本番環境でのソフトウェアのパフォーマンスを測定したものです。
セキュリティ・品質メトリクス
アプリケーションのセキュリティはソフトウェアの品質に影響する重要な要素です。 アジャイル手法を使用してプロジェクトを実行する場合、小さなエラーが元で大きな問題に発展する可能性があります。 測定すべきセキュリティと品質のメトリクスをいくつか紹介します。
- 脆弱性を解決するために必要な時間: セキュリティの脆弱性が検出されてから修正されるまでにどのくらいの時間がかかるかを示します。
- 欠陥作成率: ミスは人為的なものですが、ミスの発生率を把握することで、ソフトウェア開発チームのパフォーマンスの問題に気づき、修正するために必要な戦略を検討することができます。
- 継続的な改善: 品質に関して最も重要なのは、チームメンバーがパフォーマンスを把握し、問題に対処、改善を試みることが許可、奨励されていることです。
他にも何らかのツールを用いて品質の指標を常に計測し、ある一定の値を下回った場合にリファクタリングを行うというルールを持っているチームもいます。
一歩進んだメトリクス
結局のところ、ソフトウェアの成功の本当の決定要因は、成果物が現実の世界でどのように機能するかです。
- パフォーマンステスト: ソフトウェアがどれだけうまく機能するかを測定します。
- ビジネス目標との整合性: 作成されたビジネス要求にどの程度対応できているかを測定します。
- ユーザー満足度: エンドユーザーの満足度はどれくらいかを測定します。ネットプロモータースコア（NPS）などの顧客満足度メトリクスは、ソフトウェア開発プロセスの初期には測定されない場合もあります。 しかし、長期的な視点を持つマネージャーにとっては、リリースの価値を判断するために、ユーザー満足度を考慮する必要があります。
4. メトリクスの測定
個々のデータポイントは重要な場合もありますが、時間の経過とともに明らかになるパターンや傾向の方がより重要であると言えます。そのため、開発者のPatrick Kuaは、ソフトウェアの開発者と管理者が常に「数値ではなくトレンドを追跡する」ことを推奨しています。
たとえば、1週間の間にチーム内で沢山の会議がある場合、開発のための時間が長い人と短い人が出ますが、それは大きな問題ではありません。ただし、その傾向が数か月にわたって続く場合は、フォローアップが必要かもしれません。開発者は、難易度が高かったり実験的なプロジェクトの間に、より多くのコードチャーンを経験することがあります。何かの決定を行う前に、このような数値を他のプロジェクトのデータと比較する必要があります。
重要なのは、個々の統計にこだわりすぎないことです。マネージャーは長期的な成功と成長に焦点を当てて考える必要があります。よりトレンド志向のメトリクスを測定することによってこれを促進できます。有効なメトリクスを導入することで、全体像が見える大きなトレンドを観察し、マネージャーがどのような改善を行うことができるかを把握することができます。
現在主流のソフトウェア開発ツールスタックは、一般的にメトリクス、特にテクニカル・メトリクスの追跡に優れ、これを自動的に行う機能を備えています。レポートとダッシュボードをカスタマイズして、メトリクスがニーズと目標に沿って配信できるものもあります。
マネージメントの観点では、メトリクスが十分にシンプルで、必要な情報が簡単に収集でき、一貫性があり、あいまいでなく（紛らわしかったり議論の余地のある用語が明確に定義されている）、信頼性が高く、正確性を検証しやすく、チームに不要な手間をかけずにプロセスを行えるようなものであることが必要です。
一部のメトリクスにはあいまいな部分があります。たとえば、一部のシステムは論理ステートメント行のみを「コード」としてカウントしますが、他のシステムではコメントやその他の論理ステートメント以外の行も「コード」として含めます。メトリクスを使用する前に、選択したメトリクスのあいまいさを軽減し、混乱を防ぐ必要があります。経験豊富な開発者であれば、どのメトリクスがどの作業に対応しているかについての深い知見を持っているでしょう。
ソフトウェアエグゼクティブのTodd DeCapulaは次のように言っています。「メトリクス自体にはあなたに現場の”物語”を伝える力はありません。それができるのはチームだけです。」常にチームの状況を確認し、チームの全員が十分に状況を理解し、連携が取れていることを確認してください。
5. 結論
適切なソフトウェア開発メトリクスを選択し、測定するための適切なシステムを用意することで、ソフトウェア開発チームの生産性と成功を大きく向上させることができます。 ただし、間違ったメトリクスを選択したり、チームにデータを多用しすぎたり、あいまいな方法でメトリクスを測定したりすると、開発が遅延する可能性もあります。
また、ソフトウェア開発では結局のところコミュニケーションが重要です。メトリクス測定システムを導入さえすればうまくいくと期待してはいけません。チームと継続的にコミュニケーションをとり、フィードバックをもらい、チーム全員で同じ認識を持ち、重要な進捗状況を共有する必要があります。ツールはコミュニケーションの品質を上げるために利用しましょう。
ブログ一覧へ戻る 
