はじめに
こんにちは。エーピーコミュニケーションズ ACS事業部 亀崎です。
近年、開発者の生産性を高める手法として 「プラットフォームエンジニアリング(Platform Engineering)」が注目されています。
しかし、多額のコストを投じて内部開発者プラットフォーム （IDP : Internal Developer Platform）を構築したものの、現場の開発者に敬遠され、 結局「誰もいない更地」になってしまう、という話も出ています。
本記事では、 なぜあなたのPlatform Engineeringは「使われない」のか？失敗の本質とペルソナ戦略 と題してPlatform Engineeringが失敗する共通の要因と、 成功の鍵を握る「ペルソナ設定」の重要性について解説します。
Platform Engineeringが失敗する5つの典型パターン
開発者プラットフォームを構築することを計画すると、『共通基盤構築計画』を立てる ことが多いと思います。このプラットフォーム計画を単なる「共通基盤の構築プロジェクト」と 捉えてしまうと、以下のような罠に陥ります。
- 「プロダクト」ではなく「プロジェクト」扱い : 一度作れば終わりと考え、ユーザー（開発者）のフィードバックを受け付ける仕組みがない。
- 認知的負荷の増大 : 抽象化が不十分で、開発者が結局インフラの深い知識を求められる。
- 「強制」による心理的反発 : 利便性（アメ）ではなく、制約（ムチ）としてプラットフォームを押し付けてしまう。
- 名前を変えただけの運用チーム : 実態は従来通りの「チケット依頼・承認待ち」のままで、セルフサービス化できていない。
- 成功指標（メトリクス）の不在 : デプロイ頻度や開発者の満足度など、生産性の変化を定量化していない。
これらの罠について少し詳しく見ていきましょう。
「プロダクト」ではなく「プロジェクト」扱い
「プロダクトではなくプロジェクト扱い」という点は、Platform Engineeringが挫折する 最も根深く、かつ初期に陥りやすい罠です。
「プロジェクト」と「プロダクト」の決定的な違い
多くの組織では、プラットフォーム構築を「予算と期間が決まった一過性の仕事」として 捉えてしまいます。しかし、これこそが失敗の始まりです。
「プロジェクト」と「プロダクト」には次のような大きな違いがあるからです。
1. 終了の定義 : 納期か、価値か
プロジェクトの場合、「開発者プラットフォームを構築したら終了」という ゴールを設定します。完成したら、構築チームは解散または別の作業に移っていき、 保守モード に入ります。
プロダクトの場合、「開発者のリードタイムを20% 削減し続ける」といった価値を ゴールに設定します。技術の進化や組織の変化に合わせてプラットフォームも進化し続けるため 完成という概念がありません。
2. ユーザーとの関係 : 要件定義か、フィードバックか
プロジェクトの場合: 最初に「要件」を聞き取り、それを作って納品します。 リリース後にユーザー（開発者）が「使いにくい」と言っても、予算や期間が 終了していれば改修は困難です。 もし改修を行うとしても保守の一環として小規模に実施するか、あらたなプロジェクトとして あらためて計画しなおすことになるため時間がかかることが多くなります。
プロダクトの場合: 最小限の機能（MVP: Minimum Viable Product）を早く出し、 ユーザーの行動データや不満を分析して 継続的に改善 します。 ユーザーは「発注者」ではなく、共に プロダクトを育てる「顧客」です。
3. 成功指標 : 進捗率か、採用率か
プロジェクトの場合: 「予定通りに機能がリリースされたか（Output）」を重視します。 プロダクトの場合: 「実際にどれだけの開発者が自発的に使っているか、 満足しているか（Outcome や Adoption）」を重視します。
「プロジェクト扱い」が招く末路 : プラットフォームの負債化
プラットフォームをプロジェクトとして進めると、以下のような 「負のスパイラル」が発生します。
- 機能の押し売り: ユーザーが求めていないのに、プロジェクトの達成要件（マイルストーン）を満たすために不要な機能を実装してしまう。
- 技術の陳腐化: リリースから1年後、新しいクラウドサービスやツールが登場しても、メンテナンス体制がないため古い構成が強制され続け、開発者の足を引っ張る存在になる。
- サポートの欠如 使い方がわからないユーザーに対して「マニュアルを読んでください」で終わってしまい、ユーザー体験（DevEx）が損なわれる。
プロダクトとして扱うための「3つのアクション」
もし、今の取り組みが「プロジェクト」に寄っていると感じたら以下の転換を検討すべきです。
- プロダクトマネージャー（PdM）を置く 技術に詳しいだけでなく、「誰の、どの課題を解決するのか」を意思決定し、 ロードマップを管理する役割を明確にします。
- 社内マーケティングを行う 「良いものを作れば勝手に使うだろう」は幻想です。説明会の開催、ドキュメントの充実、 成功事例の発信など、ユーザーに選んでもらうための努力を惜しまないことです。
- 「ノーと言える」勇気を持つ 全てのチームの要望を詰め込むと、 プラットフォームは複雑怪奇なモンスターになります。プロダクトとして 「何をやらないか」を決め、一貫性を保つことが重要です。
失敗を回避する「ペルソナ設定」の重要性
「ペルソナ設定」も Platform Engineeringが挫折するもうひとつの 大きな要因です。挫折する組織の多くは、利用者のターゲットを 「全社の開発者」という広すぎる定義で設定してしまいます。 しかし、同じ「コードを書く人」でも、その背景や目的は驚くほど異なります。
「プロジェクト」と「プロダクト」の違い、の中でも説明しましたが プラットフォームは「誰にでも使いやすい」を目指すと、結果的に 「熟練者にはお節介で不自由、初心者には不親切で難解」 という「誰にとっても中途半端」なものになります。開発組織の中には、 異なるニーズを持つ複数のペルソナが存在することを理解しなければなりません。
このペルソナを特定し理解することで、「プロダクトとして扱うためのアクション」で 挙げた「誰の、どの課題を解決するのか」をより明確にすることができるのです。
ペルソナ設定
ではどのようにペルソナを特定すればよいでしょうか？ ペルソナを定義する際は、以下の2軸で考えると整理しやすくなります。
- スキル軸（抽象化の必要性） : インフラ（K8s, Terraform等）を自分で書きたいか、それとも隠してほしいか。
- 関心事軸（スピードか制御か） : 「1秒でも早くデプロイしたい」のか、「コストやパフォーマンスを極限まで最適化したい」のか。
代表的な3つのペルソナ
一般的には開発者プラットフォームは開発チーム側、プラットフォーム側で 以下のような代表的なペルソナがいます。
- アプリ開発に専念したい層 : インフラの詳細は知りたくない。「ボタン一つで環境が欲しい」というスピードを重視。
- 制御と自由度を求めるシニア層 : 標準化は歓迎するが、トラブル時に「中身が見えない」ことを嫌う。必要に応じたカスタマイズ性を求める。
- ガードレールを敷きたいセキュリティ層 : 自由度は許容しつつも、脆弱性やコストが自動的に管理される仕組みを求める。
ペルソナが不明確なことで起きる「認知的負荷の爆発」
人間が一度に扱える情報量には限界があります。ペルソナ設定の真の目的は、 この 「認知的負荷（Cognitive Load）」を最適化することにあります。
認知負荷には次の３種類があります。
- Intrinsic（課題内在性）: 基礎知識（言語の文法、サービスの仕様の理解など）。
- Extraneous（課題外在性）: 本質的でないノイズ（探し物、複雑なデプロイ手順、ツールの使い方など）。
- Germane（学習関連）: 本質的な理解や価値創造（ビジネスロジックの設計など）。
もともとPlatform Engineeringの目的は、開発チームに本質的な認知負荷である Germane 認知負荷（システム開発）に集中してもらうことにあります。 本質的ではない負荷（Extraneous / Intrinsic）となっているプラットフォームを適切に抽象化することでこれを実現します。
最適化できていないときに起きる事象は以下のようなものです。
- 過剰な抽象化 : 熟練者に「このボタン以外押せません」と制限すると、彼らは「不自由さ」というストレスを感じ、プラットフォームをバイパスして独自の環境（シャドーIT）を作り始めます。
- 不十分な抽象化 : 初心者に「このTerraformを書き換えてPRを出して」と言うと、彼らは本来の機能開発を止め、インフラ学習という高い壁に阻まれてしまいます。
こうしたことから設定されたペルソナによってプラットフォームの設計にも影響を与えます。
| ペルソナ例 | 特徴・マインドセット | プラットフォームに求めるもの | 誤った設計の例 |
|---|---|---|---|
| アプリ開発に専念したい層 | 「インフラは魔法であってほしい。ビジネス価値を出すコードに集中したい」 | GUIやテンプレート。数入力でCI/CDから監視設定まで完了する「黄金の道」。 | 生のYAMLファイルを10個以上編集させるような、低レイヤーな操作の強制。 |
| 制御と自由度を求めるシニア層 | 「中身がブラックボックスなのは怖い。いざという時は自分で設定をいじりたい」 | 拡張性と透過性。CLIで操作でき、プラットフォームの抽象化を「剥がせる」仕組み。 | 完全にブラックボックス化され、トラブル時に自分たちで調査・修正ができない仕様。 |
| ガードレールを敷きたいセキュリティ層 | 「各チームが勝手なことをして事故が起きるのを防ぎたい。コストも抑えたい」 | ガードレールと自動適用。セキュリティスキャンや予算制限が組み込まれた標準基盤。 | 手動の承認フロー。これを挟むと、プラットフォームの「セルフサービス」という利点が失われる。 |
成功の鍵 : 「誰のためのプラットフォームか」の優先順位付け
ここまでみてきたようにすべてのペルソナを同時に満足させるのは困難です。 したがって最初のステップでは、以下のような作業を実施して 「声の大きい少数層の意見に引きずられることなく」 、 「組織内で最も人数が多く、かつ最もボトルネックになっている層」 をメインペルソナに据えるべきです。
- インタビューの実施 : 想像でペルソナを作らず、現場の開発者の作業時間を何が奪っているかをヒアリングする。
- 最小限の機能（MVP : Minimum Viable Product）の対象を絞る : 最初は「新規参加したジュニアエンジニアが、初日にデプロイできるまで」のように、ターゲットを絞り込んで磨き上げる。
- オプトアウトの用意 : 熟練者のために、標準から外れるための「安全な裏口」を用意しておくことで、組織全体の反発を抑える。
「黄金の道（Golden Path）」の設計
適切なペルソナ設定ができれば、自ずと「黄金の道（Golden Path）」が見えてきます （「黄金の道」は「舗装された道（Paved Road）」と呼ばれることもあります）。 これは、プラットフォーム側が推奨する「最も抵抗が少なく、かつ安全なパス」のことです。
ペルソナごとのGolden Pathは次のようなイメージになると思います。
- アプリ開発に専念したい層 GUIやテンプレートによるフルガイド。
- 制御と自由度を求めるシニア層 にはCLIやAPIを介した柔軟な拡張性。
これらのGolden Pathやプラットフォームのコア部分にガードレールを設定することで ガードレールを敷きたいセキュリティ層 の要望を満たすようにします。
無理に使い方を統一するのではなく、 「プラットフォームを使ったほうが圧倒的に楽で安全だ」、 「プラットフォームを使えば、セキュリティ担当など管理部門に承認をもらう必要がない」 と開発者に自発的に選ばせる設計こそが、Platform Engineeringの成功の近道です。
まとめ : Platform Engineeringは「技術」ではなく「対話」から始まる
Platform Engineering の成否は、どんな高度なツール （Backstage, Kubernetes, Terraformなど）を導入したかでは決まりません。
成功の鍵は、 「プラットフォームを、特定の顧客（ペルソナ）に向けた継続的なプロダクトとして育てられるか」 という一点に尽きます。
成功のためには次のことを意識してください。
- 「開発者」を「顧客」としてリスペクトする Platform Teamは、インフラの「管理人」ではなく、開発者の生産性を最大化する 「サービスプロバイダー」です。まずは「どう使わせるか」という思考を捨て、 「何があれば彼らは喜んで使ってくれるか」という問いから始めましょう。
- 認知的負荷を「最適化」する すべての開発者にインフラの詳細を強いるのは、もはや現代の複雑な ソフトウェア開発においては非効率です。設定したペルソナに基づき、 「どこを抽象化し、どこに自由を残すか」という境界線を明確に引きましょう。
- 小さく始めて、フィードバックで改善し続ける 最初から「全社共通の完璧な基盤」を目指してはいけません。 特定のチーム、特定のペルソナにとっての「最高に楽な道（黄金の道）」をスモールステップで作ること。その成功体験こそが、組織全体にプラットフォームを波及させる最強の燃料になります。
最後に一言 プラットフォームは「生きたプロダクト」 です。
プロジェクトには「終わり」がありますが、プロダクトには「成長」があります。 開発組織の状況は日々変わります。新しい技術が登場し、ビジネスの要求も変化します。 その変化に寄り添い、常に開発者の隣で進化し続けるプラットフォームこそが、 真の競争力を生み出します。
あなたのチームが作るプラットフォームは、開発者にとって「強制されるルール」ですか？ それとも「手放せない贈り物」ですか？
まずは、現場のエンジニアへのヒアリングやちょっとした会話（チャット）から、 新しい「プロダクト」の第一歩を踏み出してみませんか。
