LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

プラットフォームエンジニアリングとは：IDPで開発者の認知負荷を下げる取り組み

プラットフォームエンジニアリングとは、開発者がセルフサービスで利用できるIDP（Internal Developer Platform：内部開発者基盤）を設計・構築・運用する取り組みを指します。目的は開発者体験（DevEx）の向上と認知負荷の低減です。

クラウドネイティブ開発が進むにつれ、開発者がCI/CD（継続的インテグレーション・継続的デリバリー）の設定、セキュリティスキャン、インフラのプロビジョニングを個別に担う「DevOps疲れ」が顕在化してきました。プラットフォームエンジニアリングはこの状況を解決するため、これらの共通基盤をIDPとして集約し、開発者が本来注力すべき機能開発に集中できる環境を提供します。

IDPの主な構成要素：セルフサービス・ゴールデンパス・フィードバックループ

IDPは一般的に3つの要素で構成されます。第一は開発者ポータル（セルフサービス窓口）で、インフラ環境の払い出しやデプロイをGUIまたはAPIで自己完結できる仕組みです。第二はゴールデンパスと呼ばれる承認済みの技術スタック・テンプレートで、組織が推奨する信頼性かつ標準的な開発経路を用意します。

第三はフィードバックループで、開発者がIDPをどの程度利用し、どこで摩擦を感じているかを計測して継続的に改善します。この3要素がそろうことで、IDPはツールの寄せ集めではなく「内部製品」として機能します。

プラットフォームチームの役割：プロダクト思考で基盤を運営する

プラットフォームエンジニアはインフラ管理者とは異なり、開発者を「内部ユーザー」と捉えてIDPをプロダクトとして運営します。ユーザーリサーチ（開発者へのヒアリング・利用データ分析）をもとにロードマップを立て、機能リリースと廃止サイクルを回す点が特徴です。

チーム規模の目安は、開発者50名以下なら2〜3名、100〜500名規模なら5〜10名が一般的とされています。小規模の組織でも専任者を置くことで、全社のDevOps生産性が底上げされます。

役割と市場動向：Gartner予測が示す80%普及の現実味

プラットフォームエンジニアリングへの関心は急速に高まっています。Gartnerは「2027年までにソフトウェアエンジニアリング組織の80%が社内にプラットフォームチームを設立する」と予測しています^*1。現時点ではまだ普及途上の組織が多く、逆にいえば先行して取り組む企業が競争優位を確保できる段階です。

背景には、クラウドネイティブ・マイクロサービス・Kubernetes（コンテナオーケストレーションツール）の普及があります。これらの技術が組み合わさると、開発者が扱うべき運用上の複雑さが急増します。IDPはその複雑さを抽象化し、開発者が意識しなくてよい層を増やす役割を担います。

Platform Engineeringが注目される3つの背景

第一は「DevOps疲れ」の顕在化です。DevOpsの理念のもとで開発者がインフラ・CI/CD・セキュリティをすべて自己管理する状況が広がった結果、本来の開発作業に使える認知リソースが削られています。

第二はクラウドコストの可視化需要です。開発者が自由にインフラを払い出せる環境では、コスト管理が分散します。IDPを経由した標準的な払い出しフローを設けることで、コスト配分タグの付与やリソース上限の制御が一元化できます。

第三はセキュリティの「シフトレフト」対応です。ゴールデンパスにセキュリティスキャンを組み込むことで、開発者が意識せずともセキュリティポリシーが適用される状態を作れます。ガバナンスと開発スピードの両立を求める声が、プラットフォームエンジニアリングの需要を押し上げています。

採用が難しい理由：新領域ゆえの希少性とIT人材不足の加速

プラットフォームエンジニアは、DevOps・SRE（サイト信頼性エンジニアリング）・開発者体験設計・プロダクトマネジメントにわたる幅広いスキルを要求する職種です。従来のインフラエンジニアやバックエンドエンジニアとは異なるスキルセットが求められるため、即戦力の母集団が少ない状況です。

IT人材全体の不足も採用難に拍車をかけています。経済産業省が2019年に公表した「IT人材需給に関する調査」^*2では、2030年に約79万人（上限の試算）のIT人材が不足すると推計されています。希少な人材を巡る採用競争は激化する一方であり、プラットフォームエンジニアに限らずIT領域全体で採用のリードタイムが長期化しています。

「IDP担当者」の採用が特に難しい3つの理由

第一に、職種の定義が標準化されていないことです。プラットフォームエンジニアという肩書は企業によって指す内容が異なり、求人票で候補者に正確に訴求することが難しい側面があります。

