計画と優先順位付け

  • [アーティクル]

プラットフォーム エンジニアリング作業の目標を特定し、一般的なシナリオを確認し、成功を測定する方法を探す方法について説明します。 目標をビジネス目標に合わせて設定することで、成功を測定できます。

目標と主要なシナリオを特定する

プラットフォームエンジニアリングのリーダーとして、一度それを言うと、「私はそこから得ることができる何かを持っているまで、プラットフォームエンジニアリングのために何かをしません。」 - Peter、プラットフォームエンジニアリングリーダー、多国籍技術会社

まず、機能や機能のローテ チェックリストを見るのではなく、プラットフォーム エンジニアリングの取り組みの目標を特定することから始めます。 時間の経過と同時に目標を継続的に計画および更新できます。 ただし、プラットフォーム エンジニアリングの取り組みへの投資から何を得たいかを明確にすると、組織のサポートを構築するのに大きな意味を持つ可能性があります。

目標について考えている間に、特定の開発チームの詳細ではなく、プラットフォーム エンジニアリング作業に関連するビジネス目標にスコープを設定します。 たとえば、プラットフォーム エンジニアリングの一般的な目標を次に示します。

  • アプリケーションの品質を向上させ、リリース中のバグや問題を減らします。
  • セキュリティの向上、セキュリティ インシデントの数の削減、または運用環境で 1 回の CVE の 検出。
  • ライセンス、アクセシビリティ、プライバシー、政府の規制などの分野でのコンプライアンスの向上によってリスクを減らします。
  • 複雑さ、オーバーヘッドを軽減し、 内部ソース プラクティスを通じてコード共有を促進することで、ビジネス間の価値を加速します。
  • 開発または運用のコストを削減し、重複を最小限に抑え、自動化を向上させます。

これらの目標はすべて長期的な目標かもしれませんが、優先度設定に対する考え方が高まるため、最も重要な目標を選ぶことが重要です。

