Slide 1

Slide 1 text

1 開発者ポータルって必要? エンタープライズにおける Platform Engineering 立ち上げの現実解 Shintaro Kitamura Specialist Solution Architect Red Hat K.K. クラウドネイティブ会議

Slide 2

Slide 2 text

2 2 北村 慎太郎 - Shintaro Kitamura Red Hat - Senior Specialist Solution Architect 出身 神奈川県 横浜市 ● アプリケーションプラットフォーム(OpenShift)を中心としたプリセー ルス ● エンタープライズ企業の”失敗しないコンテナ導入”を実現 すべく日々奮闘中 ● Ops/SRE → Platform Engineering 趣味 テニス 麻雀 カフェ巡り ひとりカラオケ

Slide 3

Slide 3 text

3 今日のテーマ 開発者ポータルって必要?

Slide 4

Slide 4 text

4 開発者ポータル(Internal Developer Portal)とは Internal Developer Portal ユーザー体験 バックエンド連携 Git CI/CD Kubernetes Security Docs ソフトウェアカタログ 誰が何を所有し、どう動いているかを可視化す る「単一の真実の情報源」 ソフトウェアテンプレート ワンクリックで「Golden Path」に沿った 開発・実行環境を自動構築 プラグイン統合 サイロ化したツール群(監視、 CI/CD、 セキュリティ等)を1つのUIに集約 開発者

Slide 5

Slide 5 text

5 最近よく言われていること きれいなポータル画面を 作る前に、裏側のインフラ を整えるべきでは? そもそも、AIが全部やって くれる時代がすぐそこに来 ているのに? 新しいツールを入れても、 結局使われずにPoCで終 わるのでは?

Slide 6

Slide 6 text

6 最近よく言われていること きれいなポータル画面を 作る前に、裏側のインフラ を整えるべきでは? そもそも、AIが全部やって くれる時代がすぐそこに来 ているのに? 新しいツールを入れても、 結局使われずにPoCで終 わるのでは?

Slide 7

Slide 7 text

7 Platform Engineering 成熟度モデルと解決策 1. Ad-hoc 2. Automated 3. Scalable Platform 4. Optimizing 手動作業・Wiki依存 各種ツールの導入・自動化 複雑性の統合・隠蔽 自律的運用・改善 IaCで 実現する世界 開発者ポータルで 実現する世界

Slide 8

Slide 8 text

8 EnterpriseにおいてPlatform Engineeringが動き出しづらい理由 インフラ、開発、セキュリティ、運用、監査のサイロ化 Excelやメールの海に埋もれた申請・承認フロー 標準化はされているが、実行経路がバラバラ Wikiや設計書はあるが、どれが最新か誰も知らない

Slide 9

Slide 9 text

9 Create Service 開発者ポータルを「変革の旗印」として概念を視覚化する 標準化パラメータガイド セキュリティガードレール セルフサービス利用ガイドライン テクニカルアーキテクチャ 運用設計 抽象的な概念 見える変化 リポジトリ作成 セキュリティスキャン CI/CD構成 デプロイ サービスカタログ登録

Slide 10

Slide 10 text

10 なぜポータルは「後回し」ではなく「並行稼働」すべきなのか 「後」っていつ? 繰り返される 「後回し」の失敗 組織の文脈は 「今」しか集まらない 複雑なインフラやプロセスの完 全な整理を待つと、永遠にポー タルは完成しない。 概念論に終始し、「変革の体 験」がいつまでも開発者に届か ない。 「ドキュメントは後で」「テストは 最後に」と同じ現象。 インフラ整理を優先しポータル を後回しにすると、実態との乖 離や手戻りが発生し、できた頃 には誰も使わないプラットフォー ムに。 カタログの中核である依存関係 の情報は、後からの棚卸しアン ケートでは揃わない。 最初からポータルをプロセスに 組み込むことで、正しいデータ が維持される。

Slide 11

Slide 11 text

11 最近よく言われていること きれいなポータル画面を 作る前に、裏側のインフラ を整えるべきでは? そもそも、AIが全部やって くれる時代がすぐそこに来 ているのに? 新しいツールを入れても、 結局使われずにPoCで終 わるのでは? 後で入れるほうが困難。 変革の旗印としてうまく活 用しよう。

Slide 12

Slide 12 text

12 最近よく言われていること きれいなポータル画面を 作る前に、裏側のインフラ を整えるべきでは? そもそも、AIが全部やって くれる時代がすぐそこに来 ているのに? 新しいツールを入れても、 結局使われずにPoCで終 わるのでは?

Slide 13

