ソフトウェア製品の開発を主導しなければならない場合、おそらく疑問に思うでしょう-チームがより速く動くのをどのように助けるのですか？そして、どのようにあなたはあなたがどれだけ速く動いているかを知っていますか？
そのような質問に答えるためにメトリックを使用することは論理的であるように思われます。結局のところ、私たちはそれらを長い間使用しており、ソフトウェア製品自体にうまく使用しています。パフォーマンスメトリック、本番サーバーの負荷、稼働時間があります。コンバージョンや保持などのユーザーの行動に基づく製品メトリックもあります。メトリックの利点は、現在の状態をより明確に理解するだけでなく、さらに重要なことに、フィードバックを提供することです。何かを改善するために変更を加えると、どの程度の改善（または劣化）が得られるかをメトリックで確認できます。人気のあるプログラミングの知恵は、プログラムのパフォーマンスのすべての最適化は測定から始めるべきであり、それは非常に理にかなっていると言い ます。
ソフトウェア製品自体にメトリックを正常に適用できるので、それらの製品の開発速度にメトリックを適用してみませんか？この場合、プロセスのいくつかの改善を試みて、それらがより速く動くのに役立つかどうかを視覚的に確認することができます。また、プログラマーの公正な給与を決定する問題も単純化されます。どのような指標を使用できますか？
これに関する適切な指標はありません。
開発速度は、単位時間あたりに完了した作業の量です。私たちは時間を測定することができます、ここではすべてが簡単です。しかし、行われた作業の量を測定する方法は？これを行う試みは、プログラミング業界自体の誕生とともに、何十年も前に始まりました。ただし、メトリックが改善のターゲットとして使用されるたびに、何かがうまくいかないことがありました。例えば：
- . , , , . , , , ;
- . , , ;
- . . , , . , , ;
- . , . , , , ;
- . , , , — , ;
- … .
開発者は機知に富み、創造的であり、複雑な問題の解決を専門としています。あなたが彼らに与える測定基準が何であれ、彼らは彼らのパフォーマンスを改善する最も簡単な方法を見つけるでしょうが、おそらくそれは実行される仕事の実際の量と質とは何の関係もありません。彼らはこれらの「不正行為」方法を使用しますか？必ずしもそうとは限りませんが、作成するインセンティブの強さなど、特定の状況によって異なります。しかし、彼らは自分たちの生産性を評価することは価値とはほとんど関係がないことを最も確実に理解するでしょう。これは意欲をそそるだけでなく、実際の仕事をすることから気をそらします。
しかし、なぜ？
メトリックは、ソフトウェア製品のプロパティを改善するためにうまく機能するのに、プログラマーによって行われた作業を測定するためには機能しないのはなぜですか？多分これはプログラマーのある種の陰謀ですか？実際、ソフトウェア開発の先を見ると、他の例があります。その中には、メトリックがうまく機能するものとそうでないものがあります。
メトリックがうまく機能する例は、大量生産または販売です。マグカップの製造と販売をしましょう。生産量を測定できます-単位時間あたりのカップ数、その品質（スクラップ率）、1カップのコスト。売上高-販売量、マージン。これらのメトリックは、管理で非常にうまく使用されています。たとえば、生産マネージャーには、コスト価格を維持しながらスクラップ率を下げるタスクを割り当て、販売マネージャーには、価格を維持しながら売上を増やすタスクを割り当てることができます。これらの指標の改善はビジネスに利益をもたらすため、担当者のパフォーマンスの指標と見なすことができます。
指標が機能しない場合の例は、科学的パフォーマンスの評価です。科学者は研究を行い、それはその後科学論文として発表されます。この領域には、論文数、引用数、結果の統計的有意性など、独自の数値指標もあります。10の科学論文を発表した科学者は、5つの論文を発表した科学者の2倍の利益を世界にもたらしたと言えますか。彼らの作品の価値は非常に異なる可能性があると同時に、主観的なレベルでさえ、どの作品がより価値があったかを理解することは難しいため、それはありそうにありません。引用や出版物の「不正行為」の問題は科学界で広く知られているため、残念ながら、それらは信頼できる価値の指標とは見なされていません。統計的有意性を操作するという問題もあり ます。
2つの主な基準
コンテキストに関係なく、適切に機能するメトリックには2つの共通点があります。
- 値との直接（間接ではない）関係。
- 精度、つまり、メトリックはいくつかの値の単位の数を測定することに基づいており、これらの単位は互いに等しいです。
上で見た例をもう一度見てみましょう
。大量生産と販売の 指標は両方の基準を満たしています。マグカップの製造において、価値は製品、つまりマグカップ自体です。接続は直接です、会社はマグカップを生産する必要があります。そして、生産は大量であるため、価値の単位（円）は互いに等しくなります。私たちが販売について話している場合、価値の単位はお金です。企業の目的は利益を上げることであるため、価値との関係も直接的なものです。また、獲得したすべてのドルは別のドルと等しいため、正確なメトリックを構築できます。
科学的研究を評価する際に、これらの基準を満たすことはできません。すべての科学的研究は独自のものであるため、科学的研究の価値を直接決定する測定単位を見つけることはできません。それ以外の場合は、単に科学の本質から進んで、新しい知識を発見することはできません。科学者が別の科学的研究を正確に繰り返すような別の科学的研究を書くことは意味がありません。それぞれの科学的研究は何か新しいものをもたらすはずです。
科学的研究の価値を直接測定する指標を見つけることができないため、出版物や引用の数など、間接的な指標のみが残されています。間接メトリックの問題は、値との相関が低く、簡単にだまされる傾向があることです。このような指標を目標として使い始めると、自分でそれを人為的に巻き上げるインセンティブを作成します。
プログラマーの生産性の測定に戻る
そこには何がありましたか？コードの行、コミット数、タスク、時間単位のタスクスコア、またはストーリーポイント... 2つの主要な基準に対してこれらのメトリックをチェックしようとすると、いずれもそれらを満たしていないことがわかります。
- 価値との直接的な関係はありません。私たちはクライアントにコード行、工数、ストーリーポイントを提供しません。ユーザーは、コミットの数や閉じたタスクの数を気にしません。
- それらは正確ではありません。コミットのコミットは異なり、コードの1行は別の行と等しくなく、タスクも異なり、工数とストーリーポイントは主観的に推定されるため、それらも異なります。
したがって、これらの指標のいずれも機能しないことは驚くべきことではありません。これらはすべて間接的で不正確です。
プログラマーの仕事の価値に直接関連する指標がないのはなぜですか？科学者がそれらを持っていないのと同じ理由で。科学者のようなプログラマーは、常に新しいものを作成しています。彼らはまったく同じコードを何度も書いているわけではありません-それは意味がありません。以前に作成したコードは、さまざまな方法で再利用したり、別のモジュールやライブラリに分割したり、最悪の場合はコピーしたりすることができます。したがって、プログラマーの毎日の就業日はユニークです。同様の問題を解決したとしても、毎回異なる状況で、新しい条件で解決します。
プログラマーの仕事は作品であり、大量生産ではありません。それらは同じ再現可能な結果を生成しないため、測定のベースラインはありません。大量生産や大量販売でうまく機能する指標は、ここでは機能しません。
研究に基づいて、もっと現代的なものはありませんか？
もちろん、今日、コード行でプログラマーの作業を測定することについて真剣に話す人は誰もいません。研究に基づいたより現代的な測定基準があるはずですよね？
幾つかある。 2018年の著書「Accelerate」の中で、著者はさまざまな業界の2,000の組織を調査した結果を引用しています。著者は、どのメトリックがパフォーマンスを測定するかを理解しようとしました。
出典：Nicole Forsgren、Jez Humble、およびGene Kim、「Measuring Performance」、Accelerate：The Science Behind DevOps：Building and Scaling High Performance TechnologyOrganizations
ここに4つのメトリックがあります。どれが値に関連していて、正確に測定できるかを見てみましょう。
- . , . , . . . . , , . , . , — ;
- Lead time — , . , , . , , , — ;
- (MTTR) — , , , . . -, . , MTTR . -, , . , — ;
- , . , . , , , . Linux, “ — ”. SaaS- . , — - , , - . , . , — . , — .
結論：これらの4つの指標はいずれも正確ではなく、顧客の価値と常に明確な関係があるとは限りません。この場合、「不正行為」の機会はありますか？承知しました。些細な低リスクの変更を可能な限り頻繁に提供し、リードタイムを除くすべてのメトリックが見栄えがします。
リードタイムに関しては、不正確であるという（重要な）事実を省略しても、それを強調すると、クライアントの最も単純な希望が優先され、クライアントが明らかに求めていないすべてのものの隅に押しやられます。通常、これらはリファクタリング、テスト、および彼が自分で考えていなかった改善だけです。
したがって、これらのメトリックをターゲットとして使用することはお勧めしません。
しかし、新しい指標が見つかるかもしれません。
もちろん、次のように言うことができます。「待ってください。適切なメトリックがまだ見つからない場合、これはまったく存在できないという意味ではありません。私たちは賢い人です。私たちは自分自身に負担をかけ、何かを考えます」。残念ながら、そうではないのではないかと思います。この領域に適切な指標がない根本的な理由があります。上で述べたように、良いものは2つの主要な基準を満たします。
- 値との直接（間接ではない）関係。
- 精度、つまり、メトリックはいくつかの値の単位の数を測定することに基づいており、これらの単位は互いに等しいです。
プログラマーの仕事の結果はすべて異なり、まったく同じものを生み出すことは決してないため、直接的な値を正確に測定することはできません。これは、ユニークで反復性のないタスクのための作品制作です。また、繰り返しがないため、比較や測定の基準もありません。プロキシだけが残っていますが、それらは価値との関連性が低く、不正行為をしやすいため、プロキシに依存することは有害です。
良い指標がない分野を改善できますか？
メトリックはフィードバックを提供するため、優れています。プロセスにいくつかの変更を加えると、それらが改善につながったかどうかを明確に確認できます。指標がない場合、フィードバックはあまり目立たなくなり、盲目的に動いているようにさえ感じるかもしれません。ピータードラッカーに起因する有名なことわざがあります：
測定できないものを制御することはできません。
これだけは真実ではありません。Drucker Instituteによると、Peter Druckerは、あらゆる活動の指標が見つかるという幻想を抱いておらず、そのような言葉を言ったことはあり ませんでした。価値のあるものすべてを測定できるわけではなく、測定できるものすべてが価値があるわけでもありません。
メトリックの複雑さは、何も改善できないことを意味するものではありません。一部の企業は、品質を犠牲にすることなく、他の企業よりもはるかに迅速にソフトウェアをリリースしています。これは、いくつかの重要な違いがあることを意味し、したがって、改善が可能であるはずです。
概要
メトリックを使用してソフトウェア製品を改善することは可能であり、必要です。パフォーマンス、負荷、稼働時間、またはコンバージョンや顧客維持などの製品指標はあなたの友達です。
ただし、適切なメトリックがないため、メトリックを使用して開発プロセスを高速化しようとしないでください。この分野の多くの指標が発明されましたが、残念ながら、それらはすべて間接的または不正確であり、多くの場合同時に両方であるため、それらを目標として使用しようとすると、害しか得られません。
しかし、落胆しないでください-希望があります！開発速度の優れた指標がないことは悲しいことですが、それは速度の改善が不可能であることを意味するものではありません。可能な限り。はい、フィードバックのための主観的な定性的評価しかありません。ただし、改善を実装し、それらの効果があるかどうかを理解するには、十分な数があります。たとえば、改善できることの1つは、 開発者と管理者の間のコミュニケーションです。上記のリンクは、コミュニケーションを改善する方法の例と、それに焦点を当てる価値がある理由を示しています。
それがすべてです、あなたが思うことをコメントに書いてください。金曜日であっても、展開を頑張ってください。