未経験メンバーに任せるタスクの設計と、コードレビューの段階

未経験で入ったメンバー2名を育てたときに、自分が使っていた方法を書く。中心は2つで、最初のタスクを「失敗しても困らない範囲」に切ることと、コードレビューの細かさを期間で区切って段階的に下げていくことだ。

どちらも誰かに教わった型ではなく、やりながら落ち着いた形なので、他のチームにそのまま当てはまるとは限らない。前提と理由もあわせて残しておく。

前提：答えは渡さず、考える時間を確保する

指導の軸は「答えをこちらから出さない。相談にはいつでも乗る」だった。教えられたことより、自分で考えてたどり着いたことのほうが定着する、という自分自身の経験からそうしている。

ただし、これは詰まっても実害が出ない状況でしか成り立たない。本番に影響するタスクで詰まれば、こちらが巻き取るしかなくなり、考える時間は消える。だから先に必要なのは、指導の仕方よりもタスクの切り方だった。

最初に渡すタスクは、影響範囲を小さく限定する。

× 「このAPIを実装して」（範囲が広すぎる）
○ 「このエンドポイントのバリデーション処理だけ書いて」

最初の1ヶ月は、次の3つを満たすものだけを渡していた。

基準	理由
本番に影響しない	間違えても利用者に届かない。やり直しがきく
他の機能と独立している	詰まっても他の作業を止めない。原因の切り分けも狭い範囲で済む
1〜2日で完了できる	行き詰まったまま長く抱え込まない。結果がすぐ出る

3つ目は見落としやすい。期間が長いタスクは、進んでいるのか止まっているのかが外から見えにくい。1〜2日で終わる大きさにしておけば、止まっていること自体がすぐ分かる。

この3つを満たしていれば、詰まることはむしろ歓迎できる。失敗しても大丈夫な場所を用意したうえで、自分で調べて抜ける経験をしてもらう、という考え方だ。

質問が来たときは、答えの代わりに次の3つを聞いていた。

「どこで詰まってる？」
「エラーメッセージは何と言ってる？」
「自分ではどう解決しようとした？」

狙いは、問題を言葉にしてもらうことにある。何が起きていて、何を試したのかを説明しているうちに、本人が解決策に気づくことが多い。

それでも進めないときは、渡す情報を少しずつ増やす。

いきなり3に行かないのがポイントで、1で抜けられるなら1で止める。

レビューの細かさは、期間で区切って下げていった。

最初の3ヶ月は、指摘よりも理由の説明に時間を使う。「こう書く」だけを伝えると、別の場面で応用がきかない。なぜその書き方なのかまで伝えて初めて、次のコードに持ち越せる。

3ヶ月を過ぎたら、コメントを指示から質問に変える。「こうしてください」ではなく「なぜこう書いた？」と聞く。説明できれば通す。説明できなければ、一緒に考える。判断基準を「正しいか」から「理由を説明できるか」に移す段階だ。

6ヶ月以降は、構成や責務の分け方といった大枠だけを見る。細部を任せるのは信頼の表明でもあるし、レビューする側の時間を空けるためでもある。

月数はあくまで自分のチームでの目安で、区切りそのものより「全行 → 要所 → 大枠」と順に手を離す流れのほうが大事だと思っている。レビューを仕組みとしてどう回してきたかは、コードレビューを3年続けた記録に書いた。

この進め方は、育てる側の時間をかなり使う。全行にコメントして理由まで書くレビューは、自分で直してしまうより確実に遅い。自分は開発や要件定義、プロジェクト管理と並行していたので、余裕がある状態でやれていたわけではなかった。

また、条件を満たすタスクがいつもあるとは限らない。本番に影響せず、独立していて、1〜2日で終わる仕事は、探さないと見つからない。大きなタスクから切り出して用意する手間は、渡す側が負うことになる。

関連記事: