Platform Engineering入門【後編】｜国内初の「認定サービスプロバイダー」が明かす実践の勘所

 ※1 参考：国内初、CTCがプラットフォームエンジニアリングの『認定サービスプロバイダー』に認定（2026年6月19日）
https://www.ctc-g.co.jp/news/info/20260619-02105.html

伊藤忠テクノソリューションズ（CTC）
DXコンサルティング本部 クラウドネイティブ推進部
アソシエイトプリンシパル
杉田 修一郎

Platform Engineeringの基礎的な概要を知りたい方は、本稿の【前編】からお読みください。

▶Platform Engineering入門【前編】

1. Platform Engineering Masters資格の意味

今回の認定取得は、CTCの支援実績に加え、杉田がPlatform Engineering Masters社（PEM社）の「Practitioner」と「Professional」資格を取得したことによるものです。 これらの資格は、グローバルで積み重ねられた成功・失敗事例から、永続的な活動にするためのポイントを抽出・凝縮して体系化したものです。

2. 先行するユーザー企業からノウハウを学ぶ

PEM社が運営するコミュニティ（以下、PEMコミュニティ）には、CTCのようなIT企業だけでなく、一般の事業会社（以下、ユーザー企業）も数多く参加し、「自分たちはこうだった」という情報を活発に交換しています。CTCでは、Platform Engineering実装の支援力向上のため、グローバルの最新動向をキャッチし、知見の蓄積に注力しており、今回の認定取得もその一環です。

杉田：Platform Engineeringを巡る最新の課題は、先進的に取り組むユーザー側にあります。そうした課題がつぶさに捉えられる点が、PEMコミュニティの大きな魅力です。このコミュニティを通じて先進ユーザーの方々と直接情報を交換し、何が重要なトレンドかを肌で感じて、日本のお客様への提案・支援につなげています。

3. 失敗事例の共通項とは

では実際に、「事例」からどんな学びがあったのでしょうか。以下では、杉田が挙げる、失敗事例に共通するポイントを見ていきます。

3-1. 効果の不明瞭さ・見えにくさ

杉田が指摘する失敗事例に共通する問題点の1つが「効果の不明瞭さ・見えにくさ」です。

杉田：Platform Engineeringは、開発スピードと品質を両立させるDevOpsの理想を複数のチームにスケールする取り組みです。関わる領域が開発・インフラ・セキュリティ・経理まで多岐にわたるため、全員の理解と協力を得るには、事前の合意形成と効果の可視化が不可欠です。 例えばセキュリティ担当者には、プラットフォーム構築によってセキュリティ要件やコンプライアンス要件を担保できることを明確に示す必要があります。効果の透明性を確保し、関係者全員へのメリットを見える化することがPlatform Engineering成功の鍵です。

3-2. 縦割り型の開発と運用組織

もう1つの失敗要因が「縦割り」です。杉田は、ソフトウェアとインフラを分けてPlatform Engineeringを進めようとすると、まず成功しないと指摘します。

杉田：Platform EngineeringはDevOpsの効率化・自動化に向け、ソフトウェアとインフラ両チームの合同体制で始めることが重要です。製造業の生産ライン構築と同様、インフラ（建屋）より先に開発者のワークフロー（生産プロセス）を設計する必要があります。順序が逆だとインフラ側の過剰な制約で自動化が阻害されるため、初期から両者が同じテーブルでワークフローを軸に協調して進める体制が不可欠です。

4. 支援の現場が直面する日本とグローバルとのギャップ

一方、お客様支援の現場では、日本と海外とのギャップによく直面します。代表的なギャップの1つが、ITの人的リソースの違いです。

海外では、ユーザー企業にIT人材が数多く在籍し、開発と運用を一体化させたDevOpsチームが当たり前のように存在します。それに対して日本のユーザー企業の場合、ソフトウェア開発を外部のIT企業に一任するスタイルが主流であり、内製のDevOpsチームを持つ企業は少ないのが現状です。

杉田：ソフトウェア開発を外部委託してきた企業が、海外のように自社内でDevOpsチームを組織しても、メンバーのスキル不足が障壁となり、うまく機能しません。そこでCTCでは、エンジニアのレベルを1から5まで定義した「成熟度マップ」で成長度合いを可視化し、実践を繰り返しながら人材を育てる仕組みを提案しています。DevOpsやPlatform Engineeringは実践ありきであり、自ら考え、設計し、運用して初めて効果的・効率的に回すスキルが身に付くのです。

5. 成功のための要点

Platform Engineeringで成果を上げる企業にも共通点があると杉田は指摘します。

杉田：着手から効果測定までのスピードが速い企業に共通するのは、DevOpsを推進する開発現場が本当に困っていて、課題解決の手段を欲している点です。言い換えれば、これから内製化を目指す企業よりも、サイクルがうまく回せず現場が疲弊している企業のほうが、危機感から前に進む動きが速いのです。

