はじめに
皆さんこんにちは。エーピーコミュニケーションズ ACS事業部 亀崎です。
IT開発の歴史は、「スピード（開発）」と「安定（運用）」のジレンマを解決するための試行錯誤の歴史です。 一人の人間にすべてを強いる「フルスタックの限界」を超え、組織として効率を最大化するために Platform Engineeringは誕生しました。
従来のインフラや運用チームの役割ががそのままPlatform Engineeringと呼ばれているわけではありません。 時代にあわせた期待を担うために新しい用語として定義されています。
今回はあらためて、Platform Engineeringで期待されていることはなにか、その背景にはなにがあったのかを これまでの歴史を振り返りながら確認していきたいと思います。
歴史を知ればなぜPlatform Engineeringなのかがあらためて理解しやすくなると思います。
それでは見ていきましょう。
ITシステム開発の歴史
職能分離の時代（〜2000年代後半）
「開発と運用の分断（サイロ化）」
この時代は、組織を機能ごとに分ける「工場モデル」が主流でした。 開発チーム（Dev）がコードを書き、運用チーム（Ops）がサーバーにデプロイする完全な分業制という構造です。 ITシステムがソフトウェア開発、データベース設計・運用、インフラストラクチャ構築などそれぞれが 高度な専門知識を必要とするということもあり、専門家ごとの分業制はもっとも効率的なものと考えられました。
分業制の課題
しかしこの分業制では、開発と運用などのチームの間に物理的・心理的な壁があり、以下のような課題が存在します。
- チーム間のやり取りに時間がかかる : 情報の受け渡しが「チケット（依頼書）」ベースで行われるため、システム開発・運用のペースが遅くなる。
- 責任の分散と対立 : 「自分の環境では動いた」という開発と、「設定が悪い」という運用側、というように責任が複数に分散してしまうことにより、チーム間の対立が生まれやすい。
- ビジネスの停滞 : オンプレミスな環境ということもあり、サーバー1台の環境を用意するにも数週間～数か月かかり、市場の変化に対応できない。
DevOps時代の到来（2010年代前半～）
文化の変革とフルスタックへの期待
職能分離時代の課題である壁の存在を壊すため、「開発と運用を一体化させる」DevOpsという哲学が普及しました。
これにはクラウドの普及も後押ししました。従来は物理的サーバーを購入するといったオンプレミス環境構築が クラウドリソースにより仮想的なサーバーを短時間に用意するといったことが可能になったため、 システムインフラストラクチャ構築の時間を圧倒的に短縮することができるようになったためです。
インフラストラクチャ構築のうち、停滞の原因となっていた「購入」部分が短縮されたため、 分業による情報の受け渡しといった部分がビジネスの停滞要因としてクローズアップされるようになりました。 これが発端となり、情報の受け渡しを極力減らす、つまり「開発と運用を一体化させる」ことで、スピードをあげ より市場の変化に対応しやすい体制にすることが求められたのです。
DevOpsの核心は 「開発と運用を一体化させる」つまり "You build it, you run it" （作った者が運用もする）です。 DevOpsを実現可能とするために、CI/CDの自動化やIaC（Infrastructure as Code コードによるインフラ管理）が 登場します。これによるリリースサイクルが劇的に短縮しました。さらにクラウドネイティブ技術の登場もDevOpsの実現を 加速します。コンテナとコンテナオーケストレーション（Kubernetes）が登場し、Microserviceといった技術や 設計思想により、リリースサイクル短縮に寄与します。
しかし新たな課題も生まれます。それが 認知負荷の爆発 です。
- 開発者が「ビジネスロジック」以外に、従来分業制で他チームが担っていた セキュリティ、ネットワーク、インフラ構築のすべてを理解しなければならなくなり、 「フルスタックの限界」 に直面
- 開発者が理解・実現しなければならない項目が増加、結果として開発効率が低下し、エンジニアの燃え尽き症候群が深刻化
参考資料 :
SRE(Site Reliability Engineering)による実装（2010年代中盤～）
DevOpsが浸透していくなかで、GoogleがSRE（Site Reliability Engineering） を提唱します。 ここでDevOpsという抽象的な概念を具体的な「エンジニアリング手法」へと昇華させました。
- エラー予算（Error Budget）という数値に基づき、リリース速度と安定性のトレードオフを論理的に判断する
- Toil（苦労）となっている繰り返し作業を自動化し、運用の半分を「ソフトウェア開発」に充てる
これにより、リリース速度と安定性という対立も解消するようになります。 しかし、まだ十分ではありませんでした。取り組んでいる内容の通り、SREは「システムの信頼性」向上に寄与しますが、 開発者が使うツールの使い勝手の向上といった 開発者体験 を改善する役割までは担えません。
Platform Engineeringの台頭 （2020年代～）
DevOpsで目指していた「スピード」と「安定」双方の向上は、ビジネス上の課題解決でもあります。 クラウドの登場でより高速化している現代において、以前の「分業制」に戻すわけにはいきません。 DevOpsの理想である「すべて自分たちでやる」という思想を維持しつつ、開発者の負担（認知負荷）を最小化するために 生まれたのがPlatform Engineeringです。
開発者のためのPlatformを整え、以下のような方法でDevOpsで発生した 開発者の認知負荷の爆発 を解消します。
- 複雑なインフラを抽象化し、「Golden Path」と呼ばれる標準的な開発ルートを提供
- 開発者が欲しいリソース（DB、サーバー等）を、誰にも頼まずに（ボタン一つで）入手できる自動販売機のような、Internal Developer Platform（内部開発者プラットフォーム）という仕組みを構築
- ポリシーやセキュリティをPlatform側で担保することで、開発者が「壊す心配」をせずに高速開発ができる環境（ガードレール）を実現
そして、Platform Engineeringの大きな特徴である点が 「Platform as a Product（プラットフォームをプロダクトとして捉える）」という視点です。 開発者を「顧客」と見なし、彼らのフィードバックを受けてプラットフォームを改善し続ける姿勢により、 開発者が本当に必要とするものを提供できるようにします。
参考資料:
専門性の再定義
ここまで見てきたように、Platform Engineeringへの進化は 「一人のスーパーマン（フルスタック）に頼るのではなく、組織としてのプロダクト開発体験をエンジニアリングで解決する」 という成熟したアプローチへの到達です。
これを実現するため、エンジニアリング組織は以下のような専門性で構造化するのが最適と考えられています。
- ビジネス開発 : 事業上のユーザー価値の創出に集中
- Platform : 開発者が迷わず・楽に・安全に開発できる「道」を作る
- SRE: 基盤となるインフラの信頼性を保証する
今わたしたちはこの段階にいます。しかし、これがゴールではありません。こうした継続的な改善や変革の中で新たな課題も 生まれてきています。
さらに、AIおよびAI駆動開発の登場で、Platform Engineeringの領域も劇的に変化しています。 もしかすると今度は Platformを担当している皆さんが 認知負荷の爆発 を感じているのかもしれません。 きっとさまざまな悩みを抱えていらっしゃると思います。
私たちは Platform Engineering領域の最新の情報や事例を踏まえながら、最新のPlatform Engineeringの 実践ができるようご支援をさせていただいております。 Platform Engineeringの領域は答えは1つではありません。みなさんの状況に合わせた形でご支援をさせていただきます。
これからPlatform Engineeringを始めようとお考えの組織、 または始めたところで 認知負荷の爆発 に苦慮しているという組織、 AIとPlatform Engineeringをどう関連付けていけばいいか悩んでいるという組織 の皆さん、ぜひ弊社にご相談ください。
