Q1. ADR（Architecture Decision Records）の主な目的は？
A. コードのドキュメンテーション B. アーキテクチャの意思決定とその根拠を記録し、将来の参考にする C. プロジェクトの進捗を管理する D. テスト結果を記録する
答えを見る
正解: B
ADRは「なぜこの技術選定をしたか」「どのような選択肢を検討したか」を記録し、将来同じ文脈で意思決定する際の参考にする。チームの入れ替わりがあっても、過去の決定の背景を理解できる。
Q2. フィットネス関数の「ホリスティック」タイプとは？
A. 単一の品質属性を測定する B. 複数の品質属性を組み合わせて総合的に評価する C. 手動でのみ実行できるテスト D. パフォーマンスのみを測定する
答えを見る
正解: B
ホリスティックなフィットネス関数は、パフォーマンス、セキュリティ、モジュラリティ等の複数の品質属性を組み合わせて、アーキテクチャの総合的な健全性を評価する。
Q3. dependency-cruiserの主な用途は？
A. npmパッケージの脆弱性スキャン B. モジュール間の依存関係ルールを定義し違反を検出する C. テストカバレッジを測定する D. バンドルサイズを最適化する
答えを見る
正解: B
dependency-cruiserは、プロジェクト内のモジュール間の依存関係を分析し、定義されたルール（例: ドメイン層がインフラ層に依存しない）への違反を検出するツール。CI/CDに統合してアーキテクチャの劣化を防ぐ。
Q4. テクニカルスタンダード（技術標準）で「非推奨」の技術が存在する意味は？
A. その技術を使用することが禁止されている B. 既存システムでの使用は認めるが、新規採用は避けるべき C. その技術は削除する必要がある D. ドキュメントに記載する必要がない
答えを見る
正解: B
「非推奨」は既存システムでの継続利用は認めつつ、新規プロジェクトでの採用を避けることを意味する。段階的な移行を促進しつつ、レガシーの即時廃止による混乱を防ぐ。
Q5. アーキテクチャレビューのタイミングとして最も適切なのは？
A. コーディング完了後の本番デプロイ直前 B. 詳細設計の開始前（設計の方向性を決める段階） C. 本番リリース後 D. 年次の定期レビューのみ
答えを見る
正解: B
アーキテクチャレビューは設計の方向性を決める早い段階で行うべき。実装が進んでからの変更はコストが高く、手戻りが大きい。「Shift Left」の原則に従い、早期にフィードバックを得る。
Q6. ADRのステータス「置換（Superseded）」の意味は？
A. ADRが削除された B. 新しいADRによってこの決定が更新されたが、歴史的記録として残す C. ADRが承認された D. ADRが却下された
答えを見る
正解: B
「置換」は、状況の変化により新しいADRが作成され、古い決定が更新されたことを示す。しかし古いADRは削除せず、「なぜ当時その決定をしたか」「なぜ変更が必要になったか」の歴史的記録として保持する。
Q7. アーキテクチャ適合度スコアリングで「重み付け」を行う理由は？
A. 計算を簡単にするため B. ビジネスにとって重要な品質属性を優先的に評価するため C. スコアを100点に正規化するため D. フィットネス関数の数を減らすため
答えを見る
正解: B
重み付けにより、ビジネスにとって重要な品質属性（例: 金融システムではセキュリティ、ECサイトではパフォーマンス）をスコアに強く反映させ、適切な優先順位で改善を推進できる。
Q8. テクニカルスタンダードに新しい技術を追加する際に最も重要なプロセスは？
A. 即座に全チームに導入を義務づける B. ADRで選定理由を文書化し、PoCで実証した上で段階的に導入する C. 最新の技術トレンドに従う D. コスト最安の技術を選ぶ
答えを見る
正解: B
新技術の導入にはADRで「なぜ必要か」「何と比較したか」を文書化し、PoCで技術的リスクを検証した上で、パイロットプロジェクトから段階的に導入するのが適切。