クイズの説明
Step 2「技術負債の戦略的管理」で学んだ内容の理解度を確認します。全8問、80%（7問）以上正解で合格です。
問題
Q1. Martin Fowler の技術負債四象限で、組織として許容すべき象限はどれですか？
- A) 意図的×無謀（「設計する時間がないからそのまま出す」）
- B) 無意識×無謀（「レイヤリングって何？」）
- C) 意図的×慎重（「出荷を優先し後でリファクタリングする」）
- D) 無意識×慎重（「後から振り返ってもっと良い方法があったと気づく」）
答えを見る
正解: C
「意図的×慎重」は、ビジネス判断として意識的に負債を受け入れ、返済計画を持つ象限です。これは合理的な判断であり、組織として許容すべきです。他の象限（無謀な判断や無意識の負債）はプロセスや教育で減らすべきです。
Q2. 技術負債の「利子率が高い」とは具体的にどういう状態ですか？
- A) 初期開発コストが高かった
- B) 毎スプリントで影響し、開発速度を著しく低下させている
- C) コードの行数が多い
- D) テストカバレッジが低い
答えを見る
正解: B
利子率の高さは「負債が日々どれだけの追加コストを生んでいるか」の指標です。毎スプリントで影響する負債は利子率が高く、優先的に返済すべきです。コードの行数やテストカバレッジ自体は負債の指標の一部ですが、利子率の定義とは異なります。
Q3. 技術負債の定量化でDORAメトリクスを使う目的は何ですか？
- A) 個人のパフォーマンスを評価するため
- B) 技術負債が開発パフォーマンスに与える影響を測定するため
- C) プログラミング言語の比較をするため
- D) サーバーのリソース使用率を監視するため
答えを見る
正解: B
DORAメトリクス（デプロイ頻度、リードタイム、変更失敗率、MTTR）は、技術負債が開発パフォーマンスに与える影響を定量的に示します。負債が蓄積するとデプロイ頻度が下がり、リードタイムが伸び、変更失敗率が上がるため、負債の影響の「温度計」として機能します。
Q4. Strangler Fig パターンの最初のステップとして正しいものはどれですか？
- A) レガシーコードをすべて削除する
- B) リバースプロキシを設置し、全トラフィックを通す
- C) 新システムを完全に構築してから切り替える
- D) データベースを先に移行する
答えを見る
正解: B
Strangler Fig の最初のステップは、リバースプロキシ（API Gateway, Nginx等）を設置して全トラフィックを通すことです。この時点では既存システムに変更を加えないため、リスクが最小限です。その後、段階的に新システムにルーティングを切り替えていきます。
Q5. リファクタリング予算の「20%ルール」について正しい説明はどれですか？
- A) コードの20%を毎スプリント書き直す
- B) スプリントキャパシティの20%を技術負債の返済に確保する
- C) テストカバレッジを20%以上にする
- D) チームの20%のメンバーだけがリファクタリングを行う
答えを見る
正解: B
20%ルールは、スプリントキャパシティの20%を技術負債の返済に確保する方法です。例えば8名チームの2週間スプリント（80人日）なら、16人日をリファクタリングに使います。持続的に負債を返済でき、予測可能性が高いのがメリットです。
Q6. 技術負債を経営陣に説明する際、最も効果的なアプローチはどれですか？
- A) 「コードが汚いので書き直す時間をください」と訴える
- B) 金融アナロジー（元本・利子・返済）とROIを使ってビジネス言語で説明する
- C) 技術的な詳細（アーキテクチャ図、コードの問題点）を詳しく説明する
- D) 他社の成功事例だけを紹介する
答えを見る
正解: B
経営陣はビジネスの言葉で考えます。「毎月XX万円の利子を払っている」「YY万円の投資でZZ万円のリターン」「投資回収期間はN ヶ月」という金融アナロジーとROIで説明するのが最も効果的です。技術用語を避け、ビジネスインパクトで語ることが重要です。
Q7. 技術負債のヒートマップで優先的に対処すべき領域はどれですか？
- A) 負債スコアが最も高い領域
- B) 変更頻度が最も高い領域
- C) 負債スコアが高く、かつ変更頻度も高い領域
- D) 最も古いコードの領域
答えを見る
正解: C
負債スコアが高く、かつ変更頻度も高い領域が最優先です。なぜなら、そこが「負債の利子を最も多く払っている場所」だからです。負債が高くても変更されないコードは利子が低く、逆に変更頻度が高くても負債が少なければ問題は小さいです。
Q8. 開発者サーベイを技術負債の定量化に使う理由として最も適切なものはどれですか？
- A) エンジニアの不満を解消するため
- B) 静的解析だけでは捉えられない負債の影響（暗黙知、プロセスの問題等）を数値化するため
- C) 経営陣への言い訳材料を集めるため
- D) 個人のスキルレベルを評価するため
答えを見る
正解: B
開発者サーベイは、コードメトリクスだけでは捉えられない負債の影響を数値化するために使います。ドキュメント不足、暗黙知への依存、プロセスの非効率など、ツールでは検出できない問題を開発者の体感から定量化できます。
結果
7問以上正解の場合
合格です。 技術負債の戦略的管理について理解が深まりました。分類、定量化、戦略、コミュニケーション — これらを組み合わせて技術負債を経営課題として扱えるようになっています。
「技術負債は”エンジニアの問題”ではなく”ビジネスの問題”だ。それを経営陣に理解してもらうのが技術リーダーの仕事だ。次は組織設計を学ぼう」 — 佐藤CTO
6問以下の場合
もう少し復習しましょう。 Step 2のレッスンを再度読み返してください。
- Q1-Q2を間違えた場合 → Step 2-1「分類と可視化」を復習
- Q3を間違えた場合 → Step 2-2「定量化」を復習
- Q4-Q5を間違えた場合 → Step 2-3「リファクタリング戦略」を復習
- Q6-Q8を間違えた場合 → Step 2-4「経営コミュニケーション」を復習