3.4

3.4 活動の指標とその限界

概要と動機

活動、SPACE(トピック3.1)のAは、システムのテレメトリから観察可能なエンジニアリングの仕事の量を数えます。コミット、開かれたプルリクエスト、変更されたコード行数、残されたコードレビューのコメントです。これはSPACEの次元の中で測定が最も簡単なものです。なぜなら、これらのイベントはすべて、エンジニアリングチームが日々使うツールによってすでに自動的に記録されているからです。そして、その測定のしやすさこそが、この次元を過剰に重みづけするのに最も危険なものにします。活動は、注意深く使われれば本物で正当な信号です。単独の生産性の代理として使われると、それはソフトウェアエンジニアリング測定の全歴史の中で、唯一最も操作され、最も誤解を招く指標の家系です。

核心にある問題は、活動が価値ではなく動きを測定するということです。コミット件数は、難しい問題をエレガントに解決したコミットと、より生産的に見せるために一つの意味のある変更を五つに分割したコミット(トピック1.2の代替操作がこの指標の家系に直接適用されたもの)を区別しません。変更されたコード行数は、不必要なコードを削除するというはるかに価値のあるスキルよりも、冗長さを報います。エレガントでよくテストされた10行を書く前に丸一日を深く中断されない思考に費やすエンジニアは、たとえ前者がしばしばはるかに多くの本物の価値を生み出しているとしても、これらの指標によれば、20分ごとに浅く未レビューの変更をコミットするエンジニアよりも「活動的」には見えません。

大規模なチームにとって、個人評価に活動指標を使う誘惑は絶え間なく、よく文書化されています。なぜなら、活動は他のSPACEの次元にあるより難しく、より正直な信号とは異なり、特定の個人に帰属させやすく、自動的に計算しやすいからです。本トピックは特にその誘惑を名指しし、チームにそれに抵抗するための言葉と証拠を与えるために存在します。なぜなら、組織がコミット件数やコード行数でエンジニアを個別にランク付けし始めると、協働、コードの品質、士気への損害はよく文書化されており、元に戻すのが難しいからです。

重要な原則

  • 活動は価値ではなく動きを測定する。 それは正当な文脈的信号であり、決して単独の生産性の代理ではありません。
  • これはソフトウェアエンジニアリング測定における、歴史的に唯一最も誤用された指標の家系である。 その歴史を偶然ではなく警告として扱ってください。
  • 個人の活動のランク付けはほぼ常に有害である。 それは協働を損ない、目に見える雑用を報い、ほぼ即座に操作を招きます。
  • 活動データは、どんな一人の人物やチームについての独立した信号としてではなく、他の次元のための文脈として集計された形で最も有用である。
  • 深く価値のある仕事は、活動のダッシュボード上ではしばしば静かに見える。 この指標の家系は、構造的に、最良のエンジニアリングの成果を生み出すまさにその種の思考に不利に偏っています。

推奨事項

素の活動件数によって個人を決してランク付けあるいは評価しない

これは本トピックにおける唯一最も難しく最も重要な規則です。コミット件数、コード行数、プルリクエスト件数は、個人の業績評価、比較的なランク付け、あるいはエンジニアの報酬、地位、評判がその数字に依存するどんな文脈にも、決して現れるべきではありません。これはトピック1.2のインセンティブ露出の原則に直接従います。活動がインセンティブ化された個人の指標になった瞬間、操作がほぼ即座に続き、結果として生じる行動、コミットを水増しする、変更を些細に分割する、ほとんど目に見えるイベントを生み出さない深く地味な仕事を避けるといったことが、組織を積極的に害します。

活動データを判決としてではなく集計された文脈として使う

活動データは、チームレベルで集計され、他のSPACEの次元と一緒に読まれたときに、本物に有用になります。チームレベルのコミット活動の急激な低下が満足度の上昇と重なっているなら、それはチームがついに深く考え技術的負債を返済する余地を得たことを示しているかもしれません。これは肯定的なパターンであり、否定的なものではありません。孤立して読むと、同じ低下は懸念すべきものに見えます。他の次元からの文脈こそが、活動データを誤解を招くものではなく解釈可能なものにします。

素の量よりも品質に近い活動の信号を優先する

