## 診断結果

### 佐々木さん: 初心者（Novice）
根拠:
- プログラミングの基礎段階にある
- エラーメッセージを自分で解釈できない（ルールに基づく行動がまだ）
- 質問を躊躇する（何が分からないかが分からない状態）

### 田村さん: 中級者（Advanced Beginner）
根拠:
- 経験をもとに動くコードは書ける（パターン認識あり）
- 設計の全体像を考えずに始める（全体の把握が不十分）
- テストの重要性の理解が浅い（文脈の考慮が限定的）

### 中村さん: 一人前〜熟練者（Competent〜Proficient）
根拠:
- 技術的な問題を自力で解決できる
- CI/CD構築などチーム貢献もできる
- 知識共有が少ない（他者への教育段階に入りきれていない）

## 佐々木さん メンタリング計画（3ヶ月）

### 目標
3ヶ月後に「簡単な機能を一人で実装し、PRを出せる」状態にする。

### 月1: 基礎固め
| 週 | テーマ | 方法 |
|----|--------|------|
| 1 | 開発環境の理解 | ペアプロ（Strong-Style）|
| 2 | エラーメッセージの読み方 | 毎日15分のデバッグセッション |
| 3 | Git の基本操作 | ハンズオン + チートシート提供 |
| 4 | 簡単なバグ修正 | ペアプロで一緒に取り組む |

### 月2: 自走力の育成
| 週 | テーマ | 方法 |
|----|--------|------|
| 1 | テストの書き方 | テンプレートを提供し、真似て書かせる |
| 2 | 小さな機能の実装 | 要件を細かく分割して渡す |
| 3 | コードレビューの受け方 | レビューの意図を一緒に読み解く |
| 4 | 自分のPRを出す | レビュー前にセルフレビューを習慣化 |

### 月3: 自立への移行
| 週 | テーマ | 方法 |
|----|--------|------|
| 1-2 | 機能を一人で実装 | 困ったら相談する形に変更 |
| 3-4 | 振り返りと次の目標設定 | 1on1で成長を言語化 |

### 1on1の頻度
- 月1: 週2回（30分）
- 月2: 週1回（30分）
- 月3: 隔週1回（30分）

### 心理的安全性の確保
- 「質問は何度でもOK」と繰り返し伝える
- 小さな成功を一緒に喜ぶ
- 失敗したときは原因を一緒に探す（責めない）

## 田村さん メンタリング計画（3ヶ月）

### 目標
3ヶ月後に「設計を考えてからコードを書き、適切な粒度のPRを出せる」状態にする。

### 月1: 設計思考の導入
| 活動 | 頻度 | 内容 |
|------|------|------|
| 設計レビュー | 実装前に毎回 | 実装前に5分間の設計スケッチを書かせる |
| ペアプロ | 週1回 | 設計判断のプロセスを見せる |
| 書籍 | 自習 | 「リーダブルコード」を推薦 |

### 月2: テスト文化の定着
| 活動 | 頻度 | 内容 |
|------|------|------|
| TDDペアプロ | 週1回 | Ping-Pongスタイルで実践 |
| PR分割の練習 | 毎PR | 300行以下を目標に分割指導 |
| テスト戦略の理解 | レッスン | Unit/Integration/E2Eの使い分け |

### 月3: コードレビュー力の向上
| 活動 | 頻度 | 内容 |
|------|------|------|
| レビュアー経験 | 週2-3件 | 佐々木さんのPRをレビュー |
| 設計ADR | 月1件 | 自分の設計判断をADRに書く |
| 振り返り | 月末 | 成長の言語化と次の目標 |

### コーチングの方針
- 答えを教えるのではなく、「なぜそう設計した？」と質問する
- 失敗を許容し、レビューで学ばせる
- 良い設計をした時は具体的に褒める

## 改善後

### 1. 「これはダメ」→
「この部分、ユーザーが null を入力した場合に
例外が発生しそうです。バリデーションを追加すると
安全になります。例えば:
`if (!input) throw new ValidationError('入力が必要です');`」

### 2. 「なんでこんな書き方するの？」→
「ここで for ループを使っている意図を教えてもらえますか？
Array.map() を使うとより宣言的に書けるかもしれません。
もし意図的に for を使っているなら、コメントがあると
次の人が理解しやすくなります」

### 3. 「テスト書いて」→
「この関数はビジネスロジックの核心部分なので、
テストがあると安心です。特に以下のケースが重要だと思います:
- 正常系: 有効な入力でユーザーが作成される
- 異常系: メールアドレスが重複した場合
参考: tests/user.test.ts に似たパターンがあります」

### 4. 「全部直して」→
「いくつかフィードバックを書きました。
優先度の高いものから対応してもらえると助かります:
1. [BLOCKER] SQLインジェクションの脆弱性（L45）
2. [CONCERN] N+1クエリの可能性（L78）
3. [SUGGESTION] 変数名の改善（L23）
3は時間がなければ次のPRでも大丈夫です」

## チーム学習計画（四半期）

### 目標
チーム内の知識の偏在を解消し、全員が学び合う文化を作る。

### 週次活動
| 活動 | 時間 | 担当 | 内容 |
|------|------|------|------|
| テックトーク | 金曜30分 | ローテーション | 最近学んだことを15分で共有 |
| モブプロ | 水曜1.5時間 | テクニカルリード | 複雑なタスクを全員で取り組む |

### 中村さんへの施策
- テックトークの最初の登壇者として依頼
- 佐々木さんのメンター役を正式にアサイン
- ADRの作成を担当し、設計判断を文書化してもらう
- 「教えることは最大の学び」の価値を1on1で伝える

### 知識共有の仕組み
1. Wikiに技術ナレッジベースを構築
2. Slack #til チャンネルで日々の学びを共有
3. 月次で「チーム技術状況レポート」を作成

### 効果測定
| 指標 | 現状 | 目標 |
|------|------|------|
| テックトーク登壇率 | 20% | 80% |
| Wiki記事数（月） | 2件 | 8件 |
| ペアプロ実施回数（週） | 0回 | 3回 |

## 心理的安全性の改善計画

### 現状の問題
佐々木さんが質問を躊躇する。他のメンバーにも同様の傾向がある可能性。

### 改善アクション

#### 即座に実施
1. テクニカルリード自身が「分からない」と積極的に発言する
2. 佐々木さんの質問に対して「いい質問だね」と反応する
3. Slack #質問-なんでも チャンネルを作り、リードが最初に質問を投稿

#### 1ヶ月以内
4. チームのグラウンドルールを設定:
   - 「初歩的な質問は存在しない」
   - 「同じ質問は2回までOK。3回目はドキュメント化の合図」
5. ペアプロの機会を増やし、自然に質問できる場を作る
6. 1on1で「何か困っていることはない？」を毎回聞く

#### 3ヶ月以内
7. Blameless Postmortemを導入し、失敗を学びに変える文化を作る
8. 「今週の良い質問」をチーム会議で共有する
9. 匿名フィードバックで心理的安全性を定期測定

### 効果測定
- Slack での質問投稿数の推移
- 1on1 での佐々木さんの自己評価
- チーム全体の匿名アンケートスコア