LASSIC Media らしくメディア
プラットフォームエンジニア不足の補完
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- プラットフォームエンジニアとSREエンジニアは役割が異なり、担う対象を混同すると採用・委託の判断を誤ります。
- 専任のプラットフォームエンジニアが社内で不足しやすい背景には、必要スキルの広さと採用市場の未成熟さがあります。
- 外部支援・委託で補完する際は、内製化する範囲と委託する範囲の線引きが成果を左右します。
目次
プラットフォームエンジニアとは何か
プラットフォームエンジニアとは、社内の開発者が使う共通基盤（IDP＝Internal Developer Platform、社内開発者向けプラットフォーム）を設計・運用し、開発者がセルフサービスでビルド・テスト・デプロイを完結できる状態を作る専門職を指します。CNCF（Cloud Native Computing Foundation、クラウドネイティブ技術の標準化を進める非営利団体）は、プラットフォームエンジニアリングを「開発者チーム向けのセルフサービスを提供するソフトウェア開発基盤を構築・維持する専門領域」と説明しています*1。
この基盤はCI/CDパイプライン・監視ツール・セキュリティゲート・環境払い出しなどを一元化した「開発者のコックピット」に例えられ、開発者がインフラの詳細を意識せずに使える設計が前提になります。単なるインフラ担当者ではなく、開発者を利用者と捉えたプロダクト志向の役割である点が特徴です。
開発者体験とセルフサービス基盤が中心テーマ
プラットフォームエンジニアの仕事の中心は、開発者体験（DevEx、開発者が日々の作業で感じる使いやすさや生産性の実感）の向上です。CNCFは、開発者がインフラ・Kubernetes・CI/CDパイプライン・セキュリティを個別に理解しなければならない負担を「認知負荷」と位置づけ、これをプラットフォームが吸収する構造を提示しています*1。
この考え方の理論的な土台には、組織設計フレームワークTeam Topologies（チームトポロジー）があります。同フレームワークは、プラットフォームチームの役割を「ストリーム整合チーム（機能開発を担うチーム）の認知負荷を下げる内部サービス提供者」と定義しています*2。各開発チームが個別にデプロイパイプラインや認証基盤を作るのではなく、共通のセルフサービス機能として提供する発想がゴールデンパス（推奨され自動化された開発・デプロイの標準ルート）につながります。
Google CloudのDORA（DevOps Research and Assessment）チームが公表する2024年版Accelerate State of DevOps Reportでも、内部開発プラットフォームは開発者の生産性を効果的に高める一方、成熟前の導入初期には一時的な生産性低下が起こり得ると報告されています*3。基盤の整備は一朝一夕には進まず、継続的な改善体制が前提になる点は法人の投資判断でも押さえておくべきです。
専任人材が社内で不足しやすい理由
プラットフォームエンジニアという職種は、比較的新しい概念であるため採用市場に候補者の母数が少なく、社内育成にも時間がかかります。求められるスキル領域は、クラウドインフラ・Kubernetes・CI/CD・セキュリティ・ソフトウェア設計に加え、開発者を「顧客」として捉えるプロダクトマネジメントの視点まで及びます。
DORAは、プラットフォームの効果を高めるにはユーザー中心設計・開発者の自律性・プロダクト志向のアプローチを優先すべきだと指摘しています*4。つまり技術力だけでなく、社内の開発者からのフィードバックを設計に反映し続ける運用力も必要であり、この両輪を持つ人材は社内異動や中途採用だけでは揃いにくいのが実情です。
また、プラットフォームチームは一度構築して終わりではなく、継続的に機能追加・改善を行う体制が前提になります*3。片手間の兼務では基盤が陳腐化しやすく、専任者の確保自体が最初の壁になりやすいと言えるでしょう。
SRE・インフラエンジニアとの役割の違い
プラットフォームエンジニアとSRE（Site Reliability Engineering、サイト信頼性エンジニアリング）は、しばしば混同されますが焦点が異なります。SREは主にサービスの信頼性・可用性・SLO（Service Level Objective、目標とするサービス品質の水準）達成に責任を持ち、障害対応や運用の自動化が中心です。これに対しプラットフォームエンジニアは、社内の開発者が使う基盤そのものを「製品」として設計し、セルフサービスで使える状態を維持する役割を担います。
インフラエンジニアはサーバー・ネットワーク・クラウドリソースの構築や維持が主務であり、対象は主にインフラそのものです。一方でプラットフォームエンジニアは、そのインフラの上に開発者向けの抽象化レイヤー（IDP）を構築し、開発者がインフラを意識せず使える状態を作る点で対象と成果物が異なります。この違いを整理すると次の表の通りです。
| 職種 | 主な対象 | 主な成果物・指標 |
|---|---|---|
| プラットフォームエンジニア | 社内開発者（利用者） | IDP・ゴールデンパス。 開発者体験・自律性の向上 |
| SREエンジニア | 本番サービスの信頼性 | SLO達成率・障害対応・ 運用自動化 |
| インフラエンジニア | サーバー・ネットワーク・ クラウドリソース |
インフラの構築・維持・ コスト管理 |
実務では3つの役割が重なり合う場面も多く、小規模な組織では兼務にならざるを得ないケースもあります。ただし発注時にこの違いを理解していないと、SRE人材を採用してもIDP整備が進まない、あるいはインフラ委託だけで開発者体験の課題が解決しないといったミスマッチが起こりやすいため、まず自社が解決したい課題がどの領域に属するかを見極める必要があります。
内製で抱える場合に必要なスキルと工数
IDPを内製で構築・運用する場合、クラウドインフラ設計・Kubernetes運用・CI/CDパイプライン構築・セキュリティポリシー実装・開発者向けドキュメント整備という広範な知識が必要になります。加えて、開発チームからの要望をヒアリングして機能改善に落とし込むプロダクトマネジメントの役割も欠かせません。
これらを1人の専任者だけで担うのは現実的ではなく、複数の専門性を持つ小規模チームでの継続運用が前提になります。DORAの報告でも、プラットフォームは一度作って終わりではなく継続的な改善投資が必要だとされており*3、初期構築だけでなく運用フェーズの体制まで見込んだ工数計画が求められます。
整備を怠ると、開発チームごとに異なるツール・手順が乱立し、後から統一しようとするとかえって移行コストが膨らむ恐れがあります。基盤構築を先送りするほど、開発者ごとの独自運用が定着してしまい、標準化の難度が上がる点はリスクとして認識しておくべきでしょう。
外部支援・委託で補完する判断軸
専任人材を社内だけで確保するのが難しい場合、外部支援・委託でIDP整備を補完する選択肢があります。判断軸の第一は、委託する範囲の明確化です。IDPの初期設計・構築フェーズのみを委託し運用は内製化するのか、構築から運用まで一貫して委託するのかによって、必要な契約形態・体制が変わります。
第二の判断軸は、自社の開発チームとの継続的な対話体制を委託先が持てるかどうかです。プラットフォームは開発者からのフィードバックを反映し続けるプロダクトである以上、外部パートナーが一度構築して離脱する形では、DORAが指摘するような改善の継続性*4が失われるリスクがあります。定例のフィードバック収集・改善サイクルを契約に組み込めるかを確認することが重要です。
第三の判断軸は、自社のクラウド環境・既存のCI/CD資産との親和性です。ゼロからIDPを構築するのか、既存ツールを土台に段階的に整備するのかで、委託先に求める技術要件が変わります。自社の技術スタックへの適合を軽視すると、せっかく整備した基盤が実際の開発チームに使われないまま形骸化する可能性があります。
委託先選定で見落としやすい留意点
IDP整備の委託では、Kubernetes・CI/CDツールの実装経験だけでなく、開発者体験を設計する視点を持つパートナーかどうかが成果を左右します。技術実装のみに強く、開発者へのヒアリングや使い勝手の改善提案が乏しい委託先を選ぶと、基盤は完成しても開発チームに定着しない事態が起こり得ます。
また、IDP整備を内製化前提の「一時的な立ち上げ支援」として依頼するのか、中長期の運用まで含めて委託するのかによって、引き継ぎ計画の有無が変わってきます。引き継ぎを想定しない契約のまま構築だけを依頼すると、委託終了後に社内で運用を継続できず、基盤が放置されるリスクがあります。
失敗コストの面では、IDP未整備のまま各開発チームが独自にデプロイ手順やセキュリティ設定を運用し続けると、チームごとの設定差異がセキュリティホールや障害対応の遅れにつながる可能性があります。委託先の選定にあたっては、構築実績に加えて、既存のインフラ・セキュリティ基盤とどう支障なく統合するかの提案力も確認すべきポイントです。
まとめ：外部支援を組み合わせたプラットフォームエンジニアリングの補完
本稿では、プラットフォームエンジニアの役割とSRE・インフラエンジニアとの違い、専任人材が不足しやすい背景、外部支援・委託で補完する際の判断軸を整理しました。要点を3つに集約すると、第一にプラットフォームエンジニアは開発者向けのセルフサービス基盤(IDP)を担う職種であり信頼性運用が中心のSREとは対象が異なること、第二に必要スキルの広さから専任人材の確保が社内だけでは難しいこと、第三に外部支援を活用する際は委託範囲・継続的な対話体制・既存環境との親和性を見極める必要があることです。自社の開発チームが抱える課題がどの領域にあるかを整理したうえで、内製と外部支援の組み合わせを検討することが、基盤整備を形骸化させない現実的な進め方だと言えるでしょう。
よくある質問
プラットフォームエンジニアとDevOpsエンジニアはどう違いますか。
DevOpsは開発と運用の連携を良くする文化・実践全般を指す概念であるのに対し、プラットフォームエンジニアリングはその実践を支える具体的な基盤(IDP)を専任で設計・運用する職種・専門領域です。DevOpsの考え方を体現する手段の一つがプラットフォームエンジニアリングと位置づけられます。
小規模な開発チームでもプラットフォームエンジニアは必要ですか。
開発チームの数が少ない段階では、専任のプラットフォームエンジニアを置かずインフラエンジニアが兼務する形でも運用できる場合があります。ただし複数の開発チームが並行して稼働し始めると、各チームで手順やツールが分散しやすくなるため、その段階で基盤整備の必要性を検討するとよいでしょう。
IDPの構築だけを外部委託し、運用は自社で行うことはできますか。
可能です。初期の設計・構築フェーズのみを委託し、運用フェーズは社内に引き継ぐ進め方は実務でよく採られる選択肢です。その場合は、委託契約の段階で運用引き継ぎのためのドキュメント整備や技術移転の範囲をあらかじめ合意しておくことが重要です。
プラットフォームエンジニアリングの導入にはどの程度の期間がかかりますか。
既存のクラウド環境やCI/CD資産の状況によって期間は変わるため、一律の目安を示すことはできません。DORAの報告でもプラットフォームは段階的に成熟していくものとされており*3、初期導入後も継続的な改善を前提に計画することが現実的です。
プラットフォームエンジニアリングを導入すれば開発速度は上がりますか。
導入自体が速度向上を保証するわけではありません。DORAの報告では、内部プラットフォームの利用を全チームに一律で強制した場合、成熟前の段階でスループットや変更の安定性が一時的に低下し得ることも指摘されています*3。開発者の自律性を保ちながら段階的に浸透させる設計が欠かせません。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：CNCF「What is platform engineering?」（2025年）
- *2 出典：Team Topologies「Team Topologies – Organizing for fast flow of value」
- *3 出典：Google Cloud「Announcing the 2024 DORA Report」（2024年）
- *4 出典：DORA「Capabilities: Platform engineering」
