Kent Beck: ジュニアエンジニアがいかにしてタスク完了から高インパクトなパフォーマンスへと移行するか

ジュニアエンジニアの目標はスループットではなく成長である

ジュニアエンジニアにとって、成功の主要な指標は完了したタスクの数ではなく、改善の速度とシステムに付加される価値です。シニアエンジニアは、新入社員の給与を、そのエンジニアが将来なり得る姿への「オプション・プレミアム」と見なし、目先の短期的な生産性よりも、高いパフォーマンスを発揮する次世代の育成を優先します。

パフォーマンス・ティアの区別：A、B、Cエンジニア

シニアエンジニアは、メンターシップやサポートのリソースをどのように割り当てるかを決定するために、新入社員を3つのティアに分類します。

• Category A (Game-Changers): 周囲の全員の生産性を向上させるエンジニア。
• Category B (Solid Performers): 安定した貢献者へと成長していく、信頼できるエンジニア。
• Category C (Underperformers): 1年以内にその役割で成功する可能性が低いエンジニア。

シニアエンジニアの時間は限られているため、彼らはCategory Aのパフォーマーを最も積極的にサポートすることを優先し、次にCategory Bを、そしてCategory Cの兆候を常に示している人々への労力は最小限に抑えます。

ベースライン：'B'エンジニアの兆候

卓越性を追求する前に、ジュニアエンジニアはまず自分がCategory Cのパフォーマーではないことを証明しなければなりません。「堅実な」（Category B）エンジニアのベースラインは、信頼性と負の外部性の回避によって定義されます。主な兆候は以下の通りです：

• Functional Code: 提出されたコードが実際に動作すること。
• Communication: 現在の活動についてチームに報告し続けること。
• Reasonable Timing: 合理的な時間枠内でタスクを完了すること（理想的には、最初の見積もりの3倍以内の範囲）。
• Minimizing Friction: 他者のために不合理な量の仕事を生み出すことを避けること。助けを求めることは許容されますが、レビュアーに過度な負担をかけたり、on-callのエラーやDevOpsのインシデントを引き起こしたりすることは否定的に捉えられます。

エンジニアを即座にCategory Cとしてマークする致命的な失敗は、仕事が完了していないにもかかわらず、完了したと主張してシステムを欺こうとする試みです。

卓越への道：'A'エンジニアの兆候

高インパクトな（Category A）エンジニアを特徴づけるのは、完了したタスクの量ではなく、各タスクからどれだけの学習を引き出したか、そして生産性の「一次導関数」です。ハイパフォーマーは、以下の行動を通じて価値を示します：

戦略的なタスク実行

• Questioning Necessity: タスクがそもそも必要ないという説得力のある主張を行うこと。
• Pareto Optimization: タスクの90%の利益をもたらす10%の部分を特定すること。
• Iterative Implementation: 最善のアプローチを見つけるために、タスクをいくつかの方法で実装すること。
• Simplification: より良い設計を見出し、必要な機能を実装しながら既存のコードベースを簡別化するdiffを提出すること。

ワークフローとツール

• Incremental Delivery: 巨大なpull requestではなく、一連の小規模で日常的なdiffを提出すること。
• Tooling Improvements: チーム全体が繰り返し行うタスクを簡素化するための内部ツールを作成すること。
• Cross-Team Contribution: 主な責任を疎かにすることなく、自身の所属チームの範囲外であっても有用なdiffを提出すること。

プロフェッショナルとしての成長とコラボレーション

• Insightful Reviewing: 応答性が高く、洞察に満ちたコードレビュアーとして行動すること。

• Quality Assurance: すべての作業において堅実なユニットテストを含めること。

• Knowledge Sharing: 学習内容を他の人が使えるように、説得力があり有用な形式でドキュメント化すること。

探索とデリバリーのバランス

ほとんどの「Aの兆候」は、タスクを完了するために必要な絶対的な最小時間よりも多くの時間を要します。これを達成するためには、ジュニアエンジニアは、完了までの絶対的な最小時間を目標にするのではなく、むしろ合理的な時間を目標にするべきです。より良い時間管理とタスク管理によって節約された時間は、チーム全体やシステムに利益をもたらす、これらの高価値な活動に再投資されるべきです。