はじめに
この記事は、Platform Engineering Advent Calendarの19日目の記事です。
こんにちは、Cloudbase株式会社所属のryukeと申します。前職のメルカリでMicroservices Platformチームの一員として働く機会を頂き、その成熟したプラットフォームとそれを支える技術・思想に感銘を受けたことがきっかけとなり、Platform Engineeringの道を志すことになりました。
さて、現在働いているCloudbaseという会社はクラウドのセキュリティリスクを監視・管理するためのセキュリティプロダクトを提供する会社です。エンジニアの人数としては10人程度のまだまだ小さなスタートアップで、まだ専任のチームもないのですが自分が主体となってPlatform Engineeringの実践の一部を取り入れており、その紹介がしたくて今回記事を書きました。
Platform Engineeringというとかなり成熟したエンジニアリング組織での事例が紹介されることが多く、Kubernetesやマイクロサービスと合わせて語られることが多い印象を持っています。しかし、その考え方はどんな規模の組織でも適用できるものであり、技術要素に関係なく価値を発揮するものだと思っています。
この記事では、スタートアップにおけるPlatform Engineeringがどんな役割を果たすべきか、どんな活動を行なっていけばいいのかを考える上での一例として、弊社での考え方と事例を紹介したいと思います。
全体の分量が多いため、2パートに分割しています。Part 1では、"Team Topologies"の書籍を引用しつつ、Platform Engineeringの役割についての考え方を整理しています。Part 2はこちら↓
スタートアップでもPlatform Engineeringがしたい！Part 2 ー CloudbaseにおけるPlatform Engineeringの実践事例
想定読者
- Platform Engineeringの考え方やその背景について知りたい
- 小規模組織でのPlatform Engineeringの実践について興味がある
Platform Engineeringをどう定義するか
一口に "Platform Engineering" といっても、組織やコンテキストによって色々な定義・捉え方の違いがあると思います。
Platform Engineeringはどのような背景で注目を集めていて、どんな目的で取り組むべきプラクティスなのでしょうか。スタートアップにおけるチームのあり方を考えるにあたって、ここでは一度HowではなくWhyに立ち返るところから考えてみたいと思います。
エンジニアリング組織の設計を考える上でバイブル的存在である "Team Topologies"^1では、エンジニアリング組織を構成する4つの基本的なチームタイプの1つとしてプラットフォームチームを導入しています。
- ストリームアラインド: 継続的な価値のストリームに沿って、すばやく安全に顧客に価値を届ける
- イネーブリング: 特定のテクニカル（プロダクト）ドメインのスペシャリストによって構成され、他のチームが専門的なスキルを獲得するための支援を行う
- コンプリケイティッドサブシステム: 特に専門性や複雑性の高いコンポーネントを開発・保守する
- プラットフォーム: 下位のサービスを抽象化されたセルフサービスなプラットフォームとして提供し、他のチームを支援する
プラットフォームチームの目的については、以下のようにまとめられています。
プラットフォームチームの目的は、ストリームアラインドチームが自律的に仕事を届けられるようにすることである。ストリームアラインドチームは本番環境のアプリケーションの開発、運用、修正を含む全体のオーナーシップを持つ。プラットフォームチームは、内部サービスを提供することで、ストリームアラインドチームが下位のサービスを下位のサービスを開発する必要性をなくし、認知負荷を下げる。
つまり、
- 顧客と対話しながらフィードバックを回し、職務横断的に最速で価値を届けることをミッションとするストリームアラインドチームを主軸とし、
- その負荷を軽減することによって価値のストリームの加速を目指すその他3つのうちのチームタイプの1つとしてプラットフォームチームが位置付けられている
ということになります。
このようなチーム構成が主流になりつつある時代的背景について、本書ではDevOpsの文脈を引用して次のように説明されています。
- DevOps志向の高まり: 世界がますます複雑で変化の激しい時代になり、より高速な変化に対応するアジリティが開発組織に求められるようになったことで、開発から運用までを一気通貫で担当し顧客からのフィードバックループを高速で回す「職能横断型プロダクト開発チーム」（=ストリームアラインドチーム）が志向されるようになった
- 技術要素の成熟: 以前のモノリシックなアーキテクチャや開発と運用チームの分断はオンプレ技術の制約による歴史的な妥当性があった。近年のクラウド、コンテナといった技術要素（ソフトウェア化されたインフラストラクチャー）の成熟により、DevOpsが技術的に実現可能になった
- 開発チームの認知負荷の増加と部分最適化: プロダクトの開発から運用までの全ての工程を1チームが遂行することを要求されるようになり、必要な知識範囲が大幅に拡大した。結果として、機能開発以外の業務の割合が増加し、本来の焦点である顧客との対話に集中できなくなってしまう。また、それぞれのチームが同じようなツールを別々に再開発するといった部分最適化の弊害が発生する
前置きとしては長くなってしまいましたが、以上をまとめると、プラットフォームチームのミッションは 「エンジニアリング組織全体が顧客に届ける価値を最大化すること」 を究極的な目標として、以下の2つの課題に取り組むことであると言うことができるでしょう。
プラットフォームのミッション
- 1. 認知負荷の軽減: 前線の開発チームが顧客に価値を届けるフローの中で障害となる認知負荷を軽減し、顧客との対話とプロダクトの価値検証に充てられるエネルギーを増やす
- 2. 技術の集合知: 部分最適と全体最適のバランスを取りながら、ストリームを横断して共通化すべき技術要素を抽出・抽象化して提供する
スタートアップにおいては、顧客と向き合いながら価値を高速で検証し、最速でプロダクトを作り変え続けることが求められます。これは「価値のストリームの最大化」そのものであり、したがって「1. 認知負荷の軽減」が重要な役割を果たすことになります。
一方チーム数が少ないため「2. 技術の集合知」の恩恵は比較的少なく、求められる要件や方向性の変化も激しいため「早すぎる最適化」にならないように部分最適と全体最適のバランスを慎重に見極めていく必要があります。一方で組織の規模が大きいほどそのレバレッジも大きくなるため、早い段階で取り組むことで長期的なリターンが見込める投資的な側面が強いと言えます。
組織の各フェーズにおけるPlatform Engineeringの役割
Platform Engineeringを上のように定義すると、特定の技術要素とは関係なく適用できるプラクティスであることがわかります。同時に、人によってその捉え方に違いが生じるのも、この幅の広さによるものだと思います。実際 "Team Topologies" でも、
どこまでをプラットフォームとするかの境界には大きな幅がある。厚いプラットフォームでは、複数の内部プラットフォームチームが無数のサービスを提供していることもある。薄いプラットフォームでは、単にベンダーのソリューションに皮をかぶせただけの場合もある。
と述べられており、色んなプラットフォームの形があることがわかります。
私個人の考え方としては、Platform Engineeringは組織のフェーズによって段階的にその役割を変えるべきものであると思っています。組織によって差はあれど、一般的にはフェーズに応じて大体以下のような役割の変化が起こるのではないでしょうか。
| 初期（〜20人） | 拡大期（〜100人） | 成熟期（100人〜） | |
|---|---|---|---|
| 求められる役割、テーマ | OSSやSaaSをラップした軽量なプラットフォーム、共通ガイドラインの策定、イネーブルメント | プラットフォームの標準化によるプロダクト品質・開発生産性の担保 | より成熟した統合的なプラットフォーム、標準化とカスタマイズ性のバランス |
| 認知負荷の軽減 | 大 | （初期に比べると）小 | |
| 技術の集合知 | 小 | 大 |
初期
プロダクトを大きく変化させながら価値の検証を最速で行うことが求められるフェーズであり、ストリームを加速させるための認知負荷の軽減が主な役割として期待されます。
エンジニアリソースが少なく開発工数も限られるため、プラットフォームとしてはOSSやSaaSを最大限活用した「開発者のニーズを満たす最小限のプラットフォーム」となるでしょう。また例えば導入したSaaSの使い方やProduction Readiness Checkといった社内標準の開発ガイドラインを整備するなど、必ずしもソフトウェア開発ではない共通プロセスの設計もスコープに入ってくることが多いのではないでしょうか。
また場合によっては「技術戦略の提案」や「最新技術の導入支援」などイネーブリング的な役割が求められる場面も多いのではないかと思います。スタートアップにおけるイネーブリングチームの取り組みについては、LayerXさんの事例がとても参考になります。
まとめると、使える手は全て使って開発者の認知負荷軽減に貢献する、という何でも屋的な側面がより強く出るのがこのフェーズの特徴と言えると思います。スコープの肥大化による開発チームへの過度な干渉や、プロダクトの方向性が固まる前に早すぎる最適化・共通化に走らないようにしないように気をつける必要があります。
拡大期
プロダクトの大きな方向性が決まり、組織を拡大しながら一気にアクセルを踏んでいくフェーズです。
典型的には組織の拡大に開発体制の整備が追いつかず、プロダクト品質や開発生産性の問題が健在化しがちな段階であると思います。そのため、可能な範囲で品質や生産性に関するベストプラクティスを抽出・共通化してプラットフォームにどう落とし込んでいくか、というのがこのフェーズのプラットフォームチームの1つの焦点になるのではないでしょうか。
また、組織規模が拡大するにつれて次第に共通技術の集約に伴う全体最適のメリットが大きくなってきます。各チームの自律性を尊重しながらも全体での技術標準を定義することで、集約された技術知見を活用しながらマルチプロダクト化などの新たな挑戦を加速させていくことができます。
成熟期
プロダクトの成熟とともに組織がさらに拡大してくるフェーズです。
この頃になるとプロダクト全体を1人の人間が把握するのが不可能になり、典型的にはマイクロサービス化によって各チームの自律性の担保と認知負荷の軽減が目指されることが多そうです。プラットフォームそれ自体もますます複雑になり、プラットフォームの利用自体が開発者の認知負荷を圧迫しないように一貫した統合的な体験を提供することがチームの1つの目標になりそうです。
また組織の拡大に伴って多様なニーズが生まれるため、最小限の労力で利用できる洗練された標準と、それぞれのニーズを満たせるカスタマイズ性のバランスを両立することが求められます。
後編に続く
以上、Platform Engineeringの定義から始めて、組織の各フェーズにおけるPlatform Engineeringの役割について整理してきました。結論として、スタートアップにおけるプラットフォームチームは「開発者が顧客に価値を届けるフローの中で、障害となる認知負荷を取り除くために使える手を使って何でもやる人たち」といった位置づけになりそうなことが分かりました。
後半のパートでは、そのような定義のもとで弊社のプラットフォームチームが実際にどのような取り組みを行なっているのかについて紹介します。Part2はこちら↓
スタートアップでもPlatform Engineeringがしたい！Part 2 ー CloudbaseにおけるPlatform Engineeringの実践事例