Port、Spreadsheetで管理されるサービス情報をinternal developer portalへ変えた転換

Zohar EinyとYonatan Boguslavskiは、イスラエル国防軍8200部隊で大規模な社内developer portalを作った経験を持つ。出典

Port is a non-code platform for internal developer portals

二人が見た課題は、開発者が必要な情報や環境を得るたびに、platform teamへ個別に依頼しなければならない状態だった。

Portはその経験を、service catalogとself-service actionsを組み合わせる製品へ翻訳した。出典

市場がplatform engineeringへ向かうにつれ、Portの役割も単なる一覧表から、scorecardやgovernanceを含む運用面へ広がった。

2024年の調査は、internal developer portalが一部の先進企業だけの話ではなくなったことを示している。出典

現在のPortはagentic SDLCを掲げ、engineering teamがソフトウェア開発の流れをbuild・govern・operateする platform として自らを位置づける。

創業時の「情報を見つけられない」問題は、AI agentを含む複雑な開発フローを安全に動かす問題へ拡張された。出典

PortのPMFは、開発組織が増えるほど膨らむ「誰が何を所有し、どう安全に実行するか」という摩擦にある。

service catalogで情報を集約し、self-service actionsで手順を標準化することで、platform teamは個別依頼の受付から再利用可能な仕組みの提供へ移れる。出典

State of internal developer portals 2024では、回答企業の約85%がinternal developer portalを導入済みまたは導入予定とされ、市場課題の広がりを示す。出典

moatは単一の機能ではなく、catalog・workflow・scorecardを各チームの運用に埋め込むことから生まれる。

連携と権限の設定が蓄積するほど、別製品への移行コストは上がるが、データ品質が前提になる。出典

ネットワーク効果は中程度。

利用チームが増えるほどcatalogの共有価値は上がる一方、一般消費者向けの直接的なnetwork effectではなく、組織内の共通文脈が強くなるタイプだ。出典

主な対象は、複数のservice・cloud・engineering teamを抱え、platform teamを設置または設置しようとしている企業だ。

開発者自身にはself-serviceを、platform teamにはgovernanceを提供する。

小規模で所有関係が単純なチームや、catalogを維持する担当を置けない組織には過剰になり得る。出典

第一に、catalog・actions・scorecardsを一つの運用面にまとめたこと。

第二に、Backstageなど既存選択肢との比較情報を公開し、導入判断の材料を増やしたこと。出典

第三に、テンプレートとcustomer storyで、抽象的なplatform engineeringを具体的なworkflowへ落とし込んでいる。出典

導入にはservice ownershipや権限設計の整理が必要で、ツールだけでは組織の曖昧さを解消できない。

catalogの品質が下がればポータルは新しい情報の分断点になる。

また、BackstageやCortexなど複数の競合と同時に比較される市場であり、差別化の説明を継続する必要がある。出典

主な成長導線は、internal developer portalの教育コンテンツ、比較ページ、template、customer storyの組み合わせだ。

検索で課題を持つplatform teamを呼び込み、free利用や導入相談で具体的なworkflowへ接続する。出典

この方法は営業だけに依存せず、導入前の理解を広げられる。

一方で、組織ごとの設計差が大きいため、標準化と個別支援のバランスが課題になる。

主要チャネル: content, community, customerStories, productLed

新しいカテゴリのSaaSでは、機能を増やすより先に、既存のSpreadsheetや個別依頼が生む摩擦を具体的なworkflowとして翻訳することが重要だ。

Portのようにcatalogを入口にself-serviceとgovernanceを接続すると、開発者体験と管理者の統制を対立させずに設計できる。出典

日本企業では、部署ごとに異なる申請・運用手順と、属人化したservice ownershipが導入の壁になりやすい。

まず全社ポータルを目指すより、クラウド利用申請やrelease checklistなど頻度の高いworkflowからcatalog化するのが現実的だと考えられる。

日本語の運用規程、監査ログ、承認フローをテンプレートとして整備できれば、platform engineeringを導入する際の翻訳コストを下げられる。