ゴールデンパスは敷いただけでは道にならない ─ 企画部門のエンジニアが技術標準を事業価値に変えるまで

「Developers Summit 2026 Summer」での登壇資料です。
イベントURL：https://event.shoeisha.jp/devsumi/20260716

Transcript

1. © 2026 Mizuho Bank, Ltd. ゴールデンパスは敷いただけでは道にならない ─ 企画部門のエンジニアが 技術標準を事業価値に変えるまで Developers Summit 2026 Summer 2026年7月16日 情報数理工学研究所 デジタル技術開発部 0 （免責事項） 当レポートは情報提供のみを目的として作成されたものであり、商品の勧誘を目 的としたものではありません。本資料は、当社が信頼できると判断した各種デー タに基づき作成されておりますが、その正確性、確実性を保証するものではあり ません。また、本資料に記載された内容は予告なしに変更されることもあります。
2. © 2026 Mizuho Bank, Ltd. 自己紹介 1 主な業務経歴 ⚫ 2018～ CCoE で銀行向けプラットフォームの継続的サービス改善 ⚫ 2021～〈みずほ〉のお客さま向けプラットフォームを構築・運用 ⚫ 2025～ 育休からの復職を機にゴールデンパスの企画・設計へ 発信活動 ⚫ builders.flash 連載、社内コミュニティ運営 ⚫ 各種テックカンファレンス、勉強会に登壇 （クラウドネイティブ会議 / DevOpsDays Tokyo / ServerlessDays Tokyo 等） 松尾 優成 上席主任研究員 技術と組織の両面から、プラットフォームエンジニアリングを推進！
3. © 2026 Mizuho Bank, Ltd. はじめに 2 本日の結論 「技術標準を現場に届け、組織に根付かせる3つの軸」 作る力と、届ける力は別物 01 「届ける」と「手放す（出口）」を同時に設計する 02 技術標準を使われ続けるプロダクトとして扱う 03 適用先ゼロから始まった実話をお伝えします
4. 序章 なぜ「届ける」話なのか 3
5. © 2026 Mizuho Bank, Ltd. 序章：なぜ「届ける」話なのか 4 〈みずほ〉における AI 活用の加速 ✓ 全社で AI 活用に力を入れており、AI 案件が急激に増加 ✓ セキュアで統一された開発環境が必要に その中で求められたのが「安全に、速く」開発を進める仕組み 業務効率化 情報収集・分析 コミュニケーション支援 ビジネス支援 AI 活用サポート
6. © 2026 Mizuho Bank, Ltd. 序章：なぜ「届ける」話なのか 5 「安全に、速く」を支える『ゴールデンパス』の導入 ⚫ 閉域ネットワーク構成など、複雑な基盤要件や統制を吸収 ⚫ 自由度は保ちつつ、ベストプラクティスに自然と誘導 迷わず、安全なルートで アプリ開発に集中できる！ ゴールデンパス AWS IaC CI/CD 基盤仕様 社内統制 閉域構成 アプリ 開発
7. © 2026 Mizuho Bank, Ltd. 序章：なぜ「届ける」話なのか 6 ゴールデンパスは、3層の「間」に位置する ゴールデンパス 安全な道 （統制と自由度の中間） プラットフォーム 基盤・統制 （強制力：高） 案件 アプリ開発 （自由度：高） プラットフォームチーム 案件推進チーム 技術企画部門 （私たちのチーム） 立場を跨いで動くからこそ、「届ける」ことが難しい…
8. © 2026 Mizuho Bank, Ltd. 序章：なぜ「届ける」話なのか 7 1. 適用先がない中で、どう立ち上げたか 2. 理想の技術より、現場に届く技術を選ぶ 3. 現場を巻き込み、共に育てる 4. 「手放す前提」の中で、どう続けるか 5. 外部発信を、組織の追い風に 本日話すこと ～5つの壁と乗り越え方～ ※技術の中身ではなく、現場に「どうやって届けたか」の話
9. 第1章 適用先がない中で、どう立ち上げたか 8
10. © 2026 Mizuho Bank, Ltd. 第1章：適用先がない中で、どう立ち上げたか 9 技術スタック標準化にアサイン（3名でスタート） ⚫ 所属部門が先行投資として認めたプロダクトアウト型のミッション ⚫ 実案件は期限に追われ、従来技術が選ばれがち ⚫ 腰を据えて「現場で使われる標準」を先に用意 技術スタック標準化 （ベストプラクティス） ？ あえて決めずにスタート ミッション 届ける先
11. © 2026 Mizuho Bank, Ltd. 第1章：適用先がない中で、どう立ち上げたか 10 プラットフォーム側だけでなく、ユーザー側を知りにいく ① Platform as a Product を実践する中で ユーザー目線が強まる（真に解決したい課題は？） ② 自身のキャリア面談で 「アプリ・ビジネスに近い領域」を希望 ③ 技術企画部門から内製開発案件に兼務で参加 ユーザー側の景色・アプリ目線を知る 越境することで、標準化すべき課題が見えてきた
12. © 2026 Mizuho Bank, Ltd. 第1章：適用先がない中で、どう立ち上げたか 11 現場で見えたのは、案件をまたいで繰り返される共通課題 ⚫ 兼務メンバーで、案件横断の課題を収集（30件超） ⚫ 案件固有の課題より、横断して繰り返される課題が目立つ ⚫ 標準化で解ける課題、技術では解けない課題を仕分け • 案件ごとに技術スタックを選定し、バラバラ • スピード優先で、セキュリティが後回し • デプロイが手作業で、変更の度に時間がかかる 課題の一例
13. © 2026 Mizuho Bank, Ltd. 第1章：適用先がない中で、どう立ち上げたか 12 ゴールデンパスの形はできたが、適用先がない ⚫ GitHubで公開されている ICASU を基にゴールデンパスを整備 ⚫ 現場課題を取り込んだが、適用先の案件がない… ⚫ モチベーションを維持するため、「ふりかえり」を実施 ICASU… https://github.com/classmethod/icasu-cdk-ecs-fargate-sample まずはここまで 作り切ったことを 讃えよう 届けるために 次の一歩を決めよう…！
14. © 2026 Mizuho Bank, Ltd. 第1章：適用先がない中で、どう立ち上げたか 13 “Wiz Base”の正式リリースで、適用先が見えた ⚫ AI エージェントを動かすための社内共通プラットフォーム ⚫ 閉域・統制が厳しく、Wiz Base 上での開発標準が求められていた ⚫ ここで初めて、ゴールデンパスの適用先が見えた 作り切った ゴールデンパス （適用先なし） Wiz Base 正式リリース （開発標準が必要） Wiz Base 向けに 調整/導入を提案
15. © 2026 Mizuho Bank, Ltd. 第1章：適用先がない中で、どう立ち上げたか 14 まずは、どの案件でも使える汎用的な構成から設計 ⚫ 閉域構成では選択肢が限られ、既存案件はリアーキが必要 ⚫ そこで Amazon ECS ベースの標準構成をテンプレート化 Direct Connect Gateway Transit Gateway テナントVPC 社用端末 標準構成の概略イメージ ECS + Aurora を 中心に標準化 ECS on Fargate
16. © 2026 Mizuho Bank, Ltd. 第1章：適用先がない中で、どう立ち上げたか 15 実案件に適用して、標準構成のギャップを埋める ⚫ 実案件へのゴールデンパス適用が決定し、想定外の要素がでてきた ⚫ 実案件を踏まえて、標準構成とサンプルアプリを見直し テナントVPC 実案件で必要な要素を追加 汎用設計はあくまで仮説 実案件に適用して初めて、現場に沿っているかが分かった
17. 第2章 理想の技術だけでなく、現場に届く技術を 16
18. © 2026 Mizuho Bank, Ltd. 第2章：理想の技術だけでなく、現場に届く技術を 17 すべてを標準化できないため、担保する範囲を決める 閉域の環境払い出しからアプリ疎通確認に1ヵ月ほどかかっていた ⇒ゴールデンパスは疎通確認までを担保することに アプリは、案件固有の要件を考慮して最小限に ゴールデンパスが担保する範囲 案件側で作りこむ範囲 開発者
19. © 2026 Mizuho Bank, Ltd. 第2章：理想の技術だけでなく、現場に届く技術を 18 現場の経験と、標準として選んだ技術スタックのギャップ IaC（Infrastructure as Code）は、AWS CDKを選定 一方で現場には Terraform 経験者も多く、移行時のギャップがあった ⚫ 静的型付けにより、人も AI も安全にインフラを定義できる ⚫ よく使う構成を抽象化し、再利用可能な部品として扱える ⚫ 標準構成をバージョン管理して、各案件に展開できる AWS CDK で目指した標準化のかたち
20. © 2026 Mizuho Bank, Ltd. 第2章：理想の技術だけでなく、現場に届く技術を 19 技術選定では、導入先との親和性と将来の拡がりを重視 ⚫ Wiz Base も CDK を採用しており、運用・ガバナンスを揃えやすい ⚫ 社内研修で多数の社員エンジニアに CDK の素地がある ⇒ 適用環境の親和性と、全社の人材プールを考慮して IaC を選定 技術の優劣ではなく、今の現場に届き これからの担い手に拡がるかで選ぶ 2021～ CloudFormation 研修開始 2024～ CDK 研修開始 2025～ Wiz Base 上で 内製開発が増加
21. © 2026 Mizuho Bank, Ltd. 第2章：理想の技術だけでなく、現場に届く技術を 20 標準として選んだ技術を、現場へ届く形にする Terraform 経験者には、CloudFormation 特有の挙動がギャップに （デプロイ失敗時に長時間実行となり、開発者体験が低下） 方針を決めただけでは使われない 移行の節目に伴走することで、現場に届く ⚫ 現場エンジニアとの直接対話で、躓きを拾う （0→10ではなく、まずサンプルアプリで0→1のデプロイを成功） ⚫ IaC 構想の違いとCDK Tipsをドキュメント化し、共有会を開催 現場の躓きを基に伴走
22. 第3章 現場を巻き込み、共に育てる 21
23. © 2026 Mizuho Bank, Ltd. 第3章：現場を巻き込み、共に育てる 22 少人数では、ゴールデンパスを拡げ続けるのに限界がある 現場案件を担うパートナー 2 社に、拡張へ加わってもらった ✓ 拡張だけでなく、現場に根付かせる狙いも（イネーブリング） A社 アプリテンプ レートの拡張 B社 ガードレール の整備 自分たちで作る標準から、現場と一緒に育てる標準へ ゴールデン パス
24. © 2026 Mizuho Bank, Ltd. 第3章：現場を巻き込み、共に育てる 23 仲間は増えたが、思うようには進まない… ⚫ パートナーは案件の開発と兼務しており、拡張の時間確保が難しい ⚫ 私たち自身、関係者へ価値を十分に伝えられていなかった ⚫ さらに開発上のトラブル対応も重なり、計画が揺れる ⚫ 動くモノを見せる文化を活かし、デモ予約で優先度をあげる ⚫ 進め方を一緒に見直す（やり方の相談、スコープの絞り込み） 前に進めるための工夫
25. © 2026 Mizuho Bank, Ltd. 第3章：現場を巻き込み、共に育てる 24 それでも、現場に参画してもらった効果は確かにあった 現場の肌感覚によって 課題の解像度が上がり、 設計を加速させた ⚫ 「現場では何がNGになりやすいか」などの肌感覚が必要 ⚫ 設計の基となる「チェックリスト」対応経験のあるメンバーが参画 ⚫ どのようなルールが必要か、スムーズに議論が進んだ ガードレール設計の事例
26. © 2026 Mizuho Bank, Ltd. 第3章：現場を巻き込み、共に育てる 25 巻き込むと、標準は拡がり始める ⚫参画者をきっかけに、周囲へ適用が広がる ⚫ゴールデンパスへの理解が深まり、現場に根づきはじめる 設計だけでなく、周知・定着にもつながった ⚫単に拡張の要件を提示しても、それだけでは揃わない （仲間を増やすだけでは、進まない） ⚫導線をつくり、目線を揃え続けて、前に進む ただし、目線は一度では揃わない
27. 第4章 「手放す前提」の中で、どう続けるか 26
28. © 2026 Mizuho Bank, Ltd. 第4章：「手放す前提」の中で、どう続けるか 27 提供後、「一旦ここまで」という雰囲気が生じた ⚫ 成果を現場に引き継いで、次のテーマへ移るのが役割 ⚫ 出口を設けるのが前提であり、自分たちで抱え続けない ⚫ だからこそ「一旦ここまで」となるのは、想定通りの動き 技術企画部門の特性 成果物、運用手順、 引継書をお渡しします こちらを基に自分たちで 進めてみます！ 技術企画部門 現場部門
29. © 2026 Mizuho Bank, Ltd. 第4章：「手放す前提」の中で、どう続けるか 28 拡大し始めた時期は、大規模な組織再編の節目だった ⚫ 「どの取り組みを残すか」が問われる局面 ⚫ 残す施策に選ばれなければ、立ち消える さらに、パートナーを巻き込み始めたばかりの状況でもあった… ⚫ 「一緒に育てよう」と言いながら、自分たちがすぐ退いてよいのか ⚫ ゴールデンパスと他施策をつなぎ、改善サイクルを定着させたい 構造に従えば撤退もあり得たが、現実には継続が必要だった
30. © 2026 Mizuho Bank, Ltd. 第4章：「手放す前提」の中で、どう続けるか 29 待たずに、価値を伝えに行く 届けたばかりのゴールデンパスを育て続けるため、以下2点を実施 ① 所属部門の当初計画に立ち返る ② 日々の場で地道に伝え続ける ✓ 復職時に示された当初の チームミッションに立ち返り ✓ 個人の主張ではなく ミッションに沿った取り組み として再度すり合わせ ✓ 1on1やチーム定例会で 成果・課題を小まめに共有 ✓ 個人の気づきを 組織の判断材料として伝える
31. © 2026 Mizuho Bank, Ltd. 第4章：「手放す前提」の中で、どう続けるか 30 風向きが変わり、ゴールデンパスが主要な取り組みへ ⚫ 所属部門に価値が伝わり、継続の判断へつながった ⚫ 関係部門が集まる場で、本取り組みが取り上げられることに ゴールデンパスの 目指す姿と現成果の 効果はこちらです！ 実案件で使えそう！ 自分たちの施策とも つながりそう！ ここまでの成果と目指す姿が認知・評価され、翌年度の主要施策に！
32. © 2026 Mizuho Bank, Ltd. 第4章：「手放す前提」の中で、どう続けるか 31 広く伝えた直後、思わぬ開発トラブルが発生 ⚫ 案件だけでなく、標準拡張の計画にも影響が及び、一旦手を止める ⚫ 組織が再発防止に動く過程で、ゴールデンパスの価値が注目された 先に価値を伝えていたからこそ、この一件が必要性を裏付けた ⚫ 「開発ルールに沿ったテンプレートを先に配る」思想が注目 ⚫ 再発防止策でも、ゴールデンパスで解消していくという位置づけに ゴールデンパスが再発防止策の一部に
33. 第5章 外部発信を、組織の追い風に 32
34. © 2026 Mizuho Bank, Ltd. 第5章：外部発信を、組織の追い風に 33 広く伝えたつもりだったが、現場に具体が届いていなかった ガイドはあったが、現場の問いに答える形になっていなかった ゴールデンパスって どこまでカバーしてる？ テンプレートや ガードレールって何？ ⚫ 背景・提供対象・価値を、具体的かつ丁寧に整理 ⚫ 外に伝えるための整理が、社内向けの説明力も高めた きっかけは、外向けの登壇資料づくり
35. © 2026 Mizuho Bank, Ltd. 第5章：外部発信を、組織の追い風に 34 外で評価されると、内側に弾みがつく ⚫ 当初は、リスク低減や再発防止の文脈で注目されることが多かった ⚫ そこに大規模カンファレンスでの採択というポジティブな出来事 ✓ 発信に通じ、外の世界を熟知するマネジメント層に採択が響いた ✓ 上からの後押しで、本登壇レポートを自社のDX事例サイトへ掲載 ✓ チームの勢いと活力が、一気に高まった 外の評価が、社内の動きを後押し リスク低減の文脈に、外部評価というポジティブな後押しが加わった
36. © 2026 Mizuho Bank, Ltd. 第5章：外部発信を、組織の追い風に 35 当たり前に使われる標準へ ⚫ 適用先ゼロだった取り組みが、今では多くの案件で使われる標準に ⚫ 拡張のリソースも継続しており、撤退ムードとは正反対の状況へ 使われ続け、育ち続けるように、ゴールデンパスを拡張中 改善導線の整理と周知 他施策との合流 インナーソース文化の醸成
37. 終章 思想と持ち帰り 36
38. © 2026 Mizuho Bank, Ltd. 終章：思想と持ち帰り 37 振り返ると、ゴールデンパスはプロダクトだった 現場に入り、標準化 すべき課題を見つけた ① ユーザーを知る まず動く形を作り、 実案件で検証した ② MVPで試す 技術を選び、仲間を 増やし、定着を支えた ③ 現場に届ける 社内外に伝える中で 価値が整理された ④ 価値を言語化する 作って終わりではなく、使われるまで育て続けた
39. © 2026 Mizuho Bank, Ltd. 終章：思想と持ち帰り 38 持ち帰ってほしいこと ⚫3名・適用先ゼロからでも、拡大フェーズまで来られた ⚫最初から完成形を狙わず、実案件で確かめながら育てる ① 標準化は小さく始められる ⚫外に伝えようと整理するほど、社内にも伝わる ⚫プロポーザル採択でゴールデンパス拡張に弾みがついた ② 外での評価が、社内の追い風になる
40. © 2026 Mizuho Bank, Ltd. 終章：思想と持ち帰り 39 まとめ『ゴールデンパスは敷いただけでは道にならない』 作る力と、届ける力は別物 01 使われて、はじめて届く 「届ける」と「手放す（出口）」を同時に設計する 02 自分たちが抱え続けなくても、残る形へ 技術標準を使われ続けるプロダクトとして扱う 03 標準も、現場と育てる
41. Appendix 40
42. © 2026 Mizuho Bank, Ltd. 41 ゴールデンパスの技術要素について、資料を公開中！ 『エンタープライズの厳格な制約を開発者に意識させない：クラウドネイティブ開発基盤設計』 Appendix 公開資料QR
43. © 2026 Mizuho Bank, Ltd. 42 本日触れたガードレールの続きとして AWS CDK Conference Japan 2026 に登壇します Appendix 2026年7月18日（土）@ 麻布台ヒルズ森JPタワー AI Coding Agent時代のcdk-nagガードレール ～組織ルールを強制CIで守り抜く設計の挑戦～ 前頁の資料では技術の全体像を紹介していますが ガードレールの深掘りはこちらでお話しします！