CNCFによるPlatform Engineering maturity modelからの実践ロードマップ（案）
この記事は、Platform Engineering Advent Calendar 2023 の20日目のエントリーです。
昨今話題となっている Platform Engineeringについて、私が興味を持った理由や、最近公開されたCNCFによる「Platform Engineering maturity model」の内容を踏まえ、どうやって実践することになるのかな？という観点で少しだけですが考察してみたものになります。
技術の話ではなく組織マネジメント的な観点が中心のエントリですので、あらかじめご了承ください。
なお「どうやって実践していくか」というお題についてはすでに、kenojiri - Qiitaさんの2日目と16日目の２回にわたる以下の超大作エントリである
でも語っていただいており、タイトルからエモい内容かと思わせつつちゃんと実践的＆具体的な話をがっつりと整理いただいた良い意味で期待を裏切る良記事です。こちらもぜひお読みになっていただくことをお勧めします。
むしろ私の方が逆（実践的に思わせといて単なるポエム・・・）になってしまったのでほんと恐縮ですが・・まずは自分なりの理解を整理してアウトプットに挑戦してみた、ということでご容赦いただけると幸いです。
目次
私がPlatform Engineeringに興味を持った理由
組織全体の成長につながる可能性を感じたからです。プロダクトを開発する部署は日々それぞれに結果を出していますが、その過程で得た効率化のノウハウや体系化した知見が組織の成長にもつながっている実感はありますでしょうか？個人やチーム内に小じんまりと閉じてしまってないでしょうか？社内勉強会等で広く共有できていたとしても、それが他のチームでも実践（再現）されているのでしょうか？これはなかなか難しい問いですがそれを実践するための考え方の1つとしてのPlatform Engineeringが有効ではないかと考えています。
Platform Engineeringは主にアプリやサービスの開発者を対象としており、開発に必要なあれこれ（＝認知負荷）を、適切にコントロールして効率よく開発をしていくための方法論が中心になります。一方でこのような考え方はいわゆるバックオフィスと呼ばれる領域に適用できる可能性を秘めているのではと感じています。例えば、各種申請、予算執行稟議・セキュリティチェックなど、実際にメンバが開発以外にも社内のルールを確認したり手続きを進めなければならないことが日々沢山あるはずです。
このようなあれこれに対するノウハウを「プラットフォームという仕組み」として積み重ね、伝承や改善を続けること（＝Platform as a Product）でエンジニアリング力を向上させること、引いては組織全体の生産性向上につながる可能性に期待しています。そしてノウハウや知見を蓄積・体系化・浸透させることをミッションとした体制（Platform Team）は、これからの組織全体の成長やスケールに向けてより重要になるのではと考えています。
- エンジニアリング力とは、技術を課題解決に活かす力。技術とは、再現性のある創造的な課題解決手法。再現性とは、誰が実施しても同じ結果を出せる事と考えます。組織として再現性のある方法を皆で使って効率的にアウトプットを出し、最も貴重なリソースである「時間」をより顧客のことを考えるために費やせるようになる事が重要と考えます。
- 蓄積とは、目的や戦略を実現可能とするための情報やノウハウそのものを現場から収集し続けられる事です。なお収集の目的や仮説がない中の蓄積は誰も幸せになりません。蓄積の結果得られた示唆が現場や組織全体に活用できること（仮説でもいいので）を基本に、現場には極力負担をさせずにもしくは蓄積に貢献し続けたくなる工夫が必要になります。ここは双方がWin-Winになるという観点（報酬やナッジを組み込む事も手段としてはアリだと思います）が重要になってくると思います。
- 体系化とは、集まった情報から現状を俯瞰的な視点で把握できるようにする事です。これにより正しい情報とその把握に基づく質の高い意思決定や判断の支援に役立てたることを目指します。
- 浸透とは、組織のメンバの誰もが業務で実践できるようにする事です。単に勉強会や講習会でインプット・アウトプットすればいいという話ではなく、それを使って実際に他の誰かのアウトプットにつながるところまで目指さないと浸透したとは言えないと思います。
CNCFのPlatform Engineering maturity model
このような漠然とした理由ではありますがPlatform Engineeringに興味を持ちつつ、でもそれってどうやっていくのかなと、実践に向けた思考を悶々と巡らせている中で「CNCFがmaturity modelのペーパを出したよ」という情報をいただき、さっそく読んでみました。
「Model Table」がキモになる部分と思いますので、以下に引用します。（注：私の翻訳による非公式の日本語訳である点に注意してください。ニュアンスの誤りやより適切な翻訳があればコメントいただけると幸いです）
|
側面 Aspect |
Level 1 |
Level 2 |
Level 3 |
Level 4 |
|
|
暫定的 |
運用可能 |
スケーラブル |
最適化 |
||
|
投資 Investment |
スタッフと資金はプラットフォーム機能にどのように割り当てられますか? |
自発的または一時的 |
専任チーム |
製品として |
有効なエコシステム |
|
採用 Adoption |
ユーザーはなぜ、どのようにして内部プラットフォームやプラットフォーム機能を見つけて使用するのでしょうか? |
不安定 |
外部からのプッシュ |
本質的な魅力 |
参加型 |
|
インターフェース Interface |
ユーザーはプラットフォームの機能をどのように操作し、利用するのでしょうか? |
カスタムプロセス |
標準ツール |
セルフサービス |
統合サービス |
|
オペレーション Operations |
プラットフォームとその機能はどのように計画され、優先順位が付けられ、開発され、維持されますか? |
リクエストにより |
一元的に追跡される |
一元的に有効化 |
マネージドサービス |
|
測定 Measurement |
フィードバックを収集し、取り入れて学習するプロセスはどのようなものですか? |
その場限り |
一貫した収集 |
洞察 |
定量的および定性的 |
実践ロードマップ（案）
CNCFのmaturity modelにおけるAspectはPlatform Engineeringとして求められる重要な観点をフォーカスしており具体化に向けた論点としても非常に興味深いところです。（Aspectの1つ1つで議論できそう）。ただし今回は一旦「Level」の軸に着目してみました。これは自分が企画として落とし込む時にロードマップの軸として有用ではないかとイメージしたからです。
|
Level 1 |
Level 2 |
Level 3 |
Level 4 |
|
|
暫定的 |
運用可能 |
スケーラブル |
最適化 |
|
|
コンセプト |
Small Success |
Minimum Value Product |
Platform as a Productの実践 |
ビジネス化への挑戦 |
|
組織 |
2-3名(1team) |
5-8名(2team) |
10-20名(4-5team) |
30名以上 |
|
目標 |
実現可能かつ効果があることの実証(PoC) |
ワークフローとツールチェーンの標準化 |
プラットフォームチームの体制化と自社内運用 |
サービス化 |
|
誰に |
自分自身 |
複数チーム |
自社内 |
自社内 |
|
成果物 |
情報整理 |
標準化(業務+ツール) |
プロダクトそのもの |
IDP＋テンプレートのマネージドサービス |
Levelの表現からもし自分がロードマップとしておくならこんな感じかなとイメージして書いてみましたがいかがでしょうか。CNCFとは観点が異なるため混乱させてしまったら申し訳ないのですが、論点のたたき台くらいになれればと思います。
まずはLevel2までを実現したいところですが、その間に積み上げた成果物や実績データを武器にLevel3に向けた予算や組織体制を提案していくのがよさそう。Level4はビジネス化を想定した位置づけにしたのでハードルが高いかもしれませんが、ここまでを見据えた企画なら経営陣への提案に向けたストーリを具体化できそうな気がします。
おわりに
Platform Engineeringに興味を持ち、その実践に向けてなにか考えてみたいという方にとっての少しでも参考になれば幸いです。私自身Platform Engineeringを学ぶ勉強会であるPlatform Engineering Meetupの運営スタッフとして僭越ながら参加させていただいております。もしMeetup等でお会いする機会があればよろしくお願いします。
platformengineering.connpass.com
