開発者の認知負荷を軽減する「Platform Engineering」の基本と実践｜クラウドネイティブ技術の活用をより簡単にするソリューションとは？

1．クラウドネイティブ環境が内包する課題

クラウドネイティブ環境は、アプリケーション（以下、サービス）の開発と運用を効率化・自動化する技術の集合体です。それを使いこなすことで、開発チームは、ユーザーニーズやビジネス要求に適合したサービスを迅速にリリースし、運用していくことが可能になります。

ただし、クラウドネイティブ環境の活用を巡っては「活用難度の高さ」「認知負荷と学習コストの増大」という課題があります。以下、これらの課題について少し詳しく見ていきます。

活用難度の高さ

クラウドネイティブ環境は「コンテナ技術」をはじめ、多数のコンテナのデプロイ、スケーリング、ネットワーキングを自動化するオーケストレーションツール「Kubernetes」、継続的インテグレーションとデリバリーを実現する「CI/CDツール」、ITインフラの構成・設定をコードとして定義し、自動的にプロビジョニングする「IaC（Infrastructure as Code）ツール」などから構成されます。

これらのクラウドネイティブ技術は、サービス開発・運用の作業を効率化・自動化する仕組みです。開発チームが、開発と運用を一体化させた「DevOps」のプロセス（*1）を効率的に回せるようにすることを目的にしています。

ただし、クラウドネイティブ技術は、それぞれが独立して進化してきたために、統合的に活用するには専門的な知識、スキルが必要になります。

また、サービスに対するユーザーニーズやビジネス要求は絶えず変化し、開発チームはそうした変化への対応スピードを維持・向上させるべく、新たな技術やツールをどんどん取り入れていかなければなりません。結果として、技術スタックが複雑化し、統合活用の難度がさらに高まることになります。

加えていえば、クラウドネイティブ技術は、多くがオープンソースソフトウェア（OSS）、ないしはOSSをベースにした仕組みです。ゆえに、進化のスピードが非常に速く、更新が短いスパンで繰り返されます。そのため開発者は、新しい技術への学習を継続して行わなければならないのです。

*1 DevOpsプロセス：一般に「企画（プランニング）」「コーディング」「ビルド」「テスト」「リリース」「デプロイ」「運用（オペレート）」「監視／観測（モニタリング／オブザーブ）」といった一連のプロセスを指す。

認知負荷と学習コストの増大

この課題は、上述した活用難度の高さが生んだ問題です。

例えば、クラウドネイティブ環境での開発を始めるに当たっては、先に触れたCI/CDツールのほか、IDE（統合開発環境）やGitリポジトリ、脆弱性検査ツール、依存関係管理システム、テストケース管理ツール、テスト自動化環境などの導入、ならびにセットアップが必要になります。また、開発基準やコーディング規約の策定、開発フローの整備、各ツールのマニュアル作成なども求められます。

ゆえに、一人の開発者が覚えるべきツール、規約、手順の数が膨大となります。

さらに、個々の開発チームがそれぞれ独自の環境を構築している場合、チームごとに使用する技術やツール、コーディング規約が異なり、開発者が複数のプロジェクトに関わる際の学習の手間、コストが大きく膨らみます。結果として、規約違反や開発品質のバラつきといった問題が発生しやすくなります。

2．課題解決の一手「Platform Engineering」とは？

Platform Engineeringとは、クラウドネイティブ環境を活用する難度を引き下げ、開発者の認知負荷を減らすソリューションであり、アプローチ（取り組み）です。

このソリューションでは、開発に必要なツールや技術、ワークフロー、コーディング規約、ナレッジ、サンプルコードなどが標準化、抽象化され、特別な知識、スキルを習得することなく簡単に扱えるようにします。つまり、Platform Engineeringは、複雑な技術的要素を「セルフサービス型プラットフォーム」としてパッケージ化し、開発者が詳細を意識せずに利用できるようにするアプローチということです。

図1：Platform Engineeringのイメージ

ここでいうセルフサービス型プラットフォームとは、開発者、または開発チームが必要な環境を自らすぐに払い出せる仕組みを意味し、それを構築することがPlatform Engineeringの本質といえます。

