プラットフォーム エンジニアリング機能モデルに基づいてプラットフォーム エンジニアリング作業の目標を特定する方法、一般的なシナリオを確認する方法、成功を測定する方法を探す方法について説明します。 目標をビジネス目標に合わせて設定して、成功を測定します。
目標と主要なシナリオを特定する
まず、 プラットフォーム エンジニアリング機能モデルを使用して、組織の現在の場所を評価します。 このモデルを使用して、投資、導入、ガバナンス、プロビジョニングと管理、インターフェイス、測定とフィードバックという 6 つの主要なプラットフォーム エンジニアリング機能のどこに組織が含まれているかをグラフ化します。 すべての組織は、他の機能よりも一部の機能の方が高度です。 組織の現在の位置を把握したら、どの機能を成長させるかを選択できます。 詳細については、「 現在のプラクティスを評価し、将来の目標を設定する」を参照してください。
時間の経過と同時に、プラットフォーム エンジニアリングの目標を継続的に計画および更新できます。 プラットフォーム エンジニアリングの取り組みへの投資から何を得たいかを明確にすることは、組織のサポートを構築するのに大きな意味を持つ可能性があります。
プラットフォーム エンジニアリング リーダーとして、"プラットフォーム エンジニアリングに対して何かを行うのは、そこから得られる何かを得られるまで行いません" - Peter、プラットフォーム エンジニアリング リーダー、多国籍技術会社
目標を検討するときは、特定の開発チームの詳細ではなく、プラットフォーム エンジニアリングの取り組みに関連するビジネス目標にスコープを設定します。 プラットフォーム エンジニアリングの一般的な目標は次のとおりです。
- アプリケーションの品質を向上させ、リリース中のバグや問題を減らします。
- 運用環境でセキュリティを改善し、セキュリティインシデントの数を減らし、同時に共通脆弱性と露出 (CVE) の検出と対応を行います。
- ライセンス、アクセシビリティ、プライバシー、政府の規制などの分野でのコンプライアンスを強化することで、リスクを減らします。
- 複雑さ、オーバーヘッドを軽減し、 内部ソース プラクティスを通じてコード共有を促進することで、ビジネス間の価値を高めます。
- 開発または運用のコストを削減し、重複を最小限に抑え、自動化を向上させます。
最も重要な目標を選ぶことは、優先順位付けに対する考え方が目標によって決まります。
さらに、 目標と主要な結果 (OKR) を リーダーシップおよび内部パートナーと合意することで、投資の現在のフェーズに対して測定可能な目標を確立するのに役立ちます。 (組織が他のものを使用している場合、その他の計画アプローチにも同様の概念があります)。最適な OKR は、主観を削除するため、具象メジャーに基づいて設定できる OKR です。
完了するべきタスクと計画シナリオ
目標を特定したら、バックログとロードマップを整理するための主要なシナリオを選択します。 たとえば、次のシナリオと、実行する関連ジョブを参照してください。
シナリオ: 新しいアプリケーションの構築を開始する
- 組織のベスト プラクティスとポリシーを理解して適用する
- 新しいリポジトリを作成する
- プロビジョニング ツール
- 一般的なインフラストラクチャをプロビジョニングする
- チーム メンバーにアクセス権を付与する
- CI/CD パイプラインを確立する
- 開発インフラストラクチャをプロビジョニングする
- "パイプ" をテストするための最初の展開
シナリオ: 既存のチームに新しいメンバーを追加または削除する
- ツールとサービスへのアクセスを更新する
- 開発者用コンピューターを設定する
- チームメンバーをアプリケーションに慣れさせる
- アプリケーション サンドボックス環境を作成する
- pull request を最初に作成して確認する
シナリオ: 既存のアプリケーションのインフラストラクチャを追加または更新する
- 組織のベスト プラクティス、使用可能なオプションを理解する
- コード成果物としてインフラストラクチャを更新または追加する
- アプリケーション サンドボックス環境を作成する
- 更新プログラムの確認
- 他の環境へ変更を展開する
シナリオ: 既存のチームのツールを追加または更新する
- 組織のベスト プラクティス、使用可能なオプションを理解する
- 新しいツールの使用を要求する
- チーム メンバーのツールへのアクセスを更新する
- (該当する場合)ツールをクライアントまたは CI/CD パイプラインに統合する
シナリオ: 既存の API、SDK、またはサービスを検索または再利用する
- 使用可能な API、SDK、またはサービスを検出する
- ニーズを満たしているかどうかを評価する
- ご質問がある場合は、担当チームに連絡してください
- アプリケーションの導入
シナリオ: 運用インシデントに対応する
- 問題の通知
- アプリ コードまたはインフラストラクチャに関連する (またはその両方) かどうかを評価する
- 本番環境と異なる場合、その環境をミラー化したサンドボックス環境を作成する。
- 変更、テスト、帯域外リリースを行う
シナリオ: セキュリティ インシデントを迅速に修復する
- 問題の通知
- 問題の幅を評価する (どのシステム)
- 顧客が直接影響を受けたかどうかを理解する
- プローブをミラー化するサンドボックス環境を作成する (異なる場合)
- 変更、テスト、帯域外リリースを行う
- 影響を受けるすべてのユーザーと通信する
シナリオ: ツールの非推奨
- ツールの使用状況を理解する
- ユーザーに非推奨を知らせる
- (省略可能)新しいツールへのユーザーの移行を調整する
新しいアプリケーションアーキテクチャモデルの導入に関するシナリオ
- パイロット提案アーキテクチャ
- パイロットの結果に基づいて調整する
- ベスト プラクティスのドキュメントを更新する
- テンプレートの作成、自動化、ポリシー、ガバナンスの更新
アプリケーション コンプライアンス (GDPR、アクセシビリティ、インフラストラクチャ標準) の監査
- 現在のコンプライアンス規則を理解する
- アプリケーションが規則を満たしていることを確認する
- 偏差の修正期限を設定する
- 変更、テスト、リリース
多くのシナリオは、複数のロールに適用されます。 改善を測定する方法のメトリックについて考えます。
問題から概念まで
次に、特定したシナリオとジョブで開発者やその他の役割が直面する最大の問題を理解します。 見た目のギャップを埋めるために新製品の調査を開始したくなる可能性がありますが、これらの製品が大きな問題を解決しない場合、採用されたり評価されたりする可能性は低いです。
仮説の進行フレームワークなど、この種の調査を行うのに役立つ方法がいくつかあります。 仮説進行フレームワークのような形式化されたプロセスを使用しない場合でも、ディスカッションの範囲を指定するために行われるジョブについて開発者にインタビューし、作業を完了する際の最大の問題を特定する必要があります。 これらの問題が何であるかを十分に理解したら、それらを解決するための計画を立て始めます。 これにより、開発者が使用する機能を確実に構築できます。
このプロセスをすばやく繰り返すことができるようにするには、社内の開発者プラットフォーム チームで顧客の声を直接表すことができるユーザーを特定します。 通常、この役割は製品マネージャーと呼ばれ (役職が異なる場合でも)、知識が増えると、より小さな意思決定の結果を正確に予測し、面接を行う必要があるタイミングを判断できます。 これにより、機敏性を維持しながら、社内の顧客に価値を提供することに集中できます。
初期投資のケースを作成する
検証済みの一連の問題と概念を取得したら、投資先を決定するのに適した立場にあります。 ただし、ソリューションを評価する際に必要な先行投資と長期的なメンテナンスを検討してください。 問題を解決できる最も低い労力のソリューションは、最初に適切なソリューションになる傾向がありますが、多くの場合、最終的に投資が成功したかどうかを決定するのはメンテナンス作業です。
別の言い方をすれば、実際に必要な場合を除き、体験の後の段階を対象とするソリューションを作成しないでください。
最も薄く実行可能なプラットフォーム (TVP) (プラットフォームの実用最小限の製品など) を特定したら、フィードバックを提供する一連の開発チームでパイロットします。 パイロット ソリューションがこれらのチームが直面している問題を解決する場合は、関与に関心のあるユーザーを見つけるのに問題はありません。
デプロイする前に概念が成功したかどうかを測定できるように、新しい機能または変更をパイロットする際に、いくつかの主要なメトリックをキャプチャする必要があります。
成功と証明の価値を測定する
成功を測定することは、製品の考え方の重要な部分です。 ささやかな投資で小さな成功を収めても、より大きな投資を構築するための基礎を築くことができます。
たとえば、ビジネス価値を提供する開発チームに対する運用税と見なすことができるため、コンプライアンスの取り組みに対する資金調達やバイインを確保することは困難な場合があります。 製品の考え方によって、その認識が変わる可能性があります。 製品の考え方により、社内の開発者プラットフォームの顧客が満足し、利害関係者のビジネス目標が満たされるようにしようとしています。 メトリックは、事実を利用してビジネス価値を提供していることを証明する立場にあなたを置きます。 OKR の設定は、特に、主観的バイアスを取り除くために使用できるメトリックがある場合に役立ちます。 現在該当するものを測定していない場合でも、学習 OKR を設定してベースラインを設定し、このベースラインが判明した後に調整することができます。
次に示す既知のメトリックの例を使用して、作業しているチームが構築している内容から価値を引き出しているかどうかを判断できます。 目標を達成しているかどうかを測定するのに役立つ指標に焦点を当てましょう、あなた自身またはあなたの開発チームの顧客とともに。 たとえば、プラットフォームが効果的なエンジニアリング組織に貢献しているかどうかを評価するのに役立つ一連のメトリックを次に示します。
- スピード / ビジネス価値までの時間: 最初のプルリクエスト完了までの日数の中央値 (オンボーディング)、ビルドおよびテストプロセスにかかる中央値の分数 (例: CI)、プルリクエストをマージするまでの中央値の時間。
- ソフトウェアの品質: 開発ごとに 1 か月に作成されたインシデント (問題) (開発の数に正規化された数)、 平均復旧時間 (MTTR)、セキュリティの問題を調査して修復する平均時間。
- プラットフォームの使いやすさ: Net ユーザー満足度 (NSAT)
- 繁栄するエコシステム: 調査対象の各質問の平均スコア:"私は最高の仕事をする権限を与えられています"、"ほとんどの日は、私がやっている仕事に活気を与えられています"、"私が行う仕事は私にとって意味があります。
その後、組織、チーム、またはプロジェクトごとにこれらのメトリックを分解できます。 開始するにはいくつかのベースラインを測定する必要がありますが、プラットフォームの改善に合わせてこれらのメトリックの変化を確認できます。
お客様またはスポンサーが測定に関心を持つ可能性があるその他のメトリックは次のとおりです。
| Area | メトリックの例 |
|---|---|
| ソフトウェア配信のパフォーマンス | 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 システムなどです。 このようなと思われる領域で緊急のニーズが見つかる場合は、長期的なメンテナンスによって時間の経過と同時に切り替える可能性が高い複数の実装オプションを計画します。