ビジネス要望の翻訳が生む アーキテクチャの複雑性とトレードオフ

2026.02.18 開催 NTT Tech Conference 2026 の 30 分枠で登壇させていただいた際の資料です。
https://ntt-techconf.connpass.com/event/382775/

個人プロフィール
https://github.com/hayashit6239

Transcript

1. ビジネス要望の翻訳が生む アーキテクチャの複雑性とトレードオフ NTT Tech Conference 2026 - Tomonori Hayashi / ぴーはや
2. 2 アーキテクチャって何でしょうか？ 2
3. 3 本日お話しすること GKE から Cloud Run への移行検証をきっかけに アーキテクチャに対して気付きを得られた話 3
4. 4 Agenda 18:00 - Opening 18:03 - Keynote 「Google Cloud Next ‘25 Wrap Up !!」 Google Cloud Japan Mori-san, Nakane-san Shigeru-san 18:45 - Community Member LT-1「振り返りと気になったセッション」 DocoTech Kanzaki-san 18:55 - Guest LT-1「A2A のドキュメントソースコードを読んでみた」 DII Yamazaki-san 19:05 - Guest LT-2「GKEラウンドテーブルと気になったセッションの振り返り」 Docomo Toe-san 19:15 - Community Member LT-2「ワークロードの規模でみる Cloud Run のアーキテクチャ」 Com Hayashi-san 19:30 - Community Member LT-3「振り返りと気になったセッション」 Docomo Fujihira-san, Yano-san 19:45 - Closing Tomonori Hayashi / ぴーはや • NTTドコモビジネス株式会社 ◦ ソフトウェアエンジニア ノーコード AI 開発ツール「Node-AI」の開発/運用 ▪ Front：TypeScript - React/Next.js ▪ Infra：Google Cloud • Google Cloud Partner Top Engineer 2024 - 2026 • Google Cloud Partner All Certification Holders 2025 • コミュニティ ◦ Jagu’e’r（Google Cloud ユーザーコミュニティ） ▪ エバンジェリスト • カンファレンス ◦ Google Cloud Community Tech Surge 2026 ▪ オーガナイザー 4 @pHaya72
5. 5 アーキテクトへの期待からアーキテクチャを考える ‘‘ アーキテクトには、チームや部門、あるいは企業全体の技術的な決定を導くために使用される、アー キテクチャ決定や設計指針を定義 することが期待されている。’’ — 1.2.1 アーキテクチャ決定を下す 5 ‘‘ アーキテクトには、事業ドメインに関する一定の専門知識が求められる 。... 事業ドメインの知識がな ければ、ビジネス上の問題や目標、要件を理解するのは難しい。そうすると、ビジネス要件を満たす効 果的なアーキテクチャも設計できない 。’’ — 1.2.6 事業ドメインの知識を持っている ‘‘ アーキテクトは、アーキテクチャと技術スタックを継続的に分析し、改善を提案することが期待され ている。’’ — 1.2.2 アーキテクチャを継続的に分析する
6. © NTT Communications Corporation All Rights Reserved. 6 アーキテクトへの期待からアーキテクチャを考える ‘‘ アーキテクトには、チームや部門、あるいは企業全体の技術的な決定を導くために使用される、アー キテクチャ決定や設計指針を定義 することが期待されている。’’ — 1.2.1 アーキテクチャ決定を下す ユーザーの価値を最大化するために ユーザーの要望を実現可能な技術仕様へ翻訳し、 それを決定として積み重ね、変化し続けるもの ※ 一個人の解釈です 6 ‘‘ アーキテクトには、事業ドメインに関する一定の専門知識が求められる 。... 事業ドメインの知識がな ければ、ビジネス上の問題や目標、要件を理解するのは難しい。そうすると、ビジネス要件を満たす効 果的なアーキテクチャも設計できない 。’’ — 1.2.6 事業ドメインの知識を持っている 意思決定が積み重ねられている ビジネスの成功と技術的制約が考慮されている ‘‘ アーキテクトは、アーキテクチャと技術スタックを継続的に分析し、改善を提案することが期待され ている。’’ — 1.2.2 アーキテクチャを継続的に分析する 継続的に改善されている
7. © NTT Communications Corporation All Rights Reserved. 7 第一法則 “ソフトウェアアーキテクチャはト レードオフがすべてだ” — 1.4 ソフトウェアアーキテクチャの法則 第二法則 “「どうやって」よりも 「なぜ」の方がずっと重要だ ” — 1.4 ソフトウェアアーキテクチャの法則 ソフトウェアアーキテクチャの二つの法則 7 万能な解決策、つまり銀の弾丸は 存在しない 設計図そのものより、その決断に至っ た理由を残せ
8. © NTT Communications Corporation All Rights Reserved. 8 ソフトウェアアーキテクチャの二つの法則 8 第一法則 “ソフトウェアアーキテクチャはト レードオフがすべてだ” — 1.4 ソフトウェアアーキテクチャの法則 第二法則 “「どうやって」よりも 「なぜ」の方がずっと重要だ ” — 1.4 ソフトウェアアーキテクチャの法則 万能な解決策、つまり銀の弾丸は 存在しない 設計図そのものより、その決断に至っ た理由を残せ 大事なことはわかる、、しかし実感が持てない
9. © NTT Communications Corporation All Rights Reserved. 9 Node-AI の紹介 時系列分析に特化した ノーコード AI 開発 Web アプリケーション Asyc Processing GKE ☑ 開発者数名で内製開発 しているプロダクト
 
 ☑ アジャイル開発で 1 週間での機能リリース
 
 ☑ アプリケーションはマイクロサービスとして 
 　 GKE でホスティングして運用 
 ブラウザからすぐに無料で 始めることができます！ 9