このセルフサービス型プラットフォームの活用イメージを簡単にいえば「ポータル画面で数クリックするだけで、標準化されたCI/CDパイプラインや各種のツール、さらには、サービスのデプロイ先となるインフラなどを使い始められる」というものです。

例えば、開発者に対して「この手順書に従って開発のための環境を構築してください」と文書で指示しても、手順書の内容に対する解釈が人によって異なることがよくあります。また、手順書の更新が開発の実作業に追いつかず、間違った指示のもとで開発者に環境を構築させてしまうこともあります。

開発プロセスを標準化する取り組みは、かねてより行われてきました。ただし、これまでの取り組みは、基本的に「人依存」のものといえ、開発の実作業に対する「標準の適用度合い」は属人的でした。それゆえに、開発を管理（あるいは支援）する側のリソース不足から、標準への順守を徹底させるのが困難になることも間々ありました。

それに対してPlatform Engineeringでは、標準がシステムに組み込まれます。そのため開発者は、ルールの存在を特別に意識することなく、標準に準拠した開発が進められます。また、開発の実作業への標準の適用度合いが人によって異なり、開発の品質にバラつきが出るといった問題も解決されるのです。

3．Platform Engineering とDevOpsの関係とは

Platform Engineeringについては、ときおり「DevOpsに代わる新しい概念」と見なされることがあります。ただし、その見方は間違いで、Platform EngineeringはDevOpsの新たなトレンドに位置づけられます。

上で触れたように、クラウドネイティブ環境をそのまま使ってDevOpsを実践しようとすると、開発者は多数の知識を習得しなければならなくなり、かつ、DevOpsチームが増えるのに従って認知負荷が増大していきます。

Platform Engineeringを導入することで、そうした認知負荷を大きく減らすことが可能になります。

4．Platform Engineeringがもたらす効果

ここで、Platform Engineeringを導入する効果についてまとめておきましょう。その主な効果は以下の4点です。

①DevOps内製化の加速

Platform Engineeringを導入することで、一定の開発スキルや運用スキルがなければ実現できなかったDevOpsのワークフローを「仕組み化」することが可能になります。これにより、クラウドネイティブ環境を使ったサービスの開発と運用に精通していなくても、DevOpsを実践できるようになります。結果として、DevOpsの内製化が現実的な選択肢となり、サービスの開発、運用の両面で外部の協力会社への依存度を引き下げることが可能になります。

②サービス開発の効率化

Platform Engineeringを通じて、クラウドネイティブ環境を誰でも安全に、かつ簡単に利用できるようにすることで、これまでサービス開発の統制や学習にかけていた時間とコストを低減できます。これにより、新たなプロジェクトを立ち上げる時間が短縮されるほか、開発者は、サービスのビジネス価値を高める業務により多くの時間を割けるようになります。

また、開発チーム間でのナレッジの共有も促進され、開発組織全体の総合力も強化されます。例えば、Platform Engineeringを通じて、あるチームで培ったベストプラクティスを、セルフサービス型プラットフォームに組み込むことで、他のチームもその恩恵を受けられるようになるのです。

③セキュリティガバナンスの徹底

Platform Engineeringには、サービス開発におけるセキュリティ対策を機械的に徹底できるというメリットもあります。

例えば、Platform Engineeringで構築されたセルフサービス型プラットフォームでは「脆弱性のあるライブラリを使おうとすると自動的に警告が出る」「機密情報をコードに直接書き込もうとするとブロックされる」といった仕組みが組み込まれます。そのため、複雑なセキュリティルールを完全に理解していなくても、安全性の高いサービスを開発することが可能になります。

Platform Engineeringを通じて、サービス開発時におけるセキュリティ上のルール違反をリアルタイムでモニタリングできるようにもなります。これにより、開発組織全体においてセキュリティ上のルール、ポリシーが守られているかどうかが容易に把握できるようになり、各種の法律・規制に対するコンプライアンスを徹底するのも簡単になります。

④AI活用の最大化

Platform Engineeringでは、サービス開発・運用におけるさまざまなアクションやワークフローをコードで定義し、それらの実行結果をログとして出力します。

