LESSON 30分

「自分だけが詳しい状態は、チームにとってリスクだ」と佐藤CTOは言った。「知識を共有し、チーム全体の技術力を底上げする。それがシニアエンジニアの最も重要な仕事の一つだ。」

1. メンタリングフレームワーク

SITUATIONモデル

ステップ説明
Skill assessmentメンティーの現在のスキルレベルを評価「TypeScriptは書けるがDB設計は未経験」
Identify goals目標を設定「3ヶ月後にDB設計を自走できるようにする」
Tailor approach個別のアプローチを設計ペアプログラミング週1回 + 課題図書
Undertake actions実行実際のタスクで実践
Assess progress進捗を評価月次1on1でフィードバック
Track outcomes成果を追跡スキルマトリクスの更新

スキルマトリクス

チームスキルマトリクス(例)

メンバー    | TypeScript | DB設計 | AWS | セキュリティ | CI/CD |
─────────────────────────────────────────────────────────
Aさん(Sr)  | ★★★      | ★★★  | ★★★| ★★☆       | ★★★  |
Bさん(Mid) | ★★★      | ★★☆  | ★★☆| ★☆☆       | ★★☆  |
Cさん(Jr)  | ★★☆      | ★☆☆  | ★☆☆| ★☆☆       | ★☆☆  |
Dさん(Jr)  | ★☆☆      | ★☆☆  | ★★☆| ★☆☆       | ★☆☆  |

→ バスファクター(1名のみ★★★のスキル)を特定し、知識共有を計画

2. Tech Talk 文化

■ Tech Talk プログラム
頻度: 隔週金曜 16:00-17:00
形式: 30分発表 + 15分 Q&A + 15分 ディスカッション

■ テーマ例
- 技術共有: 「GraphQLへの移行で学んだこと」
- 障害レビュー: 「先月のインシデントから学んだ3つの教訓」
- 外部発表練習: カンファレンス登壇前のリハーサル
- 読書会: 「Designing Data-Intensive Applications」第3章

■ 運営のコツ
- 登壇のハードルを下げる(LTからスタート)
- 録画してアーカイブ(非同期で視聴可能に)
- 質問は歓迎する雰囲気を作る

3. ドキュメンテーション戦略

種類目的
ADR意思決定の記録「なぜPostgreSQLを選んだか」
Runbook運用手順「インシデント対応手順」
How-to手順書「ローカル開発環境のセットアップ」
Architecture Overview全体像「システムアーキテクチャ図」
Onboarding Guide新メンバー向け「チームの開発フロー」

ドキュメントの鮮度維持

■ Doc Rotation
- 各ドキュメントにオーナーを設定
- 四半期ごとにレビュー & 更新チェック
- 古いドキュメントは「archived」ラベルを付与
- 新メンバーのオンボーディング時に不足を発見 → 即追加

4. Communities of Practice(実践コミュニティ)

■ CoP 設計例
Frontend CoP: フロントエンド技術の横断的な知識共有
  - 月1回のミーティング
  - Slackチャンネル #cop-frontend
  - 共有リソース: デザインシステム、ベストプラクティス

Backend CoP: バックエンド・インフラの横断的な知識共有
  - 月1回のミーティング
  - 共有リソース: API設計ガイドライン、パフォーマンス基準

Security CoP: セキュリティの横断的な意識向上
  - 月1回のセキュリティニュースレター
  - 四半期ごとのCTF(Capture The Flag)イベント

まとめ

トピック要点
メンタリングスキルマトリクスで可視化し、個別にアプローチ
Tech Talk隔週開催、ハードルを下げて文化を育てる
ドキュメントADR, Runbook, How-to を整備し鮮度を維持
CoP横断的な実践コミュニティで組織学習を加速

チェックリスト

  • スキルマトリクスでチームのバスファクターを特定できる
  • Tech Talkプログラムを設計できる
  • ドキュメンテーション戦略を策定できる
  • Communities of Practiceの運営計画を立てられる

次のステップへ

テクニカルメンタリングとナレッジ共有を学んだ。次は 演習 で、技術提案書を作成しよう。

推定読了時間: 30分