はじめに

この記事は、Platform Engineering Advent Calendar 2023 の23日目の記事です。

「Part1 ー組織の各フェーズにおけるPlatform Engineeringの役割とは」の後編となります。

Part 1では、Team Topologies^1を引用し、組織の各フェーズにおけるPlatform Engineeringの役割について整理しました。後編では、スタートアップである弊社でPlatform Engineeringとしてどのような取り組みを行なっているのかについて紹介したいと思います。

Cloudbaseで取り組んでいること

弊社では、HashicorpのSix Pillars of Platform Engineering やDevOpsの書籍^2 ^3などを参考に、Platform Engineeringの柱として次の5つを軸に活動内容を整理しています。

Delivery
Security
Testing
Reliability
Observability

5つの柱の概要と、それぞれについて現在取り組んでいること・今後やっていきたいことの中からいくつかをピックアップして紹介したいと思います。一部の項目は複数の柱にまたがる内容も含みますが、いずれか1つに含めています。

これらはエンジニアリング組織全体として持つべきケイパビリティであり、各開発チームが自律的に実践していくべき内容となっています。プラットフォームチームの役割としては、各領域での最終的なオーナーシップは各チームに持たせつつ、専門知識・集合知を1つのインターフェースとして凝縮して提供することが期待されます。特にスタートアップのフェーズでは、プラットフォームを提供するに留まらずイネーブルメント的にチームに入っていくなど「使える手を全部使って」開発者の認知負荷を下げにいくことが求められるでしょう。

Delivery

開発したソフトウェアを本番環境にリリースするまでのプロセス全体の効率化を目指す柱です。この開発のパイプラインはエンジニアリング組織の価値のストリームそのものであり、CI/CD環境や機能のリリースに関わる手順の効率化はダイレクトにストリームの加速に寄与する他、Four Keysのようなパイプラインに関する指標はPlatform Engineering全体の有効性を判定する上で重要な手がかりとなります。

取り組んでいること

Feature Flagソリューションの導入
- DevOpsハンドブック^2でも言及されているように、Feature Flagはデプロイとリリースを切り離し、トランクベースな開発と本番環境での積極的な実験を促進する有用なプラクティスの一つです。弊社ではStatsigというSaaSソリューションを導入してこれを実現し、開発者が利用するための軽量なラッパーと利用ガイドラインを整備しています。
Github Copilotの全社導入
- プラットフォーム？という感じですが、開発者の生産性向上に直結すると考えて全社的に導入しています。プラットフォームチームの仕事としては利用ガイドの作成やベストプラクティスの共有などが含まれます。
CI/CDパイプラインの設計支援・サポート
terraformの共通モジュールの整備

今後やっていきたいこと

Security

近年DevSecOpsというキーワードが注目されているように、テストやオブザーバビリティと同様セキュリティについても専門チームに任せきりにするのではなく開発チームが責任を持って担保すべき品質として捉える考え方が主流となりつつあります。専門性の要求されるこの分野もセキュリティチームの知見をいかにプラットフォームに落とし込めるかが勝負となります。そしてそれは、まさにCloudbaseが事業として取り組んでいることです。

取り組んでいること

Cloudbaseのドッグフーディング運用
- 弊社が提供しているプロダクトも、知見を集約し開発者の認知負荷を下げるプラットフォームの1つと言えます。社内で実際に運用を回すことでプロダクトの改善に繋げるとともに、プラットフォームの一部として活用することで開発の生産性向上に繋げたいと思っています。
本番環境の一時的な権限付与の仕組み
- 権限最小化 (Least Priviledge) の実践の一つで、本番環境侵害のリスクを最小限に抑えるために、開発者に恒常的な権限を付与せず障害対応時など必要なタイミングに限ってオンデマンドで一時的な権限を払い出す仕組みです。メルカリさんの事例がとても参考になります。
Row Level Securityの導入支援

今後やっていきたいこと

Cloudbaseの機能拡充！！
- 自分たちで自社のプロダクトを運用していくことで、プロダクトの価値が上がるにつれて社内の開発体制も強化され、開発体制強化によりプロダクト開発が加速する、という正のフィードバックループを目指します。
DevSecOps
- セキュリティをテストと同様開発チームの責務として取り組み、その検査を開発フローの全ての段階に組み込んでいこうというDevSecOps・シフトレフトという考え方が注目を集めており、今後取り組んでいきたいと思っている領域の一つです。ローカルでのコミット時に機密情報が含まれていないかをチェックするツールや、CIプロセスにパッケージ構成解析・脆弱性解析・コンテナスキャンなどの検査を組み込むなどのプラクティスが挙げられます。

Testing

ソフトウェアの品質（外部品質としての機能適合性・内部品質としてのテスタビリティ）も開発チームが責任を持つべき領域ですが、有用なテストツールを提供したりチームの知見やベストプラクティスを共有することで開発チームを支援することができます。特に、LLMの活用によって今後大幅な効率化・自動化が期待される領域の1つであり、集合知としてのプラットフォームの役割が大きくなってくる...かもしれません。

やっていること

開発者用検証環境の構築（Lab環境）
- トランクベースな開発を促進するために、開発者が各ブランチの内容をデプロイして検証できる環境を開発者ごとに用意しています。インフラごと環境数分用意する簡易な実装となっているので、今後人数が増えてもスケールするようにするためにはより洗練された仕組みが必要になりそうです。
状態宣言型のDBテストツール
- Wantedlyさんで紹介されている事例に近いような形で、テストに用いるテーブルの状態を宣言的に記述できるようにすることでテストの可読性を高めるツールを開発者に提供しています。機会があれば別の記事で紹介したいです。

