はじめに
こんにちは、ACS事業部の東出です。
私はACS事業部でDX Enabling部という、内製化コンサルティング・プロダクト開発支援を提供する部署の責任者をしております。
ACS事業部では、Platform Engineeringに関する取り組みや情報発信を積極的におこなっています。
今回から何回かに分けて、Platform Engineering Maturity Modelに関して紹介記事を書いていく予定です。
第一回目にあたる今回は、Platform Engineering Maturity Modelの全体感を紹介をしたいと思います。
なんで書くの？
私の部署で提供している内製化コンサルティングサービスでは、事業会社におけるシステム開発の内製化推進、特にクラウドネイティブ技術を活用した開発の内製化をご支援しています。
その中で、開発組織の体制・組織文化をどのように作り上げていくかにあたって、Platform Engineeringの考え方を取り入れています。
コンサルティングにおいては、現状のIT資産や組織能力の状況をアセスメントさせて頂き、お客様個々の事情・状況にあわせて内製化をどういう順序・範囲から進めていくかなどを計画立案していきます。
そういったアセスメントや計画立案を進めていくにあたって参考になると思い、自身の理解を深めるためにも所々で本件の考察をおこなってみよう、と思い立ちました。
前置き：自身の属性について
ただ概要を紹介するだけではなく、自身の経験と知識に基づいての所感なども織り交ぜつつお伝えしたいと思っています。
その前提となる自身の属性を軽く紹介します。
私は業界歴16年ぐらいで、金融系システム・コンタクトセンター系システムのPjMを長くやっていました。
技術的にはアプリ開発からインフラの設計キッティングまで幅広く経験しました。
（余談ですがコンタクトセンター系をやっていた関係で、テレフォニー系システム、あとデータ系の領域が好きめです）
現時点でPlatform Engineeringに対する解像度が高くて関心を寄せているアーリーアダプター層の人間ではなく、ずぶずぶのSIer仕立ての人間です。
この後の考察については、そういった経験の人から見たものだ、というふうに捉えて頂けたらと思います。
Platform Engineering Maturity Modelの全体感と考察
ここからは、Platform Engineering Maturity Modelにある各章立てについて書いていきます。
Introduction
Introductionでは以下のように書かれています（超意訳）
- CNCF Platforms White Paperでは、Platformとは何ぞや？価値は何ぞや？について示した
- とはいえ、価値を達成するためには、自組織の現状を鑑みつつ継続的に改善していく必要あるよね
- Platform Engineering Maturity Modelはそのための枠組みだよ
What is platform engineering?
CNCF Platforms White Paperに関する内容の要約にあたるので、割愛します。
How to use this model
ここでは本成熟度モデルの使い方について解説しています。
ポイントとしては以下になります。
- 成熟度が上がるにつれて、ヒトモノカネの要件が増すので、自組織に合った改善を進めるべき
- 成熟度モデルのレベル上げ自体が目的になってはいけない
- プラットフォームの実装についてはCloud Native Maturity Modelを活用しよう
- 自組織の現状を把握するというより、改善するために取り組むべき事項の把握に使うべし
上記にポイントを列挙しましたが、「成熟度モデルのレベル上げ自体が目的になってはいけない」という点が意識すべき点だと考えます。
得てして、「成熟度」と銘打つものはレベルが高いほどいいものだ、と考えがちですが、そうではなく自組織の現状（外部環境・内部環境）と照らし合わせて必要な改善をおこなっていくものだと捉えた方が良さそうです。
私もその昔、CMMIとかの成熟度の定義とかを見て、「うちはダメだ」「レベル高い企業すごいな」なんて考えていましたが、今思えば、開発物やシチュエーションも異なる企業間で、汎用的な成熟度モデルで優劣をつけることはナンセンスだなと反省しています。
Context behind this work
本項では成熟度モデルが作られた背景が語られています。
まず対象読者について語られていますが、（技術系の）経営陣やベンダーまで、幅広い層を対象にしています。
特に印象的なのは経営陣が含まれていることでしょうか。
この後の紹介になりますが、本成熟度モデルの側面として、単一のチームに閉じたものではなく、エンジニアリング部門全体や、更に広い組織全体での協力体制が必要だとしているため、必然とそうなるのでしょう。
また、成熟度のレベルについての概説がありますが、How to use this modelで述べたように、レベル分けは絶対的な能力分類ではなく、あくまで現状を把握する指標、フレームワークなんだよ、と言っています。
レベル上げが目的になってはいけないですね。
Model table
成熟度モデルが定義されています。
それぞれの内容は次回以降に解説していきたいと思いますが、縦軸でASPECT（投資、適用、などの側面で成熟度を分類）を表現し、横軸でレベル（PROVISIONAL→OPERATIONAL→SCALABLE→OPTIMIZING）を示しています。
ざっくり、成熟度は組織的展開の度合いが反映されていると見てよいでしょう。
さいごに
いかがだったでしょうか？
今回はPlatform Engineering Maturity Modelの全体感について簡単な考察を入れつつ紹介いたしました。
次回以降で、成熟度モデルの細かい内容について見ていきたいと思っています。
ACS事業部のご紹介
私達ACS事業部はAzure・AKSなどのクラウドネイティブ技術を活用した内製化やPlatform Engineering関連のご支援をしております。
www.ap-com.co.jp
また、一緒に働いていただける仲間も募集中です！
今年もまだまだ組織規模拡大中なので、ご興味持っていただけましたらぜひお声がけください。
www.ap-com.co.jp
今回触れたようなことを、内製化コンサルティングとしてお客様と対話したりしています。 メンバー絶賛募集中でございます。