とはいえ、やみくもにPlatform Engineeringを推進しても成功にはつながりません。取り組み方にも成功のポイントがあり、以下、それを見ていきます。

5-1. MVPを作ることから始める

Platform Engineeringの最終ゴールは、セルフサービス型の「開発者ポータル」を実現し、開発エンジニアの（技術への）認知負荷を下げながら、開発チーム（あるいはDevOpsチーム）の全員が自律的かつ効率的に課題を解決し、タスクをこなせる状態を築くことです。

ただ、この最終ゴールに至る過程でも、局所的な改善が行われるたびに開発エンジニアは効果を体験できます。疲弊度の高い開発チームほど、こうした小さな改善に前のめりに反応し、次の取り組みへの意欲を高めるのです。

杉田：Platform Engineeringでは、一気に最終ゴールを目指す必要はありません。例えば、お客様の開発現場で使われている「CI/CD（継続的インテグレーション/継続的デリバリー）」のパイプラインに、AIやセキュリティの機能を組み込むだけで、開発の品質を労せず上げられ、お客様に大変喜んでいただけます。また、PEMのプラクティスにも「実用最小限の製品（Minimum Viable Product：MVP）」を作ることから始めなさいとの教えがあります。これに従い、開発チームの一番のペインポイントをPlatform Engineeringで解決すれば、メンバーは効果を実感でき、活動に勢いが出て賛同者が自ずと増えていきます。

5-2. 先行事例を参考に課題を特定する

一方、開発チームの課題は常に明確とは限らず、むしろ何が問題かを整理できていないほうが一般的です。そのような場合にCTCが提示するのが海外の先進事例です。

杉田：先進事例からは、先行者たちが「どのような課題からどう対応し、今どんな状態にあるか」が分かります。この状態と自社の現状を見比べれば、自分たちの課題を顕在化させ、優先順位をつけることが簡単にできます。その上で、解決すべき課題を、どんなに長くても3カ月ほどで効果を出せる範囲に絞り込み、そこから取り組みを始めるのが効果的です。

では、これから内製化に取り組む企業は、事前に何を整えるべきなのでしょうか。

杉田：理想をいえば、お客様側で課題を明確にし、その上で解決策について当社のようなPlatform Engineeringのエキスパートに相談いただくことです。ただ、自分たちだけでは課題を特定できないこともあります。その場合は、「現状を何とか打破したい」という熱意と、Platform Engineeringをプロジェクトとして成立させるための社内への働きかけ、そして取り組みを後押ししてくれるキーマンやスポンサーを見つけることが出発点になります。

5-3. 暗黙知を開放する

DevOpsやPlatform Engineeringを推進する上でもう1つ欠かせないのが、開発・運用のあり方を大きく変えることへの社内合意です。DevOps、あるいはPlatform Engineeringの根底にある考え方は、個人の経験や勘に頼らず、チームとして課題解決の能力を高めていく「自己組織化力」の強化・確立です。それには、属人的な暗黙知を形式知化し、プログラムコードや、AIが最も理解しやすいデータ記法である「Markdown」などを使ってナレッジを蓄積する文化への転換が求められます。

杉田：日本企業では、開発・運用のノウハウが「匠の技」として暗黙知のままにされ、一部のベテランエンジニアに依存した開発・運用が行われるのが一般的です。しかし、このような組織文化は、貴重なナレッジの共有・継承・活用を困難にし、チーム全体のスキルアップを阻害します。ゆえに、ベテランのノウハウを形式知化し、誰もがAIで横断的にアクセス・活用できる仕組みを作ることが重要です。Platform Engineeringはこの考え方をベースにした取り組みであり、だからこそチームの成長を加速できるのです。

5-4. 先進チームでリファレンスモデルを作り・広げる

Platform Engineeringの取り組みは、複数の開発チーム・DevOpsチームにスケールしていくことが組織全体の生産性向上につながります。そのためには、MVPを作らせるチーム、あるいは社内で最初に着手させるチームとして、社内的に注目されている先進的なチームを選ぶことが大切です。

杉田：先進的なチームが抱える課題は、大抵の場合、他のチームでもいずれ直面します。ゆえに、その課題をPlatform Engineeringで解決してリファレンスモデル化し、他のチームに展開すれば、後続のチームは同じ課題につまずかずに済みます。

こうした横展開を支えるのは、実践を繰り返しながら学びを蓄積・共有するフィードバックループです。プログラムコードやドキュメントをはじめ、コーディング上の規約・作法・品質基準など、暗黙知になりやすいナレッジもドキュメント化し、AIで横断的に検索できる状態にします。その上で「課題の顕在化」→「MVPの作成」→「リファレンスモデル化・仕組み化」→「横展開」のサイクルを回し続けることで、継続性が担保されます（図1）。

