クイズの説明
Month 5「技術標準とベストプラクティスを策定しよう」の卒業クイズです。技術棚卸し、標準化設計、策定プロセス、普及戦略、進化サイクルの全領域から出題します。
合格ライン: 80%（10問中8問正解）
問題
Q1. テクノロジーレーダーの活用（Step 1）
テクノロジーレーダーの4つの象限（Adopt/Trial/Assess/Hold）のうち、「新規プロジェクトでの利用を推奨し、既存プロジェクトでも段階的に採用すべき」と位置づけられるカテゴリはどれですか？
- A. Assess — 注目すべき技術として調査中
- B. Trial — 限定的なプロジェクトで検証中
- C. Adopt — 組織として推奨する標準技術
- D. Hold — 新規利用を非推奨とする技術
答えを見る
正解: C
Adopt（C）は組織として推奨する標準技術であり、新規プロジェクトでの利用を推奨し、既存プロジェクトでも段階的な採用を促します。Assess（A）は情報収集の段階で本番利用には早く、Trial（B）はパイロットプロジェクトでの検証段階です。Hold（D）は新規利用を非推奨とし、既存利用については移行計画の策定を求めます。テクノロジーレーダーは技術の「推奨度」を組織全体で共有するコミュニケーションツールです。
Q2. 技術的負債の評価（Step 1）
技術的負債の優先度を決定する際に最も適切な評価基準の組み合わせはどれですか？
- A. コード行数と開発者の好み
- B. 影響度（セキュリティリスク、障害頻度）と修正コスト（工数、期間）
- C. 技術の新しさと流行度
- D. マネージャーの意見とベンダーの推奨
答えを見る
正解: B
技術的負債の優先度は「影響度」と「修正コスト」のマトリクスで判断します（B）。影響度はセキュリティリスク、本番障害の頻度、開発生産性への影響で評価し、修正コストは必要な工数、期間、リスクで評価します。影響度が高く修正コストが低い負債（例: CVE対応）が最優先です。コード行数（A）は負債の深刻度と直接相関しません。技術の新しさ（C）は負債の評価基準ではなく、マネージャーの意見（D）だけでは客観性に欠けます。
Q3. 標準化スコープ（Step 2）
標準化の「Must（必須）/ Should（推奨）/ May（任意）」の3段階分類において、「テストカバレッジ60%以上」はどのレベルに分類されるのが最適ですか？
- A. Must — CI/CDでブロックし、達成しないとマージ不可
- B. Should — Warningを出し、レビューで指摘するが強制はしない
- C. May — 各チームの裁量に完全に委ねる
- D. 標準化の対象外
答えを見る
正解: B
テストカバレッジはコードの品質と生産性に寄与する指標であり、Should（推奨）に分類するのが最適です（B）。Must（A）にすると、グッドハートの法則により「カバレッジを上げるためだけの意味のないテスト」が量産されるリスクがあります。一方、May（C）にすると基準がなくなり、チーム間で大きな品質格差が生じます。Shouldレベルでは、CI/CDでWarningを表示し、コードレビューで議論の対象とすることで、数字だけでなくテストの質も含めた判断が可能になります。
Q4. RFCプロセス（Step 3）
RFCプロセスにおいて、技術的な提案が「全エンジニアにオープンなレビュー」を経る最も重要な理由はどれですか？
- A. レビュー参加者が多いほど、提案の品質が上がるため
- B. 影響を受ける全チームが意見を述べる機会を持ち、合意形成と当事者意識を促すため
- C. 提案者の責任を分散するため
- D. レビューの実績をエンジニアの人事評価に使うため
答えを見る
正解: B
オープンなレビューの最大の目的は「合意形成」と「当事者意識の醸成」です（B）。技術標準は全チームに影響するため、影響を受ける人々が議論に参加し、自分たちの意見が反映されたと感じることが重要です。トップダウンで押し付けられた標準よりも、議論を経て合意された標準のほうが遵守率が高くなります。多くのレビュアーによる品質向上（A）も副次的な効果ですが、最大の目的は組織的合意です。責任分散（C）は目的ではなく、人事評価への利用（D）はRFCの趣旨に反します。
Q5. ADRの実践（Step 3）
ADR（Architecture Decision Record）に記録すべき最も重要な要素はどれですか？
- A. 決定事項のみを簡潔に記録する
- B. 決定事項、背景（コンテキスト）、検討した選択肢、選択の理由、却下された選択肢とその理由
- C. 決定者の名前と役職
- D. 決定に要した会議の時間と参加者リスト
答えを見る
正解: B
ADRの最大の価値は「なぜその決定をしたのか」を未来の読者が理解できることです（B）。決定事項だけでなく、当時のコンテキスト（制約条件、組織の状況）、検討した選択肢（却下されたものを含む）、選択の理由を記録します。特に「却下された選択肢とその理由」が重要で、将来同じ議論が繰り返されることを防ぎます。決定事項のみ（A）では背景が失われ、決定者の名前（C）や会議の詳細（D）はADRの本質ではありません。
Q6. ツーリングによる標準の自動化（Step 4）
CI/CDパイプラインに品質ゲートを導入する際、「Warning → Critical Block → Full Gate」の段階的アプローチを取る理由として最も適切なものはどれですか？
- A. ツールのライセンスを段階的に購入するため
- B. 既存コードベースには新しい基準を満たさないコードが多数あり、一気にブロックすると開発が停滞するため
- C. エンジニアに段階的にプレッシャーをかけるため
- D. 上層部への報告がしやすいため
答えを見る
正解: B
段階的導入の最大の理由は「既存コードとの共存」です（B）。レガシーコードが多い環境でいきなりFull Gateを導入すると、大量のPRがブロックされ、通常の開発業務が停滞します。Warning期間で現状の違反を可視化し、チームに修正の時間を与え、段階的にブロック条件を厳格化することで、開発の継続性と標準準拠のバランスを取ります。この「ゆでガエル」ではなく「段階的な引き上げ」が、標準浸透の成功パターンです。
Q7. マイグレーション戦略（Step 4）
本番稼働中の大規模サービスをレガシーフレームワークから新フレームワークに移行する場合、Strangler Figパターンが推奨される最大の理由はどれですか？
- A. 移行コストが最も安いため
- B. ビジネスの継続性を確保しながら、リスクを最小化して段階的に移行できるため
- C. 移行が最も速く完了するため
- D. 新旧のフレームワークの性能を同時に比較できるため
答えを見る
正解: B
Strangler Figパターンの最大のメリットは「ビジネス継続性の確保」と「リスクの最小化」です（B）。旧サービスと新サービスを共存させ、機能単位でトラフィックを段階的に切り替えることで、ロールバックが容易であり、問題が発生しても影響範囲を限定できます。移行コスト（A）は必ずしも最安ではなく（並行稼働期間のコストがかかる）、移行速度（C）もBig Bangのほうが理論上は速い場合があります。性能比較（D）は副次的な効果に過ぎません。
Q8. メトリクスの活用（Step 5）
以下の状況を分析してください。技術標準導入後6ヶ月の指標:
- テストカバレッジ: 52% → 78%（大幅改善）
- 本番障害件数: 月4.2件 → 月4.0件（ほぼ横ばい）
この結果から導き出される最も適切な解釈はどれですか？
- A. テストカバレッジが上がったので、障害も必ず減少するはず。計測ミスだ
- B. カバレッジは上がっているが障害が減っていないため、テストの「質」に問題がある可能性がある
- C. カバレッジと障害件数には相関がないため、カバレッジの計測は不要
- D. 標準化は効果がなかったため、元に戻すべき
答えを見る
正解: B
カバレッジの量的改善が質的改善に繋がっていない典型的なケースです（B）。カバレッジが上がっても、以下の原因で障害が減らない可能性があります: (1)assertionのないテスト、(2)正常系のみのテスト（異常系・境界値の不足）、(3)障害の原因がテストでカバーしにくい領域（インフラ、設定ミス等）にある。メトリクスは「組み合わせで判断」することが重要で、カバレッジと障害件数を併せて見ることで、テストの質を改善すべきという示唆が得られます。カバレッジの計測自体が不要（C）ではなく、標準を元に戻す（D）のは早計です。
Q9. 非推奨化プロセス（Step 5）
Vue.js 2（サポート終了済み）を非推奨化し、Reactへの移行を進める場合、非推奨化の段階的強制力として正しい順序はどれですか？
- A. Hard Block → Soft Block → Warning
- B. Warning → Soft Block → Hard Block
- C. Hard Block のみ（段階なし）
- D. Warning のみ（ブロックなし）
答えを見る
正解: B
非推奨化の強制力は「Warning → Soft Block → Hard Block」の順に段階的に引き上げます（B）。まずWarningで非推奨の事実を周知し、チームに認識を促します。次にSoft Block（新規のVue.js 2コンポーネント追加をブロック）で新たな負債の蓄積を防ぎます。最後にHard Block（Vue.js 2関連コードのすべてのPRをブロック）で完全な廃止を強制します。いきなりHard Block（A, C）は開発を停滞させ、Warningのみ（D）は移行が進まないリスクがあります。各段階に十分な期間を設け、移行支援を並行して提供することが重要です。
Q10. 総合判断問題（All Steps）
あなたは技術標準体系のリードとして、CTO、VPoE、各チームリードが出席する技術会議で技術標準体系書のプレゼンテーションを行います。以下の4つの質問が想定されます。最も適切な回答の組み合わせはどれですか？
CTO: 「標準化すると、イノベーションが阻害されないか？」 チームリードA: 「うちのチームはGoを使いたいが、標準はTypeScript推奨だ。どうすればいい？」 チームリードB: 「標準を導入しても、忙しくてテストを書く時間がない」 SREリード: 「標準を変更するたびにCI/CDが壊れるのでは？」
- A. CTO: 「イノベーションは禁止」、リードA: 「Goは使用禁止」、リードB: 「テストは任意」、SRE: 「CI/CDは変更しない」
- B. CTO: 「Assess/TrialゾーンでイノベーションのためのPoCを許容。RFCで提案すればAdoptに昇格可能」、リードA: 「RFCでGoの採用提案を行い、ユースケースと理由を示して委員会の承認を得る。例外プロセスも利用可能」、リードB: 「テンプレートとCI/CDにテストを組み込むことで、テストを書く”追加コスト”を最小化。品質ゲートの段階的導入で負担を分散」、SRE: 「段階的導入とWarning期間で影響を最小化。テンプレートのバージョニングで変更を制御」
- C. CTO: 「標準は変えない」、リードA: 「転職すればいい」、リードB: 「テストは必須、残業で対応」、SRE: 「壊れたら直せばいい」
- D. CTO: 「全員自由にやればいい」、リードA: 「何でも使って良い」、リードB: 「テストは不要」、SRE: 「CI/CDは廃止」
答えを見る
正解: B
各質問への適切な回答:
CTO: 技術標準はイノベーションを殺すものではなく、テクノロジーレーダーのAssess/Trialゾーンが「実験の場」として機能します。新技術は限定的なPoCで検証し、効果が確認できればRFCで提案してAdoptに昇格させるプロセスがあります。標準は「安全に実験するためのフレームワーク」です。
チームリードA: 標準はトップダウンの命令ではなく、RFCプロセスを通じて民主的に変更可能です。Goの採用にユースケースがあるなら、RFCで提案し、パフォーマンス要件やチームのスキルセットを根拠に示してください。また、一時的例外プロセスを利用し、6ヶ月の検証期間を得ることも可能です。
チームリードB: プロジェクトテンプレートにテストの雛形を組み込み、CI/CDで自動実行することで「テストを書く追加コスト」を最小化します。品質ゲートはWarning→Criticalと段階的に導入し、既存コードの一括修正は求めません。新規コードから段階的にカバレッジを上げていくアプローチです。
SREリード: 標準の更新はIaCテンプレートとCI/CDパイプラインのバージョニングで管理します。テンプレートのメジャーバージョンアップは移行期間を設け、各チームが準備できてから適用します。Warning期間で事前に影響を確認でき、Soft Blockの段階でCI/CDの破壊的変更は発生しません。
結果
合格（8問以上正解）
おめでとうございます。Month 5「技術標準とベストプラクティスを策定しよう」を修了しました。
技術棚卸し、標準化設計、RFC/ADRプロセス、普及戦略、進化サイクル — 技術標準体系に必要なすべての要素を学び、組織全体の技術基盤を設計する力を身につけました。
「技術標準は”制約”ではなく”共通言語”だ。エンジニアが安心して挑戦し、チーム間でナレッジが自然に流通する組織を作るための土台だ。この力を活かして、技術組織を次のレベルに導いてくれ」 — 田中VPoE
不合格（7問以下正解）
Month 5の内容を復習し、再度チャレンジしましょう。特に不正解だった領域のStepを重点的に復習してください。
| 問題番号 | 対応するStep |
|---|---|
| Q1 | Step 1: テクノロジーレーダー（4象限の分類） |
| Q2 | Step 1: 技術的負債の評価（影響度 x 修正コスト） |
| Q3 | Step 2: 標準化スコープ（Must/Should/May） |
| Q4 | Step 3: RFCプロセス（合意形成の重要性） |
| Q5 | Step 3: ADR（決定の理由の記録） |
| Q6 | Step 4: ツーリング（段階的導入） |
| Q7 | Step 4: マイグレーション（Strangler Figパターン） |
| Q8 | Step 5: メトリクス（組み合わせで判断） |
| Q9 | Step 5: 非推奨化（段階的強制力） |
| Q10 | 総合: 全Stepの統合判断 |
推定所要時間: 30分