第二に、求められるスキルの複合性です。Kubernetes・Terraform（インフラをコードで管理するツール）・CI/CDパイプライン設計・開発者ポータル（Backstage等）の構築知識に加え、ユーザーリサーチやプロダクト思考まで求められます。単一のスキル領域の専門家ではなく、複数領域を横断する人材が必要です。

第三に、社内での認知が低いことです。プラットフォームチームの投資対効果は、開発者の生産性向上という形で現れるため、経営層への説明が難しく、採用予算の確保自体が障壁になるケースがあります。

外注・委託で補完する3つの選択肢：伴走/IDP構築受託/運用委託

採用難の状況でもIDPを立ち上げるには、外部のプラットフォームエンジニアリング経験者と協働することが有効です。補完の形態は大きく3つに整理できます。

立ち上げ伴走型：社内チームに並走して知見を移転する

社内に兼任エンジニアや近い領域の担当者はいるものの、プラットフォームエンジニアリング専門知識が不足している場合に向いています。外部の専門家がメンター・テクニカルリードとして週次・月次で参加し、設計レビュー・技術選定・ロードマップ策定を支援します。

費用は固定契約や月次顧問契約の形を取ることが多く、IDP構築の内製力を育てながら進められる点がメリットです。社内チームの成長を最優先にしたい場合に適しています。

IDP構築受託型：設計から初期構築までを丸ごと委託する

「IDP自体を最短で動かしたい」「社内にKubernetes・Backstage・Terraformの知見がない」という状況では、初期構築を受託会社に委ねる選択肢があります。要件定義・アーキテクチャ設計・実装・社内への展開支援までをスコープとして依頼します。

スコープが明確であれば品質と期限を契約で担保しやすいのが利点です。一方、仕様変更が多い場合は追加費用が発生しやすく、構築後の運用を自社で引き取るための知識移転計画を事前に設けることが大切です。

運用委託型：IDPの継続改善・運用を外部に預ける

初期構築後の継続的なメンテナンス・バージョンアップ・開発者からのフィードバック対応を委託する形です。社内のプラットフォームチームが定員に達するまでの暫定措置として、あるいは採用採用が間に合わない間のブリッジとして機能します。

ラボ型契約（専属チームを月次契約で確保する形態）に近い構造になることが多く、長期にわたる関係構築が前提となります。プロダクト理解が深まるにつれてコミュニケーションコストは下がりますが、初期のオンボーディングに時間がかかります。

補完を進める4ステップ：現状把握→ゴールデンパス設計→PoC→内製移管

外注・委託でIDPを立ち上げる際は、以下の4ステップで進めることで品質・スピード・知見移転のバランスを取りやすくなります。

ステップ1：DevOps疲れの実態を現状把握する

まず「何が開発者の認知負荷を最も高めているか」を定性・定量の両面で把握することが出発点です。具体的には、CI/CDの設定に費やす時間・本番障害対応の頻度・インフラ申請の待ち時間・新規サービス立ち上げのリードタイムなどを計測します。

この段階で測定値が取れない場合は、開発者へのヒアリングで課題を洗い出します。「困っている操作の上位3つ」を聞くだけでも、IDPが解決すべきユースケースが明確になります。外注先にブリーフィングする際も、この現状把握が要件定義の精度を高めます。

ステップ2：ゴールデンパスの優先順位を設計する

IDPで提供するゴールデンパスは、一度にすべてを網羅しようとすると開発が長期化します。「開発者が最も頻繁に行う作業」から優先順位をつけ、最初のバージョンでは2〜3本のゴールデンパスに絞ることが有効です。

たとえば「Kubernetesクラスタへの新サービスデプロイ」と「CI/CDパイプラインのセットアップ」の2本から始め、利用率と開発者フィードバックをもとに拡充する形が現実的です。外注先との共同設計ワークショップを設けることで、スコープの合意と優先度設定を効率化できます。

ステップ3：PoCで効果と摩擦を確認する

初期構築が終わったら、小規模なチームを対象にPoC（概念実証）を実施します。ゴールデンパスを実際に利用してもらい、「どこで詰まるか」「どの操作が直感的でないか」を収集します。

PoCの評価軸は4点が参考になります。デプロイのリードタイム変化・設定に関する問い合わせ件数の変化・開発者が感じる摩擦スコア（5段階アンケートなど）・セキュリティポリシー適用の遵守率です。PoCを通じて外注先との認識齟齬も早期に発見でき、本番展開前の手戻りを最小化できます。

ステップ4：段階的な内製移管とチーム組成を並走させる

