プラットフォームエンジニアリングの適用範囲は、どこから広げるか 〜大企業で起きやすい3つの障壁と、最初の一歩の決め方〜  

プラットフォームエンジニアリングは、開発者が自分で使える社内プラットフォームを作り、育て続ける取り組み

開発環境が複雑になると、環境構築やリリースのたびに運用担当者への依頼が必要になります。その間、開発者の作業は止まります。申請や設定を人手で繰り返すほど、特定の担当者への依存も強まります。

プラットフォームエンジニアリングは、こうした定型作業を開発者が自分で進められるようにする取り組みです。環境の準備やリリースを、決められた手順に沿って自力で完了できるプラットフォームを用意し、使われ方を見ながら改善し続けます。

ここでいうプラットフォームは、開発者が環境の準備からリリースまでを、運用担当者に依頼せず自分で完了できる仕組みの総称です。その入口が、セルフサービス型の「開発者ポータル」です。ただし、プラットフォームはツールだけを指しません。次のものを含みます。

• プラットフォームを提供・運用するチーム

• 標準化された開発環境と手順

• 開発者が意識せずとも満たせるセキュリティ・権限の仕組み

• 効果を測る仕組み

では、実際の導入はどこまで進んでいるのでしょうか。伊藤忠テクノソリューションズ（以下：CTC）は、大企業の情報システム・システム開発・IT基盤の担当者・責任者201名に調査を実施しました。このうち、プラットフォームエンジニアリングを理解している、またはある程度知っている138名に導入状況を聞いています。

最も多い回答は「一部の部門・チームで導入している」で50.7％。「全社的に導入・展開している」は35.5％でした。合わせて86.2％が何らかの形で導入していますが、最も多いのは部門・チーム単位にとどまります。

つまり大企業の論点は、導入するかどうかではありません。一部で導入した後、どう範囲を広げるかです。

本稿では、調査で上位に挙がった3つの障壁を読み解きます。その上で、まず1つの開発作業で効果を確かめ、そこから必要な範囲へ広げる進め方を解説します。

1. 導入・展開を止める3つの障壁

導入の途中段階にある86名に、導入や全社展開が進まない理由（Q4）を複数回答で聞きました。上位3項目は次のとおりです。

※Q3で「全社的に導入・展開している」「導入しておらず、予定もない」以外を回答した方が対象

1-1. 障壁1　既存システムとの移行・連携

最多となった回答は「レガシーシステムが残っており、移行や連携が難しい」で55.8％でした。

長く使ってきたシステムには、次のような事情が重なりがちです。

• 改修を繰り返し、仕様の文書化が追いついていない

• 詳細を把握している担当者が限られる

• 周辺システムと同時に止められない

そのため、新しい基盤とつなぐには調整と検証に時間がかかります。

ただし、この障壁を「既存システムを刷新できるか」の問題として捉えると行き詰まります。論点は刷新の是非ではなく、どこまでを標準化された開発環境の対象に含めるかという範囲の設計です。
プラットフォームは、複雑な技術や手順を抽象化し、開発者から見えないようにする仕組みです。裏を返せば、標準の環境に載せられない既存システムが残るほど、セルフサービスで完了できる作業の範囲は狭まります。
そこで、既存システムを次の3つに仕分けます。

• 標準の環境に載せる

• 共通の接続部分を用意し、開発者からは同じ手順に見えるようにする

• 当面は対象外と明示し、従来どおり個別に対応する

1-2. 障壁2　自社で運用・改善し続ける体制

2番目は「内製・運用できる体制が整っていない」で38.4％でした。

プラットフォームは、作って終わりではなく、技術の更新・利用者の追加・ルールの変更・障害対応が続きます。

ここで前提になるのが、体制の組み方です。プラットフォームを提供する側と、それを使って開発を進める側。この2つの役割は分けて考えます。ただし、提供する側をインフラ担当だけで構成してはいけません。

