「とりあえず動く」の先へ。 AI時代のチーム開発と内部設計/2026-slsdays

Transcript

1. 「とりあえず動く」の先へ。 AI時代のチーム開発と内部設計 Se r ve rl e s s O p er a t i o n s So n u Kim
2. 自己紹介 金 仙優 / Sonu Kim COO at Serverless Operations, Inc. Full-stack AWS Serverless Engineer AWS Community Builders (2023 - ) Serverless JP および グローバル AWS コミュニティで活動中 02 / 16
3. Agenda AI時代におけるチーム開発での悩み事 チーム開発において特に重要となる内部設計のポイント サーバーレスの特性を踏まえたアプローチと対応方法
4. 事前にお伝えしておきたいこと コーディングエージェントの使い方そのものの説明よりも、 現場において議論になりやすい課題とプラクティスにフォーカスを当てています。 アーキテクチャの説明は基本的にAWSメインになっていますが、 主要クラウドベンダーのサービスに置き換えてイメージしていただければと思います。 課題を説明するために、前提付きの状況を説明することがあります。 実際にはより多種多様なシチュエーションがあると思いますので、思考の参考となれば幸いです。
5. 製造工程における様々な業務プロセスを考える 製造業界の業務プロセスは、生産はもちろんのこと、企画・量産・出荷・販売・CSなど多岐にわたる アイディアを形にする 技術検証・PoC推進 製造工程の見える化 予知保全・生産(量産)管理 EC・製品カタログサイト 構築運営、量販店連携 修理・その他 カスタマサポート受付対応 企画構想 製品詳細設計・試作 アーキテクチャ設計 設計構想 調達・生産 ・品質 SCM・倉庫管理 出荷業務効率化 出荷・物流 販売 カスタマー サポート
6. 時代に関わらず、開発現場で必要とされている業務 開発プロセスも、叩き上げた設計書やコードを手に、有識者にレビューを依頼し、 開発を進め、慎重にテストを重ねた上でリリースし、運用することが主な業務の流れ 顧客やビジネス要望の 実現性を検討、要件整理 設計資料を元に、 開発タスクを起票・遂行 自動 E2E テストと実行 レポート自動作成 各種運用ツール開発 トラブル対応、不具合調 要件定義 整理した要件を元に、 UML/設計資料を作成 基本設計・詳細設計 プロジェクト 計画・管理 有識者によるレビュー レビュー・品質管理 テスト・QA 品質管理 カスタマー サポート
7. チーム開発という観点での AI コーディングと悩み 「とりあえず動く」ものは素早く作れても、コードの中身やロジックの詳細が把握しきれない なぜ動くのか、なぜそのような仕様になっているかを説明できない 過剰な設計・実装によるコード量の増加、それらに伴うトークン消費量の増加 チームメンバー同士でのボトムアップや人材育成 ビジネスやチーム規模にあった技術選定、仕様策定の判断を任せきれない
8. 「とりあえず動く」ものは素早く作れても・・・ 動くものは すぐに作れる 要望・依頼が来る ペースが早まり、仕 事の量は減らない 不具合・品質管理の優 先度が下がり、業務量 の見積が甘くなる 04 / 16
9. なぜ動くのか、なぜそのような仕様になっているかの説明が大変 経験とノウハウがないまま AI に頼っても、チーム拡張とオンボーディングが用意になるわけではない チーム拡張 メンバーA オンボーディング 機能・ドメイン・領域 メンバーB 単位での業務オフロード AI 生成の設計ドキュメン ト・コードベースが重厚な ため、AI 解析に頼る 04 / 16
10. 過剰な設計・実装によるコード量の増加、それらに伴うトークン消費量の増加 なぜ動くのか、なぜそのような仕様になっているかを説明できない メンバーA AI 生成の設計ドキュメン 負債を解消しきれ ト・コードベースが重厚な 意図・狙いを持たず ず、コードベース ため、AI 解析に頼る 大量のソース解析 はさらに増加 ・仕様整理を進行 メンバーB
11. 過剰な設計・実装によるコード量の増加、それらに伴うトークン消費量の増加 AI に頼らざるを得ない状況で、ループとターンが増えるほど、負債と費用が同時に増大しやすい メンバーA LLM メンバー各自の トークン消費量 ・費用増大 負債を解消しきれず、 メンバーB コードベースはさらに増加
12. チームメンバー同士でのボトムアップや人材育成 チームメンバー間のスキル、経験、観点の違いを擦り合わせる機会の減少 サイロ化が進み、問題 の言語化が十分に訓練 されず、協業体制での 問題解決経験が減少 メンバーA メンバーC メンバーB 複数の人・有識者に 直接レビュー依頼、 助言とサポートを得る メンバーA メンバーC メンバーB 04 / 16
13. 認知負荷増大によるブラックボックス化 チームメンバー間のスキル、経験、観点の違いを擦り合わせる機会の減少 サイロ化が進み、問題 の言語化が十分に訓練 されず、協業体制での 問題解決経験が減少 業務ロジック、テクニック、作業管理等 あらゆる方面における会話が以前より減少 必要な脈略と付帯環境の理解・解像度が減少、 作業範囲が狭小になるか、逆に負債が増加 メンバーA メンバーC 協業がさらに難しくなるに連れ、 特定の人に作業が集中したり、 メンバーB 後進が育ちにくい結果となる
14. チーム開発観点での、時代に合った持続可能な仕組みとは？ シンプルかつ予測可能な内部設計方針 トークン消費量に対するアプローチ 過剰ではなく、わかりやすい成果物を作るための工夫 負債を増やさず、トークンの無駄遣い をせず、品質を保つためには？ 04 / 16
15. まずは基本に立ち返る 外部から入ってくるデータは、基本的に信頼せず、境界にて検証する ユーザーリクエスト、API 応答、ファイル読み込み、LLM 応答 検証したデータをドメインデータモデルに変換し、ビジネスロジックへ投入 副作用のない純粋関数で構成され、処理失敗時の冪等なリトライが可能 ローカルでのサーバー起動なしでもロジックのテストができるように 外部システムを呼び出し、結果を記録するレイヤーをロジックから分離 データの保存、外部APIとの通信、ログ、ファイルI/Oなどの副作用が対象 ロジックから分離し、状態を持たず、外部世界とつながる処理に徹する ドメインに関連するデータはしっかりモデリングを行い、ロジックと状態管理の分離を徹底する
16. シンプルかつ予測可能な内部設計方針 2つの基本原則： Functional Core 「純粋な核」 副作用のない純粋関数、ロジック、判断 Imperative Shell Functional Core 「命令の殻」 外部世界とつながる境界、薄い処理 Imperative Shell
17. シンプルかつ予測可能な内部設計方針 Web API バックエンドの構成の例 処理の入口・出口 業務ロジック・状態管理 DB・外部通信 API ルーティング ビジネスロジック 純粋関数 DB接続 入力チェック 内部状態管理 ドメインデータモデル 外部API呼び出し
18. シンプルかつ予測可能な内部設計方針 Web API バックエンドの構成の例 Functional Core Imperative Shell 処理の入口・出口 業務ロジック・状態管理 DB・外部通信 API ルーティング ビジネスロジック 純粋関数 DB接続 入力チェック 内部状態管理 ドメインデータモデル 外部API呼び出し
19. シンプルかつ予測可能な内部設計方針 Functional Core 副作用のない純粋関数で構成され、 業務ロジック・状態管理 処理失敗時の冪等なリトライが可能 ビジネスロジック 純粋関数 ローカルでのサーバー起動なしでも 内部状態管理 ドメインデータモデル ロジックのテストができるように ドメインに関連するデータはしっかり モデリングを行い、ロジックと状態管 理の分離を徹底する 04 / 16
20. シンプルかつ予測可能な内部設計方針 Imperative Shell DB・外部通信 外部から入ってくるデータは、 基本的に信頼せず、境界にて検証する DB接続 外部システムを呼び出し、結果を記録 するレイヤーをロジックから分離 外部API呼び出し ロジックから分離し、状態を持たず、 外部世界とつながる処理に徹する 04 / 16
21. バックエンド（WebAPI / AI Agent / Agentic Workflow）参考構成 Imperative Shell Functional Core
22. フロントエンド参考構成 Imperative Shell Functional Core
23. ※ 参考：AIコーディング時の修正量を最適化する、3つのアプリケーションコードルール https://d58jc7otpfuct.cloudfront.net/ja/posts/16b4ec トークン消費量に対するアプローチ 仕様変更が発生しても、変更範囲を最小限に抑える戦略的な構成 Functional Core Component A Hook/Service A Component B Hook/Service B Component C Hook/Service C Data Model Adapters Imperative Shell External API
24. ※ 参考：国語施策と公用文作成指針に基づく客観的なプロンプト作り https://d58jc7otpfuct.cloudfront.net/ja/posts/fb6df9 過剰ではなく、わかりやすい成果物を作るための工夫 人にも AI にも効率よく情報が伝わるように、少しの配慮を加える [リーダビリティ規則] - 一文にはひとつの考えだけを入れる。 - 文の長さは20~30字を超えない。 - 目的語と述語を備えた完結した文で書く。 - 条件と例外をひとつの文に重ねず、文を分ける。
25. チーム開発での AI 開発環境構築とツール整備も重要 AI 開発ツール整備を書かせるという意味ではなく、活用する前提の上での内部設計の工夫により チーム課題を解決することが本セッションの目的 プロジェクト内でのスキル・コーディングエージェント関連設定と環境の共有 PR一次レビュー、障害一次調査・レポート作成 各種運用・DevOps業務代行Agent作成 CI/CD に組み込まれた自動E2Eテスト・レポート 開発メンバー、AI 両方においてのナレッジベース となる Markdown ベースの静的ウェブサイト運用 サイロ化・認知負荷・負 債・トークン消費を軽 減、生産性を上げる
26. 会社紹介 サーバーレスで クラウドの価値を最大限に Serverless Operations はこれまでグローバルの第一線で 培ってきたクラウド技術、アマゾンウェブサービス （AWS）の豊富な実績と知見を活かし、お客さまの サーバーレスに関するさまざまな課題を解決しま す。 serverless.co.jp
27. serverless.co.jp