活動データが少しでも有用な場合、素の件数よりも品質に合わせて調整された信号を優先してください。レビューの深さ(トピック2.9)に対するプルリクエストのサイズ、あるいはチームがコードの複雑さを蓄積しているのか能動的に単純化しているのかを明らかにできる、新しいコードと削除されたコードの比率です。これらの調整された信号は今も活動次元のデータですが、素の件数が招く最も粗野な操作に強いものです。

活動データにおける代替操作のパターンに特に注意する

活動指標が操作される最も一般的な方法は、まさにトピック1.2の代替パターンです。件数を水増しするために、本物に意味のある仕事を多くの小さく些細なイベントに分割することです。もしコミットやプルリクエストの頻度が上昇する一方で、変更の根底にある複雑さやサイズが急激に低下しているなら、本物の生産性の改善の手柄にする前に、トピック2.10がデプロイ頻度について推奨するのと同じ診断の規律を使って調査してください。

活動シアターを明示的に名指しし抑制する

活動シアターとは、価値があるからではなく、意識的にせよ無意識にせよ、主に目に見えて数えられるからという理由で行われる仕事です。頻繁な小さなコミット、目立つ深夜の活動、あるいは共有チャンネルでの目に見える忙しさです。このパターンをあなたのチームに明示的に名指しし、経営陣が貢献を判断するために素の活動を使わないことを透明にすることは、そもそもそれが起きるインセンティブの多くを取り除きます。

トレードオフ:長所と短所

アプローチ長所短所
個人の活動ランキング単純で、計算しやすく、直接行動可能に感じられるほぼ即座に操作される。協働と士気を損なう。間違ったものを測定する
活動の測定をまったく行わない誤用のリスクを完全に避けるチームレベルのパターンを見つけるための本物に有用な文脈的信号を失う
文脈の中で読まれるチームレベルの集計活動個人のリスクなしに有用な文脈を提供する孤立してではなく他の次元と一緒に解釈する規律が必要
品質調整された活動の信号最も粗野な素の件数の操作に強い単純な件数よりも計算と説明が複雑

中心にある緊張関係は有用性と誤用のリスクです。注意深く集計され文脈の中で読まれた活動データは、持続不可能なペースや、チームが技術的負債に対処する余地を静かに見つけているといったパターンを見つけるのに本物に有用です。同じデータが個人のスコアカードとして使われると、ほぼ一様に有害です。この緊張を解消するには、活動データを完全に避けるのではなく、思慮深く文脈化されたチームレベルの使用を許可し、さらには奨励しながら、個人的な使用に対する厳格な組織的ルールを構築してください。

チームで話し合うべき問い

  1. 私たちの組織の誰かが、正式あるいは非公式に、コミットやコード行数のような素の活動件数を使って評価されたことがあるでしょうか。 これを直接尋ね、不快だが必要な答えに備えてください。この誤用は、公式な方針になることなく、マネージャーからの何気ない一言を通じて静かに起こることがよくあります。

  2. 私たちのチームで具体的に活動シアターはどのように見え、私たちはその兆候を見たことがあるでしょうか。 このパターンがあなた自身のチームで取りうる具体的でもっともらしい形を名指しすることは、それが起き始めたときにはるかに認識しやすくします。

  3. 私たちのチームレベルの活動データが動いたとき、私たちは他のSPACEの次元と一緒にそれを解釈するでしょうか、それとも孤立してでしょうか。 孤立して読まれた活動の低下は懸念すべきものに見えます。同じ低下が満足度やパフォーマンスの改善と一緒に読まれると、本物に肯定的なパターンに見えることがあります。あなたの実際のレビューの慣行をこの区別と照らし合わせて確認してください。

  4. 私たちは、平均的な変更サイズが縮小する一方でコミットやプルリクエストの頻度が上昇し、本物の生産性の利益ではなく些細な分割を示唆しているのを見たことがあるでしょうか。 実際のデータを持ち出し、この特定の代替操作のパターンを確認してください。

  5. 私たちは現在、チームで「誰が最も貢献しているか」についてどう話しているでしょうか。そしてその会話は、正式な指標がなくても暗黙のうちに活動データに頼っているでしょうか。 目に見える忙しさへの非公式で測定されていない偏りは、明示的な活動ベースの方針がなくても認識と報いを形づくることがあります。これを正直に表面化させてください。

  6. 私たちのチームで、本物に価値があるが静かな仕事、深い思考、注意深い設計、メンタリングはどのように見え、それが目に見える活動データをほとんど生み出さないにもかかわらず、私たちはそれが認識されるようどう確実にしているでしょうか。 この問いは前の問いへの肯定的な補完です。良く静かな仕事がどのように見えるかを名指しすることは、それがより騒がしく、より数えやすい仕事を優先して見過ごされるのを防ぐのに役立ちます。