さらに、 目標と主要な結果 (OKR) を リーダーシップや内部パートナーと合意することは、投資の現在のフェーズで測定可能な目標を確立するのに役立ちます。 (organizationが他のものを使用している場合、他の計画アプローチにも同様の概念があります。最適な OKR は、主観を取り除くので、具体的なメジャーに基づいて設定できる OKR です。

実行するシナリオとジョブ

目標を特定したら、バックログとロードマップを推進するために使用する主要なシナリオを特定します。 たとえば、次のシナリオと実行するジョブを参照してください。

シナリオ: 新しいアプリケーションの構築を開始する

  • 組織のベスト プラクティスとポリシーを理解して適用する
  • 新しいリポジトリを作成する
  • プロビジョニング ツール
  • 共通インフラストラクチャをプロビジョニングする
  • チーム メンバーにアクセス権を付与する
  • CI/CD パイプラインを確立する
  • 開発インフラストラクチャをプロビジョニングする
  • "パイプ" をテストするための初期デプロイ

シナリオ: 既存のチームに新しいメンバーを追加または削除する

  • ツール、サービスへのアクセスを更新する
  • 開発者用コンピューターを設定する
  • アプリケーションでチーム メンバーを増やす
  • アプリケーション サンドボックス環境を作成する
  • 最初の PR を作成して確認する

シナリオ: 既存のアプリケーションのインフラストラクチャを追加/更新する

  • 組織のベスト プラクティス、使用可能なオプションを理解する
  • コード成果物としてのインフラストラクチャの更新/追加
  • アプリケーション サンドボックス環境を作成する
  • 更新プログラムを確認する
  • 他の環境への変更のロールアウト

シナリオ: 既存のチームの追加/更新ツール

  • 組織のベスト プラクティス、使用可能なオプションを理解する
  • 新しいツールの使用を要求する
  • チーム メンバーのツールへのアクセスを更新する
  • (該当する場合)ツールをクライアントまたは CI/CD パイプラインに統合する

シナリオ: 既存の API、SDK、またはサービスを検索/再利用する

  • 使用可能な API、SDK、サービスを検出する
  • ニーズを満たしているかどうかを評価する
  • 質問がある場合は、所有チームとつながる
  • アプリケーションに採用する

シナリオ: 運用インシデントに対応する

  • 問題の通知
  • アプリ コードまたはインフラストラクチャが関連しているかどうかを評価する (またはその両方)
  • prod をミラー化するサンドボックス環境を作成する (異なる場合)
  • 変更、テスト、帯域外リリースを行う

シナリオ: セキュリティ インシデントの迅速な修復/一般的な脆弱性と露出 (CVE) に関する通知

  • 問題の通知
  • 問題の幅を評価する (どのシステム)
  • 顧客が直接影響を受けたかどうかを理解する
  • prod をミラー化するサンドボックス環境を作成する (異なる場合)
  • 変更、テスト、帯域外リリースを行う
  • 影響を受けるすべてのユーザーと通信する

シナリオ: 非推奨のツール

  • ツールの使用状況を理解する
  • 非推奨の状態をユーザーに通知する
  • (省略可能)調整 ユーザーの新しいツールへの移行

シナリオ: 新しいアプリ モデル/アーキテクチャを定義/ロールアウトする

  • パイロット提案アーキテクチャ
  • パイロット結果に基づいて調整する
  • ベスト プラクティスのドキュメントを更新する
  • テンプレートの作成、自動化の更新、ポリシー、ガバナンス

アプリケーション コンプライアンス (GDPR、アクセシビリティ、インフラストラクチャ標準) を監査する

  • 現在のコンプライアンス規則を理解する
  • アプリケーションが規則を満たしていることを確認する
  • 偏差の修正期限を設定する
  • 変更、テスト、リリースを行う

多くのシナリオが複数のロールに適用されるため、シナリオがどれだけ向上するかを理解する方法のメトリックについても考える必要があります。

問題から概念まで

次に、特定したシナリオやジョブで開発者やその他の役割が直面する最大の問題を理解することをお勧めします。 認識されたギャップを埋めるために新製品の調査を開始したくなるかもしれませんが、これらの製品が大きな問題点を解決しなければ、採用されたり評価されたりする可能性は低いです。

この種の調査を行うのに役立つ方法はいくつかあります。 1つは 仮説進行フレームワークです。 仮説進行フレームワークのような正式なプロセスを使用しない場合でも、ディスカッションの範囲を指定するために行われる仕事について開発者にインタビューし、その作業を達成する際の最大の問題を特定することで、多くのことを得ることができます。 これらの問題が何であるかを十分に理解したら、それらを解決するための概念を考え出すことができます。 これにより、開発者が使用する機能を確実に構築できます。

このプロセスをすばやく繰り返すことができるようにするには、内部開発者プラットフォーム チームで顧客の声を直接表すことができるユーザーを特定する必要があります。 この役割は通常、製品マネージャーと呼ばれ (役職が異なる場合でも)、知識が増えるにつれて、より小さな意思決定の結果を正確に予測し、面接を行う必要があるタイミングを判断できます。 これにより、機敏性を維持しながら、内部の顧客に価値を提供することに集中することができます。

初期投資のケースを作成する

検証済みの一連の問題と概念が得られると、投資の引数を作成するのに適した立場になります。 ただし、事前投資のレベルと長期的なメンテナンスが必要であることに注意してください。 問題を解決できる最も低い労力の解決策は、最初から適切なソリューションになる傾向がありますが、多くの場合、最終的に投資が成功したかどうかを決定するのはメンテナンス作業です。

別の言い方をすれば、実際に必要な場合を除き、体験の後の段階を対象とするソリューションを作成しないでください。

最も実行可能な最も薄いプラットフォーム (TVP) (プラットフォームの MVP) を特定したら、フィードバックを提供する一連の開発チームでパイロットできます。 パイロット ソリューションがこれらのチームが直面している問題を解決する場合は、関与に関心のあるユーザーを見つけるのに問題はありません。

新しい機能や変更をパイロットする際には、いくつかの主要なメトリックをキャプチャして、展開する前に概念が成功したかどうかを測定できるようにする必要があります。

成功と証明の価値を測定する

最初の投資を行うかどうかにかかわらず、自分がどれだけ成功しているかを測定することは、製品の考え方の重要な部分です。 これは、目標を達成したかどうかを知るのに役立つだけでなく、小規模な投資でも、より大きな投資を構築するための基礎を築くことができます。

たとえば、ビジネス価値を提供する開発チームに運用税として認識される可能性があるため、コンプライアンスの取り組みのために資金やバイインを確保することは困難な場合があります。 製品の考え方は、その認識を変える可能性があります。 製品マインドセットを使用すると、内部開発者プラットフォームの顧客が満足し、利害関係者のビジネス目標が達成されるようにしようとしています。 メトリックを使用すると、ファクトを使用してビジネス価値を提供していることを証明する立場に立ちます。 OKR を設定すると、特に主観的な偏見を取り除くために使用できるメトリックがある場合に役立ちます。 現在該当するものを測定していない場合でも、学習 OKR を設定してベースラインを設定し、このベースラインが判明した後に調整することができます。

次に示す既知のメトリックの例を使用して、作業しているチームが構築している内容から価値を得ているかどうかを判断できます。 自分と開発チームの顧客が目標を達成しているかどうかを測定するのに役立つものにゼロインします。 たとえば、プラットフォームが効果的なエンジニアリング organizationに貢献しているかどうかを評価するのに役立つ一連のメトリックを次に示します。

  • 速度/ビジネスまでの時間の値: 最初のプル要求を完了するまでの中央値 (オンボーディング)、ビルドおよびテスト プロセスの中央値 (例: CI)、pull request をマージする中央値の時間。
  • ソフトウェアの品質: 開発ごとに 1 か月あたりに作成されたインシデント (問題) (開発の数に正規化されたカウント)、修復する時間 (MTTR) を意味し、セキュリティの問題を調査して修復する時間を意味します。
  • プラットフォームの使いやすさ: Net ユーザー満足度 (NSAT)
  • 繁栄するエコシステム: 調査対象の各質問の平均スコア: "私は最善の仕事をする権限を与えられている"、"ほとんどの日は、私がやっている仕事に活気を与えられている"、"私がやっている仕事は私にとって有意義です。

その後、organization、チーム、またはプロジェクトでこれらのメトリックを分解できます。 開始するには、いくつかのベースラインを測定する必要がありますが、プラットフォームを改善するにつれて、これらのメトリックの変更をwatchできます。

お客様またはスポンサーが関心を持っている可能性があるその他のメトリックは次のとおりです。

領域 メトリックの例
ソフトウェア配信のパフォーマンス DevOps Research and Assessment (DORA): リード タイム、デプロイの頻度、変更の失敗率、サービスの復元時間 (MTTR) の変更
Operations DORA (MTTR)、平均故障間隔 (MTBF)、確認までの平均時間、エンド カスタマーの可用性、待機時間、スループット メトリック、チームあたりのコスト、デプロイあたりのコスト
プラットフォーム機能導入メトリック ツールまたは機能を経時的に使用するチームまたは開発者の数、プラットフォームを使用するリポジトリの割合、最も一般的なテンプレート、パイプラインなど。

メトリックの収集には時間と労力が必要であるため、特定したコア目標 (特に OKR を強化する目標) の重要なメトリックに焦点を当てることが重要です。 Application Insights などの OpenTelemetry ベースの製品が役立ちます。 関係なく、プラットフォームの使いやすさを測定し、繁栄しているエコシステムがあることを定期的に調査してください。 これらのメトリックは、内部システムでは見逃されることが多く、関与した参加が成功に不可欠であるため、より広範なビジネス目標を達成するかどうかに関する主要な指標です。 また、次に進む場所を理解するために、さらなる顧客開発を行う時が来たかどうかを把握するのにも役立ちます。

その他のヒント

開始方法に関係なく、次のガイドラインに注意してください。

変更を計画する

ターゲット アプリケーション プラットフォームは時間の経過と共に進化し、既存のすべての投資を一度に移行できない場合があります。 多くの場合、時間の経過と同時に複数のバリエーションをサポートし、変更を計画する方法を考える必要があります。

新しいアプリケーションでアイデアを検証する

一般に、新しいプラットフォームまたはプラットフォームの機能を試験運用する場合は、適切なサイズの新しいアプリケーションから始めるのが最善です。 これにより、製品としてのプラットフォームの管理経験も得られます。 作業を進めるにつれて学習するため、プロジェクトの再プラットフォーム化を始めるのを恥ずかしがり、大規模な既存のアプリケーションには、多くの場合、再プラットフォーム化作業自体の間にのみ明らかにされる固有のニーズがあります。 そのため、これらの種類の作業に成功を結合すると、期待の不一致や遅延の問題が発生する可能性があります。 新しいものから始めると、それが提供する価値の方向に自信を持つことができます。 これにより、これらのより大きな取り組みに取り組むリスクが軽減されます。 言い換えると、人々が正しいスタートを切り、正しい状態を維持できると確信している場合は、経験から学んだことで適切なキャンペーンを推進する方が簡単になります。 この方法が不可能な場合は、すべてを一度に変更するのではなく、慎重な分析を行い、期待値を設定し、段階的にステップインする必要があります。

新しいユーザー エクスペリエンスを作成する前に、既存の重心に重点を置いてユーザー エクスペリエンスを実現する

開発者は、既に好きで使用しているものに表面化したときに、新しい機能を採用して使用する可能性が高くなります。 新しい機能を提供するための概念を評価するときは、既存の "重心" を拡張するオプションを必ず調査してください。たとえば、エディター/IDE (Visual Studio、VS Code)、DevOps スイート (GitHub、Azure DevOps)、既存の CLI、既存の内部ポータルは、まったく新しいポータルや他の UX よりも効果的です。 詳細については、 ユーザー エクスペリエンス に関するページを参照してください。

最小特権の原則を想定する

開発者は、インフラストラクチャのプロビジョニングなどのダウンストリーム システムへのアクセスが制限されているとします。 セルフサービス エクスペリエンスのためにこのアクセスを有効にするには、制御された方法が必要です。

制御された実験の計画

大きな変更または危険な変更をロールアウトする前に実験します。 開始するためにすべてが完全に自動化されている必要はありません。 自動的にトリガーされる手動ワークフローは、アイデアをパイロットするための優れた方法です。

アプリ プラットフォームのカスタマイズを最小限に抑える

ソフトウェア ベンダーが時間の経過と同時にリリースする機能によって利用される可能性があるカスタムビルド アプリケーション プラットフォーム機能を回避してください。 たとえば、ランタイム ホスティング、サービス メッシュ、ID システムなどです。 このようなと思われる領域で緊急のニーズが見つかる場合は、長期的なメンテナンスによって時間の経過と同時に切り替える可能性が高い場合は、複数の実装オプションを計画します。

ソフトウェア エンジニアリング システムを適用する