チーム開発で伸びる人が、コードの外でやっていること

一人で書ける量には限りがあります。同じ実力でも、チームの中での動き方で成果は大きく変わる。レビュー、質問、記録という3つの場面から整理しました。

一人で書ける量には限りがあります。だから、ある段階から先の成果はチームの中での動き方で決まります。技術力が同じでも、ここで差がつきます。

レビューで、何を見ているか

伸びる人は、レビューを2つの方向で使っています。

受けるとき。指摘を直すだけで終わらせず、なぜそう指摘されたのかを1つ質問する。直し方より、判断基準のほうが次に効きます。

出すとき。動くかどうかだけでなく、この変更が他にどう影響するかを見る。他人のコードを読む量が、そのまま設計の引き出しになります。

質問の仕方が、伸び方を決める

質問しない人は伸びが遅く、質問しすぎる人は信頼を失う。この間にちょうどいい形があります。

• 調べた範囲を先に書く。「◯◯を試して、△△までは分かりました」。相手の説明が短くて済みます。
• 詰まっている時間に上限を決める。30分調べて進まなければ聞く、と決めておく。判断を毎回しなくて済みます。
• 答えをもらったら、記録して共有する。同じ質問を他の人がしなくなります。

3つ目が特に効きます。質問を、自分だけの解決から、チームの資産に変える動きだからです。

書く力が、想像以上に効いてくる

設計の意図、判断の理由、詰まったところの記録。これらを書ける人は、チームの中で位置が変わります。

理由は単純で、書かれていないことは、その人がいないと分からないからです。書いてある状態を作れる人は、任される範囲が広がります。

しかも、書く作業は自分のためにもなります。説明できないということは、まだ理解していないということなので、書く過程で穴が見つかります。

詰まっている人に、気づく

チームの生産量を落とすのは、難しい問題より誰かが静かに詰まっている時間です。

進捗が止まっている、質問が減った、コミットが途切れた。こうした変化に気づいて声をかける人は、目立たないところでチーム全体の速度を上げています。

この役割は肩書きと関係なく発生します。そして、成果が「起きなかった遅延」の形をしているので、評価に乗りにくい。自分でやっているなら、記録に残しておく価値があります。

技術の話を、技術以外の人にする

経験を積むほど、非エンジニアと話す場面が増えます。ここで伝えられるかどうかが、選べる仕事の範囲を決めます。

コツは、実装ではなく選択肢と、その結果を話すことです。「AとBがあって、Aは早いが後で作り直しが要る、Bは遅いが長く使える」。

この形にすると、相手が判断できます。技術の説明をしても、相手は判断できません。

まとめ

• ある段階から先の成果は、チームの中での動き方で決まる
• レビューは、直し方ではなく判断基準を1つ聞く
• 質問は、調べた範囲を書き、時間の上限を決め、答えを共有する
• 書かれていないことは、その人がいないと分からない。書ける人に範囲が集まる
• 詰まっている人に気づく役割は、評価に乗りにくいので記録に残す
• 技術以外の人には、実装ではなく選択肢と結果を話す