プラットフォームエンジニアリングは、開発と運用を一体で回すDevOpsを組織全体に広げる取り組みです。この前提に反して、ソフトウェアとインフラを別々の組織のまま進めようとすると、うまくいきません。インフラ側の制約が先に立ち、開発者のワークフローに合わない仕組みができあがるためです。設計すべき順序は、インフラの構成ではなく、開発者が実際にたどる作業の流れが先です。提供する側のチームには、開発とインフラの双方の知見を持つメンバーが同じテーブルにつく必要があります。

その上で、次の3つの役割を分けて置きます。

• 何を標準化し、何を対象外とするかを決める責任者

• プラットフォームを提供・運用するチーム（開発とインフラの合同体制）

• 実際に使って意見を返す開発チーム

同調査では「専任の人材やスキルが不足している」も31.4％で4位でした。構築の技術力だけでなく、運用と改善を続ける人と役割の確保も課題になっていることが伺えます。

プラットフォームは「作るモノ」ではなく「育てるモノ」です。当初決めたゴールに到達しても終わりではなく、実際に使う開発者との継続的な対話を通じて進化させ続けるものだからです。利用を規程で強制するのではなく、開発者が「そちらのほうが楽だから使う」状態を目指します。担当者を決め、要望を集め、改善の順番を決めて更新していく。この運営の形があるかどうかで、使われる範囲は変わります。

1-3. 障壁3　投資判断と社内説明

3番目は「投資判断の階層が多く、意思決定に時間がかかる」で33.7％でした。

関係部門も承認者も多い大企業では、「開発者が使いやすくなる」という説明だけでは通りません。業務への影響や具体的な数値に置き換える必要があります。同調査では「投資対効果（ROI）を説明・証明しづらい」も26.7％。階層の多さに加えて、効果を示す材料が足りないことが投資判断を難しくしています。

そこで、示す数値は、開発と運用のスピードに直結するものを選びます。例えば、1回のリリースにかかる日数、リリースの頻度、リリース後に障害となった割合、障害から復旧するまでの時間です。いずれも開発現場の状態を表す一般的な指標で、部門をまたいだ比較にも使えます。

社内説明に使う効果指標は、最初に解決する問題に合わせて2〜3項目に絞ります。

2. 1つの開発作業で価値を確かめてから、必要な範囲へ広げる

2-1. 最初の利用者と、改善する作業を1つに絞る

プラットフォームは、必要な機能を全てそろえてから配るものではありません。当初から完璧な形を目指すと、構築に時間がかかりすぎ、現場が直面している課題にタイムリーに対応できなくなります。
そこで最初に作るのは「MVP（Minimum Viable Platform：最小実用構成）」です。最も解決が急がれる課題領域に絞って作り、使ってもらい、成果を積み上げてから適用範囲を段階的に広げていく。これがプラットフォームエンジニアリングで定着している進め方です。

逆に、全社の開発者をいきなり対象にすると、要望も例外も増えます。最初の基盤に何を載せるかが決まりません。

着手時に決めるのは3つです。最初に使う開発チーム、改善する作業、そして関係する既存システムの扱いです。

まず、最初に使う開発チームを1つ決めます。

次に、環境構築・テスト・リリース・権限申請・監視設定の中から、改善する作業を1つだけ選びます。選ぶ基準は4つです。

• 繰り返し発生している

• 待ち時間や手戻りを生んでいる

• 既存環境から切り離しやすい

• 着手前後の差を測れる

技術的に作りやすい機能より、利用者が「楽になった」と実感しやすい作業を優先します。

例えば新しい開発環境の準備に数日かかっているなら、申請・権限付与・環境作成をひとまとめに自動化します。開発者は開発者ポータルで必要な項目を選ぶだけで、テスト環境とリリースの仕組みが一式そろった状態を受け取れる。これが最初のMVP（最小実用構成）になります。

 もう1つ選びやすいのが、すでに現場で使われているCI/CD（継続的インテグレーション／継続的デリバリー）のパイプラインへの機能追加です。ビルドからテスト、本番反映までの流れに、セキュリティ検査を組み込む。開発者は従来どおりの手順で進めるだけで、必要な検査が自動的に適用された状態になります。品質確保の負担を、開発者からプラットフォーム側へ移す方法です。