図1：MVP作りを起点に組織全体にPlatform Engineeringの取り組み・成果を広げるプロセス

5-5. 全てをドキュメント化しない

ナレッジの形式知化（＝明文化）と、それによるプロセスの標準化はPlatform Engineeringの重要なルールです。ただし、「過度の明文化」は避けなければなりません。例えば、プラットフォームの使い方まで全てマニュアル化すると、ドキュメント量が増え、かえって認知負荷が増大します。

Platform Engineeringで追求すべきは、エンジニアの良質な開発体験であり、技術ドキュメントやマニュアルを何も読まずにタスクが進められる、自動化された分かりやすいプラットフォームです。全てをマニュアル化しようとするのは、これとは真逆の発想です。

杉田：開発チームの中には、アジャイル開発やDevOps的なアプローチを採用しているにもかかわらず、成果報告や中間成果物などはこれまでの習慣通りワープロソフトや表計算ソフトで行う例があります。アジャイル開発では新しい成果が次々と生まれ、ドキュメントを頻繁に更新しなければなりません。その過程で新旧差分が分かりにくくなり、作る側も読む側も認知負荷が高まり、またファイルの更新などの手間も増えます。そこでCTCは、そのようなファイルでの情報管理をやめ、プログラムコードやドキュメントの変更履歴を記録・追跡が容易な「Git」やWikiのような仕組みを使い、差分や変更理由を可視化して承認を得られる状態にするようアドバイスしています。

6. 成功を支える「人と組織」の整え方

Platform Engineeringを推進するチームには、インフラ系かソフトウェア系かの境界を越えた、以下のような役割が求められます。

• アーキテクト：プラットフォームの構造を設計する役割。インフラと開発双方の知識・スキルに加え、CI/CD・IaC（Infrastructure as Code）などの自動化領域の知見が必要とされる

• UXデザイナー：開発エンジニアにとって迷わず使える、良質な体験をデザインする役割

• QA（Quality Assurance）：ソフトウェアの品質保証を担い、セキュリティやテストを支援する役割

加えて昨今は開発・運用でのAI活用が進み、Platform Engineeringにおいても「AIエンジニア」の重要性が高まっています。

杉田：今や、Platform EngineeringとAIは、ソフトウェアの生産性を高め、DXを前進させるための両輪です。そこにきちんと投資し、効果を測る仕組みを持つことが、企業競争力の維持・向上につながります。

さらに杉田は、経営層・IT部門・開発チームがそれぞれの役割を果たせるかどうかが推進力を大きく左右すると指摘します。

杉田：中でも重要なのは経営層のコミットメントであり、その強弱が変革を続けられるかどうかを決めます。ですので、より多くの経営層に「DXが生まれやすい環境」に積極的に投資していただきたいですし、その環境の1つがPlatform Engineeringを推進する場でもあります。そしてIT部門は、外部IT企業にソフトウェア開発を全て委託する役割から脱し、少なくとも開発の上流工程は自分たちで担い、アイデア出しから実装までを一気通貫でつなぐ仕組み作りを検討すべきです。

7. 開発のプラットフォームは
「作るモノ」ではなく「育てるモノ」

Platform Engineeringは、当初設定した最終ゴールに到達しても終わる取り組みではなく、開発エンジニアとの継続的な対話を通じてプラットフォームを進化させ続ける必要があります。杉田は、その先に「開発とAIとの完全な形での融合がある」と見通します。

杉田：Platform Engineeringは今後、「AI駆動開発」における「ハーネス」の役割を担うようになるでしょう。ハーネスとは、AIが安定した振る舞いや回答を行えるようにする一方でその効果を最大化させるために、AIの動きを制御・監視する仕組みのことです。こうしたスキームの中で、Platform Engineeringは、ITコスト最適化手法の「FinOps」や、AIによる運用自動化手法の「AIOps」などとも統合され、DevOpsプラットフォームの進化を支えていくでしょう。最終的には、AIが自律的にソフトウェアを開発・運用する一連の仕組みになると見ています。

こうした将来を見据え、杉田は、これからPlatform Engineeringに取り組む企業に次のようなメッセージを贈ります。

杉田：Platform Engineeringは今後、DevOpsの実現手段にとどまらず、AI駆動開発の品質と生産性を高める手段としても進化し、企業がDX時代を勝ち抜く上で欠かせない取り組みになります。日本でも着手する企業が増えており、乗り遅れないためにも早めの着手をおすすめします。実践で困りごとに突き当たった際は、ぜひ私たちにご相談ください。Platform Engineeringの成功に向けて、お客様の取り組みを支援いたします。