業種別の視点

スタートアップ。 小さく密に協働するチームであれば、活動データは通常ダッシュボードをまったく必要とせずに見えます。そして本トピックが警告する個人ランキングのリスクは、単純に誰もがすでに他の誰が何に取り組んでいるかを知っているために、起きにくいものです。危険なのは代わりに、創業者が初期の採用や持分の決定をするときに、無意識のうちに目に見えて「忙しい」行動を好むことです。

中小企業。 あなたの既存のツールからの活動データは、チームのスループットについての一般的な感覚を得るためにざっと見るのには問題ありませんが、それを使って個々の貢献者を直接比較することには抵抗してください。小さなチームの本物の価値は、しばしば、コミット件数の見方が体系的に過小評価するであろう、静かで高レバレッジな仕事をする少数の人々に集中しています。

企業。 ここでこそ個人ランキングの誘惑が最も強く最も有害です。なぜなら、活動データは、何千人ものエンジニアにまたがる業績評価プロセスにとって引き出すのが最も簡単な信号であり、何か定量化可能な入力を見つけるプレッシャーは本物だからです。個人の活動ランキングに対する明示的で伝えられ執行される方針を構築し、その方針が単に述べられているだけでなく実務で実際に従われていることを確認するために業績評価の慣行を定期的に監査してください。

政府。 活動指標は、生産性の証拠として公開報告書で引用したくなる誘惑があります(「今年1万件のコミット」)が、この種の見出しはほとんど無意味であり、知識のあるレビュアーが素の活動が成果について何も語らないと指摘した瞬間、まさに間違った精査を招くことがあります。代わりに成果とパフォーマンスのデータ(トピック3.3)を報告し、どんな外部向けのコミュニケーションでも活動件数を避けてください。

事例

企業。 あるソフトウェア企業のエンジニアリング指導層は、正式な方針なしに、昇進の議論で個人のコミット頻度データを非公式に参照し始めていました。無関係な離職分析プロジェクトによって促された社内レビューは、会社の最も複雑で最も高価値のシステム(どんなコードが書かれる前にも長期間の注意深い設計作業を必要とする)に取り組んでいるエンジニアが、よりシンプルでより段階的に開発されるシステムのエンジニアよりも体系的に低いコミット件数を持っており、その結果として昇進の会話で微妙に不利な立場に置かれていたことを発見しました。指導層は、業績と昇進の議論における活動件数の参照を禁止する明示的で伝えられた方針を発行し、昇進の証拠をトピック3.3の複数信号のパフォーマンスのアプローチへと移しました。

政府。 ある議会の監督委員会に生産性を示すプレッシャーのもとにあったデジタルサービス機関は、当初、届けられた価値の証拠として、そのエンジニアリングプログラム全体にわたる総コミット数と書かれたコード行数を報告することを提案しました。社内の技術アドバイザーはこれに異議を唱え、技術に精通した委員会のメンバーが、素のコード量はそのコードが機能したか重要だったかについて何も語らないと容易に指摘できるため、この枠組みはまさに間違った精査を招くと正しく指摘しました。この機関の改訂された報告書は代わりに成果指標(トピック5.3)を使いました。市民報告のエラーの削減と成功したセルフサービス完了の増加です。これは活動の数字が示したであろうよりもはるかによく委員会の質問に耐えました。

ビジネスケース:動機、ROI、総所有コスト

活動指標を個人のスコアカードとしてではなく文脈的に使うことで正しく行うことからの見返りは、損害の回避です。エンジニアを活動によって個別にランク付けする組織は、確実に操作の行動、協働の減少(チームメイトを助けるのではなく自分自身の目に見えるアウトプットを守るエンジニア)、そして最も価値を生み出しながら最も目に見える活動を生み出さないことが多い深く高レバレッジな仕事への体系的な偏りを見ます。その損害を覆すことは、ひとたび業績評価文化に根づいてしまうと、本物に困難で遅いものです。