いずれの場合も、着手前と後で、使い始めるまでの時間を測ります。あわせて、関係する既存システムの扱いも、1-1で挙げた3つの仕分けに沿って着手時に決めておきます。

2-2. 必要な機能だけを作り、実際の開発案件で確かめる

用意するのは、2-1で選んだ作業を改善できる範囲だけです。

その状態で実際の開発案件に使ってもらい、次の3点を確認します。

• 利用者が手順に迷わず進められるか

• 運用担当者の確認作業が減るか

• 既存システムとの連携で作業が止まらないか

使われない場合は、説明不足だと決めつけずに、手順・画面・権限設計・例外時の対応も点検します。集まった意見をもとに、追加する機能と次に広げるチームを決める。この流れを繰り返します。

2-3. 解消した問題を、着手前後で測る

効果は、着手前と後で同じ指標を測って比べます。着手前に、次の4つを記録しておきます。

• 環境の準備にかかる時間

• 申請から使い始めるまでの時間

• 運用担当者への問い合わせ件数

• 1回のリリースにかかる日数

どれだけ使われているかは、利用者数やログイン回数、開発者が自分で完了できた申請の割合で把握します。

数値だけでなく、開発者が迷った手順、運用担当者に残った作業、セキュリティ確認や障害対応への影響も見ておきます。改善できたことと残った課題をまとめれば、対象部門を広げる判断にも、経営層への説明にも使えます。

3. 外部支援は、社内に残す判断と支援範囲を分けて考える

3-1. 80.2％が、実務に踏み込んだ外部支援を希望

導入の途中段階にある同じ86名に、外部パートナーをどう活用したいか（Q6）を聞きました。最も多いのは「自社主導で進め、特定の領域だけ支援してほしい」で52.3％。「設計から運用まで主導的に支援してほしい」が27.9％で続きます。実務に踏み込んだ支援を求める回答は、合わせて80.2％に上りました。

「自社だけで解決するのは難しい」と感じる項目（Q5）の上位は次のとおりです。

• レガシーシステムの移行・刷新：53.5％

• 内製で運用できる体制づくり・人材育成：40.7％

• 投資対効果の整理や経営層への説明：36.0％

技術の実装だけでなく、体制づくりと社内説明にも支援を求める声が出ています。

3-2. 社内に残す判断を先に定める

外部パートナーを活用する場合も、決めること自体は社内に残します。何を社内で決め、どこから外部の専門性を借りるか。整理すると次のようになります。

判断の軸を社内に置いておけば、支援の範囲が変わっても運用の方針は保てます。

パートナーを選ぶときは、製品を導入する技術力だけで判断しません。限定した範囲で検証を回せるか、運用体制まで設計できるか、社内担当者へ知識を引き継ぐ方法があるか。支援が終わった後も社内で改善を続けられるかまで含めて評価します。

4. まとめ　範囲を広げる前に、障壁と最初の対象を明確にする

適用範囲を広げるのに必要なのは、技術選定だけではありません。標準化の対象に含める範囲の線引き、開発とインフラ双方を含む提供チーム、そして着手前後の比較で示す説明材料。この3つをそろえることです。

まずは1つのチーム、1つの作業に絞り、最小限の機能で試す。

着手前後で同じ指標を測り、解消できた問題と残った問題を示す。そしてプラットフォームを「作るモノ」ではなく「育てるモノ」として運営し、開発者が「そちらのほうが楽だから使う」状態を積み上げていく。この順番が、次のチームへ広げる判断につながります。

5. 大企業201名の回答から、導入と展開の全体像を確認する

ホワイトペーパー「大企業のプラットフォームエンジニアリング活用実態調査」では、全6問の調査結果を掲載しています。本記事では触れていない認知度や評価に関する結果も確認できます。

自社の状況を他社の回答と照らし合わせ、社内での合意形成や予算申請、外部パートナーへ依頼する領域を整理する際の資料としてご活用ください。