Slide 13 text

13 誰もが抱く、次なる疑問 AIがコードを書き、 設定を作り、 デプロイまで支援する時代に、 人間が情報を探すため のポータル画面は 不要になるのではないか?

Slide 14

Slide 14 text

14 ポータル画面を毎回開く体験は減っていく 減少するUXの価値 ● 人間が毎回ブラウザで情報を探す体験 ● IDEからのコンテキストスイッチ(Alt+Tab) ● 目的地としてのポータル 消えない価値 ● 組織固有の文脈 ● 承認済のサービスカタログとアーキテクチャ標準 ● セキュリティとコンプライアンスのガードレール

Slide 15

Slide 15 text

15 開発者ポータル(Internal Developer Portal)とは Internal Developer Portal ユーザー体験 バックエンド連携 Git CI/CD Kubernetes Security Docs ソフトウェアカタログ 誰が何を所有し、どう動いているかを可視化す る「単一の真実の情報源」 ソフトウェアテンプレート ワンクリックで「Golden Path」に沿った 開発・実行環境を自動構築 プラグイン統合 サイロ化したツール群(監視、 CI/CD、 セキュリティ等)を1つのUIに集約 開発者 →何が存在し、誰が責任を持つのか →どう作れば標準に沿うのか →作ったものが安全・運用可能かどうか AIが企業内で安全に動くための “Enterprise Context” を持つ

Slide 16

Slide 16 text

16 コンテキストなきAIは自信満々なハルシネーションマシンと化す エンタープライズレディなエージェント ・承認済みパッケージの使用 ・組織ルールの自動適用 ・ガードレール内での自律動作 自信満々なハルシネーションマシン ・アーキテクチャ標準の無視 ・コンプライアンスのスキップ ・間違った環境へのデプロイ Enterprise Contextへのアクセス AI の 能 力 High Low None Full 従来の手作業

Slide 17

Slide 17 text

17 The dual-purpose IDP ブラウザ IDE Cursor Claude Copilot Human Developers AI Agents Internal Developer Portal 両者が参照・実行する共通の入口 ガードレールを設定し、 AIの実行を監督・承認する。 組織の現実に沿って、 自律的にタスクを実行する。 Catalog Policy Template Infrastructure Enterprise Context 人間とAIが「同じ現実」を見るための Control Plane

Slide 18

Slide 18 text

18 Golden Path for AI Guardrail Guardrail Developers Business Value SBOM生成 脆弱性 スキャン 署名 ポリシー チェック Deploy Build Run Code Golden Path Platform Engineer 人間の意図 コンプライアンス要件 セキュリティポリシー アーキテクチャ As-Is To-Be AI Agents 作成 実行 実行

Slide 19

Slide 19 text

19 Agent Gateway 標準プロトコルによる、エンタープライズ文脈への統制されたアクセス どのエージェントを使用しても、同じ統制された企業コンテキストを安全に提供 Cursor Claude Copilot Model Context Protocol (MCP) ソフトウェアカタログ テンプレート Wiki

Slide 20

Slide 20 text

20 最近よく言われていること きれいなポータル画面を 作る前に、裏側のインフラ を整えるべきでは? そもそも、AIが全部やって くれる時代がすぐそこに来 ているのに? 新しいツールを入れても、 結局使われずにPoCで終 わるのでは? ポータルは人間とAI両方 に対して進化する。情報 の価値は変わらない。

Slide 21

Slide 21 text

21 最近よく言われていること きれいなポータル画面を 作る前に、裏側のインフラ を整えるべきでは? そもそも、AIが全部やって くれる時代がすぐそこに来 ているのに? 新しいツールを入れても、 結局使われずにPoCで終 わるのでは?

Slide 22

Slide 22 text

22 小さく始め、利用されながら育てる5ステップ Step 1:見える価値から始める CICD連携、リポジトリ作成など「デモで伝わる体験」を最初に作る Step 2: Golden Pathを「1つ」作る 全パターン網羅はNG。まずはWeb APIやコンテナ等、代表的なルートに救る Step 3: Guardrailを最小限入れる 統制を重くしすぎず、コンテナスキャンや必須メタデータなど最低限から Step 4:利用状況を見て改善する どのテンプレートが使われたか?どこで詰まったか?を計測し改善サイクルへ Step 5: AI Readyな基盤 へ拡張 MCP経由での AIアクセス、 AIによるSelf-service Actionの実行へ

Slide 23

Slide 23 text