これらのコードやログをAIに読み込ませることで、DevOps全体のコンテキストを理解させることが可能です。これにより、AIの有効活用が促進され（AIに）「最適なデプロイのタイミングを提案させる」「異常を即座に検知させる」「パフォーマンス改善に向けたアイデアを出させる」といったことが実現されます。

5．Platform Engineering実現に必要な技術要素

Platform Engineeringでは、いくつかの技術要素を組み合わせて統合されたセルフサービス型プラットフォームを構築していきます。以下では、Platform Engineeringに必要とされる主な技術要素と、それぞれの役割について確認しておきます。

開発者ポータル

このポータルは、開発者がセルフで開発環境を払い出すためのフロントエンドアプリケーションです。ポータルには、開発に関するさまざまな「情報」「ツール」「リソース」「ワークフロー」が集約され、抽象化されたデザインのもとでDevOpsの各工程を自ら実行できるようになります。

なお、ポータルの機能は、GUIやCLI（コマンドラインインタフェース）、APIなど、さまざまな形式で提供されることが望ましく、開発者のスキルに応じて適切なインターフェースを選択できるようにすることが重要です。

CI/CDツールチェーン

この技術要素は、GitリポジトリやCI/CDツール、ビルド&テストツールなどから構成され、開発者ポータルを通して自動で払い出されます。

CI/CDツールチェーンは、開発者向けのツールチェーンとして機能するだけでなく、開発者ポータルのバックエンドとしてさまざまな管理機能を提供する役割も担います。また、このツールチェーンを通じて開発チームは、統一されたワークフローで開発を進めることができます。

IaC

IaCも、Platform Engineeringにおける重要な技術要素です。Platform Engineeringでは、その担当組織がIaCツールを使ってインフラ構築・変更用のテンプレートを作成し、提供します。そのテンプレートを開発者がポータルからセルフで利用し、インフラの詳細を意識することなく、標準化された適切な環境にサービスをデプロイすることができます。

セキュリティツール

ここでいうセキュリティツールとは、サービス開発の過程で脆弱性が混入してしまうのを防ぐ仕組みを指しています。その仕組みとしては、サービスやサービスのソースコード、IaCコード、コンテナイメージの脆弱性を診断するツールをはじめ、使用しているOSSに関して脆弱性やライセンス遵守の検査を行うツールや、ランタイム保護を実現するツールなどが挙げられます。

オブザーバビリティツール

オブザーバビリティツールは、システムを「観測が可能な状態」にする仕組み、つまりはシステムに「オブザーバビリティ（可観測性）」という属性を付与するためのツールのことです。同ツールを使うことで、システムを構成するサービスやインフラ（＝サービスの稼働環境）からログなどのデータを収集し、それぞれの状態をリアルタイムに可視化することができます。これにより、サービスの異常を早期にとらえ、原因を特定したり、サービスに潜在する性能上のボトルネック発見したりすることが可能になります。

6．Platform Engineering導入を成功に導く実践アプローチ

Platform Engineeringの技術要素を確認したところで、このエンジニアリングを成功させるためのポイントについて見ていきます。成功の主なポイントは以下の4つに分けることができます。

①開発者体験を重視したプラットフォーム設計

Platform Engineeringの大きな目的の1つは、開発者体験を向上させることです。

ゆえに、Platform Engineeringを始めるに際しては、開発チームが使用している技術やワークフローを分析し、どこに課題があるのか、どこに摩擦があるかを明確にしておくことが重要です。そして、分析結果から、Platform Engineeringに取り入れるべき技術や手法を特定し、併せて、あるべき開発ワークフローを策定するのが大切です。

また、プラットフォームの提供時には、まずはプロトタイプを開発者に使ってもらい、そこから得られたフィードバックを設計に反映させる必要もあります。このようにしてプラットフォームの改善を重ねていくことで、開発者に便利と感じてもらえる実用性の高い仕組みが構築できるからです。

②スモールスタートで段階的に拡張

