クイズの説明
Month 6「開発者プラットフォームを構築しよう」の卒業クイズです。Platform Engineering、DevEx評価、セルフサービス設計、IDP、Golden Path/ガードレール、プラットフォーム運営の全領域から出題します。
合格ライン: 80%（10問中8問正解）
問題
Q1. Platform Engineeringの本質（Step 1）
Platform Engineeringの3つの柱として正しい組み合わせはどれですか？
- A. インフラ自動化、コスト削減、セキュリティ強化
- B. Developer Experience、Golden Path、Platform as a Product
- C. CI/CD、Kubernetes、Terraform
- D. マイクロサービス、コンテナ、サーバーレス
答えを見る
正解: B
Platform Engineeringの3つの柱は、(1) Developer Experience（認知負荷の軽減、セルフサービス化、高速フィードバック）、(2) Golden Path（標準化されたテンプレート、ベストプラクティスの組み込み、「正しいことが簡単なこと」）、(3) Platform as a Product（開発者を顧客として扱い、フィードバックに基づいて改善）です。A（インフラ自動化等）やC（CI/CD等）は手段であり目的ではありません。
Q2. 開発者体験の測定（Step 1）
以下のメトリクスのうち、DORAメトリクスに含まれないものはどれですか？
- A. デプロイ頻度
- B. リードタイム
- C. eNPS（従業員推奨度）
- D. MTTR（平均復旧時間）
答えを見る
正解: C
DORAメトリクスの4つのキー指標は、(1) デプロイ頻度、(2) リードタイム（コミットからデプロイまでの時間）、(3) 変更失敗率、(4) MTTR（障害からの復旧時間）です。eNPS（Employee Net Promoter Score）はDORAメトリクスには含まれず、SPACEフレームワークのSatisfaction（満足度）の指標です。DORAメトリクスはソフトウェアデリバリーのパフォーマンスを、eNPSは開発者の満足度を測定する異なる軸の指標です。
Q3. セルフサービス設計（Step 2）
セルフサービスプラットフォームにおいて、production環境のリソース作成にTeam Leadの承認を要求し、dev/staging環境では自動承認にする設計の目的はどれですか？
- A. Team Leadの権威を示すため
- B. dev/staging環境ではセキュリティが不要なため
- C. 開発速度（dev/staging）と統制（production）のバランスを取り、リスクの高い操作にのみ人間の判断を介在させるため
- D. インフラコストを削減するため
答えを見る
正解: C
環境ごとに承認レベルを変える設計は、開発速度と統制のバランスを最適化するためです。dev/staging環境は実験と学習の場であり、自動承認により開発者の自律性と速度を最大化します。一方、production環境は顧客に影響するため、リソース作成にTeam Leadの承認を要求し、コストやセキュリティの観点でチェックを行います。B（セキュリティ不要）は誤りで、dev/staging環境でもガードレール（rootユーザー禁止等）は適用されます。
Q4. GitOpsとロールバック（Step 2）
GitOpsにおいて、障害発生時のロールバック方法として最も適切なものはどれですか？
- A. 本番サーバーにSSHで接続し、前のバージョンのバイナリを手動でデプロイする
- B. GitOpsリポジトリでgit revertを実行し、Argo CDが自動的に前のバージョンに同期する
- C. CI/CDパイプラインを手動で再実行し、前のバージョンのイメージを指定する
- D. Kubernetesのkubectl rollout undoコマンドを直接実行する
答えを見る
正解: B
GitOpsにおけるロールバックは、GitOpsリポジトリでgit revertを実行するだけです。Argo CDが変更を検知し、自動的にクラスタの状態をGitの状態（=前のバージョン）に同期します。D（kubectl rollout undo）は即座にロールバックできますが、Gitの状態とクラスタの状態に乖離（ドリフト）が生じます。GitOpsではGitをシングルソースオブトゥルースとするため、変更は必ずGit経由で行い、監査証跡を完全に保持します。
Q5. Internal Developer Portal（Step 3）
Backstageのサービスカタログで最も重要な成功要因はどれですか？
- A. 美しいUIデザイン
- B. catalog-info.yamlの情報鮮度を維持し、開発者にとって信頼できる情報源にすること
- C. できるだけ多くのプラグインを導入すること
- D. Backstageの最新バージョンを常に追従すること
答えを見る
正解: B
サービスカタログの最も重要な成功要因は「データの信頼性」です。catalog-info.yamlの情報が古かったり不正確だったりすると、開発者はカタログを信頼しなくなり、再びSlackやConfluenceで情報を探すようになります。CIパイプラインでcatalog-info.yamlの更新をチェックし、ヘルススコアカードで情報鮮度を評価し、「カタログを見れば必ず正確な情報がある」という信頼を確立することが最重要です。
Q6. ソフトウェアテンプレート（Step 3）
Backstage Software Templateのスケルトンコードにセキュリティスキャン（Semgrep）、ヘルスチェックエンドポイント、Datadogモニタリング設定を組み込む設計の意図はどれですか？
- A. テンプレートの見た目を豪華にするため
- B. 開発者がGolden Pathに沿って新規サービスを作成するだけで、セキュリティ、運用可能性、可観測性のベストプラクティスが自動的に適用されるようにするため
- C. プラットフォームチームの技術力をアピールするため
- D. テンプレートのテストを容易にするため
答えを見る
正解: B
テンプレートにセキュリティスキャン、ヘルスチェック、モニタリング設定を組み込む設計は、「正しいことがデフォルト」にするためです。開発者はテンプレートから新規サービスを作成するだけで、追加の作業なしにセキュリティスキャン、ヘルスチェックエンドポイント、モニタリングが設定された状態でスタートできます。これにより、ベストプラクティスの適用を「追加作業」ではなく「初期状態」にし、開発者の認知負荷を増やさずに品質を保証します。
Q7. Golden PathとOff-Road（Step 4）
Golden Pathの採用率が50%を下回った場合、最も適切な対応はどれですか？
- A. Golden Pathの使用を全チームに強制する
- B. 採用率が低い原因を調査し、Golden Pathの品質（速度、使いやすさ、ドキュメント）を改善する
- C. Golden Pathを廃止し、各チームの自由に任せる
- D. 採用率の計測をやめる
答えを見る
正解: B
Golden Pathの採用率が50%を下回った場合、それはGolden Pathの品質問題です。開発者に問題があるのではなく、Golden Pathが開発者のニーズを満たしていません。原因として考えられるのは、(1) Off-RoadよりGolden Pathが遅い、(2) ドキュメントが不足している、(3) テンプレートが使いにくい、(4) 特定のユースケースに対応できていない。開発者インタビューやサーベイで原因を特定し、Golden Pathの品質を改善することが正しい対応です。A（強制）はOpt-inの原則に反します。
Q8. ガードレールの設計（Step 4）
多層ガードレール（IDE→Pre-commit→PR→CI/CD→Admission→Runtime）の設計で、各レイヤーのチェック内容を最も適切に配置しているのはどれですか？
- A. すべてのレイヤーで同じポリシーチェックを実行する
- B. IDE/Pre-commitで軽量な即時フィードバック、PR/CI/CDで詳細なセキュリティスキャン、Admissionで最終的なポリシー強制、Runtimeで異常検出を行う
- C. Admissionレイヤーのみですべてのチェックを実行する
- D. IDEレイヤーですべてのチェックを実行し、後段は省略する
答えを見る
正解: B
多層ガードレールでは、各レイヤーに適切なチェックを配置します。IDE/Pre-commitではコーディング規約やシークレット検出など軽量で即時フィードバック可能なチェックを実行。PR/CI/CDではSAST、依存脆弱性スキャン、コンテナイメージスキャンなど詳細なセキュリティチェックを実行。Kubernetes Admissionではデプロイ時の最終安全ネットとしてポリシーを強制。Runtimeでは稼働中の異常検出とネットワーク制御を行います。各レイヤーは補完関係にあり、Shift Left（早期フィードバック）と深層防御を両立します。
Q9. プラットフォームチームの運営（Step 5）
プラットフォームチームのサポートモデルで「Tier 0（セルフサービス）での解決率80%」を目標にする理由として最も適切なものはどれですか？
- A. プラットフォームチームの工数を削減するため
- B. 開発者が待ち時間なく問題を自己解決できる状態を実現し、プラットフォームチームは新機能開発に注力できるようにするため
- C. サポートチケットの数を減らして見栄えを良くするため
- D. 開発者にセルフサービスを強制するため
答えを見る
正解: B
Tier 0での解決率80%は、開発者とプラットフォームチームの双方にとって最適な状態を目指す指標です。開発者はドキュメント、FAQ、テンプレートを使って待ち時間なく問題を自己解決でき、プラットフォームチームはサポート対応に追われることなく新機能の開発や品質改善に注力できます。Tier 2への問い合わせが多い場合、それはドキュメントの不足やプラットフォームのUX問題を示すシグナルであり、Tier 0の品質改善が必要です。
Q10. Platform as a Product（Step 5）
プラットフォームの効果測定で「Adoption（採用率）が高い」「Satisfaction（満足度）が高い」「Impact（効果）が低い」という状況の解釈として最も適切なものはどれですか？
- A. プラットフォームは完全に成功している
- B. プラットフォームは使われており満足もされているが、開発者の真のボトルネック（コードレビュー待ち、要件の曖昧さ等）がプラットフォーム外にあり、プラットフォームだけでは生産性が改善されていない可能性がある
- C. メトリクスの測定方法が間違っている
- D. プラットフォームへの投資を増やせば解決する
答えを見る
正解: B
Adoptionが高く（使われている）、Satisfactionも高い（満足されている）にもかかわらず、Impactが低い（DORAメトリクス等が改善していない）場合、開発者の生産性のボトルネックがプラットフォーム以外の領域にある可能性が高いです。例えば、環境構築は高速化されたが、コードレビュー待ちが2日あったり、要件定義のフェーズで手戻りが多かったりする場合、プラットフォームの改善だけでは全体のリードタイムは改善しません。この場合、開発プロセス全体の分析が必要です。
結果
合格（8問以上正解）
Month 6「開発者プラットフォームを構築しよう」を修了しました。Platform Engineeringの基本原則から、セルフサービス設計、IDP構築、Golden Path/ガードレール、プラットフォームチーム運営まで、開発者プラットフォーム構築の総合的な知識を習得しました。
あなたが身につけたスキル：
- 開発者体験（DevEx）を定量的に評価し、改善ポイントを特定する能力
- セルフサービス型プラットフォームをAPI駆動で設計する能力
- Backstage等を活用したInternal Developer Portalの構築能力
- Golden Pathとガードレールによる自由と統制のバランス設計能力
- プラットフォームチームを組織し、プロダクトとして継続的に改善する能力
不合格（7問以下正解）
全体を復習しましょう。特に間違えた問題に対応するStepを重点的に見直してください：
- Q1-Q2: Step 1（Platform Engineeringの基本、DevEx測定）
- Q3-Q4: Step 2（セルフサービス設計、GitOps）
- Q5-Q6: Step 3（IDP、Backstage、テンプレート）
- Q7-Q8: Step 4（Golden Path、ガードレール）
- Q9-Q10: Step 5（プラットフォームチーム運営、効果測定）
推定所要時間: 30分