はじめに
採用の話（hiring）でも、入社初日の話（onboarding）でも、一緒にコードを書く話（pair-programming）でもない。ジュニアエンジニアが入社後も継続して技術力を伸ばし続けるための仕組みをClaude Codeで作る話だ。
ジュニアエンジニアが詰まったとき、シニアが手を離せない——この状況はどのチームでも起きる。コードレビュー待ち、別のミーティング中、集中作業の真っ最中。「後で聞いて」が積み重なると、ジュニアは停滞し、シニアは申し訳なさを抱える。育成の質が「シニアが何時間使えるか」に依存しているうちは、チームが大きくなるほどこの問題は深刻になる。
Claude Codeを「疲れ知らずのメンター」として機能させる設計を、実践レベルで整理した。
「疲れ知らずのメンター」をCLAUDE.mdで設計する
Learning Mode × TODO(human)マーカー
Claude Codeには「Learning」出力スタイルがある。このモードでは、Claudeが全コードを書き切るのではなく、`#TODO(human)` マーカーで実装すべき箇所をジュニアに残す。
/output-style learningこのコマンドでLearningモードに切り替わる（公式確認済み）。定期的に立ち止まり、「ここはあなたが実装してみてください」と促す。「一緒に問題を解くペアプログラマー」のような経験を再現する設計だ。実装の全てをAIに丸投げするのではなく、自分の手を動かす機会を意図的に残す。
shipyard.buildの報告によると、Claude Codeの出力スタイルを活用したチームがパターン理解の深化を通じてフィーチャー開発速度が約30%向上したという。「全部やってもらう」ではなく「考えながら使う」スタイルが、成長速度に直結している。
Explanatoryモードとの使い分けも重要だ。
- Learning Mode: コードを書きながら学ぶ（TODO(human)マーカーで自分で実装する機会を残す）
- Explanatory Mode: アーキテクチャ判断の背景・トレードオフを解説させる（なぜSSRではなくSSGを選んだのか等）
FOR[yourname].md——コードベースの「入門書」を自動生成する
CLAUDE.mdに以下のような指示を書くことで、Claude Codeがプロジェクトのコードベースを読んで、新メンバー向けの「入門書」を自動生成するようになる。
## ジュニアエンジニア向け学習ドキュメント
新しいエンジニアが参加したら、FOR[名前].mdを作成すること。
内容：
- システム全体のアーキテクチャを平易な言葉で説明
- 技術選定の背景と理由（「なぜRabbitMQではなくKafkaなのか」）
- 遭遇したバグの事例と解決方法
- チームのベストプラクティスと暗黙知
- 「知らないとハマる」落とし穴
文体は教科書的でなく、アナロジーや具体例を使って読みやすく。新メンバーが参加するたびに、コードベースを読んだClaude Codeがその人向けの入門書を自動生成する。シニアエンジニアが毎回同じ説明をする必要がなくなる。
なお、FOR[yourname].mdパターンは「コードベースを初日に理解する」文脈でも活用できる。本記事では入社後の継続的な技術スキル成長支援への転用にフォーカスしている（コードベース理解の詳細については、別途公開のcodebase-understanding記事を参照してほしい）。
副産物として、生成されたFOR[yourname].mdは引き継ぎドキュメントにもなる。担当者が抜けるときの「自分しかわからない」を減らす資産だ。ただし、自動生成されたドキュメントには誤解釈が含まれる可能性があるため、生成後に人間がレビューすることは欠かせない。
ミスをCLAUDE.mdに追記して「二度と起きない」仕組みを作る
PRで発生したケアレスミスを、CLAUDE.mdに追記することで「同じミスをさせない」仕組みを作れる。
1. PRで具体的なミスが発生する
↓
2. CLAUDE.mdにルールとして追記
↓
3. 次回から同じミスをClaude Codeが事前に指摘
↓
4. ミス率が測定可能な形で低下していく追記の例はこうなる。
## よくあるミスと対処法
- user_idはUUID（int64ではない）——過去のバグ#123で発覚
- タイムゾーンは全てUTC保存、表示時にJSTに変換
- 非同期処理には必ずtry/catchを書く（silent failureを防ぐ）
- テストを書いてからコードを書く（TDD原則）ミスが起きるたびにCLAUDE.mdが育ち、次のジュニアには同じミスが起きにくくなる。「ミスを責める」文化から「ミスをルール化する」文化への転換だ。
EMとしての視点では、ジュニアのミスは「チームの学習資産」として扱える。個人の問題ではなくシステムの問題として捉えると、改善サイクルが組織全体に広がる。CLAUDE.mdが育つほどミス率が下がるこの仕組みは、チームの規模が大きくなるほど複利で効いてくる。
ジュニアに伝える「Claude Codeと考える」哲学
Sanityのスタッフエンジニアが6週間のClaude Code活用をまとめた教訓がある。「最初の試みは95%ゴミになる。ジュニア開発者が複雑な機能を一発でクリアすることを期待しないのと同じだ。」
この姿勢は重要だ。Claude Codeを使い始めたジュニアエンジニアが「なんでもすぐに正解が出る」と期待すると、最初の結果に失望するか、精度が低い出力をそのまま使ってしまう。
興味深い逆説がある——Claude Codeとの協働では、ジュニア開発者がシニアより優れたアプローチを取ることがある。シニアは「自分の考え」に固執しがちだが、ジュニアは素直に「どうやればいいですか？」と複数の選択肢を求める。正解を「知っていると思っていない」ため、Claude Codeの回答を先入観なく評価できる（medium.com/@aaron.rose.tx）。
EMがジュニアエンジニアに伝えるべき具体的なプロンプトパターンを整理した。
# 理解を深めたいとき
「この実装を複数の方法で提案して。それぞれのトレードオフを説明して」
# 自分のアプローチを検証したいとき
「私はXXXという実装を考えています。経験豊富なエンジニアが指摘しそうな問題点を教えて」
# 失敗から学ぶとき
「このコードがなぜ動かないか教えて。原因だけでなく、なぜそういうバグが起きるかも説明して」「全部作ってもらう道具」ではなく「問いながら考える相手」として使うことが、技術力が伸びる使い方になる。この哲学をチームのカルチャーとして定着させることがEMの役割だ。
ただし、Claude Codeに頼りすぎると自分で考える力が育たないリスクがある。TODO(human)マーカーや「アプローチ検証プロンプト」のような仕掛けで、意図的に「自分で考える機会」を設計することが重要だ。
まとめ
`/output-style learning` で始めて、FOR[yourname].mdを一枚書いてみる。これだけでチームのメンタリング構造が変わる可能性がある。
育成のボトルネックが「シニアの空き時間」にある限り、チームのスケールは止まる。Claude Codeを疲れ知らずのメンターとして機能させる設計に、一度投資してみてほしい。シニアが解放された時間を、より高度な判断と本当のメンタリングに使える体制が作れる。
コメント