データも、最初は彼らに同意していた。

言われたこと

あるエンジニアの成果が期待に届いていないと言われました。

その懸念は、プロダクトとエンジニアリング双方のリーダーシップから寄せられていました。

このエンジニアは、提供までに時間がかかりすぎる、決定に対して異議を唱えすぎる、チームの調和を乱している、と評されていました。

組織は、このエンジニアをチームから外すことを検討していました。

証拠は、一見はっきりしているように見えました。

GitHubで仕事が割り当てられてからプルリクエストが開かれるまで、このエンジニアはしばしば、実装そのものにかかると想定される時間よりも長く時間をかけていました。

その指標で見る限り、このエンジニアは確かに遅かったのです。

観察したこと

GitHubは、経過時間を示していました。

しかし、その時間の間にエンジニアが何をしていたかまでは示していませんでした。

そこで私たちは、Slackにまで仕事を追跡しました。

依頼を受けると、このエンジニアはしばしば、なぜその仕様が存在するのか、それがどんな問題を解決しようとしているのか、あるいは別の実装のほうが同じ目的をよりよく達成できないか、と質問していました。

これらは、思いつきの反論ではありませんでした。

実装が始まる前に、要件の背景を理解しようとする試み、あるいは代替案を提案しようとする試みだったのです。

プロダクトオーナーは、概してこうした質問や提案を不要なものとして扱っていました。

提案が却下されると、このエンジニアはすぐに実装を始めました。

質問や提案に返答がない場合でも、このエンジニアは無期限に待ち続けることはありませんでした。

営業日で三日が経過すると、返答がなかったことを述べたうえで、元の依頼どおりに実装を進める旨を伝えていました。

コーディングという仕事が始まるのは、そこからでした。

パターン

組織は、割り当てから提供までの時間をすべて、エンジニアリングの実行時間として計測していました。

しかし、その時間のかなりの部分は、実装が始まる前に費やされていました。

このエンジニアは、意図を明確にしたり、前提を問い直したり、代替案を提案したりしようとしていたのです。

こうした活動は、有用な仕事として数えられていませんでした。

むしろ、遅れとして解釈されていました。

この解釈は、このエンジニアの評判も形作っていました。

質問することは、抵抗のように見えました。

代替案を提案することは、指示に従うことを拒んでいるように見えました。

答えの出ていないプロダクトの決定を待つことは、実装が遅いように見えました。

こうして、同じ振る舞いが、この人物に対する複数の否定的な評価の根拠として使われていたのです。

そして、もう一つのシグナルを見つけた

このエンジニアが却下された、あるいは無視された提案の一部は、そこで消えてなくなったわけではありませんでした。

当初の実装がリリースされたあと、プロダクトオーナーが後のスプリントで同じアイデアを求めることがあったのです。

以前は不要とされていた提案が、のちに正式な要件として戻ってくることがありました。

それには意味がありました。

それは、このエンジニアの質問や代替案が、単なる妨害ではなかったことを示していました。

少なくともその一部は、プロダクト組織がいずれにせよ最終的には求めることになる改善点を特定していたのです。

私たちの仮説

このエンジニアが抱えていたのは、主として能力の問題ではありませんでした。

組織は、ある一種類のエンジニアリング行動だけを、他のすべてより優先して評価する環境をつくり出していました。すなわち——

与えられた指示を、そのまま実行すること。

仕様に疑問を呈することは、遅れを生みました。

代替案を提案することは、摩擦を生みました。

説明を待つことは、計測されるリードタイムを増やしました。

この観点から見ると、実装前に仕事をよくしようとするエンジニアは、ただちにコーディングを始めるエンジニアよりも、生産性が低く見えることがありました。

この仕組みは、単に提供の速さだけを計測していたわけではありませんでした。

指示への従順さを、間接的に評価していたのです。

当初の診断が説得力を持って見えた理由

当初の判断は、架空のデータに基づいていたわけではありませんでした。

経過時間は、実際に長かったのです。

そこが、このケースを興味深いものにしている点です。

一つの証拠源が、組織の結論を裏づけていました。

もし私たちがGitHubの時点で調査をやめていたら、同じ結論にたどり着いていたかもしれません。

しかし、この指標が答えていたのは、たった一つの問いだけでした。

割り当てから提供まで、どれだけの時間が経過したか。

この指標が答えていなかったのは——

• 実装は実際にいつ始まったのか。
• 実装の前に何が起きていたのか。
• 誰が誰を待っていたのか。
• どの決定が未解決のままだったのか。
• コードそのものの外で、どんな価値が生み出されていたのか。

証拠が示したこと

提供までの経過時間だけを測れば、このエンジニアは確かに遅いということになります。

しかし、その数字は、いくつもの異なる種類の活動を一つの指標にまとめてしまっていました。

実装を、明確化・提案・意思決定・待機時間から切り分けたとき、この数字の意味は変わりました。

組織は、システムレベルの相互作用のパターンを、個人のパフォーマンスの問題として解釈していたのです。

このエンジニアをチームから外しても、そのパターンは解消されなかったでしょう。

それは、そのパターンを可視化していた人物を取り除くだけのことだったはずです。

データが間違っていたわけではありません。解釈が不十分だったのです。

Pulsarの視点

私たちは、ある人が仕事において良いか悪いかを判断することから始めるわけではありません。

私たちは、仕事そのものを追います。

このケースでは、GitHubが提供に時間がかかっていることを示していました。

Slackが、その理由を示していました。

その後のプロダクトの決定は、不要とされていた振る舞いの一部が、実は本当の価値を見出していたことを示していました。

これらの観察のどれ一つとして、単独では全体像を語ってはいませんでした。

しかし、それらを合わせると、診断は変わりました。

私たちは、一つのシグナルだけで人を評価しません。そのシグナルを生み出したシステムを調べるのです。