この罠を避ける総コストは、主に組織的な規律です。個人の活動ランキングに対する明示的で一貫して執行される方針、そして代わりにトピック3.3に記述されたより難しくより正直なパフォーマンス測定に投資する約束です。その規律は、個人の活動指標が時間とともに確実に生み出す、誤導された昇進の決定、損なわれた協働、操作の行動よりも安く済みます。

アンチパターンと落とし穴

  • コミット件数やコード行数による個人ランキング。 本書全体における、唯一最も有害で歴史的に最も一般的な誤用です。
  • 活動シアター。 主に価値のためではなく可視性のために行われる仕事であり、活動ベースの評価への完全に予測可能な反応です。
  • 他のSPACEの次元を確認せずにチームレベルの活動の低下を孤立して解釈する。 本物に肯定的なパターンを懸念すべきものと取り違えることがあります。
  • 外部や経営陣向けのコミュニケーションで素の活動件数を引用する。 まさに間違った精査を招き、実際の価値についてほとんど語りません。
  • ほとんど目に見えるイベントを生み出さない深く注意深い仕事を体系的に過小評価する。 この指標の家系全体に組み込まれた構造的な偏りです。
  • 非公式で方針化されていない活動の偏りが昇進やレビューの会話に忍び込む。 その背後に公式な指標がなくても有害です。

成熟度モデル

  • レベル1、開始: 活動指標は、リスクについての認識なしに、正式あるいは非公式に個人を評価しランク付けするために使われています。
  • レベル2、発展: リスクについての認識はいくらか存在しますが、活動データが非公式にレビューや昇進の議論に影響を与えることを防ぐ明示的な方針はありません。
  • レベル3、標準化: 明示的で伝えられた組織全体の方針が個人の活動ランキングを禁止しており、活動データは集計されたチームレベルの文脈でのみ使われています。
  • レベル4、管理: 業績評価と昇進の慣行が、方針が実務で従われていることを確認するために定期的に監査され、活動データが少しでも使われる場合には品質調整された活動の信号が素の件数に置き換わっています。
  • レベル5、最適化: 組織は、評価文化を活動指標からトピック3.3の複数信号のパフォーマンスのアプローチへと実証可能に移行させており、その移行がうまくいった証拠として、協働の目に見える改善と減少した操作の行動を示すことができます。

議論のためのアイデア

  1. ここにいる誰かが、たとえ非公式にであっても、活動がどれだけ「忙しく」見えるかで評価されたと感じたことがあるでしょうか。
  2. 私たちのチームで具体的に活動シアターはどのように見えるでしょうか。
  3. 私たちは個人の活動ランキングに反対する明示的で書面化された方針を持っており、それは実際に従われているでしょうか。
  4. 私たちのチームで、現在最も目に見える活動データを生み出していない静かで高価値な仕事は何でしょうか。
  5. 活動件数を完全に取り除くために、私たちの業績評価の証拠をどう再設計するでしょうか。

主な要点

  • 活動は価値ではなく動きを測定します。これはソフトウェアエンジニアリングにおける歴史的に唯一最も誤用された指標の家系です。
  • 個人を素の活動件数によって決してランク付けあるいは評価しないでください。 これは本トピックにおける最も難しく最も重要な規則です。
  • 活動データは他のSPACEの次元のための文脈として集計された形で使い、決して単独の判決としては使わないでください。
  • この指標の家系の中で特に活動シアターと代替操作のパターン(トピック1.2)に注意してください。
  • 深く高価値な仕事はしばしば最も目に見える活動データが少ないものです。それが体系的に過小評価されることから守ってください。

参考文献とさらなる読書

  • Forsgren, Nicole, Margaret-Anne Storey, Chandra Maddila, Thomas Zimmermann, Brian Houck, and Jenna Butler, “The SPACE of Developer Productivity,” ACM Queue (2021)。
  • Peopleware: Productive Projects and Teams, Tom DeMarco、Timothy Lister 著。
  • Deep Work: Rules for Focused Success in a Distracted World, Cal Newport 著。
  • The Tyranny of Metrics, Jerry Z. Muller 著。