2024.06.03

プラットフォームエンジニアリング勉強会に参加して

梅

Contents

はじめに

ume(梅)です。早いもので気付いたら入社して3ヶ月が経ってました。
今回は社内でプラットフォームエンジニアリングの勉強会に参加しましたのでそのまとめ記事をお届けします。

CNCFのホワイトペーパーを各自輪読の上、数回にわたって章毎のディスカッションを行いました。
以降の節がホワイトペーパーの当社的な解釈です。

以下を読み進める上で2つの単語を理解しておくと良いです。

認知的負荷: 簡単に言うと「勉強・調査しないとわからないようなこと」のこと、特にプラットフォームエンジニアリングは以下の低減を目的にしている
- 課題内在性負荷・・・学習内容の難しさによる負荷
- 課題外在性負荷・・・「気が散る」ことや、メールなどで入ってくる無関係な情報などによる負荷
プラットフォームチーム: チームトポロジーで定義されたチーム定義のうちのひとつ、インフラやツール、CI/CDなどの共通サービスなどをプラットフォーム化したものを提供するチーム

プラットフォームを開発し以下を目的となります。

プラットフォームの成熟度は以下5つの段階が想定されています。

プラットフォームとして必要なことは以下の通りです。

製品のような扱いでプラットフォームを整備する
プラットフォームのUX向上を意識する
ドキュメント整備とオンボーディング
- ドキュメント、テンプレート、ツールを用意して、オンボーディングをスムーズに行う
セルフサービス（開発チームが自分だけでプロビジョニングできる）
- プラットフォームチームの作業を必要とせず、ユーザーが自らオンデマンドで利用できるようにする
ユーザーの認知不可の軽減
- プラットフォームの実装の詳細をカプセル化する
オプションで構成可能（カスタマイズ可能）
- プラットフォームが対応していない場合でも、自分たちで持ち込むことは可能な状態にする
- プラットフォームが制約になってしまわないようにする
デフォルトで安全（セキュア）
- なにも設定しなくても、デフォルトで払い出された状態で安全である状態

プラットフォームを提供するチームとして必要なことは以下の通りです。

プラットフォームのユーザー要件を調査し、機能ロードマップを計画する
- ユーザーインタビュー、インタラクティブなハッカソン、問題追跡ツールとアンケート、可観測性ツールによる使用状況直接観察
プラットフォームが提案する価値観を売り込み、宣伝し、擁護する
- インバウンドフィードバックと思慮深いデザイン
- アウトバウンドマーケティングと擁護
ポータル、API、ドキュメントとテンプレート、CLIツールなどの機能とサービスを使用および観察するためのインタフェースを管理および開発する
- 自分たちではなるべく作らない、うまく既存のあるツール・サービスを利用する
- ボタンを押したらIaCツールが実行されるようなイメージ

プラットフォーム構築に対する課題と対策は以下の通りです。

プラットフォームを製品のように扱い、ユーザーといっしょに開発する必要がある
- フィードバック無しで機能やエクスペリエンスをリリースするのはNG
優先順位と最初のパートナーアプリケーションチームを慎重に選択する必要がある
- プロダクト固有の機能は優先度を低くする
- 熱心なアプリケーションチームに使ってもらい、良いフィードバックを出してもらう
企業リーダーのサポートを求め、バリューストリームへの影響を示す必要がある
- インフラを単なるコストとして認識されてしまわれないように、企業リーダーの理解を得ることが必要
- バリューストリームチームに対する直接的な影響と関係を実証する

プラットフォームチームを運営していくにあたっての課題は以下の通りです。

プラットフォームのKPIには以下が挙げられます。

ユーザーの満足度と生産性
- アクティブユーザーと維持率
- ネットプロモータースコア、ユーザーの満足度
- SPACEフレームワーク
組織の効率性: 自動的に測るツールがあると良いかも
- サービスが使えるようになるまでの時間
- 本番環境にデプロイできるまでの時間
- 新しい開発メンバーが最初にコードをコミットするまでの時間
製品と機能の提供
- Four Keysの本番環境に対する指標を測ると良い