Skip to content

シニアエンジニアが若手にClaude Codeを活かす方法

シニアエンジニアとしての新しい役割

Section titled “シニアエンジニアとしての新しい役割”

シニアエンジニアにとって、Claude Codeは「自分の仕事がなくなる」ツールではありません。むしろ「よりシニアらしい仕事に集中できる」ツールです。

コードを書く作業の一部をClaudeが担うことで、シニアエンジニアは本来最も価値を発揮できる仕事に時間を使えます。

  • アーキテクチャ設計・技術判断
  • 若手のメンタリング・レビュー
  • ビジネス側とのコミュニケーション
  • 技術的な意思決定

若手のコードをより深くレビューできる

Section titled “若手のコードをより深くレビューできる”

Claude Codeを使うと、若手が書いたコードをより短時間でレビューできます。

「このPRのコードを以下の観点でレビューしてください。
[PRのコードをペースト]
観点:
1. バグの可能性
2. パフォーマンスの問題
3. セキュリティの懸念
4. 保守性・可読性
5. このコードをレビューした場合の「必ず指摘すべき点」と「できれば指摘したい点」を分けて
背景: 担当は入社2年目のジュニアエンジニア。成長を促すフィードバックにしたい。」

Claudeがチェックリスト的なレビューを行い、あなたは「なぜそれが重要か」「どう改善するか」の文脈を加えるという分業ができます。

若手から「この設計でいいですか?」と相談を受けたとき、Claudeに事前に壁打ちしておくことで、より深いフィードバックができます。

「若手エンジニアからこの設計案を見せてもらいました。
[設計案]
この設計について:
1. 優れている点(若手を正しく評価するために)
2. 問題点と、その影響
3. 代替案
私のフィードバックの準備として整理してください。」

自分が担当しない領域のコードを見るとき

Section titled “自分が担当しない領域のコードを見るとき”

シニアでも、専門外の技術スタックのコードレビューは難しいことがあります。

「このKubernetesのマニフェストファイルをレビューしたいですが、
k8sの詳細はあまり詳しくありません。
インフラエンジニアの観点で問題点があれば教えてください。
[マニフェスト]」

若手のClaude Code活用を指導するフレームワーク

Section titled “若手のClaude Code活用を指導するフレームワーク”

若手にClaude Codeを正しく使ってもらうための指導方針です。

「Claudeに聞く前に考える」ルール

Section titled “「Claudeに聞く前に考える」ルール”
悪い使い方: 問題が出たら即Claudeに聞く
良い使い方:
1. まず5〜10分自分で調べる
2. 仮説を立てる
3. Claudeに「自分の仮説はこうだが、合っているか確認したい」と聞く

「理解してからコミットする」ルール

Section titled “「理解してからコミットする」ルール”
「Claudeが生成したコードは、
理解してからコミットしてください。
理解できないコードはコミットしない。
もし理解できないコードがあれば、Claudeか私に質問してください。」

このルールをCLAUDE.mdに明記することもできます:

# チーム規約
## Claudeが生成したコードについて
- 生成されたコードは理解してからコミットすること
- 理解できない部分はコメントに `// TODO: 理解する [担当者名]` と残すこと
- PRレビューで「ここはどういう意図で書いたか」を聞かれることがある

ペアプログラミングの新しい形

Section titled “ペアプログラミングの新しい形”

「若手 + Claude + シニアのレビュー」という3者の協働パターンが有効です。

ワークフロー:
1. 若手がClaudeと一緒に実装する
2. 実装が完了したら、Claudeにコードの説明コメントを追加させる
3. シニアがコードと説明コメントを一緒に確認する
4. コードより「設計の意図・判断」をレビューする
CLAUDE.md: プロジェクトのルートに置くClaude Code専用の設定ファイル。プロジェクト固有のルールやコンテキストを記述する。コミット: Gitでファイルの変更を履歴として記録する操作。

CLAUDE.mdでチームのレベルに合わせた指示をする

Section titled “CLAUDE.mdでチームのレベルに合わせた指示をする”

チームの習熟度に合わせてCLAUDE.mdを調整します。

## Claudeへのお願い
このプロジェクトのメインの開発者は、
プログラミング経験1〜2年のジュニアエンジニアです。
以下を心がけてください:
- コードを生成したら、何をしているか説明するコメントを追加する
- 初めて使うパターンを採用したときは、なぜそのパターンを使うか説明する
- 複数の実装方法がある場合は、「シンプルで理解しやすい方」を選ぶ
- エラーが出たとき、エラーメッセージの読み方も教える
## Claudeへのお願い
このチームは全員がシニアエンジニアです。
- 説明は省略してよい。コードの意図が明確なら説明不要
- パフォーマンス・スケーラビリティを重視した実装を選ぶ
- トレードオフがある場合は選択肢を提示して選ばせる

シニアエンジニア自身の活用方法

Section titled “シニアエンジニア自身の活用方法”

アーキテクチャドキュメントの作成

Section titled “アーキテクチャドキュメントの作成”
「このシステムのアーキテクチャドキュメントを作成してください。
CLAUDE.mdとコードベースを参照して、以下の内容で:
1. システム概要図(テキストで表現)
2. 主要コンポーネントの説明
3. データフロー
4. 技術的な意思決定とその理由
5. 既知の技術的負債
ドキュメントの読者: 新しく参加するシニアエンジニア」
「[技術名]の採用を検討しています。
以下の観点で調査レポートを作成してください:
- 成熟度・コミュニティの状況
- 我々のユースケースへの適合度
- 同様の技術との比較
- 既知の欠点・落とし穴
- 採用した場合のマイグレーション工数(現在の[現在の技術]からの移行)」
マイグレーション: データベースのスキーマ(テーブル構造)を安全に変更するための手順書。