DDDを始める前に ― 問題発見の技術（AI時におけるエンジニアの価値）

ゆるテク なんかそれっぽい勉強会 2025.11
https://techplay.jp/event/987798
の発表資料です

Transcript

1. DDDを始める前に ― 問題発見の技術 AI時におけるエンジニアの価値 ゆるテク なんかそれっぽい勉強会 2025.11 ソーイ株式会社／YOKUMIRU株式会社 新垣圭祐 1
2. 自己紹介 新垣圭祐 (ソーイ株式会社 / YOKUMIRU株式会社) Web/モバイルアプリ開発エンジ ニア 大学院で自律分散コンピューテ ィングの研究 インドに渡り現地システム会社 にて勤務 帰国してフリーランスエンジニ ア → 会社設立 2
3. ソーイ株式会社（ソフトウェアパッケージと受託開発の会社） YOKUMIRU株式会社（オンライン医療相談サービスを提供する事業会社） 3
4. はじめに 「この1ヶ月で、実装したのに使われなかった機能はありますか？」 → その機能は「誰の・どんな問題」を解いていたでしょうか？ 4
5. なぜ「問題発見」が重要なのか？ コーディングや設計の自動化が進み、生成AIが高速に「答え」を出す時代 それでも失敗するプロダクトがあるのはなぜか → 間違った問題を高速に解いているだけ AIは「どう解くか」を加速するが、 「何を解くか」を教えてくれない 5
6. 問題とは、望まれた事柄と 認識された事柄の間の相違 である 『ライト、ついてますか？』G.M.ワ インバーグ／D.G.ゴース 6
7. DDDを始める前に ― 問題発見の技術 DDDの設計パターンを学んでも、 「何を解くべきか」を間違えていたら、すべてが ズレる DDDの"前"に"問題発見"をしっかりとすることが大事 7
8. 1. 問題発見とは何か 8
9. 「問題解決」と「問題発見」の違い 問題解決：解決策を考える 反応的な行為 → 明確に定義された問題ならAIが得意 問題発見：解くべき対象を見極める 主体的な行為 → 人間が担う（AIには不可能） 9
10. 「問題解決」を急過ぎると失敗する 例：バグをすぐに直そう！ → バグ修正のために表面的なパッチをあてる → 根本的な設計はそのままなので、バグが発生しやすい状態が継続する 10
11. AIは「正しそうな答え」をくれる でも 問題定義がズレていたら？ 根本原因が違っていたら？ → 間違った問題 × 正しい解決 = ムダな努力（問題を誤ると、すべてがズレる） AIは間違いを高速化する 11
12. 「問題発見」が価値になる時代 良い問いは、良いプロダクトを生む。 問題発見のための3つの問い： 1. 誰の問題を解いていますか？（問題設定） 2. 何が起きないと理想ですか？（成功条件） 3. この解決が新しい問題を生んでいませんか？（副作用） 12
13. 2. 『ライト、ついてますか？』 13
14. 『ライト、ついてますか？』 G.M.ワインバーグ／D.G.ゴース 第1部　何が問題か? 第2部　問題は何なのか? 第3部　問題は本当のところ何か? 第4部　それは誰の問題か? 第5部　それはどこからきたか? 第6部　われわれはそれをほんとうに 解きたいか? 14
15. ①問題とは、望まれた事柄と認識された事柄の間の相違である 問題は欲求を変えること、または認識を変えることによって解決できる 本当に解くべき問題の解を見つけるために、まず問題定義をしよう 問題を抱えている人は誰か？ その人にとって問題の本質は何か？ その人にとって問題の解決はどういうものか？ 15
16. ② クライアントが提示した解決案を、問題の定義と取り違えるな （実際の文章）解法を問題の定義と取り違えるな。ことにその解法が自分の解法 であるときには注意 問題の本質に目を向ければ、より良い本当の解が見つかるかも 他に解くべき本質的な問題があるかも（やり遂げる必要が無い場合もある） 16
17. ③ 「彼らの問題」にしてしまう 例）トンネル前の標識でライト点灯を促す 複雑な指示: 4パターンすべてを指示する（昼間は消す、暗いときはつけ る...） シンプルな問いかけ: 「ライト、ついてますか？」 問題を「彼らの問題」にすることで、自発的に解決してもらう 17
18. 3. システム開発現場での事例 18
19. 「解決策」ではなく「不満の背景」を聞く 例：要件定義での失敗 ユーザー： 「ボタンを増やしてほしい」 → その通り実装したが、UIが混乱してしまう 本当の課題： 「目的の操作が見つけにくい」 19
20. AIからの過剰な提案 例：AIに出した最適化の指示 「システムの可用性を高めたい」 → AI提案：高可用性構成を推奨 → コストが跳ね上がる AIは与えられた情報に基づいて最適化するが、制約を明示しなければ過剰な提 案になる。 例「可用性を高めたい。ただし、夜間はアクセスが少ないため縮退運用可。コス トは現状維持」 20
21. 解決策を要件と勘違い ユーザー要望： 「ダッシュボードにグラフを追加して」 → そのまま実装 → 使われない 再定義： 1. なぜグラフが必要か？ → データの傾向を把握したい 2. 誰が使うか？ → マネージャー層 3. 何が見えれば良いか？ → 「売上トレンド」と「異常値」 → 本当の課題： 「異常値を素早く検知する仕組み」 → 解決策：アラート機能 + 簡易グラフ 21
22. 事例のまとめ：共通パターン すべての失敗に共通するのは... 1. 解決策を問題だと思い込んだ 2. 制約条件を明示しなかった 3. 誰の問題かを確認しなかった → 問題発見の3つの問いが重要 22
23. 4. 問題発見からドメイン駆動設計へ 23
24. 問題発見はAIでは代替できない AIは： 過去のパターンを模倣する 意図や文脈は理解できない 人間は： 目的を再定義できる コンテキストを読み取れる エンジニアの価値 → どんな問題を解くためのソフトウェアかを理解すること 24
25. 『ドメイン駆動設計をはじ めよう』 ― ソフトウェアの実装と事業戦略を 結びつける実践技法 Vlad Khononov　著 第Ⅰ部　設計の基本方針 第Ⅱ部　実装方法の選択 第Ⅲ部　ドメイン駆動設計の実践 第Ⅳ部　他の方法論や設計技法との 関係 25
26. ドメイン駆動設計とは 価値のあるソフトウェアを開発するために、まず事業活動の目的を理解し、その 事業目的を達成するためにどのような業務活動が行われているかを分析し、その 分析結果を活かしてソフトウェアを設計する方法 → 問題発見で「何を解くか」を見極め、DDDで「どこに注力するか・どんな実装をす るか」を判断する 26
27. ドメイン駆動設計の考え方 他社との差別化を実現し競争優位を生み出す機能に焦点を合わせる 競争に関わらない部分はできる限り手を抜く 問題発見からDDDへ 1. 問題発見: 解くべき問題を特定する 2. DDD: その問題が中核・一般・補完のどこに属するかを判断し、その問題を解くた めの実装方法を選択する 27
28. 業務領域の差別化とロジックの複雑さで分類 28
29. ドメイン駆動設計 → 競争優位性に焦点を当てた実装方法の選択 中核の業務領域が事業を持続させる 他社とは異なる際立つ価値を提供するためには、業務ロジックは複雑になる 競争優位性を維持・発展させるために、業務ロジックの変更を繰り返す 29
30. 5. まとめ エンジニアは「問題発見」で価値を生む 問題発見 × DDD = 価値あるソフトウェア 問題発見で「何を解くか」を見極める DDDで「どこに注力するか」を判断する 中核領域に注力し、競争優位を生む 良い問いが良い設計を生む 30