クイズの説明
Month 9「技術の羅針盤を握ろう」の総合理解度をチェックします。
- 全8問
- 合格ライン: 80%（7問正解）
- 全Stepの内容から出題されます
問題
Q1. テクニカルリードの4つの柱として正しい組み合わせはどれですか？
- A) 技術ビジョン、コーディング、テスト、デプロイ
- B) 技術ビジョン、意思決定、メンタリング、コミュニケーション
- C) 設計、実装、レビュー、運用
- D) 採用、評価、育成、配置
答えを見る
正解: B
テクニカルリードの4つの柱は、技術ビジョン（チームの技術的方向性）、意思決定（技術的な判断）、メンタリング（チームメンバーの育成）、コミュニケーション（ステークホルダーとの橋渡し）です。Dはエンジニアリングマネージャーの領域です。
Q2. 技術選定の評価基準マトリクスで「重み」をつける目的と、PoC実施の判断基準の組み合わせとして正しいものはどれですか？
- A) 重みは全基準を平等にするため / PoCは全ての選定で必須
- B) 重みはプロジェクト固有の重要度を反映 / PoCは机上評価で判断できない場合に実施
- C) 重みはスコアを100点満点にするため / PoCは予算が余った場合に実施
- D) 重みは候補を絞り込むため / PoCは候補が3つ以上の場合に実施
答えを見る
正解: B
評価基準の重みは、プロジェクトの状況（期限、チームスキル、パフォーマンス要件等）に応じた重要度を反映するために設定します。PoCは評価マトリクスだけでは判断できない技術的仮説を、実際に手を動かして検証するために実施します。
Q3. ADRのイミュータブル原則と、RFCの承認後の流れとして正しいものはどれですか？
- A) ADRは自由に修正できる / RFCは削除する
- B) ADRは変更せず新しいADRで置き換える / 承認されたRFCはADRとして記録する
- C) ADRは毎月更新する / RFCは永久に保管する
- D) ADRはコードに埋め込む / RFCはWikiに移動する
答えを見る
正解: B
ADRのイミュータブル原則では、一度承認されたADRの内容は変更しません。状況が変わった場合は、元のADRを「superseded」にし、新しいADRを作成します。RFCは承認された後、その決定がADRとして簡潔に記録され、意思決定の変遷履歴が残ります。
Q4. ドレイファスモデルの「一人前（Competent）」のエンジニアに最も適したメンタリングアプローチはどれですか？
- A) 具体的な手順を示し、逐一確認する
- B) 目標を共有し、方法は本人に任せる
- C) 高度なデザインパターンを教え込む
- D) メンタリングの方法論を教える
答えを見る
正解: B
「一人前（Competent）」のエンジニアは、計画を立てて問題を解決できる段階にあります。このレベルでは、自主性を尊重し、目標を共有した上で方法は本人に任せることが効果的です。困った時の相談相手として存在し、新しい挑戦の機会を提供します。
Q5. コードレビューで「ソクラテス式質問法」とBLOCKERラベルを適切に使い分ける場面はどれですか？
- A) ソクラテス式は常に使い、BLOCKERは使わない
- B) ソクラテス式は学習機会に使い、BLOCKERはセキュリティ等の重大な問題に使う
- C) BLOCKERを常に使い、ソクラテス式は使わない
- D) ソクラテス式はシニア向け、BLOCKERはジュニア向け
答えを見る
正解: B
ソクラテス式質問法は教育的な場面で使い、レビュイーに自分で考えさせることで学習効果を高めます。一方、BLOCKERラベルはセキュリティ脆弱性やデータ損失リスクなど、対応必須の重大な問題に使います。両者は補完関係にあり、状況に応じて使い分けます。
Q6. 心理的安全性を高めるためにテクニカルリードが取るべき行動と、Blameless Postmortemの核心の組み合わせとして正しいものはどれですか？
- A) 完璧な技術力を見せる / 障害の責任者を特定する
- B) 自ら弱さを見せ「分からない」と言う / 個人ではなくシステムの問題を探す
- C) 厳格なルールで品質を守る / 二度と障害が起きないことを保証する
- D) メンバーの発言を全て記録する / 障害の頻度をKPIにする
答えを見る
正解: B
テクニカルリードが自ら「分からない」と言い、失敗を共有することで、チームメンバーも安心して挑戦できるようになります。Blameless Postmortemでは「誰がミスしたか」ではなく「なぜミスが可能だったか」を探し、システム（プロセス、ツール）を改善します。
Q7. ベンダーロックインの回避にPorts & Adaptersパターンを使う場面と、ロックインを受容してよい場面の判断として正しいものはどれですか？
- A) 全てのサービスに抽象化層を設ける / ロックインは一切受容しない
- B) コアビジネスロジックとデータ層を抽象化する / 生産性向上が抽象化コストを大きく上回る場合は受容する
- C) UIレイヤーのみ抽象化する / コストが安ければ受容する
- D) 抽象化は不要 / 全てのベンダーサービスを受容する
答えを見る
正解: B
Ports & Adaptersパターンは特にコアビジネスロジックとデータアクセス層に適用し、ベンダー固有の実装をAdapterとして分離します。一方、ベンダー固有サービスの生産性向上が抽象化のコストを大きく上回る場合（例: マネージド認証サービス）は、リスクを理解した上で受容するのが合理的です。
Q8. テクニカルリードとして新規プロジェクトの立ち上げで最も重要な最初のアクションはどれですか？
- A) 最新のフレームワークを選定してすぐにコーディングを始める
- B) 要件を明確化し、技術戦略を立て、チームと合意を形成する
- C) 詳細なドキュメントを全て書いてからコーディングを始める
- D) チームメンバー全員にプレゼンテーションスキルを教える
答えを見る
正解: B
テクニカルリードとしてプロジェクト立ち上げ時に最も重要なのは、要件の明確化、技術戦略の立案（スタック選定 + ロードマップ）、そしてチームとステークホルダーとの合意形成です。フレームワークの選定もその一部ですが、要件分析と戦略なしに技術を選ぶのは「Hype Driven」のアンチパターンです。
結果
7問以上正解の場合
合格です。おめでとうございます。
Month 9「技術の羅針盤を握ろう」を完了しました。
あなたはテクニカルリードとして以下のスキルを身につけました：
- 技術的意思決定を主導し、体系的なフレームワークで技術選定を行える
- ADR/RFCを通じて意思決定を記録・共有できる
- メンバーの成長段階に応じたメンタリングを設計できる
- 技術をステークホルダーに伝え、チームのナレッジ共有を推進できる
次の Month 10 では、さらに組織レベルの技術戦略に踏み込みます。
6問以下の場合
もう少し復習しましょう。
| 問題 | 復習セクション |
|---|---|
| Q1 | Step 1: テクニカルリードの役割 |
| Q2 | Step 2: 技術選定の方法論 |
| Q3 | Step 3: RFC/ADRの書き方 |
| Q4, Q5 | Step 4: メンタリングとチーム育成 |
| Q6 | Step 4: 心理的安全性と学習する組織 |
| Q7 | Step 2: ベンダーロックインの回避 |
| Q8 | Step 6: 総合演習 |
Month 9 完了
お疲れさまでした。
学んだこと（全体の振り返り）
| Step | テーマ | 核心 |
|---|---|---|
| Step 1 | テクニカルリードの役割 | 技術の方向性を示し、チームを導く |
| Step 2 | 技術選定の方法論 | 体系的なフレームワークで判断する |
| Step 3 | RFC/ADRの書き方 | 意思決定を記録し、議論を構造化する |
| Step 4 | メンタリングとチーム育成 | 成長段階に応じた支援を設計する |
| Step 5 | テクニカルコミュニケーション | 技術を伝え、知識を共有する文化を作る |
| Step 6 | 総合演習 | 全スキルを統合してプロジェクトを導く |
テクニカルリードとしての心得
「テクニカルリードの仕事は、最高のコードを書くことではない。 チーム全員が最高のコードを書ける環境を作ることだ」 — 高橋アーキテクト
推定所要時間: 30分