今後やりたいこと

テストデータ管理
- 古いテストのデータを最新の仕様に追従させるのにメンテコストがかかることが多く、特に本番環境のDBに入っているデータとテストで仮定しているデータに差異があると本番環境でしか発生しないバグを引き起こす可能性があり、危険です。また、セキュリティスキャンを行うコンポーネントではクラウドのAPIで取得したデータに対してテストを行う必要があるため、テスト環境のデータで挙動を網羅しきることが難しいです。このようなテストデータ管理の課題をうまく解決できれば、ソフトウェアの保守性・テストの効率性に大きく寄与すると考えられます。
カバレッジの計測・可視化
- Deliveryの指標と同様、テストカバレッジの状況を可視化することは開発者にフィードバックを与えて自律的な改善を促すレバレッジの高い施策の一つだと考えています。
テスト自動化ツールの導入（Autify/Mablなど）
負荷テスト基盤

Reliability

SRE (Site Reliablity Engineering) や CRE (Customer Reliability Engineering) に関係する、サービスの信頼性を守っていくための柱です。Testingよりも本番環境での品質、運用に焦点を当てています。

取り組んでいること

SREプラクティスの実践支援
- SREのプラクティスとして挙げられるSLOの運用、Production Readiness Check、ポストモーテムなどの導入を主導し、各チームの実践を支援しています。ただし、メンバーの経験不足もあり十分に機能する形で運用できていないのが現状です。
オンコール体制の整備
定期的なデータの整合性チェック基盤

今後やっていきたいこと

SLO・アラートハンドリングの運用強化
- エラーバジェットがなくなった時のアクションを明確に定義する、基準・ステップの明確なインシデント宣言フローを定義して各チームで実践されるよう支援していくというプロセスも含めた品質向上を目指していきたいと考えています。
サポートリードタイムの計測
- サポートについてもDeliveryと同様に計測を行い、改善していくための準備を整えていきます。
問い合わせの半自動化・効率化
- こちらも集合知を活用したLLMによる効率化が見込めそうな領域です。

Observability

オブザーバビリティとは「システムの分解能」とも呼べるシステム特性を表す言葉で、DevOpsやPlatform Engineeringと同様近年注目を集めている比較的新しい技術動向の一つです。SLOのようなモニタリングと比較して、「本番環境で何かが起こった時に原因を掘り下げて究明できるツールが揃っていること」に焦点を当てています。
Observability Engineering^4で述べられているように、エンジニア組織全体のプラクティスとしてテスト同様継続的に実践していくことが重要であり、プラットフォームチームがツールを通してその支援を行うことができます。

取り組んでいること

Datadogの導入
- オブザーバビリティツールとしてDatadogを導入し、全社的に活用を進めています。LTなどで一部の取り組みを紹介しているのでよろしければぜひご覧ください。Error Tracking for Logsを用いたバッチ処理のエラー監視
Quicksightを用いたユーザーデータの分析
Client Logging
- クライアント側のアプリケーションで発生したイベントを網羅的に計測できるようにすることもオブザーバビリティの実践の一環になります。長期的には他のデータソースと組み合わせてユーザーの行動についての分析を社内の様々なステークホルダー（開発者・プロダクトマネージャー・CS・経営者）が簡単に行えるようなデータ分析基盤も必要になってくるでしょう。

今後やっていきたいこと

オブザーバビリティの浸透
- オブザーバビリティが各開発チームで継続的に実践されていくためには、テストと同様にそれが開発の一部であるという意識・文化を組織内で醸成することが重要です。ツールの提供やサンプルプロジェクトを用意するなどの取り組みとともに、勉強会等を通して社内の共通言語・認識を作っていくことが大事になると思っています。
OpenTelemetryの導入
- オープンソースのオブザーバビリティフレームワークとしてますます注目を集めているOpenTelemetry では、言語ごとに基本的なテレメトリーを収集してくれる自動計装がサポートされています。このように初期コストを必要とせず気軽に計装を始められるプラットフォームは、オブザーバビリティの文化をチームに根付かせる上で大きな役割を果たすはずです。
メトリクス等の命名規則の整備

まとめ

今後課題や状況に合わせて柔軟に組み換えていくことは前提としながら、現在Cloudbaseではこれらの方向性で各種開発基盤の整備を進めていこうと考えています。

これらの5つの柱は開発を加速させるものであると同時に、ソフトウェアの品質を支える土台となるものです。特に急激な組織拡大が求められるグロース期には、これらの土台に投資しておくことが開発を前に進める上で多くの障害を取り除く助けになると考えています。

最後に

Platform Engineeringというとどうしても使用している技術やその仕組みに注目されがちですが、今回見てきたようにその本質は顧客志向を土台とする考え方であると思っており、開発チームが「お客様との表面積を最大化する」取り組みとも言えると思います。そしてだからこそ、お客様と真摯に向き合い続けることがミッションクリティカルな命題であるスタートアップにおいて、Platform Engineeringが大きな価値を発揮すると考えています。

まだまだ普及途上なPlaform Engineeringですが、今後スタートアップなど多様なフェーズの組織での活用事例がたくさん出てきたらいいなと思っています。この記事がその盛り上がりの一助となれば幸いです。

最後に少しだけ宣伝

Cloudbaseでは今回紹介したような取り組みを共に前に進めるソフトウェアエンジニアを全力採用中です！
少しでも興味を持って頂けた方はぜひ下のページからの応募や、@ryuke までお気軽にご連絡をお願いします！！