はじめに
エーピーコミュニケーションズ ACS事業部亀崎です。
これまで、いくつかのお客様にもPlatform Engineeringについてご紹介させていただきました。 また本ブログでも様々な観点からPlatform Engineeringについてご紹介してきました。
そうしたなかで聞かれるのが「Platform Team」って有用なの？ということでした。
今回はその点について考えてみたいと思います。
一般的なプログラムの話
Platform Teamについて考える前に一般的なプログラミングについて考えてみます。
現在、以下のようなX、Y、Zという３つのシステムがあるとします。
それぞれのシステムの中を分析すると、A/B/C/X/Yという3システム共通の部分と、Ax/Ayのように各システム固有の部分がありました。 そして、この共通部分については今後増加するであろうシステムでも同様に共通に利用していくと予測されるものでした。
さて、みなさんならばどのようにこのシステムを改善（リファクタリング）していきますか？
ひとつの方法として以下のように共通部分を各システムから切り出しライブラリ化するのではないでしょうか。
各システム（そして今後追加されるであろう新システム）に分散してしまう共通のナレッジが、共通化しライブラリに反映することで、その内容もより進化していくことが期待できます。
プラットフォーム（インフラストラクチャ）
実は同様のことがプラットフォーム（インフラストラクチャ）においても言えます。 先日ご紹介したIaCの事例がそれです。
共通モジュールが上記一般的プログラミングにおけるライブラリに相当します。 このように各チームが利用する共通部分を切り出してまとめることができるのです。
この共通モジュールを誰が考え、そしてIaCを用意するのか。それがPlatform Teamです。 共通部分を1か所にまとめることができれば、それだけナレッジも集約されますし、新規システムを作成する場合もいちから考えるという無駄が省かれます。
ですが、本当にこのようなことができるのでしょうか。
コンウェイの法則／逆コンウェイ戦略
少し話がそれますが、みなさんはコンウェイの法則をご存じでしょうか。
コンウェイの法則とは
システム設計は、組織構造を反映する
というものです。組織構造がシステム設計に密接に関係しています。
そして逆コンウェイ戦略というものもあります。
最適なシステム設計に合わせて組織構造を変えていくことで組織も最適化する
というものです。
今回のPlatform Teamについてはまさにこの逆コンウェイ戦略が適用できます。
システム上、共通モジュールを切り出すのがシステムとして最適なのであれば、それにあわせて組織構造を合わせていけばよい、それがPlatformTeamであると考えられます。
有用性
今回の例では、なにもないところから汎用的なPlatformを作ろうとしているのではなく、各システムが持っているものから共通部分を切り出すといったリファクタリングベースで考えいます。 一般的なプログラミングにおけるリファクタリングの有用性はみなさんご存じのとおりだと思います。そのアプローチを適用したPlatform化も同様に有用でしょう。
Platform Team、Platform Engineeringという言葉を聞くと新しいもので本当に有用なのか？必要なのか？と疑ってしまいますが、そこで行おうとしていることはこれまでソフトウェア／ITシステム開発で有用と考えられてきた共通化・標準化・汎用化といった手法を応用したものですので、Platform Teamを作るというアプローチも有用性が高いと考えてよいのではないでしょうか。 実際すでにPlatform Team/Platform Engineeringを実践している企業では十分有用であるとされています。
ぜひ、Platform Engineering／Platform Teamについてあらためて考えていただきたいと思います。
まとめ
そうは言ってもやっぱり難しいし、どう手をつけていいかわからない、ということもあるかと思います。
弊社ではクラウドネイティブ分野のシステム導入・開発支援を行っています。Platform Engineeringなどもこれらのサービスに含まれます。ご興味のある方はぜひご連絡ください。
