クラウドによって素早い開発と運用が可能になり、CI/CD・DevOps・SRE などの考え方が普及してきました。しかし同時にクラウドの機能や設定も複雑になってきた結果、開発チームの認知的負荷が上昇してきたのも事実です。プラットフォームエンジニアリングは、このような状態において開発チームが本来の力を発揮できるように優れた開発体験を提供し、パフォーマンスを向上させるための考え方と言えます。
クラウド普及と進化により開発チームに何が起きたのか
現在、多くの企業にクラウドが広く普及し、DevOps 体制での開発もどんどんと浸透してきています。私たちの事例でも紹介しているように、IT 基盤にクラウドを取り入れ、内製化に乗り出す企業が年々増えてきています。
しかし、その一方でビジネス課題や市場のニーズも以前より複雑多様化し、それに伴い技術トレンドについてもどんどんと高度化・複雑化が進んでいます。初めて AWS のサイトにアクセスすると、数多くのサービスが存在することに、驚いた方も多いでしょう。
せっかく定義した標準的な技術やプラクティスは陳腐化しやすく、クラウドの進化により開発手法も年々多様化しています。以前のように一筋で統制を行なったり、標準定義した技術の利用を開発チームに強制またはルール化することも現実的ではなくなっています。
さらに、迅速にプロダクトをリリースして価値を検証するプロダクト開発において重要なポイントであった、ワンストップでビルド・テスト・デプロイして運用もしていくスタイルでは、やるべき設定とそれに関連する知識の量に圧倒されてしまうことも少なくありません。開発・環境構築・品質管理・運用監視・セキュリティなど日々複雑化していく周辺環境のなか、このような領域全般に纏わる知識と経験を持つ人材は非常に限られています。
このように、昨今のアプリ開発チームは迅速なリリースサイクルを持つプロダクト開発を継続して行うことが、クラウド台頭初期に比べて難しくなってきています。開発スピード向上やコスト削減を期待して導入したクラウドが、普及高度化したことによって、かえって開発チームの負荷を高めることになってしまっています。
古くて新しいプラットフォームエンジニアリング
従来のインフラ業務の考え方としては、どちらかと言えば安定的な運用であったり、インシデントの抑制であったりがミッションとなることが多く、素早く使いたいとか、最新かつ多様な技術を取り入れたいといった開発チームとは必ずしも利害が一致しないケースもあるかと思います。
このような問題に立ち向かうべく、私たちもこれまでお客様から様々な要望を受け、行ってきたものです。例えば、以下のような作業をイメージしてみてください。
- API 仕様ドキュメント作成の自動化とホスティング
- 統合テスト・E2Eテストのためのツール選定と構築
- 環境構築を行うための IaC コード作成およびテンプレート化
- テスト・ビルド・デプロイ作業自動化のための CI/CD パイプライン構築
- リリース判定の項目策定とリリース判定を行うための会議体・ワークフローを定義
- マイクロサービス構成におけるユーザー認証・認可基盤、ログ収集基盤の構築運用
- 運用・監視設計、オブザーバービリティの確保
- 企業のセキュリティガイドラインに沿ったチェックリスト作成、脆弱性スクリーニング導入、脆弱性検査の実施
- 各種システムマニュアルおよびリンク集を含む、社内ITポータルの構築運用
- その他組織全体における各種技術の標準化への取り組み
このような個別の作業や技術はもうすでに存在していて、多くのエンジニアが実際に行ってきていることです。ただし前項でもお伝えしたように、現状これらの全ての領域において、良いパフォーマンスや成果を出すことは至難の業です。中には、認証認可やログ収集のようなアプリ開発の領域であるものの、開発者からすれば力を入れすぎたくような、差別化が図りにくい領域も存在します。
ここで、クラウドを導入されている企業では組織横断的に利用できる開発基盤を構築し、各業務や技術要素を共通化し、再利用できる形でカタログ化を図るといった対応をされる企業も増えてきました。
開発基盤とプラットフォームの違い
似たようで異なるニュアンスで語られることが多いトピックになるかと思いますが、プラットフォームのポイントとしては「Platform-as-a-product」と捉えることです。具体的には、プラットフォームを利用する開発者にとって認知・作業負荷が軽減され、快適な開発経験が与えられる仕組みを提供することです。共通開発基盤でもこれらの観点は取り入れられますが、トップダウン型で制約がかかるような環境の利用を推進する形ではなく、開発者が需要に応じて複数の選択肢の中から必要なもの・欲しいものを選んで利用できるようにすることがプラットフォームエンジニアリングの特徴なります。
とはいっても、現実ではある程度管理を行う必要が出てくることも事実です。企業コンプライアンスやセキュリティ要件を、可能な限り開発経験を損なわずに行える施策とサービスとして提供できれば、プラットフォームの積極的な利用に繋がります。
ただし、プラットフォームが提供する機能を、開発者が必ず利用するということではないため、共通化や統制の意味では共通基盤と比べて効果は薄れてしまいます。プラットフォームエンジニアリングでは、IDP（Internal Developer Platform）という内部開発者ポータルを展開し、「セルフサービス形」で利用できるようにすることが謳われています。せっかく投資をしてプラットフォームを構築しても、あまり利用されなかったり、投入したコストを回収できるほどの効果があるとも限らないので、その点どのような目標とスタンスで取り組むか、狙いを定める必要があります。
大規模で継続的な開発を行う組織のIT部門にこそ必要
プラットフォームエンジニアリングの取り組みは、実は多くの企業でニーズがあり、私たちも実際に構築を支援してきました。
例えば、AWS Security Hub における適用項目を、企業のセキュリティガイドラインに沿って設定し、用途別にカタログ化。それを Terraform で管理し、展開できる仕組みを構築したケースがあります。
また、外部サービスとの契約が不要で、自前で簡単に構築できるタイプの使いやすいドキュメント管理ツールを社内に展開、最新トレンドを反映したフレームワークの見本とテンプレートを IaC 含めコード化し、カタログを用意しリポジトリで管理。クラウド環境構築だけでなく、エンジニアの端末にセットアップする開発ツールも、インストールが不要なポータブルバージョンのカタログ化を行っています。
しかし、コードや開発手法だけがプラットフォームの構成要素ではありません。リリース周期を短縮しながらも仕組みで品質を保つワークフローとツールを提供することは IT 部門が強みを持つ領域です。
特に過去様々な共通基盤構築と管理業務の経験がある IT 部門は、開発者が見落としがちな部分やインシデントを未然に防ぎ、プラットフォームをより安心して頼れるようにするための知識とノウハウを持っています。開発チームと異なるベクトルに向くのではなく、同じ方向を見て補完し合う構造が取れることで、コストセンターから、プラットフォーム構築で専門性を発揮する組織へ変革し、新たな付加価値を生み出すことに繋がります。
最も大事なのは、価値創出の実体験と信頼形成
方法論は様々ありますが、何より大事なのはプラットフォームを積極的に利用してもらうことと、それによって開発チームの課題が解決され、開発経験が向上してビジネスで成果を出すことです。そのためにはプラットフォームが提供するサービスの「使いやすさ」「時間／コスト効率の良さ」も当然必要ですが、何より開発チームが抱えている課題や負荷と真摯に向き合い、解消した実体験を開発チームと共有することが重要だと考えています。
一緒に課題を解決した共有感は信頼関係となり、その信頼関係に基づいて、開発チームと同じベクトルを向いて成果を作り出すことが本質であると考えます。
この記事に関する内容またはプラットフォームエンジニアリングの具体的なプラクティス、運用について詳細が気になる場合は、是非お気軽にお問い合わせください。