PoCが成功したら、内製チームへの移管ロードマップを外注先と合意します。具体的には、採用活動と並走しながら外注先がドキュメント整備・設計レビュー・知識移転セッションを担い、内製エンジニアが育つにつれてスコープを段階的に引き取る形です。

移管時のリスクを下げるため、ADR（Architecture Decision Records：アーキテクチャ判断の記録）とランブック（運用手順書）の整備を委託スコープに含めることをお勧めします。インフラはIaC（Infrastructure as Code：コードでインフラを管理する手法）で管理することで、担当者が変わっても環境の再現性が保たれます。

内製採用と外注の比較：コスト・スピード・リスクの3軸で選ぶ

内製採用と外注・委託は対立する選択肢ではなく、段階的に組み合わせるものです。ただし、状況に応じた優先度は異なります。主な比較軸を整理します。

実務上は「IDP構築受託で基盤を最短で動かしながら、立ち上げ伴走で内製チームを育てる」組み合わせが機能しやすい形です。採用が成功したタイミングで外注スコープを段階的に絞り込むことで、コストと自立性の両立を図れます。

委託時の3つの注意点：プロダクト思考・内製移管・属人化回避

プラットフォームエンジニアリングの外注では、通常のシステム開発委託と異なる観点が必要です。IDPは「作って終わり」ではなく継続的に磨き込む内部製品であるため、委託先の姿勢と契約設計に特有のポイントがあります。

注意点1：「インフラ構築」と「プロダクト思考」は異なる

IDPの委託先に求めるのはインフラ構築の技術力だけではありません。開発者を内部ユーザーとして捉え、ユーザーリサーチ・利用率計測・フィードバックループの設計ができる「プロダクト思考」を持つ委託先が必要です。

委託先の選定では、「以前に開発者ポータルを開発者ヒアリングをもとに改善した経験があるか」「利用率の計測方法を提案できるか」を確認することが有効です。技術スタックだけで選ぶと、ツールは整っても開発者が使わないIDPが出来上がるリスクがあります。

注意点2：内製移管の出口を契約時に設計する

委託開始時点から「いつまでに・何を内製化するか」のロードマップを合意しておくことが大切です。内製移管を想定していない委託先は、ドキュメント整備やオンボーディング支援に消極的になりやすい傾向があります。

契約条件に、ADR・ランブック・アーキテクチャ図の最新版納品を定期的な成果物として明記することをお勧めします。委託終了後に「環境の仕組みがわからない」という状態を防ぐため、社内エンジニアが月次の設計レビューに参加できる機会を設けることも有効です。

注意点3：属人化を招くブラックボックス設計を避ける

IDPの構成が委託先エンジニア1名の知識に依存する状態は、継続的な委託関係の中でも発生します。Terraform・Helmチャート（Kubernetesのパッケージ管理ファイル）・CI/CDパイプライン定義を含むすべての設定をコードとして管理し、社内のGitリポジトリに置くことが基本です。

委託先が独自ツールや独自スクリプトを多用する場合は、標準的なOSSへの置き換えを交渉することを検討してください。特定の委託先なしには運用できない状態（ベンダーロックイン）は、将来の移管コストを跳ね上げます。設計レビューを週次または隔週で実施し、ブラックボックス化を早期に検知する体制が有効です。

まとめ：IDP不足に対応する3つの判断軸

本稿では、プラットフォームエンジニアリング・IDPの概要から市場動向・採用難の背景・外注補完の選択肢と進め方・委託時の注意点までを整理しました。要点を3つに集約すると次のとおりです。

第一に、採用を待つ前に外注で立ち上げを先行させること。Gartnerが2027年に向けて80%普及を予測するプラットフォームチームの設立において、採用リードタイムを理由に先送りすることは機会損失につながります。立ち上げ伴走・IDP構築受託を活用して、開発者体験の改善を早期に開始することが現実的です。

第二に、補完形態はスピード・知見移転・コストの3軸で選ぶこと。伴走型は知見移転が最もスムーズですが初動がやや遅く、構築受託型は初動が速い分だけ知識移転計画を別途設ける必要があります。自社のマネジメント余力と内製化の優先度に合わせて選択することが、後の問題を防ぎます。

第三に、委託開始時点から内製移管を前提に設計すること。ADR・ランブック・IaCによるインフラのコード管理を契約に組み込み、プロダクト思考を持つ委託先を選ぶことで、外注依存からの脱却と自立した内部プラットフォームチームの組成を両立できます。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：Gartner「Platform Engineering Will Be Essential for AI-Augmented Development by 2027」（Gartner予測、2022年公表）
2. *2　出典：経済産業省「IT人材需給に関する調査」（2019年公表）

Tweet