この記事は博報堂テクノロジーズ Advent Calendar 2025 20日目の記事です。
こんにちは、博報堂テクノロジーズで主に Google Cloud 環境の運用開発を担当している松島です。
本記事では、私の所属するチームが少し前から取り組んでいるプロトタイピング環境向けの Platform Engineering の取り組みについて紹介したいと思います。
まだ実装前の構想段階ですが、どのような課題を解決しようとしているのか、どんなアプローチを考えているのか、是非参考にしていただければと思います。
背景
当社には、社内向けの新規プロダクトを迅速に試作するためにプロトタイピングを多く行うチームがあります。アイデアを形にするスピードを重視し、頻繁にアプリケーションを立ち上げています。
しかし、このチームにはアプリケーション開発やデータ／機械学習の専門家が多い一方で、クラウド環境のセットアップに不慣れなメンバーも少なくありません。
プロトタイプごとに Google Cloud 環境を一から構築する必要があり、開発者にとって負担となっているという課題がありました。
課題へのアプローチ
Platform Engineering とは開発者の認知負荷を下げ、本来集中したいプロダクト開発のコア部分に集中できるような社内プラットフォームを提供する取り組みを指します。
以下のようなものを提供することが一般的です。
- ドキュメントやポータル：プラットフォームの利用方法や各種機能を案内するためのサイト
- Golden Path：新規プロジェクトを迅速に立ち上げるために提供されるツールやインフラ構成を組み合わせたテンプレートとドキュメントのセット
- セルフサービス API・CLI：必要なリソースやサービスをユーザー自身でオンデマンドに払い出せる仕組み
今回の場合、動作環境のセットアップが認知負荷となり、開発のスピードを損ねてしまっていることが課題だったため、本記事の末尾に記載の文献を参考に、Platform Engineering の考え方に基づいて何らかのソリューションを提供することで課題の解決を図る取り組みを開始しました。
1.要件の明確化
まず、現在のプロトタイピングにおける一般的なユースケースや困りごとをヒアリングしました。
Platform Engineering ではユーザー指向でプラットフォームのデザインを行うことがかなり重視されていることもあり、開発者と積極的に対話しながら課題を明文化し、必要な要件を一緒に決定していきました。
2.プラットフォームのレベル調整
次に、どの程度自動化やテンプレート化を進めるべきかを検討しました。今回は以下の理由から、比較的シンプルな形態で提供する方針にしました（詳細は次章で紹介）。
- 利用部門が限られており、ユースケースがプロトタイピングに限定されている
- 専任のプラットフォームチームはなく、既存のインフラ管理チームが業務の一環として対応する
また、部分的に動くサンプル実装を用意し、イメージを共有しながら進めています。
提供予定のプラットフォーム
現時点では Notion を利用したポータルやドキュメントと、cookiecutterをベースとした Golden Path の提供に絞った、下図のようなシンプルな仕組みを提供する予定となっています。
特徴
- プロトタイプ用の Google Cloud プロジェクトを用意
- Web アプリケーションが中心であることを踏まえ、次のような共用リソース部分を管理側で作成
- 共用ロードバランサー、VPC など、個別構築が不要なリソース
- 組織ポリシーや Security Command Center などの統制用リソース
- 各プロダクト用のリソースについて cookiecutter によるテンプレートを用意し、アプリケーションコード雛形と共用リソースに接続する Terraform コードを生成。これらを実行することでコンテナアプリケーションと最低限必要なリソース一式が立ち上がるように構成
- cookiecutter はテンプレートからファイル一式を生成するためのコマンドラインツールで、今回のようなテンプレート配布に広く利用されています
- 一部スクリプト実行など手動作業が残るため、チャット相談用チャンネルを開設し、フォロー体制を整備
検討のポイント
利用部門が限定される、かつ用途がプロトタイピングであることを念頭に運用負荷と提供するメリットのバランスを考えて構成検討を行いました。
特に重要だったポイントを以下に挙げます。
- Platform Engineering のためのツールとして有名な Backstage の採用も検討したが、今回の規模やユースケースでは学習および運用コストのほうがメリットを上回ると判断し、導入しない方針を取った
- 本番環境用ではないため、厳密な環境分離は行わず単一の Google Cloud プロジェクトを複数のプロダクトで共有する形式とした
- プロトタイプ用ということもあり、スピードを重視してある程度の手動変更を前提に設計する
今後に向けて
ここまで書いた内容はまだ検討段階で、年明けから本格的に環境やテンプレートの構築やサービス提供を予定しています。
利用者ごとのコストモニタリングをどうするか、などいくつか課題も見えていますが、次の機会には実装やサービス運営上の工夫などより具体的な部分について紹介できるよう、引き続き頑張っていきたいと思います！
補足
参考文献
- O'Reilly: Platform Engineering
- 翔泳社：Kubernetesで実践する Platform Engineering
- CNCF
- Platform Engineering Meetup過去回の資料や登壇映像
Backstageについて
Backstage については Platform Engineering 界隈で有名ということもあり、ある程度導入イメージが湧く程度には検証を行いました。
結果的に今回は採用を見送りましたが、Backstage の機能を把握することで、どの程度に自動化レベルを調整するか、そもそもどのようなものを提供すればよいかを考える上でとても参考になったため、検証自体は大変有意義でした。
ちなみに、テンプレート提供に cookiecutter を利用しているのは、あとから Backstage に統合することも考慮に入れての選択です。