EngThrive: Make It Fast and Easy to Do Great Work
本論文は、マイクロソフトで開発された開発者生産性を速度、容易さ、品質の周りに組織化し、ウェルビーイングを優先するとともに、活動ではなく真の成果と指標を整合させるためにテレメトリと調査の組み合わせを活用する多次元の測定および改善システムであるEngThriveを紹介する。
原論文は CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) でライセンスされています。 これは以下の論文のAI生成解説です。著者が執筆または承認したものではありません。技術的な正確性については原論文を参照してください。 免責事項の全文を読む
巨大な船の船長になったと想像してください。あなたの目標は、船を可能な限り速く目的地に到達させることです。長年、あなたは成功を、乗組員が舵を回した回数や、船から水をくみ出したバケツの数で測ってきました。「くみ出した水のバケツ数が多い＝船が速い」と考えていたのです。
しかし、ある奇妙なことに気づきます。乗組員は舵を激しく回し、狂ったように水をくみ出しているのに、船は以前より速く進んでいません。むしろ、乗組員は疲れ果て、怒り、船を降りる準備さえしています。
これがマイクロソフトのエンジニアリングリーダーたちが直面した問題です。彼らは、コード行数やプルリクエスト数といった「活動」を数えることが、開発者が実際に素晴らしい仕事をしているかどうかを測る悪い方法だと気づいたのです。
この論文は、ソフトウェア工学を工場の組立ラインではなく、生きた生態系として扱う新しい生産性の測定方法「EngThrive」を紹介しています。その仕組みを簡単に解説します。
大きな過ち：間違ったものを数える
この論文は、長年、企業が「コード行数」のような単一の数値で生産性を測定しようとしてきたと説明しています。
- 罠: 作家を単語数で報酬を支払えば、彼らはより多く報酬を得るために長く退屈な文章を書くでしょう。開発者をコード行数で評価すれば、彼らは数値に合わせるために散漫で非効率なコードを書くでしょう。
- 「リモートワーク」のパラドックス: パンデミック中、マイクロソフトは開発者が以前より 20% 多くのコードを提出しているのを目撃しました。古い計算方法では、全員がスター選手でした。しかし、開発者に「気分はどうですか？」と尋ねると、78% が燃え尽き症候群だと答えました。船は速く進んでいましたが、乗組員は溺れかけていたのです。
解決策：「速度、容易さ、品質」の三脚
EngThrive は単一の数値ではなく、三脚のような三つの要素を使用します。一本の脚が短ければ、三脚は倒れてしまいます。高く立つためには、三つすべてが必要です。
- 速度（レース）: これは単にタイピングが速いことではありません。「アイデアから顧客へ」までの時間です。
- 比喩: 車の塗装が到着するのを 3 週間待たなければならない、あるいは管理者が色を頻繁に変更している場合、あなたが車をどれだけ速く塗っても意味がありません。速度とは、アイデアを持つ瞬間から顧客が実際にそれを使うまでの「総時間」を測定するものです。
- 容易さ（スムーズな道）: これは摩擦を測定します。
- 比喩: 車を運転していると想像してください。ブレーキが固着し、ラジオが壊れ、赤信号のたびに書類を記入しなければならない場合、エンジンがパワフルでもあなたは速く運転できていません。「容易さ」は、開発者が新しいものを構築する時間に対して、ツールとの格闘や会議の待機、壊れたビルドの修正に費やす時間をどれくらい測定するかを表します。
- 品質（耐久性）: これは仕事が持続するかどうかを測定します。
- 比喩: 1 日で家を建て（速度）、手間もかからず（容易さ）、雨が降るたびに屋根が漏れるなら、あなたは生産的だったわけではありません。あなたは単に後でより多くの作業を生み出しただけです。品質は、物がどれほど頻繁に壊れ、それを直すのにどれくらい時間がかかるかを測定します。
安全装置：「Thriving（繁栄）」
「Thriving」と呼ばれる第四の要素があります。これは最大化すべき目標ではなく、安全装置です。
- 比喩: 車のスピードメーターを想像してください。アクセルを踏み込んで速く走ることができますが、エンジンから煙が出始め、運転手が苦痛で叫び始めたら、ブレーキを踏む必要があります。
- 変更がチームを速くしても、彼らを不幸にすれば（燃え尽き症候群、悪い日）、Thriving 指標は警報を鳴らします。この論文では、不幸な開発者は生産性がないと述べる可能性が 25 倍高く、辞める可能性が 2 倍高いことがわかりました。乗組員が辞めてしまっては、速い船は作れません。
測定方法：「混合手法」
EngThrive は、単にコンピュータのログ（テレメトリ）を見るだけ、あるいは人々に気分を尋ねるだけ（アンケート）ではありません。それらを組み合わせます。
- テレメトリはフィットネストラッカーのようです。それは「何が起こったか」を教えてくれます（例：「会議に 4 時間費やしました」）。
- アンケートは人に尋ねるようなものです：「それはどう感じましたか？」（例：「その会議は無意味で苛立たしかったです」）。
- 両方を組み合わせることで、完全な物語が語られます：「会議に 4 時間費やしましたが、それは時間の無駄に感じられました」。
論文からの実例
この論文は、マイクロソフトでこの仕組みがどのように機能したかという 3 つの物語を共有しています。
- 「会議」の修正: あるチームは、開発者が会議に溺れていることに気づきました。彼らは全員により多くの「集中時間」を与えることを目標に設定しました。
- 結果: 開発者は週に 2 時間余分の集中時間を得ました。彼らは単に速く働くだけでなく、彼らを悩ませていた古くて壊れたコード（技術的負債）を修正しました。結果は？「悪い日」が減り、実際の出力が 13% 向上しました。
- 「ゲーム」実験: あるチームは、「最初のプルリクエストまでの時間（新入社員がコードを提出するまでの速さ）」という指標を「ハック」しようと試みました。初日に小さく簡単なタスクを与えることでです。
- 結果: 驚くべきことに、これは機能しました！彼らが指標を「ハック」したにもかかわらず、新入社員はより自信を持ち、ツールを早く習得し、翌年以降により多くのコードを書くことになりました。その「ゲーム」が正しい行動を強制したのです。
- 「健康デー」実験: 燃え尽き症候群の危機の間、あるチームは全員に 2 日間の計画外の休暇を与えました。
- 結果: コード出力は 2 日間低下しました（「速度」にとっては悪いこと）。しかし、燃え尽き症候群の緩和は数ヶ月続いたため、チームは失われた仕事をわずか 2 週間で取り戻しました。「Thriving」という安全装置がなければ、リーダーたちは 1 日目には「失敗」に見えたため、休暇をキャンセルしたかもしれません。
AI についてはどうでしょうか？
この論文は、AI は新しいハンマーや速い車のような、単なる別のツールであると主張しています。
- AI は人々がコードを速く書くようにするかもしれませんが（活動）、EngThrive はこう問います：それは実際に製品を顧客に速く届けるのでしょうか（速度）？仕事をより苛立たなくするのでしょうか（容易さ）？物を壊す頻度を減らすのでしょうか（品質）？
- このフレームワークは、オフィスビル、休暇制度、会議のルールと同様に、AI に対しても機能します。
結論
あなたは単一の数値で人間を測定することはできません。EngThrive は次のようなシステムです：「素晴らしい仕事をするのを速く、容易に、高品質にし、仕事をする人々がその間幸せで健康であることを確認しましょう」。
それは企業を「何行のコードを書きましたか？」という問いから、「どれだけの価値を生み出し、それを作るのはどんな感じでしたか？」という問いへと移行させます。
自分の分野の論文に埋もれていませんか？
研究キーワードに一致する最新の論文のダイジェストを毎日受け取りましょう——技術要約付き、あなたの言語で。