はじめに
はじめまして。NTT DATAの金融分野で基盤なんでも屋さんをやってる杉野です。
突然ですが皆さん「プラットフォームエンジニアリング」という言葉を耳にしたことはありますか？
私も少し前に耳にしたばかりですが、調べて見たところ考え方や思想は共感する点も多く
調べてみた内容を共有し、最終的には実際の開発現場での実践結果まで皆さんに共有できたらと思います。
プラットフォームエンジニアリングとは
一部ですが検索すると以下のように色々な企業やITメディアで解説するページが存在しており非常に注目度が高いことが読み取れます。
・Gartner社
プラットフォーム・エンジニアリングとは、ソフトウェアの開発とデリバリを目的とした、セルフサービス型の開発者プラットフォームの構築と運用に関する専門分野です。
・Microsoft社
プラットフォーム エンジニアリングは、安全で管理されたフレームワーク内の改善された開発者エクスペリエンスとセルフサービスを通じて、各開発チームのセキュリティ、コンプライアンス、コスト、およびビジネス化までの時間に関する価値を向上させることを目的として、DevOps 原則から構築されたプラクティスです。 製品ベースの考え方のシフトと、それをサポートするための一連のツールやシステムの両方です。
はい。ちょっといきなり長い文章は頭に入りづらいですね..
AIに聞いてみよう
もう今や新しいことを調べるときはAIにも聞くのが当たり前の世の中になりましたね。
2年ほど前に某所で生成AIを学んでいた時はハルシネーションが多く見られ、まだまだ世の中に普及しないよな～と思っていたのですが本当に恐ろしい速度です。
■質問内容
プラットフォームエンジニアリングを簡単に説明して。
・Gemini
社内のソフトウェア開発者が楽に、そして素早く開発できるようにするための専門チームとその活動
・ChatGPT
開発者が効率よくソフトウェアを開発・運用できるように、共通のインフラやツールを整備・提供する仕事や取り組み
なるほど。つまり
「共通のプラットフォームを使って開発者の開発体験を向上させようぜ！」
って考え方ですね。
知人にこの話をした時に、なんかDevOpsやアジャイルもそんな感じの話してなかったっけ？何が違うんだっけ？と話があがったのですが、それぞれの手法に触れる機会が少ないと全部似てるように感じますよね。
アジャイル開発は「顧客価値の最大化」が目的でチームやプロセスを対象として開発の効率化を目指します。
どちらもアジリティを高めるといった点では共通しているのですが、プロセスに焦点を当てるのがアジャイルで、開発者が実際に利用するツールや環境に焦点を当てているのがプラットフォームエンジニアリングと理解しています。
DevOpsは考え方や文化そのもので、開発と運用のサイクルを迅速かつ効率的にするという目的は同じですが、プラットフォームエンジニアリングはDevOpsといったお題目を理想に近づけるための道具といったイメージと自分は認識しています。
なぜ注目を集めたのか
この考え方自体は一部の企業では存在していたらしいのですが、トレンドの火付け役となったのはGartner社です。
2022年に発表したハイプサイクル（新規イノベーション技術が市場に登場してからの期待度の移り変わりを時系列で表現）にプラットフォームエンジニアリングを選出したことで広く知れ渡るようになったようです。
この時の予測ではプラットフォームエンジニアリングが主流になるまで2～5年と定義され一気に注目を集めました。
ちなみにこの2022年のハイプサイクルでは機械学習コード生成やジェネレーティブ・デザインAIにも言及されているのですが、主流の採用には5～10年と定義されており
いかにここ最近の生成AIに関する技術の進展が早いのかを読み取ることができ興味深いです。
Gartner社のハイプサイクルは毎年秋ごろにかけて公開されているので、興味のある方は毎年チェックをおススメします。
（先日2025年版も出ており、ついにプラットフォームエンジニアリングは幻滅期に突入しました）
日本におけるクラウドとAIのハイプ・サイクル：2025年
プラットフォームエンジニアリングが登場した背景
簡潔に言うと「考えることが多すぎる！開発に集中させてくれ！」って感じですね。
時系列としてはざっくり以下の流れと理解しています。
（長いので興味のない方は割愛推奨）
・クラウドの多機能化
今や開発現場では無くてはならないくらいに市民権を得たクラウドですが
非常に便利である一方で、あまりに進化の速度が速くかつ複雑化しており学習コストが重くのしかかっています。
私が経験したのはある開発案件で「今このサービスはないし代替機能作るか～」と設計・製造し、テストしているとほぼ同一機能（むしろ上位互換）がリリースされていたなんてことも..
最近では性能やセキュリティといった要素も加わり、選択も非常に困難になってきたと感じます。
「このアプリケーションの実行環境としてEC2、ECS、Lambdaどれが適切ですが？」と問われて即座に回答ができる人はそこまで多くないのではと認識しています。
・マイクロサービスアーキテクチャの促進
昔は開発者は全ての機能が一つの巨大なアプリケーション（モノリス）開発にのみ集中していればよかったのですが、今やどこもマイクロサービスを採用する開発が多いですよね。
このマイクロサービスは開発速度の向上や拡張性に非常に大きく寄与しましたが
開発者にとっては自分が担当するサービスだけなく多数のサービス間の連携や通信を考慮する必要が出てきました。
また、分割されたサービスの数も膨大となり管理コストも急増しました。
・Dev/Ops技術の発展
マイクロサービスが普及するに伴い、「どうやってその分割したサービスたちを効率的にデプロイ・管理するのか」といった課題が生じました。
その解決策として生まれたのがDocker、Kubernetesといったコンテナ技術やインフラ構成の自動化といったDev/Ops（ここでは開発と運用の意）技術です。
この技術は新たなカテゴリが生まれるだけでなく、既存技術は日々高度化していくといった状態で
開発者は考慮すべき内容が増大し続けています。
これらの経緯を経て、開発者の求められる姿が「アプリケーションを開発する人」から「アプリケーション開発全般（リリースやインフラ含む）ができる人」に変化したわけですが
これで「アプリケーションの開発に集中する」は実際無理がありますよね？
人には何かを理解したり、問題を解決する際に脳に精神的な負荷がかかります。
そのことを「認知負荷」と呼ぶのですが、その認知負荷が高くなって開発者が開発に集中できないという状況が最近の開発者が置かれた状況だったわけです。
どうやって開発に集中できるようにする？
目的は背景の真逆で、「開発者がアプリケーション開発に集中できるようにすること」ですね。
じゃあどうやって開発に集中できるようにするかというと
開発者共通のプラットフォームを整備しようとなるわけです。
開発者みんながアクセスできるポータルサイトからボタン一つでAPIや接続環境の対向先を簡単に変えたり、新規開発用の環境が払い出されたり、自動でエラーログが取得されたりするとめちゃくちゃ開発楽になるなぁって思いませんか？
（これでインフラチームとの煩雑なやり取りやチーム間調整の負担が軽減されます）
CNCFというクラウド技術を推進する非営利団体が「CNCF Platforms White Paper」にて
プラットフォームエンジニアリングについて非常に分かりやすくまとめてくれています。
中でも共通プラットフォームの成功に影響を与える要素として以下が言及されており、非常に参考になります。
| プラットフォームの成功に影響を与える要素 |
|---|
| 1.プラットフォームを「プロダクト」として扱う |
| プラットフォームエンジニアリングの根源的な思想です。 開発者がアプリケーションに集中できるように設計し、進化させることでプラットフォームの価値を最大化させる必要があると定義されています。 ここで重要なのが最も一般的なユースケースを提供するというところでしょうか。 実際のアプリケーション開発あるあるですが、特定のニーズに合わせた機能が汎用性に欠け、結果的に利用されないケースは避けましょうということですね。 |
| 2.ユーザ体験 |
| GUI、API、コマンドラインツール、IDE、ポータルなど、一貫性があって使いやすいインターフェスを提供し優れたユーザ体験とすることと定義されています。 |
| 3.ゴールデンパスの整備 |
| ユーザが簡単にプラットフォームを利用できるようにゴールデンパス（推奨される標準的な手順）を揃えようと定義されています。 |
| 4.セルフサービス |
| ユーザが自律的に自動で使えるようにしましょうということですね。 例えばアプリケーション開発していて「開発用の環境がもう1つ欲しいな～」って時ありますよね？ こんな時に別チーム（もしくは作れそうな人）に依頼して、スケジュール調整して..といった一連の流れが今は当たり前って開発現場が多いと思いますが、プラットフォーム上からボタン1つで作れるようになったら便利ですよね。 |
| 5.ユーザの認知負荷の削減 |
| プラットフォームの実装の詳細は利用者（開発者）にわからないようにして、アプリケーション開発に集中できるようにしましょうと定義されています。 |
| 6.プラットフォームを使うかどうかは開発者次第 |
| プラットフォームでは開発者は必要だと思った部分だけ利用できるべき、独自ツールと組み合わせることも許容しましょうと定義されています。 |
| 7.セキュアにしましょう |
| こちらはまぁそりゃそうだよね、ということで割愛します。 |
プラットフォームチームの役割
プラットフォームチームは開発者がアプリケーション開発に集中できるようなプラットフォームの構築・運用を専門で行います。
チームが意識すべきことは「開発者（ユーザ）の意見を取り入れながら、プラットフォーム改善のサイクルを回し続ける」という点でしょうか。
プラットフォームって本当に必要？
ここまですごく共感する内容も多かった一方で、個人的に思ったのは「これ、小規模でうまく開発が回っている案件・企業で導入したとき費用対効果低くない？」ですね。
私が小規模案件のPMの立場として正直コストを掛けて開発者共通のプラットフォームを導入するか、と言われたら難しいよなぁ〜ってのが正直なところです。
なので、小規模案件はIaC化やテンプレート（ゴールデンパス）の整備といったプラットフォームエンジニアリングの思想を引き継ぎつつ将来拡張が必要になったときに備えるという動きで良いのでは？と個人的には考えています。
次回プラットフォームエンジニアリング実践編へ
ここまでは私が調べたプラットフォームエンジニアリングを連携させて頂きましたが
結局皆さんが気になるのは「じゃあ、実際どうやる？どうだった？」ですよね。
長くなってきたので一旦終わらせていただきますが、次回「プラットフォームエンジニアリング実際にやってみた（仮）」でお会いしましょう。
NTT DATA公式アカウントです。 技術を愛するNTT DATAの技術者が、気軽に楽しく発信していきます。 当社のサービスなどについてのお問い合わせは、 お問い合わせフォーム nttdata.com/jp/ja/contact-us/ へお願いします。