私は 20 年以上にわたってソフトウェア チームのリーダーを務めてきました。その経験を通じて、メトリクスに関してわかったことがあります。それは、多くのリーダーには、大局を考慮することなく、エンジニアリングのメトリクスだけを重視する傾向があることです。
さまざまな業種のエンジニアリング リーダーに聞き込みを行い、世界中のソフトウェア チームが処理した何千万ものジョブを調査した結果、インサイトに富み、関連性も高いメトリクスが以下の 3 カテゴリに分類できることを突き止めました。
- スピードのメトリクス
- 意欲のメトリクス
- ビジネスのメトリクス
スピードのメトリクス
エンジニアリングのスピードに関するメトリクスでは、ソフトウェア デリバリー パイプラインのスピードと効率性を評価します。これは、多くのマネージャーとって最も関心の高いカテゴリです。これから説明するように、スピードのメトリクスだけを 唯一重要なカテゴリとして追跡すればよいわけではありません。しかし、スピードのメトリクスの監視は、エンジニアリング チームが遅延箇所を特定しやすくなり、全体のパフォーマンスを最適化する方法も見つけやすくなるので重要です。
最も一般的なスピードのメトリクスには、以下のものがあります。
- スループット
- 変更リード タイム
- スプリントのスピード
- 実行時間
- 平均復旧時間
- 成功率
作業体制に合わせてスループットの計測方法をカスタマイズする
データ処理/レビュー プラットフォームを提供する Zapproved 社でエンジニアリング責任者を務めていた Moses Mendoza 氏は、チームの作業ペースを把握するためにスループットを活用しています。同氏は次のように語っています。
「スループットが、自分たちのスピードを把握し、理解するうえで役立つのは事実です。ただし、システムのスループットは、根本的な制約に縛られた指標でもあります。スループットを測定すれば、一連のイベントの中で最も時間がかかっている問題を知ることはできます。しかし、どうすれば作業をスピードアップできるかはわからないのです」
スループットの計測方法は、それぞれのチームに合わせてカスタマイズすることが重要です。その証拠を示す具体例として、CircleCI のエンジニアリング マネージャー、Graeme Harvey の経験をご紹介します。
「CircleCI の私たちのチームはペアプログラミングを実施しているので、スループットを計測しても各個人の生産性を知ることはできません」(Harvey)
スループットに関して、Harvey のチームのエンジニアは、個人ではなく チームのために最適化 を行っています。ペアプログラミングとメンバー間の助け合いは、個人の進捗の妨げになると思う人もいるかもしれません。しかし、実際は、チームの (ひいてはビジネスの) 最も重要なポイントにエネルギーを集中できるのです。
スループットは成果を追跡するうえで価値あるメトリクスですが、どのようなチームにも合う万能の測定方法はありません。スループットを正確に計測するには、チームの構造と作業のやり方を考慮に入れる必要があります。
リード タイムを測定してコミュニケーションの問題とパイプラインの質を特定する
ソフトウェア構成ツールを提供する Puppet 社の元成長担当 VP、Alex Bilmes 氏によれば、変更リード タイムを計測する方法は 2 つあると言います。「変更リード タイムを計測する 1 つの方法は、アイデアを出し、そのアイデアがサイクルを完了するまでにかかった時間を測ることです。もう 1 つの方法は、デプロイのリード タイムを測ることです。つまり、開発者が変更を本番環境にプッシュしてから、それが反映されるまでの時間を計測します」
サイクル完了の変更リード タイムからは、コミュニケーションや理解度の問題、バックログの量がわかります。デプロイのリード タイムは、パイプラインとツールの品質を知るのに適しています。
スプリントのスピードを活用してワークロードを計画する
スプリントのスピードでは、1 つのチームが 1 回のスプリントで取り組むことのできる作業量を計測します。これは、プランニングやチーム パフォーマンスの計測に用いられるメトリクスです。
ビデオ会議プラットフォームを提供する Livestorm 社 CTO の Tom Forlini 氏は、3 つのより細かなメトリクスに着目して、さらに詳細にスピードを計測しています。
- イシューとストーリー ポイントの数
- 完了できたイシューの数と予定していたイシューの数の比較
- イシューの種類ごとの分布割合
「当社では、エンジニアが 2 週間のスプリントで作業しており、各スプリントに 50 個のストーリー ポイントが存在します。完了したイシューの数と計画していたイシューの数を計測し比較している理由は、プロダクト チームと技術チームで策定されたスプリント計画の質を測る良い指標になるからです」(Forlini 氏)
さらに、Forlini 氏のチームでは、イシューの割合を種類ごとに確認しているそうです。その訳を同氏は次のように語っています。「たとえば、あるスプリントに新機能関連のイシューしか設定されていないなら、そのスプリントの難易度はかなり高いと最初から予測することができます。理想的には、スプリントごとに複数の種類のイシューをバランスよく含めるように調節するべきです」
意欲のメトリクス
意欲のメトリクスは、おそらく、エンジニアリングのカテゴリの中で最も見落とされているメトリクスです。このメトリクスは、エンジニアが自らの仕事の品質や職務内容についてどのように感じているかを計測するメトリクスであり、人材を維持するうえで主要な要因です。人材定着率が高いということは、意欲が高く保たれているということです。
意欲のメトリクスには、以下のものがあります。
- 個人とチームの意欲
- コード品質に対する自信
エンジニアに直接質問して意欲を測定する
Zapproved 社の Mendoza 氏は、従業員の定着状況を監視するために意欲を追跡していたと語っています。「当社では、調査を実施したり、対話を行ったり、マネージャーに従業員との 1 対 1 のミーティングを開き心情を聞き出すように依頼することで、仕事に対する意欲を計測していました」
こうした調査に対する反応が驚くほど前向きだったなら、何がそれに寄与したのか、どうしたらそれを職場環境の改善に転用できるかを調べましょう。また、反応が後ろ向きであれば、チームに直接聞き込みをして、従業員がそのように感じている理由や、問題解決のためにできることは何かを確認するとよいでしょう。
カバレッジよりも自信を重視する
Zapproved 社の Mendoza 氏は、すべてのスプリントをチームのマネージャーおよびスクラム マスターと一緒にレビューし、自信を計測していたと述べています。「2 ～ 3 回のスプリントでコード品質に対する自信を計測して、その結果が低調であったなら、そのスプリントにおいてチームによる各メンバーへの投資計画に何か間違いがあったということです」
私の部下でエンジニアリング マネージャーの Harvey も、自信に基づいて仕事を評価しています。
「カバレッジよりも自信をメトリクスとして重視するなら、まずは重点をコード カバレッジから外さなくてはいけません。コード カバレッジが 80 ～ 90% に達したからリリースし、コードに問題があると判明して終わるというような、コード カバレッジを当てにした行動をやめることが極めて重要です。テスト カバレッジは、コードに対する自信を表す指標の一部と言えます。テスト カバレッジがコードの 95% に及ぶ場合、20% である場合に比べて、そのテストに合格したコードなら問題なく仕上がっていると強く確信できるはずです」(Harvey)
Harvey のチームは、小規模なイテレーションを迅速にデリバリーすることに注力しています。こうすることで、瑕疵のない高品質なプロダクトを作成しているという自信を持ち、ダッシュボードの開発に適したツールを選べているという確信を手にしているのです。
ビジネスのメトリクス
エンジニアの行動は、そのすべてにおいて、企業の成長を推進するものであるべきです。そのため、ビジネスのメトリクスの計測も重要です。
ビジネスのメトリクスの一例としては、以下のものがあります。
- 企業の成長ファネルのメトリクス
- エンドユーザーにとっての価値
ビジネスの拡大速度を追跡する
ビジネスのメトリクスを追跡すれば、ユーザー数の増加に対するチームの対応のスムーズさがわかります。元 Uber 社員の Yixin Zhu 氏は、エンジニアリングの実行に関するメトリクスを調べるだけでなく、企業の目標に注目し、成長を計測することも重要だと説明します。
Uber 社が急成長を遂げた際、Zhu 氏のエンジニアリング チームが成功するには、ビジネスのメトリクスの追跡が非常に重要であったそうです。「6 か月ごとに業績を倍増させたいなら、開発が必要なもの、予想される機能低下のタイプ、必要なデータ センターの数、必要なボックスの数などがわかるメトリクスを追跡すべきです」
簡潔に言えば、プロジェクトの立ち上げや計画を的確に行うためには、エンジニアはビジネスのメトリクスをリアルタイムで注視しなければなりません。「先を見越した行動が必要です」と、Zhu 氏は付け加えています。
重要なメトリクスの価値を最大限に引き出すには
最後に、エンジニアリングの取り組みの 価値を最大限に引き出す ためのヒントをご紹介します。
- ビジネス目標を定義する: エンジニアは、自社が目指している目標を知っている必要があります。自社の向かう先がわかれば、自分の仕事が向かう先も知ることができます。
- メトリクスをこまめにレビューする: どのようなミーティングでもまずはメトリクスの確認を行い、適切に進んでいる作業、改善が必要な箇所について、チームの認識を統一しましょう。
- 小さな取り組みから始める: 最初、メトリクスの数は 1 ～ 3 つで十分です。もし、追跡対象のメトリクスとしてシンプルなものを選び、さまざまなアプローチを試して、メトリクスの推移を見守る意思があるなら、いずれメトリクスを追加することを検討してもよいでしょう。
- 実行に関するメトリクスの先を見る: エンジニアリング チームの成功の鍵を握っているのは、エンジニアリング メトリクスだけではありません。エンジニアリングのメトリクスとビジネスのメトリクスを組み合わせると、毎日何を、なぜ開発しているのかが見えてきます。
この記事の出典: VentureBeat