10. © NTT Communications Corporation All Rights Reserved. 10 直面した設計の属人化 Asyc Processing GKE GKE で運用する上での難しさ ・ノードプールの適切な設計と管理 ・スケーリングの繊細なチューニング ・ミドルウェアとの魔合体 ・社内 DevOps ツールとの強い依存 … etc インフラ 
 任せろ！！ 
 インフラ 
 わからん！！ 
 インフラ 
 無理！！ 
 インフラ 
 任せた！！ 
 インフラ 
 なにそれ！！ 
 インフラ 
 うおおお！！ 
 ※ イメージです 10 GKE = Kubernetes + Google Cloud の知識が求められる その点も相まった学習コストの高さから属人化が加速 少人数の開発者チームの中でも 特定のメンバーのみが GKE 職人となる
11. © NTT Communications Corporation All Rights Reserved. 11 インフラリビルドを検討 GKE（Kubernetes + Google Cloud）という 学習コストの高さも相まって属人化が加速 GKE で運用する上での難しさ ・ノードプールの適切な設計と管理 ・スケーリングの繊細なチューニング ・ミドルウェアとの魔合体 ・社内 DevOps ツールとの強い依存 … etc 少人数の開発者チームの中でも 特定のメンバーのみが GKE 職人となる 属人化解消としてインフラリビルドの検討を開始 フルマネージドサービスである Cloud Run を検討対象に Asyc Processing Asyc Processing GKE GKE Cloud Run Worker Pools GKE = Kubernetes + Google Cloud の知識が求められる その点も相まった学習コストの高さから属人化が加速 当時の GKE 上に存在した十数種類のマイクロサービス を Cloud Run に移行することを目標とした
12. © NTT Communications Corporation All Rights Reserved. 12 インフラリビルドを検討 GKE（Kubernetes + Google Cloud）という 学習コストの高さも相まって属人化が加速 GKE で運用する上での難しさ ・ノードプールの適切な設計と管理 ・スケーリングの繊細なチューニング ・ミドルウェアとの魔合体 ・社内 DevOps ツールとの強い依存 … etc 少人数の開発者チームの中でも 特定のメンバーのみが GKE 職人となる 属人化解消としてインフラリビルドの検討を開始 フルマネージドサービスである Cloud Run を検討対象に Asyc Processing Asyc Processing GKE GKE Cloud Run Worker Pools GKE = Kubernetes + Google Cloud の知識が求められる その点も相まった学習コストの高さから属人化が加速 当時の GKE 上に存在した十数種類のマイクロサービス を Cloud Run に移行することを目標とした 結論 移行しないことで決定
13. © NTT Communications Corporation All Rights Reserved. 13 移行を断念した要因 機械学習コンポーネントにフォーカス 本コンポーネントはクライアントであるバックエンドコンポーネントからタスクを受け取って非同期で処理する コンテナのアップデートやスケールインのタイミングでも処理を継続する 例えば、学習処理など長い時間を要する処理の場合に処理中にコンテナのアップデートで処理を停止させないことが可能 13 Asyc Processing GKE Celery Python 製の分散タスクキューであり、 イベント駆動で処理が開始し ワーカーで非同期に処理させる用途で利用 Agones Kubernetes 上で動くゲームサーバーの管理サービスであり、 所定の数のコンテナリソース確保や 処理中コンテナを保護する用途で利用
14. © NTT Communications Corporation All Rights Reserved. 14 移行を断念した要因 現状のアプリケーションのままでは Cloud Run で実現できないことが判明 Agones は Kubernetes 上で動くことが前提であり、Cloud Run worker pools との併用は不可 Agones なしに現状の役割である「所定の数のコンテナリソースの確保」や「処理中コンテナの保護」を実現できなかった さらにアプリケーションの中で Celery/Agones/GKE が密接に依存しており、単純なインフラ切り替えは絶望的だった 14 Asyc Processing Celery Agones GKE GKE アーキテクチャの複雑性が増加 ⬆⬆ (デメリットの 1 つとして )
15. © NTT Communications Corporation All Rights Reserved. 15 調査結果から湧いた疑念 全体最適も難しい 機械学習コンポーネントは 0 から作るに等しいコストが分かった上に、異なるバックエンドコンポーネントも GKE と密接に構築されて おり移行には 0 からというほどではないが大きなコストが必要なことが判明 15 GKE Cloud Run Worker Pools Asyc Processing Cloud Run Services 特定のコンポーネントでは 0 から作り上げる必要があったり、最終系として Cloud Run と GKE の併用になる可能性も高 い、この未来に突き進むことで当初の目標が本当に達成できるのか？
16. 16 移行しなかった理由 リビルドコスト vs 属人化解消の価値を比較 した時に 不確実性の高いインフラ刷新という名の投資を強行する 価値を見出せなかった 16
17. © NTT Communications Corporation All Rights Reserved. 17 なぜここまで大きな改修が必要なのか？ 実装の基となった仕様に目を向ける アプリケーションの中で Celery/Agones/GKE が密接に依存している、なぜこの構成になったのか知る必要があった Agones にフォーカスすると役割の 1 つとして「処理中コンテナの保護」が存在した 17 Asyc Processing GKE 仕様 ・安全な停止メカニズム アップデートの際に計算中のコンテナを強制終了しない仕組みを実装 ・リソースの確保 所定の数のワーカーを立ち上げ常に即座に処理開始可能な仕組みを実装
18. © NTT Communications Corporation All Rights Reserved. 18 なぜここまで大きな改修が必要なのか？ 公理を疑う アプリケーションの中で Celery/Agones/GKE が密接に依存している、なぜこの構成になったのか知る必要があった Agones にフォーカスすると役割の 1 つとして「処理中コンテナの保護」が存在した 18 Asyc Processing GKE 機械学習処理においてユーザー体験を考慮して「処理を停止させない方針 」を重要視しているが、 非同期処理のプラクティスに立ち返ると「いつでも停止・再開できる方針 」を重要視してもいいのではないか？ ビジネス要件 ・ユーザーのリクエストが想定外に長くならないこと 　・計算処理がすぐに始まること 　・サービスのアップデートなどで計算に悪影響を与えないこと ・常に最新のアプリケーションを利用できること 仕様 ・安全な停止メカニズム アップデートの際に計算中のコンテナを強制終了しない仕組みを実装 ・リソースの確保 所定の数のワーカーを立ち上げ常に即座に処理開始可能な仕組みを実装 非同期処理のユースケースにおいて この仕様がかなり厳しいものになっているのでは？
19. © NTT Communications Corporation All Rights Reserved. 19 アーキテクチャに対する気づき① 実装は「ビジネス要件が仕様にどのように落とし込まれるか」に大きく影響されている 19 ビジネス要件 ・サービスのアップデートなどで計算に悪影響を与えないこと ・常に最新のアプリケーションを利用できること 翻訳パターン① ・安全な停止メカニズム アップデートの際に計算中のコンテナを強制終了しない仕組みを実装 　 ユーザーへの価値を技術の言葉に翻訳するフェーズ 「実行中の計算を停止させない」という形で 非機能要件でいう可用性を重視 翻訳パターン② ・いつでもやり直せる アップデートの際に処理を途中から開始できる仕組みを実装 「実行中の計算をいつでも中断・再開できる」という形で 非機能要件でいう回復性を重視 実装 　 ・Agones を利用することで処理中のコンテナを保護する 実装（例えば） 　 ・処理の中間状態を記録して再開できるようなロジックを追加する
20. © NTT Communications Corporation All Rights Reserved. 20 ソフトウェアアーキテクチャの法則が腑に落ちた瞬間 20 実装の基になったビジネス要件/仕様が残っていたからこそ 今回の撤退の判断やアーキテクチャの気づきを得ることができた 改めて、ADR のようなアーキテクチャドキュメントの重要性を実感した 第一法則 “ソフトウェアアーキテクチャはト レードオフがすべてだ” — 1.4 ソフトウェアアーキテクチャの法則 第二法則 “「どうやって」よりも 「なぜ」の方がずっと重要だ ” — 1.4 ソフトウェアアーキテクチャの法則 万能な解決策、つまり銀の弾丸は 存在しない 設計図そのものより、その決断に至っ た理由を残せ
21. © NTT Communications Corporation All Rights Reserved. 21 ソフトウェアアーキテクチャの法則が腑に落ちた瞬間 21 設計図そのものより、その決断に至っ た理由を残せ 今回の実装はアーキテクチャが複雑になる 1 つの要因となったが アプリケーションに中断/再開のロジック追加が不要といったことを含む恩恵を得られた 唯一の正解を模索するのではなくトレードオフを見極めることの重要性を実感した 第一法則 “ソフトウェアアーキテクチャはト レードオフがすべてだ” — 1.4 ソフトウェアアーキテクチャの法則 第二法則 “「どうやって」よりも 「なぜ」の方がずっと重要だ ” — 1.4 ソフトウェアアーキテクチャの法則 万能な解決策、つまり銀の弾丸は 存在しない 設計図そのものより、その決断に至っ た理由を残せ
22. © NTT Communications Corporation All Rights Reserved. 22 アーキテクチャに対する気づき② 22 ビジネス要件 ・プロダクトの信頼性維持 サービスのアップデートなどで計算に悪影響を与えないこと ・運用の簡素化とアジリティ 複雑な仕組みの導入を避けいつでもアップデート可能であること 翻訳パターン① ・安全な停止メカニズム アップデートの際に計算中のコンテナを強制終了しない仕組みを実装 　 ここでの翻訳が適切になっているかを確認 「実行中の計算を停止させない」という形で 非機能要件でいう可用性を重視 翻訳パターン② ・いつでもやり直せる アップデートの際に処理を途中から開始できる仕組みを実装 「実行中の計算をいつでも中断・再開できる」という形で 非機能要件でいう回復性を重視 実装 　 ・Agones を利用することで処理中のコンテナを保護する 実装（例えば） 　 ・処理の中間状態を記録して再開できるようなロジックを追加する 実装の複雑性が増加する場合には、異なる仕様への落とし込みができないかを見直してみる
23. 23 Agenda 18:00 - Opening 18:03 - Keynote 「Google Cloud Next ‘25 Wrap Up !!」 Google Cloud Japan Mori-san, Nakane-san Shigeru-san 18:45 - Community Member LT-1「振り返りと気になったセッション」 DocoTech Kanzaki-san 18:55 - Guest LT-1「A2A のドキュメントソースコードを読んでみた」 DII Yamazaki-san 19:05 - Guest LT-2「GKEラウンドテーブルと気になったセッションの振り返り」 Docomo Toe-san 19:15 - Community Member LT-2「ワークロードの規模でみる Cloud Run のアーキテクチャ」 Com Hayashi-san 19:30 - Community Member LT-3「振り返りと気になったセッション」 Docomo Fujihira-san, Yano-san 19:45 - Closing まとめ GKE から Cloud Run に移行検証する中で 何気なく使っていた「アーキテクチャ」という言葉が ユーザー価値と密接に紐づいているを実感した • How である実装での行き詰まりは Why である翻訳が適切であるかも疑う • 「ユーザー価値を技術の言葉に訳す」という能力はアーキテクトにとって重要な要素 ◦ 少人数の開発チームには、往々にしてエンジニアにも求められる能力 • なぜそのような技術の言葉への訳し方をしたのか課題 /選択肢/意思決定をドキュメントに残す 生成 AI がよしなにやってくれる時代になる中で ユーザーの価値を最大化するためのコンテキストを解釈して技術を使える エンジニアが求められるのではないでしょうか 23
24. 24 Agenda 18:00 - Opening 18:03 - Keynote 「Google Cloud Next ‘25 Wrap Up !!」 Google Cloud Japan Mori-san, Nakane-san Shigeru-san 18:45 - Community Member LT-1「振り返りと気になったセッション」 DocoTech Kanzaki-san 18:55 - Guest LT-1「A2A のドキュメントソースコードを読んでみた」 DII Yamazaki-san 19:05 - Guest LT-2「GKEラウンドテーブルと気になったセッションの振り返り」 Docomo Toe-san 19:15 - Community Member LT-2「ワークロードの規模でみる Cloud Run のアーキテクチャ」 Com Hayashi-san 19:30 - Community Member LT-3「振り返りと気になったセッション」 Docomo Fujihira-san, Yano-san 19:45 - Closing Thanks! @pHaya72 @t_hayashi 24