【クラウドネイティブ会議】相手を知ることから始める、使われる社内基盤を育てるためのプラットフォームエンジニアリング

クラウドネイティブ技術の浸透により、開発者の責任範囲と認知負荷が拡大するなか、注目されているのがプラットフォームエンジニアリングである。クラウドネイティブ会議のセッション「プラットフォームエンジニアリング 結局何をすれば良いのか」では、PagerDuty Japanの草間一人氏が、プラットフォームを「魅力的な社内プロダクト」として捉え、使う相手を知り、小さく始め、プロダクトとして育て続ける重要性を解説した。

プラットフォームエンジニアリングとは何か、認知負荷を下げる共通基盤

草間氏はまず、「プラットフォームとは何か」から説明を始めた。ここでは開発者や運用者に役立つ機能を「魅力的な社内プロダクト」として整備した基盤をプラットフォームと位置づける。ここでいう機能には、セルフサービスのAPI、ツール、サービス、ナレッジ、サポートなどが含まれる。共通機能を提供し管理することで、開発者やオペレーターがアプリケーションやサービスを迅速に提供できるようにするものだ。

プラットフォームとは

この定義を説明するために、草間氏は空港の例を挙げた。空港には多くの航空会社が乗り入れているが、滑走路や管制塔、給油設備、保安検査場などを航空会社が個別に運営しているわけではない。空港という共通インフラを管理会社が整備し、各航空会社に提供している。プラットフォームも同様に、個々の開発チームが毎回すべてを用意するのではなく、共通して必要となる仕組みをまとめて提供する役割を担っているというわけだ。

「プラットフォームエンジニアリングの定義で言うプラットフォームでは、それが魅力的であることにかなりフォーカスを置いています」と草間氏は語った。単に共通基盤を作ればよいわけではない。開発者や運用者にとって「使いたい」と思えるものでなければ、プラットフォームとしての価値は発揮されない。

では、なぜ今プラットフォームエンジニアリングが注目されているのか？ 背景にあるのは、開発者の認知負荷の増大である。現在、1つのアプリケーションを開発するだけでも、プログラミング言語やフレームワークに加え、CI/CD、Dockerfile、Kubernetesマニフェスト、IaC、データベース、Observability、セキュリティなど、多くの要素を考慮しなければならない。

そこで登場するのが、Internal Developer Platform／Internal Developer Portal、ゴールデンパスといった考え方である。Internal Developer Platformは、インフラ、CI/CD、監視、認証などを抽象化し、開発チームがアプリケーション開発に集中できるようにする内部向けのプラットフォームである。一方、Internal Developer Portalは、開発者向けのインターフェースであり、必要な情報や操作を集約する窓口となる。

またゴールデンパスは、開発者がたどるべき推奨ルートである。CI/CDテンプレート、IaCテンプレート、モニタリング設定、開発ガイドラインなどを用意し、開発者が安全かつ効率的に作業できるようにする。これらはいずれも、開発者が毎回すべてを調べ、判断し、作り込む負担を減らすための仕組みである。

共通基盤はなぜ失敗するのか、使われない原因は「相手を見ていない」こと

草間氏は、プラットフォームエンジニアリングや共通基盤の考え方自体は決して新しいものではないと指摘した。企業の中には、これまでも「次世代共通プラットフォーム」や「新統合基盤」といった名称で、似たような取り組みを進めてきた例が多くある。

しかし共通基盤は成功するとは限らない。むしろうまくいかない例も多い。草間氏はこれらの「共通基盤」について約4割は生まれながらにして時代遅れとなり、さらに約4割は運用がうまくいかず不要になっていくと説明した。真に成功するものは2割以下、決して多くないという見立てである。

ではなぜ失敗するのか。草間氏が挙げた大きな理由は、「魅力がない」ことである。そして、なぜ魅力がないのかといえば、多くの場合、使う人のことを第一に考えていないからであるという。

共通基盤の構築は、しばしば作り手側の思い込みから始まる。世の中で流行っている技術だから、ガバナンスのために必要だから、全社的に標準化すべきだからといった理由で構想が進む。しかし実際に使う開発者や運用者が何に困っているのか、どの作業に時間を取られているのかを十分に把握しないまま作ってしまうと、結果として「誰のためのものかわからない基盤」になってしまう。

