計画と優先順位付け
プラットフォーム エンジニアリングの取り組みの目標を特定し、一般的なシナリオを確認し、成功を測定する方法を探す方法について説明します。 目標をビジネス目標にスコープ設定して、成功を測定します。
目標と主要なシナリオを特定する
能力や機能のチェックリストを機械的に見るのではなく、まず、プラットフォーム エンジニアリングの取り組みの目標を特定します。 時間の経過と共に目標を継続的に計画および更新できます。 ただし、プラットフォーム エンジニアリング体験に投資して何を得たいかを明確にすることは、組織のサポートの構築に大きな意味を持つ可能性があります。
プラットフォーム エンジニアリング リーダーとして、"私はそこから得られる何かを得ることができるまで、プラットフォーム エンジニアリングのために行動を起こしません": Peter、プラットフォーム エンジニアリング リーダー、多国籍テクノロジ企業
目標を検討するときは、特定の開発チームの詳細ではなく、プラットフォーム エンジニアリングの取り組みに関連するビジネス目標にスコープを設定します。 高レベルのプラットフォーム エンジニアリングの一般的な目標は次のとおりです。
- リリース時にアプリケーションの品質を向上させ、バグや問題を減らします。
- 運用環境で、セキュリティの向上、セキュリティ インシデントの数の削減、または共通脆弱性識別子 (CVE) の検出を 1 回行います。
- ライセンス、アクセシビリティ、プライバシー、政府の規制などの分野でのコンプライアンスを強化することで、リスクを減らします。
- 複雑さやオーバーヘッドを軽減し、内部ソース プラクティスを通じてコード共有を促進することで、ビジネス化までの時間に関する価値を向上させます。
- 開発または運用のコストを削減し、重複を最小限に抑え、自動化を改善します。
優先順位付けに対する考え方が目標によって決まるため、上位の目標を選ぶことは重要です。
さらに、リーダーシップや内部パートナーと目標と主要な成果 (OKR) に同意することで、投資の現在のフェーズに対して測定可能な目標を確立できます。 (組織が他のものを使用している場合、その他の計画アプローチにも同様の概念があります)。最適な OKR は、主観を排除するため、具体的な指標に基づいて設定できる OKR です。
実行するシナリオとジョブ
目標を特定したら、バックログとロードマップを推進する主要なシナリオを選択します。 たとえば、これらのシナリオと、実行する関連ジョブをご覧ください。
シナリオ: 新しいアプリケーションの構築を開始する
- 組織のベスト プラクティスとポリシーを理解して適用する
- 新しいリポジトリを作成する
- プロビジョニング ツール
- 一般的なインフラストラクチャのプロビジョニング
- チーム メンバーにアクセス権を付与する
- CI/CD パイプラインを確立する
- 開発インフラストラクチャのプロビジョニング
- "パイプ" をテストするための初期のデプロイ
シナリオ: 既存のチームに新しいメンバーを追加または削除する
- ツールやサービスへのアクセスを更新する
- 開発者用コンピューターを設定する
- アプリケーションでチーム メンバーを準備する
- アプリケーション サンドボックス環境を作成する
- 最初の PR を作成して確認する
シナリオ: 既存のアプリケーションのインフラストラクチャを追加または更新する
- 組織のベスト プラクティスと使用可能なオプションを理解する
- コード成果物としてインフラストラクチャを更新または追加する
- アプリケーション サンドボックス環境を作成する
- 更新を検証する
- 他の環境への変更のロール アウト
シナリオ: 既存のチームにツールを追加または更新する
- 組織のベスト プラクティスと使用可能なオプションを理解する
- 新しいツールの使用を要求する
- チーム メンバーのツールへのアクセスを更新する
- (該当する場合) ツールをクライアントまたは CI/CD パイプラインに統合する
シナリオ: 既存の API、SDK、またはサービスを検索または再利用する
- 使用可能な API、SDK、サービスの検出
- ニーズを満たしているかどうかの評価
- 質問がある場合は、所有チームに問い合わせる
- アプリケーションの採用
シナリオ: 運用インシデントへの対応
- イシューの通知
- アプリ コードまたはインフラストラクチャに関連する (またはその両方) かどうかを評価する
- 運用環境をミラーリングするサンドボックス環境の作成 (異なる場合)
- 変更、テスト、特別なリリースを行う
シナリオ: セキュリティ インシデントを迅速に修復する
- イシューの通知
- イシューの幅を評価する (システムについて)
- 顧客が直接影響を受けたかどうかを理解する
- 運用環境をミラーリングするサンドボックス環境の作成 (異なる場合)
- 変更、テスト、特別なリリースを行う
- 影響を受けたすべてのユーザーと通信する
シナリオ: ツールの非推奨
- 使用状況の理解
- 非推奨の通知をユーザーに通知する
- (省略可能) ユーザーの新しいツールへの移行調整
シナリオ: アーキテクチャの新しいアプリ モデルのロールアウト
- パイロットから提案されたアーキテクチャ
- パイロットの結果に基づいて調整する
- ベスト プラクティスのドキュメントを更新する
- テンプレートの作成, 自動化の更新, ポリシー, ガバナンス
アプリケーション コンプライアンス (GDPR、アクセシビリティ、インフラストラクチャの標準) の監査
- 現在のコンプライアンス規則を理解する
- アプリケーションが規則を満たしていることを確認する
- 偏差の修正期限を設定する
- 変更、テスト、リリースを行う
多くのシナリオは複数のロールに適用されるため、シナリオがどれだけ改善されるかを理解する方法のメトリックについて考える必要があります。
問題から概念まで
次に、特定したシナリオやジョブで開発者やその他のロールが直面する最大の問題を理解します。 見た目のギャップを埋めるために新製品の調査を開始したくなる可能性がありますが、これらの製品が大きな問題点を解決しない場合、採用されたり評価されたりする可能性は低いです。
この種の調査を行うのに役立つ方法はいくつかあります。 1 つは、Hypothesis Progression Framework です。 Hypothesis Progression Framework のような形式化されたプロセスを使用しない場合でも、ディスカッションの範囲を指定するために行われるジョブについて開発者にインタビューし、作業を完了する上での最大の問題を特定する必要があります。 これらの問題が何であるかを十分に理解したら、それらを解決するための計画を立て始めます。 これにより、開発者が使用する機能を確実に構築できます。
このプロセスをすばやく繰り返すことができるようにするには、社内の開発者プラットフォーム チームで顧客の声を直接表すことができるユーザーを特定します。 この役割は通常、(役職が異なる場合でも) 製品マネージャーと呼ばれ、知識が増えると、より小さな意思決定の結果を正確に予測し、さらにインタビューを行う必要があるタイミングを判断できます。 これにより、機敏性を維持しながら、社内顧客に価値を提供することに集中できます。
初期投資のケースを作成する
検証済みの一連の問題と概念を入手したら、投資先を決定するのに適した立場にあります。 ただし、ソリューションを評価する際に必要な先行投資と長期的なメンテナンスを検討してください。 問題を解決できる作業が最も少ないソリューションは、それから開始するのに適している傾向がありますが、多くの場合、最終的に投資が成功したかどうかを決定するのはメンテナンス作業です。
別の言い方をすれば、実際に必要な場合を除き、体験の後の段階を対象とするソリューションを作成しないでください。
実用可能な最薄プラットフォーム (TVP) (プラットフォームの MVP) を特定したら、フィードバックを提供する一連の開発チームでパイロットします。 パイロット ソリューションがこれらのチームが直面している問題を解決する場合は、関与に関心のあるユーザーを見つけるのに問題はありません。
デプロイする前に概念が成功したかどうかを測定できるように、新しい機能または変更をパイロットする際に、いくつかの主要なメトリックをキャプチャする必要があります。
成功と証明の価値を測定する
自分がどれだけ成功しているかを測定することは、製品マインドセットの重要な部分です。 ささやかな投資で小さな成功を収めても、より大きな投資を構築するための基礎を築くことができます。
たとえば、ビジネス価値を提供する開発チームに対する運用税と見なすことができるため、コンプライアンスの取り組みに対する資金調達や賛同を得ることは困難な場合があります。 製品マインドセットによって、その認識が変わる可能性があります。 製品マインドセットにより、社内の開発者プラットフォームの顧客が満足し、利害関係者のビジネス目標が満たされるようにしようとしています。 メトリックは、ビジネス価値を提供していることを証明するためにファクトを使用するように促します。 OKR を設定すると、特に、主観的な偏りを取り除くために使用できるメトリックがある場合に役立ちます。 現在該当するものを測定していない場合でも、学習 OKR を設定してベースラインを定めておき、このベースラインを把握した後に調整することができます。
次に示す既知のメトリックの例を使用して、作業中のチームが構築している内容から価値を得ているかどうかを判断できます。 自分と開発チームの顧客が目標を達成しているかどうかを測定するのに役立つものに焦点を絞ります。 たとえば、プラットフォームが効果的なエンジニアリング組織に貢献しているかどうかを評価するのに役立つ一連のメトリックを次に示します。
- 速度 / ビジネスまでの時間: 最初のプル要求を完了するまでの中央値 (オンボード)、ビルド、テスト プロセスの中央値 (例: CI)、プル要求をマージする中央値の時間。
- ソフトウェアの品質: 開発ごとに 1 か月あたりに作成された (開発の数に正規化された数) インシデント (イシュー)、(MTTR) を修復する平均時間、つまり、セキュリティの問題を調査して修復する時間。
- プラットフォームの使いやすさ: ネット ユーザー満足度 (NSAT)
- 活発なエコシステム: 調査対象の各質問の平均スコア: "私は最高の仕事をする権限を与えられています"、"ほとんどの日において、私は自分の仕事から活気を得られています"、"私が行う仕事は自分にとって意味があります。"
その後、組織、チーム、プロジェクトごとにこれらのメトリックを分解できます。 まず、いくつかのベースラインを測定する必要がありますが、プラットフォームの改善に合わせてこれらのメトリックの変化を確認できます。
お客様またはスポンサーが測定するその他のメトリックは次のとおりです。
| 面グラフ | メトリックの例 |
|---|---|
| ソフトウェア配信のパフォーマンス | DevOps Research and Assessment (DORA): リード タイム、デプロイの頻度、変更の失敗率、サービスの復元時間 (MTTR) |
| 操作 | DORA (MTTR)、平均故障間隔 (MTBF)、平均確認時間、エンドユーザーの可用性、待機時間、スループット メトリック、チームあたりのコスト、デプロイあたりのコスト |
| プラットフォーム機能の導入メトリック | 時間の経過に伴うツールまたは機能を使用するチームや開発者の数、プラットフォームを使用したリポジトリの割合、最も一般的なテンプレート、パイプラインなど。 |
メトリックの収集には時間と労力が必要であるため、特定した主要な目標 (特に OKR を活用する主要な目標) の重要なメトリックに焦点を当てることが重要です。 Application Insights などの OpenTelemetry ベースの製品が役立ちます。 関係なく、プラットフォームの使いやすさを測定し、活発なエコシステムがあることを定期的に調査してください。 これらのメトリックは多くの場合、内部システムで見逃され、成功するには関心度の高い参加者が不可欠であるため、より広範なビジネス目標の達成に関する主要な指標になります。 また、次に進む場所を理解するために、さらなる顧客開発を行う時期を把握するのにも役立ちます。
その他のヒント
開始方法に関係なく、変更の計画、パイロット用の新しいアプリケーションの開始、既存のユーザー エクスペリエンスの強化、最小限の特権の原則の採用、制御された実験の計画、カスタマイズの最小化を行う必要があることに注意してください。
変更の計画
ターゲット アプリケーション プラットフォームは時間の経過と同時に進化し、既存のすべての投資を一度に移行できない場合があります。 時間の経過と同時に複数のバリエーションをサポートし、変更を計画する方法を検討してください。
新しいアプリケーションでアイデアを検証する
新しいプラットフォームまたはプラットフォーム機能のパイロットでは、適切なサイズの新しいアプリケーションから始めます。 これにより、プラットフォームを製品として管理する経験も得られます。 学習しながらプロジェクトの再プラットフォーム化を始めるので躊躇することもあり、大規模な既存のアプリケーションには、多くの場合、再プラットフォーム化に取り組む間にのみ明らかになる固有のニーズもあります。 そのため、これらの種類の作業と自身の成功を結合した結果、期待の不一致や遅延の問題が発生する可能性があります。 新しいものから始めると、そこから得られる値の方向性に自信を持つことができます。 これにより、さらに大きな活動に取り組むリスクが軽減されます。 別の言い方をすると、ユーザーが正しく開始し、適正な状態を維持できると確信している場合は、経験から学んだことを使用して適切なキャンペーンを推進する方が簡単になります。 この方法が不可能な場合は、すべてを一度に変更するのではなく、慎重な分析を行い、期待値を設定し、段階的にステップインする必要があります。
新しいユーザー エクスペリエンスを作成する前に、既存のユーザー エクスペリエンスの重点的な部分に注目する
開発者は、気に入って既に使用しているものに対する新機能が登場すれば、それを採用し、継続して使用する可能性が高くなります。 導入する新しい機能の概念を評価するときは、既存の "重心" を拡張するオプションを必ず調査してください。たとえば、エディター / IDE (Visual Studio、VS Code)、DevOps スイート (GitHub、Azure DevOps)、既存の CLI、既存の内部ポータルは、まったく新しいポータルや他の UX よりも効果的です。 詳細については、「ユーザー エクスペリエンス」をご覧ください。
最小特権の原則を想定する
開発者は、インフラストラクチャのプロビジョニングなどのダウンストリーム システムへのアクセスが制限されているとします。 セルフサービス エクスペリエンスのためにこのアクセスを有効にするには、制御された方法が必要です。
制御された実験の計画
大きな変更や危険な変更をロール アウトする前に実験します。 開始するためにすべてが完全に自動化される必要はありません。 自動的にトリガーされる手動ワークフローは、アイデアをパイロットするための優れた方法です。
アプリ プラットフォームのカスタマイズを最小限に抑える
ソフトウェア ベンダーが時間の経過と共にリリースする機能によって利用される可能性があるカスタムのアプリケーション プラットフォーム機能は避けてください。 たとえば、ランタイム ホスティング、サービス メッシュ、ID システムなどです。 これに当てはまると思われる領域で緊急のニーズが見つかった場合は、長期的なメンテナンスによって時間の経過と共に切り替える可能性が高い複数の実装オプションを計画します。