開発者を支える Internal Developer Portal のイマとコレカラ / To-day and To-morrow of Internal Developer Portals: Supporting Developers

Platform Engineering で語られる主要なツールの一つである Internal Developer Portal/Platform(IDP) は現在大きな転換点を迎えています。現在のところ、開発者の生産性を向上し、コミュニケーションやナレッジを向上するために有効なツール・概念である IDP は、それらを推進する Platform Engineer なしでは手を出しづらいものです。

本セッションでは、従来の IDP の概念とツールとしての技術要素に触れながら、今後より Platform Engineering を専任としないエンジニアがこれらの利点を「イマ」活かす方法を皆様と一緒に考察します。 その上で Platform Engineering の取り組みの中で IDP に求められる要素を分解し、「コレカラ」必要とされるこの先の展望を、実際の IDP を例に挙げつつご説明します。 IDP が生まれた実際の経緯から、最新の状況と展望を再考する機会をお届けします。

Transcript

1. @AoToLog_ �� 開発者を支える Internal Developer Portal のイマとコレカラ 8th Sep, Platform Engineering Meetup #14 Speaker: Kento Kimura
2. @AoToLog_ �� 話すこと 01 さあ、アプリを開発しよう！ 04 コレカラ：IDP はどこへ？ 03 イマ：みんなの IDP 02 IDP ってなんだっけ？ 05 まとめと紹介
3. @AoToLog_ �� 話すこと 01 さあ、アプリを開発しよう！ 04 コレカラ：IDP はどこへ？ 03 イマ：みんなの IDP 02 IDP ってなんだっけ？ 話さないこと 05 まとめと紹介 XX Datadog の具体的な機能解説 XX IDP の歴史 XX Golden Path の話
4. @AoToLog_ �� 話すひと • 所属： Technical Solutions / Sales Engineering • 担当： パブリッククラウドのアーキテクト知識を活かした 　 Datadog のプリセールス技術支援 • コミュニティ： Google Cloud のユーザーコミュニティ「Jagu'e'r」 Datadog のユーザーコミュニティ「JDDUG」 AWS のユーザーコミュニティ「JAWS」 • カンファレンス： 初開催！Observability Conference Tokyo 2025 木村 健人 (Kento Kimura) Datadog Japan GK
5. @AoToLog_ �� さあ、アプリを開発しよう！
6. @AoToLog_ �� さあ、アプリを開発しよう！ エディタを用意して、コードを書き初めて… コンテナイメージを作って、レジストリを準備して… テスト実行環境を用意して、CI/CD と繋げて… インフラを準備して、IaC 化して…
7. @AoToLog_ �� さあ、アプリを開発しよう！ エディタを用意して、コードを書き初めて… コンテナイメージを作って、レジストリを準備して… テスト実行環境を用意して、CI/CD と繋げて… インフラを準備して、IaC 化して… いつデプロイできるの？
8. @AoToLog_ �� 開発者が最初に準備すること… やることと求められる知識 やること • 開発環境構築 • (アプリケーション)開発 • (アプリケーション)ビルド • (アプリケーション)デプロイ • DevSecOps • IaC • AI コーディング 求められる知識 • エディタ・IDE(統合開発環境) • コーディング • アプリケーション言語 • ランタイム・コンテナ・OS • CI/CD • GitOps • オブザーバビリティ • Terraform, CloudFormation, CDK, ARM+Bicep • AI コーディングエージェント … … … 開発者が注力したいもの
9. @AoToLog_ �� どのタイミングで必要なの？ 1. 開発チームのオンボーディング • 新入社員 • チームへの合流 • 新規開発 2. 組織内標準のアプローチ • VM の払い出し • チーム間のコミュニケーション手法 • ベストプラクティスの共有 3. セキュリティ • SBOM・署名の提供 • オブザーバビリティの整備 プラットフォームが提供するもの： 開発上の本質ではない、組織上の制限や 特定の推奨事項の提供・プロダクトの統合 開発者が注力したいもの： 開発で重要視される、プロダクトの設計や 効率的なフレームワーク・ライブラリの選定、 パフォーマンス向上の工夫、外部 API の設計 組織共通のプラットフォームを通して、開発プロセスの効率化=ソフトウェアの整備 を行うことで、開発者の生産性が向上できそうなタイミング！
10. @AoToLog_ �� Platform Engineering とは 組織において有用な抽象化を行い、 セルフサービス インフラストラクチャを構築するアプローチ 有用な抽象化とは “ “ 迅速なプロジェクト開発に役立つ 巧みに統合されたコードと機能のテンプレート構成 “ “ 引用：『道を照らす: プラットフォーム エンジニアリング、ゴールデンパス、セルフサービスのパワー』 散乱したツールをまとめ、開発者の生産性を高める • テンプレートの提供：スケルトンソースコード・IaC ファイル・Kubernetes yaml ファイル • ドキュメントの整備：スタートアップガイド・リファレンス • モニタリング標準化：依存関係の管理・オブザーバビリティの整備
11. @AoToLog_ �� IDP ってなんだっけ？
12. @AoToLog_ �� Platform Infrastructure 頻繁に語られる2つの IDP 開発・製品チームが迅速にソフトウェアを デプロイしサービスを提供するための… …単一のインターフェース →Internal Developer Portal 　(社内開発者ポータル) …複雑性を排除した中心的な基盤 →Internal Developer Platform 　(社内開発者プラットフォーム) Platform Engineering： プラットフォームと開発・製品チームを繋ぐ ID Portal を ID Platform を通して提供する Platform Tools Developer and Product Teams Internal Developer Platform (社内開発者プラットフォーム) Reusable Component Tools Platform Service Knowledge Internal Developer Portal (社内開発者ポータル) 推奨パス 例外パス
13. @AoToLog_ �� Platform Infrastructure IDP に求められるもの 開発・製品チームが共通して利用する ツールやサービスを見つけられる、 単一のインターフェース・UI Platform Tools Developer and Product Teams Internal Developer Platform (社内開発者プラットフォーム) Reusable Component Tools Platform Service Knowledge Internal Developer Portal (社内開発者ポータル) 推奨パス 例外パス プラットフォームチームが統制し、 ポータルに機能を提供する API を持つ 保守性・拡張性の高いサービス 意思決定を迅速にするガードレールと 例外を許容するブレークグラスを持つ 柔軟なツールとしてのエコシステム
14. @AoToLog_ �� Backstage: 最も有名な CNCF の IDP プロジェクト • CNCF の incubating プロジェクト • Spotify により2020年に寄贈 • Internal Developer Portal を 構築するオープンフレームワーク • コア・アプリ・プラグインの3つの コンポーネントで構成される • インテグレーションとプラグインで のカスタマイズが可能 引用：Backstage『Software Catalog / Overview』『Software Template / Overview』『TechDocs / TechDocs Addons』
15. @AoToLog_ �� Backstage: 2つの IDP Platform Infrastructure Platform Tools Developer and Product Teams Internal Developer Platform (社内開発者プラットフォーム) Reusable Component Tools Platform Service Knowledge Internal Developer Portal (社内開発者ポータル) 推奨パス 例外パス Integrations Infrastructure Services Plugins Other Tools Backstage App Backstage Plugin Software Templates Software Catalog TechDocs 推奨パス 例外パス Backstage Core UI Backstage Plugin UI + Database
16. @AoToLog_ �� Backstage: IDP に求められるもの 開発・製品チームが共通して利用する ツールやサービスを見つけられる、 Backstage(+ Plugin) UI プラットフォームチームが統制し、 ポータルに機能を提供する App を持つ 保守性・拡張性の高い Core/App 意思決定を迅速にするガードレールと 例外を許容するブレークグラスを持つ 柔軟な Core/Integration/Plugin 引用：Backstage『Software Catalog / Overview』『Software Template / Overview』『TechDocs / TechDocs Addons』
17. @AoToLog_ �� 開発者を支える Internal Developer Portal のイマとコレカラ 8th Sep, Platform Engineering Meetup #14 Speaker: Kento Kimura
18. @AoToLog_ �� 開発者を支える Internal Developer Portal のイマとコレカラ 8th Sep, Platform Engineering Meetup #14 Speaker: Kento Kimura 開発者を支える Internal Developer Portal のイマとコレカラ 答えがある話ではないため、 カタカナで誤魔化しています…
19. @AoToLog_ �� イマ：みんなの IDP
20. @AoToLog_ �� IDP を導入・利用している方！！
21. @AoToLog_ �� IDP って本当に使われているの？ IDP サービスを提供する Port 社が2024年に 欧米の企業を中心に行った調査レポートでは、 50%の企業が Internal Developer Portal を採用 ※150名以上の開発者を抱える企業の従業員100名 つまり… 日本の少数精鋭な中小企業ではもっと少なそう… 引用：Port.io『2024 State of internal developer portals』 考えられる理由として… • Platform Engineering の取り組みはあるが、 専任のチームは存在しない • ある程度の標準化や共通化が行われているが、 IDP と呼べるレベルものではない • ある程度のドキュメント整備は行っているが、 稼働しているサービスの実態と乖離している
22. @AoToLog_ �� みんなのプラットフォームエンジニアリング 専任の Platform Engineer がいなくともできる取り組みから始める ＝プラットフォームより開発者体験を向上する取り組みを始める IDP がないと思っていても、プラットフォームは出来上がっているかも🤔 1. コードを本番環境に適用するまでの手法 2. インフラストラクチャをプロビジョニングする手順 3. 開発やプロダクトの関連する体系的な知見 4. 複数チームにまたがる承認フロー 既に出来上がったプロセス=「プラットフォーム」をモデル化・効率化する ソフトウェアを構築することが Platform Engineering となる！
23. @AoToLog_ �� CNCF：IDP の将来についての会話 2024年9月30日、CNCF ブログで貴重な Internal Developer Portal のトピック 【抄訳】 プラットフォームエンジニアリングで成功する鍵 • 同じソフトウェア手法を各開発チームにも適用すること • プラットフォームを製品として扱うこと • 製品が達成しようとしていることを定義し、常に改善方法を模索すること ポータルの使いやすさと視覚的な性質が開発者の価値基準 • フロントエンドからロジックを分離すること • Infrastructure as Codeと宣言型の手法を用いてポータルを構築すること • オープンソースプラグインの共有を通じてコミュニティと負荷を分担すること 参考：CNCF ブログ/コミュニティ投稿『社内開発者ポータル（IDP）の将来についての会話』 “ “ “ “
24. @AoToLog_ �� CNCF：IDP の将来についての会話 2024年9月30日、CNCF ブログで貴重な Internal Developer Portal のトピック 【抄訳】 プラットフォームエンジニアリングで成功する鍵 • 同じソフトウェア手法を各開発チームにも適用すること • プラットフォームを製品として扱うこと • 製品が達成しようとしていることを定義し、常に改善方法を模索すること ポータルの使いやすさと視覚的な性質が開発者の価値基準 • フロントエンドからロジックを分離すること • Infrastructure as Codeと宣言型の手法を用いてポータルを構築すること • オープンソースプラグインの共有を通じてコミュニティと負荷を分担すること 参考：CNCF ブログ/コミュニティ投稿『社内開発者ポータル（IDP）の将来についての会話』 “ “ “ “ プラットフォーム側も 楽しようね😇😇😇😇
25. @AoToLog_ �� コレカラ：IDP はどこへ？
26. @AoToLog_ �� IDP はどこへ？ 開発・製品チームが利用したいのは Internal Developer Portal Internal Developer Platform の管理は IDP を導入する障壁 1. SaaS IDP IDP サービスを SaaS として 提供し、利用者が管理する 要素を極力削減する ex) Spotify for Backstage, Port.io 2. IDP in Cloud プラットフォームの基盤を 提供するクラウドサービス 自身が IDP 機能を提供する ex) Google Cloud App Hub, Cloud Hub 3. IDP in O11y ソフトウェアの実働状態を 把握できる O11y を通して IDP がサービス管理する ex) Datadog Internal Developer Portal プラットフォーム側も 楽しようね😇😇😇😇
27. @AoToLog_ �� Example: Spotify for Backstage IDP のオープンフレームワークである Backstage をその生みの親である Spotify が SaaS として標準機能を提供し、Platform の管理を不要にする IDP の導入の障壁であった Platform 側を意識することなく、必要な Portal のサービスが利用できる 引用：Spotify for Backstage『Putting Backstage into action』
28. @AoToLog_ �� Example: Google Cloud App Hub サービスとワークロードの標準化された論理構造である「アプリケーション」に定義し、 開発・製品・プラットフォームチームの管理範囲を明確にする デプロイされたサービスは自動検出され、アプリケーションからテンプレートをデプロイできる 引用：Google Cloud Blog『App Hub - トイルを排除したアプリケーション管理を実現』
29. @AoToLog_ �� Example: Datadog Internal Developer Portal 検出されたテレメトリーデータから標準化された「システム」と「サービス」を定義し、 開発・製品・プラットフォームチームに必要なセルフサービスアクションを提供する オブザーバビリティの力でサービスの実態を把握し、同一のプラットフォームで実際のアクションに繋げる 引用：Datadog Documentation『Internal Developer Portal』
30. @AoToLog_ �� Internal Developer Portal のその先 Platform Engineering は開発者体験の 向上が目的だが、IDP の構築が目的に なると本末転倒… PFE 側も楽をして、SaaS や他プラット フォーム上の ID Platform の活用で、 最小限の管理リソースで開発者ための インターフェースである ID Portal を 提供できる！！ 結論：みんな幸せ Developer and Product Teams Internal Developer Platform (社内開発者プラットフォーム) 管理不要 Internal Developer Portal (社内開発者ポータル) 推奨パス 例外パス
31. @AoToLog_ �� まとめ
32. @AoToLog_ �� まとめ • Internal Developer Portal はさまざまなツールやサービスを 開発・製品チームが利用できるようにするインターフェース • Internal Developer Portal を導入することを目的にすると、 Platform Engineering の目的(開発者生産性の向上)からは離れてしまう • IDP はさまざまな方法で Platform の管理が不要になるよう進化し、 専任 Platform Engineer 不要で開発者が有用な抽象化ができる
33. @AoToLog_ �� 宣伝
34. @AoToLog_ ��
35. @AoToLog_ �� OCT 16, 2025
36. @AoToLog_ �� OCT 16, 2025
37. @AoToLog_ �� Thank you!