Platform Engineeringでは「Minimum Viable Product（MVP：実用最小限の製品）」の考え方を採用することも成功への近道となります。つまり、当初はプラットフォームの機能を必要最小限のものに絞って提供し、その実効性や効果を見定めながら、段階的に機能の守備範囲を拡張していくのが良策ということです。

例えば、まずはCI/CDの標準化・抽象化から取り掛かり、のちにセキュリティ、テストといったかたちで標準化・自動化の範囲を広げていくと良いでしょう。それを通じて小さな成功を積み重ね、効果を実証しながら拡張していくアプローチが、Platform Engineeringによって開発したセルフサービス型プラットフォームの組織全体への浸透を促進します。

③「ゴールデンパス（推奨経路）」の提供

開発者が迷わず開発の作業（または、DevOpsの作業）が進められるようにすることも、Platform Engineeringの成功には欠かせません。そのための手段として有効なのが、標準的なユースケースに対する「ゴールデンパス（推奨経路）」を用意することです。

Platform Engineeringにおけるゴールデンパス（推奨経路）とは、理想的な開発ワークフローを反映させた各種のコードセットを指しています。そのコードセットには以下のようなものがあります。

• コードレポジトリ、CI/CD、コンテナといった各種環境の初期化/プロビジョニングのためのコードセット

• GitOps（2）やCIOps（3）の振る舞いを定義するパイプラインコード（Pipeline as Code）

• セキュリティポリシーをコード化したコードセット

• サービスのデプロイ先をプロビジョニングするIaCのコードセット

• 開発者が独力でサービスを開発できるようにするサンプルコード集

上記のようなコードセットを活用することで、開発者はセキュリティやガバナンス上のルールを守りながら、開発、あるいはDevOpsの作業を効率的に進められるようになります。とはいえ、既成のコードセットですべてのケースに対応できるわけではないため、カスタマイズの余地も残すことが大切です。

*2 GitOps：Gitリポジトリ内のコードでシステム全体を管理し、自動的にデプロイ・運用する手法のこと。

*3 CIOps：継続的インテグレーション（CI）主導のデプロイ手法のこと。

④開発の自由度とガバナンスの両立

開発においてセキュリティやガバナンスを徹底させることは大切ですが、それによって開発の自由度を低下させてはなりません。

そこで重要になるのは、開発の自由度とセキュリティのバランスのとれたワークフローを設計することです。

それを行ううえではプラットフォームのプロトタイプの提供を通じて「どこまでの自由を認めるべきか」「開発者に安心感を与える、セキュリティ上のルールを逸脱しないための仕組みとはどのようなものか」を検証し、適切なゴールデンパス（＝上で触れたセキュリティポリシーコード）を作ることが大切です。

まとめれば、開発者が「制約の中で窮屈に感じる」のではなく、「安心して開発に集中できる」と感じられる環境を目指すべきといえます。

ROIの明確化

Platform Engineeringの導入には一定の投資が必要になります。ゆえに、Platform Engineeringに着手するに当たっては、自社の経営陣をはじめとするステークホルダーによる支持・支援が必須となります。そうした支持・支援を獲得するうえでは、中長期的な開発効率の向上やリスク低減による効果を定量的に示すなど、ROI（投資対効果）の明確化が必要となります。

7．開発者が本来業務に集中できる環境づくりを

Platform Engineeringは、複雑なクラウドネイティブ環境における開発者の負担を低減し、より生産的な開発業務に集中できる時間を拡大する取り組みです。

この取り組みによってセルフサービス型プラットフォームを構築することで、個々の開発チームのみならず、開発組織全体の生産性を向上させることが可能になります。また、標準化されたワークフローとナレッジの共有により、組織全体の開発力がアップし、新たなイノベーションの土台も形成されます。

CTCでは、Kubernetesをベースにした業界スタンダード商用パッケージである「Red Hat OpenShift」や開発者ポータルを構築するためのプラットフォーム「Red Hat Developer Hub」を活用しながら、お客様のPlatform Engineeringをコンサルティングから運用に至るまでの一貫体制でサポートしています。お客様固有の技術ニーズにも柔軟に対応していますので、お気軽にお問い合わせください

図2：CTCが提供するPlatform Engineeringサポートサービスの概要