課題の背景とスコープ
多数のサービス、チーム、デプロイ環境を抱える組織向けに社内開発者プラットフォームを設計します。このプラットフォームは、チケット待ちのキューになったり、すべてのチームに単一のアーキテクチャを強制したりすることなく、一般的なデリバリータスクを容易にする必要があります。
開発者を異なるワークロードを持つ顧客として扱います。Backstageはサービス、ライブラリ、ドメインなどのエンティティを追跡するソフトウェアカタログを提示しています。また、DORAは単一の生産性指標を使用するのではなく、デリバリーパフォーマンスと開発者体験のシグナルを組み合わせることを推奨しています。
面接官が見ているポイント
面接官は、Platform-as-a-Productの思考力、セグメンテーション、ワークフローの優先順位付け、変更管理、ガバナンス、およびメトリクス設計を評価しています。優れた回答は、プラットフォームの機能と開発者のジョブ、および測定可能な成果を結びつけつつ、正当な例外のためのエスケープハッチ（脱出経路）を維持します。
回答前に確認すべき質問
- 最初のターゲットは誰か：新規チーム、オンコールエンジニア、サービスオーナー、それともセキュリティレビュアーか？
- 最もコストがかかっている反復タスクは何か：ブートストラップ、デプロイ、オーナーシップの特定、可観測性（オブザーバビリティ）、それともコンプライアンスの証跡収集か？
- サポートする必要がある言語、ランタイム、クラウド、成熟度レベルの数はどれくらいか？
- どの制約が必須で、どこでチームがオプトアウトできるか？
- 目標は、デリバリーの高速化、変更の安全性向上、オンボーディングの容易化、それとも認知的負荷の軽減か？
30秒の回答フレームワーク
「サービスを繰り返し作成し、オーナーシップや安全なデプロイのデフォルト設定を見つけるのに苦労しているチームから始めます。MVPは、明確なオーナーを持つカタログ、セルフサービスのサービステンプレート、1つの舗装されたデプロイパス、検索可能なランブックです。チームは文書化された理由があればそのパスから外れることができます。代表的な3チームでパイロット運用を行い、本番環境への初変更までの時間、デプロイ失敗からの復旧時間、オンボーディング時間、タスク完了率、開発者満足度を測定した上で、摩擦が軽減された証拠が得られた領域にのみ展開します。」
ステップごとの詳細解説
ステップ1：開発者のジョブをセグメント化する
サービスオーナー、新入社員、オンコールエンジニア、プラットフォーム運用者に個別にインタビューします。依存関係の特定、リポジトリの作成、安全なリリース、統制の証明など、彼らのペインは異なります。機能リクエストだけでなく、観察されたワークフローやサポートチケットを活用します。
ステップ2：ゴールデンパスをマッピングする
頻度が高くリスクの高いジャーニーを1つ選択し、その入力、デフォルト設定、承認フロー、出力を定義します。ゴールデンパスは、隠れた強制ではなく、最も簡単で安全なルートであるべきです。チームがカスタマイズまたは離脱できる箇所を文書化します。
ステップ3：最小限の有用なカタログを構築する
オーナーシップ、ライフサイクル、重要な依存関係、デプロイやランブックへのリンク、鮮度インジケーターから始めます。Backstageのカタログモデルはエンティティとメタデータを使用します。レコードが放置されたディレクトリにならないよう、オーナーとソースファイルを必須とします。
ステップ4：セルフサービスアクションを追加する
次のボトルネックに対するテンプレートを提供します（サービスの作成、標準CIの追加、環境のリクエスト、可観測性の有効化など）。各アクションには、前提条件、見積もり時間、結果、および自動化が失敗した場合の復旧パスを表示する必要があります。
ステップ5：ガードレールとしてのガバナンスを設計する
セキュリティと信頼性のデフォルトを自動化しますが、ポリシーと実装を分離します。プラットフォームは、説明可能な理由と例外ワークフローを用意してリスクのあるデプロイをブロックすることはできますが、チームのコードを勝手に書き換えたり、オーナーシップを隠蔽したりしてはなりません。
ステップ6：導入と移行を計画する
デザインパートナーを募り、1つの実際のサービスをエンドツーエンドで移行し、サンプルを公開して、オフィスアワーを提供します。移行にかかる労力を追跡し、レガシーなパスも文書化して残します。摩擦を減らすことで得られた導入は、サポートのない強制よりも持続性があります。
ステップ7：プラットフォームの信頼性を定義する
カタログの鮮度、テンプレートの成功率、デプロイワークフローの可用性、インシデント対応など、プラットフォーム自体のSLOを設定します。壊れた社内プラットフォームは本番環境の依存関係となるため、ステータス、ロールバック、サポートのオーナーシップを提供します。
ステップ8：成果とガードレールを測定する
デプロイ頻度やデプロイ失敗からの復旧時間などのデリバリーメトリクスを、サービスの作成時間、初回デプロイまでの時間、セルフサービス完了率、サポートチケットなどのタスクレベルの測定値とともに使用します。変更失敗率、プラットフォームのインシデント、チーム間の不均衡な影響に対する開発者アンケートやガードレールを追加します。
トレードオフと境界線
トレードオフ1：標準化か自律性か
標準のデフォルトは認知的負荷を減らし、自律性はチームの適合性を維持します。まずはインターフェースと安全制御を標準化し、その背後での実装の選択肢を許容します。
トレードオフ2：新規構築か統合か
差別化要因となるワークフローやポリシーのみを構築します。契約（コントラクト）を満たす場合は、既存のカタログ、CI、シークレット、可観測性システムを統合します。すべての統合はプラットフォームの信頼性領域の一部となります。
トレードオフ3：機能の追加か完了度の向上か
半分しか動かないプラグインが20個あるカタログは、信頼できる少数のアクションセットよりも多くの摩擦を生み出します。機能数よりもエンドツーエンドのタスク完了度を優先します。
障害訓練と進化計画
訓練1：テンプレートが途中で失敗する
作成された内容、安全に再試行する方法、クリーンアップの担当者をユーザーに表示します。可能な限りアクションをべき等にし、プラットフォーム管理者権限を必要とせずにログを公開します。
訓練2：チームがゴールデンパスをバイパスする
非準拠と決めつける前に彼らにインタビューします。そのパスに正当なユースケースが欠けているか、デフォルト設定が不十分であるか、または隠れた移行コストが課されている可能性があります。ジャーニーを改善し、正当な離脱を文書化します。
訓練3：プラットフォームの停止によってリリースがブロックされる
縮退運転、ステータス通知、および手動のフォールバックをテストします。プラットフォームは運用のリスクを軽減するものでなければならず、不透明な単一障害点（SPOF）になってはなりません。
よくある間違いとフォローアップ
間違い1：ポータルを単なるホームページとして扱う
リンクだけでは作業はなくなりません。タスクを特定し、セルフサービスの結果を提供してください。
間違い2：コード行数やクリック数を測定する
これらはアクティビティのカウントであり、プロダクトの成果ではありません。デリバリーデータとタスク完了度、開発者体験のシグナルを組み合わせてください。
間違い3：単一のスタックを強制する
プラットフォームの契約は複数のランタイムをサポートできます。どの制約が安全性に関するもので、どれが単なる好みに過ぎないのかを説明してください。
間違い4：メタデータのオーナーシップを無視する
陳腐化したカタログはインシデント対応を妨げます。オーナー、ソース管理されたメタデータ、鮮度チェック、およびエスカレーションパスを必須にしてください。
間違い5：最初にすべてのチームを移行しようとする
デザインパートナーと測定可能なジャーニーから始めてください。検証前の広範な移行は抵抗を生み、使いやすさのギャップを覆い隠してしまいます。
間違い6：プラットフォームが本番ソフトウェアであることを忘れる
プラットフォーム自体に対して、SLO、インシデントのオーナーシップ、リリースコントロール、およびロールバックパスを設定してください。