経営陣は指標を好みます。「現状を測る数値が必要だ。数値は人々の意識を集中させ、成功を測るのに役立つ。」という考え方です。善意に基づいたものではありますが、数値による管理は直感に反して問題のある行動を招き、最終的にはプロジェクト全体と組織全体の目標を阻害します。指標自体は悪いものではありません。ただ、多くの場合、不適切に使用されているのです。このエッセイでは、経営陣による従来の指標の使用によって生じる多くの問題点を示し、これらの機能不全に対処するための代替案を示します。

ビジネス会議では、数値のグループを平均値を比較することで比較することが一般的です。しかし、そうすることで、これらのグループの数値の分布における重要な情報が隠されてしまうことがよくあります。この情報を明らかにするデータ視覚化ツールがいくつかあります。これには、ストリップチャート、ヒストグラム、密度プロット、ボックスプロット、バイオリンプロットなどがあります。これらは無料で入手できるソフトウェアで簡単に作成でき、12個程度の小さなグループから数千個の大きなグループまで対応できます。

開発者生産性の測定は難しい課題です。開発サイクル時間やスループットに焦点を当てた従来の指標は限界があり、他に目を向けるべき場所も明らかではありません。定性的な指標は、開発者自身から得られたデータを使用して開発者生産性を測定し理解するための強力な方法を提供します。組織は、システムからのデータではなく、人間からのデータを使用して開発者生産性を測定することを優先すべきです。

ソフトウェアプロセス、設計プラクティスなどについて、多くの感情的な議論を見かけます。ソフトウェア業界には、ソフトウェア開発の有効性の基本的な要素の一部を測定する能力がないため、これらの議論の多くは解決不可能です。特に、生産性を合理的に測定する方法がありません。

技術的負債は非常に有用な概念ですが、それをどのように測定するのかという疑問が生じます。悲しいことに、技術的負債は財政的負債とは異なり、どれほど負債を抱えているかを簡単に判断することはできません（ただし、最近では財政的な負債の測定にも苦労しているようです）。

5ポンドの袋に10ポンドの糞を入れることはできません。

– 試みたことがある人なら誰でも

ケントと私が「エクストリームプログラミングの計画」を書いたとき、この気まぐれな引用句を付け加えて、計画の本質を理解するのに役立てました。

私のキャリアの中で、関数の適切な長さについて多くの議論を聞いてきました。これは、より重要な質問である「いつコードを独自の関数にカプセル化するべきか」に対する代理指標です。これらのガイドラインの中には、画面に収まる大きさにするなどの長さに基づいたものもありました。再利用に基づいたものもありました。一度以上使用されるコードは独自の関数に入れるべきですが、一度しか使用されないコードはインラインのままにするべきです。しかし、私にとって最も意味のある議論は、**意図と実装の分離**です。コードの断片を見て何をしているのかを理解するために努力する必要がある場合は、それを関数に抽出し、その「何」を関数名にする必要があります。そうすれば、再度読むときに、関数の目的がすぐに分かり、ほとんどの場合、関数がその目的をどのように果たしているか（関数の本体）を気にする必要がなくなります。

ショッピングウェブサイトのソフトウェアを作成しているチームを想像してみてください。チームのアウトプットを見ると、過去四半期に作成した新機能の数、またはページの読み込み時間の短縮など、クロスファンクショナルな指標を検討するかもしれません。しかし、アウトカム指標では、売上高の増加や製品に関するサポート呼び出し数の減少を考慮します。アウトプットではなくアウトカムに焦点を当てることで、ソフトウェアのユーザーや顧客の有効性を向上させるためにより多くのことを行う機能の構築が促進されます。

アジャイルソフトウェア開発に初めて出会ったのは、エクストリームプログラミングの黎明期にケント・ベックと協力して働いていたときです。そのプロジェクトで感銘を受けたことの1つは、私たちが計画に取り組んだ方法です。これには、軽量でありながら以前見たものよりも効果的な見積もりアプローチが含まれていました。10年以上が経ち、今では経験豊富なアジャイリストの間で、見積もりを行う価値があるかどうか、あるいは積極的に有害であるかどうかについて議論されています。この質問に答えるには、見積もりがどのような目的で使用されるのかを検討する必要があると思います。

アジャイル手法には厳密な定義がないという不満をよく耳にします。苦情を言う人は、これによって特定のチームがアジャイル手法を使用しているかどうかを判断できないと言うかもしれません。また、これにより、アジャイル手法の実施方法を人々に教えるのが難しくなる、カリキュラムは何になるのかと言うかもしれません。

ある程度、この苦情の痛みは理解できますが、治療法がないことを受け入れています。この厳密さがないことは、アジャイル手法を定義する性質の一部であり、その中核となる哲学の一部です。

最近、エクストリームプログラミングの計画アプローチを使用する複数のチームのために、標準的なストーリーポイントメカニズムを考案することについて、いくつかの質問を受けました。期待は、いくつかのチームが同等のストーリーポイントを使用することによって、あるチームの3ストーリーポイントの努力が別のチームと同じになることです。

これを考案しようとすると、せいぜい価値が限られており、最悪の場合危険です。

時々、人々が目指すべきテストカバレッジ（コードカバレッジとも呼ばれる）の値を尋ねたり、誇らしげにカバレッジレベルを述べたりしているのを耳にします。そのような記述は要点を外しています。テストカバレッジは、テストされていないコードベースの部分を見つけるための便利なツールです。テストカバレッジは、テストの質を数値で示すものとしてはほとんど役に立ちません。

CHAOSレポートによると、プロジェクトの成功率は34％のみです。

スタンディッシュグループのCHAOSレポートは長年にわたり、ITプロジェクトで数十億ドルもの無駄な費用が発生していると述べています。34％の成功率は、2001年の28％という数値よりも実際には改善されています。しかし、「失敗」とは本当に何を意味するのでしょうか？