23 AI開発時代を支えるプラットフォーム Guardrail Guardrail SBOM生成 脆弱性 スキャン 署名 ポリシー チェック Deploy Build Run Code Golden Path 迷わず安全に開発を進めるための AI-Readyなポータル SBOM生成 / 管理 デジタル署名 / 検証 DevSecOpsパイプライン ソフトウェアサプライチェーンの保護と DevSecOpsの完全自動化 あらゆるインフラ上で標準化された開発者体験と一貫した運用を提供する アプリケーション開発・運用プラットフォーム Red Hat Lightspeed AIを使って ITモダナイズを加速 Enterprise Context AI Agents MCP Server

Slide 24

Slide 24 text

24 PoC死を回避し、プロダクトとして育てる デモでは動くが 本番利用されない 運用担当が 決まらない セキュリティ部門 との接続なし Platformの オーナーを決める 最初の利用チーム を明確化 Sec/Ops部門を 初期から巻き込む KPIとロード マップを持つ プロジェクト思考 プロダクト思考 ● ポータルを立てた ● テンプレートを作った  PoC死  (昔やったPoCとして放置) 全社基盤として スケールする第一歩

Slide 25

Slide 25 text

25 組織を動かす「着火剤」としての第三者利用 Dev Sec Ops Red Hat コンサルティン グサービス (着火剤) ご提案 社内に推進者を立てづらいなら、我々のよう な部外者を「着火剤」としてうまく活用してくだ さい。 PoC死をく第 2の壁:「オーナー( Who)をどう決めるか?」 自分たちだけでサイロを壊し、リーダーシップを発揮できるなら苦労はしない。 「Platform Engineering」という プラクティス自体の組織導入 アクション 各部門のステークホルダーを、同じテーブル に座らせ、議論を前に進めるお手伝い(組織 編成支援)からスタート。 効果 運用責任とオーナーシップが明確化され、 「誰も旗を振れない」状態から脱却。 PoCを全 社基盤へとスケールさせる推進力を生み出 す。

Slide 26

Slide 26 text

26 海外での導入事例 課題 情報の散在やセキュリティの障壁により、開発の待機時間が発生。開発 プロセスの可視化不足が、組織的なコラボレーションを阻害していた。 成果 ● 標準化された基盤(OpenShift)との統合により、ソフトウェア開発サ イクルを短縮 ● 概念実証(PoC)を通じて、開発者の生産性向上とサイクルタイムの 短縮を実証 ● オープンソース・アプローチによる柔軟なインフラ対応とベンダーロッ クインの回避 課題 ツール・プロセスの統制および標準化の欠如。リソースの散在により、利 用開始時(オンボーディング)の摩擦や運用効率の低下を招いていた。 成果 ● API管理とDeveloper Hubの統合により、従来欠如していた「単一の 統合プラットフォーム」を実現 ● プロセスの標準化によりガバナンスを強化し、一貫性のある運用体 制を構築 ● サードパーティツールとの統合および高い拡張性による、最適なソ リューションの確立 海外 政府機関 ヨーロッパ大手銀行

Slide 27

Slide 27 text

27 Red Hat 社内でも開発者ポータルを活用 Red Hat Developer Hub は、Red Hat 社内で500名以上 の開発者に利用されている お客様向けコンソールの開発を支えるプラットフォームと なっている ドキュメントの一元化とチャットボット活用により、開発者体 験の向上を実現している プラグイン開発を含む形で、各チームの知見が製品開発 へ還元されている

Slide 28

Slide 28 text

28 最近よく言われていること きれいなポータル画面を 作る前に、裏側のインフラ を整えるべきでは? そもそも、AIが全部やって くれる時代がすぐそこに来 ているのに? 新しいツールを入れても、 結局使われずにPoCで終 わるのでは? 適切なツールと「着火剤」を 活用して意味あるPoCにしましょ う

Slide 29

Slide 29 text

29 未来に向けたプラットフォームを、今始める 開発者ポータルは Platform Engineeringを組織に見せる「変革 の 旗印」であり、標準を実行可能にする「入口」である。 開発者ポータルは将来、 AIエージェントが迷わず、逸脱せず、説 明責任を持って働くための「 Control Plane」となる。 デモで終わらせず、実際の開発経路につなぎ、運用責任と改善サ イクルを持つ「プロダクト」として育ててください。

Slide 30

Slide 30 text

30 linkedin.com/company/red-hat youtube.com/@redhat facebook.com/redhatinc x.com/RedHat Red Hat is the world’s leading provider of enterprise open source software solutions. Award-winning support, training, and consulting services make Red Hat a trusted adviser to the Fortune 500. Thank you アンケートにご回答ください