プラットフォームエンジニアリングは、単にプラットフォームを作る活動ではない。活用され、ビジネス成果を出す共通基盤を作り、運用し続け、育て続けるための方法論である。作った瞬間がゴールではなく、使われ続けることが重要なのだ。

だから、プラットフォームエンジニアリングが必要

そのためには、利用者の課題を出発点にしなければならない。どれほど高度な技術を使っていても、利用者にとって価値がなければ定着しない。反対に小さな仕組みであっても、現場の困りごとを確実に解決できれば、プラットフォームとしての価値を持つ。

結局何をすればよいのか 相手を知り、プロダクトとして育て続ける

草間氏が示した答えは明快である。まずは相手を知ることだ。プラットフォームを使う開発者や運用者が、普段どのような仕事をしているのか、何に困っているのか、どのような制約の中で動いているのかを知らなければ、使われるプラットフォームは作れない。

まずは相手を知るところからはじめる

そのための具体策として、草間氏はまず、「一緒にご飯を食べに行く」ことを挙げた。これは冗談ではなく、かなり大真面目な助言である。利用者となるチームと頻繁にランチに行き、会話を重ねることで、相手の状況や悩みが見えてくる。形式的なヒアリングだけでは出てこない、日常の困りごとを知るためには、こうした関係づくりが欠かせない。

草間氏は、プラットフォームを使ってもらう人のことを知ることが「何よりも大事な第一歩」だと語った。重要なのは、作り手が想定した便利さではなく、使う人にとっての便利さである。その意味で、プラットフォームチームは、まず利用者に近づかなければならない。

さらに深く相手を知るには、相手チームと一緒に仕事をすることが有効である。草間氏は、チームトポロジーズで定義されるコラボレーションにも触れた。これはプラットフォームチームとストリームアラインドチームが1対1で深く連携し、ほぼ1つのチームのように動く考え方である。

相手チームの一員として仕事をすれば、どの作業に時間がかかっているのか、どの作業が面倒なのか、どの部分にリスクがあるのかを目の前で観察できる。そこで見えた課題に対して、プラットフォームチームが小さな改善を提供すれば、即座に価値を示すことができる。草間氏は、まず目の前の1チームを幸せにすることから始めるべきだと説明した。

ここで重要なのは、最初から全社向けの巨大な共通基盤を作ろうとしないことである。小さく始めればよい。チームトポロジーズの著者によれば、最小のプラットフォームは、クラウドへの便利なリンク集を集めたWikiかもしれないという。また、よく整備されたドキュメントも、十分に価値あるプラットフォームになり得る。

そのうえで必要になるのが、Platform as a Productの考え方である。社内向けであっても、開発者を顧客として捉え、プラットフォームをプロダクトとして提供する。ユーザーの声を聞き、優先順位を付け、改善を重ね、必要に応じて社内マーケティングやブランディングも行う。草間氏は、理想的にはプラットフォームチームにプロダクトマネージャーがいるべきだとも語った。

Platform as a Product

さらに草間氏は、プラットフォームエンジニアリングを「ソシオテクニカル」な取り組みとして捉える重要性を強調した。ソシオテクニカルとは、人や組織といった社会的システムと、ツールやアーキテクチャといった技術的システムが不可分であるという考え方である。プラットフォームエンジニアリングは、まさにこの両方を扱う。

技術に詳しい人ほど、ツールやアーキテクチャに関心が向きやすい。しかし、プラットフォームを使うのは人であり、導入されるのは組織である。プラットフォームが使われるかどうかは、技術の良し悪しだけで決まるものではない。

最後に草間氏は、プラットフォームエンジニアリングには決まった正解がないと語った。AWSを使うべきか、Azureを使うべきか、どのツールを採用すべきかといった答えは、外部のベストプラクティスだけで決まるものではない。正解は、それぞれの組織の中にある。

プラットフォームエンジニアリングとは、どこかにある正解をそのまま持ち込む活動ではない。自分たちの組織にとっての最適解を探し続けるための方法論である。使う人を知り、小さく始め、プロダクトとして育て、技術と組織の両面から改善し続ける。その積み重ねこそが、「結局何をすれば良いのか」という問いに対する草間氏の答えであった。