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

DDDを始める前に ― 問題発見の技術 AI時におけるエンジニアの価値ゆるテクなんかそれっぽい勉強会 2025.11 ソーイ株式会社／YOKUMIRU株式会社新垣圭祐 1

自己紹介新垣圭祐 (ソーイ株式会社 / YOKUMIRU株式会社) Web/モバイルアプリ開発エンジニア大学院で自律分散コンピューティングの研究インドに渡り現地システム会社
にて勤務帰国してフリーランスエンジニア → 会社設立 2

ソーイ株式会社（ソフトウェアパッケージと受託開発の会社） YOKUMIRU株式会社（オンライン医療相談サービスを提供する事業会社） 3

はじめに「この1ヶ月で、実装したのに使われなかった機能はありますか？」 → その機能は「誰の・どんな問題」を解いていたでしょうか？ 4

なぜ「問題発見」が重要なのか？コーディングや設計の自動化が進み、生成AIが高速に「答え」を出す時代それでも失敗するプロダクトがあるのはなぜか → 間違った問題を高速に解いているだけ AIは「どう解くか」を加速するが、「何を解くか」を教えてくれない 5

問題とは、望まれた事柄と認識された事柄の間の相違である『ライト、ついてますか？』G.M.ワインバーグ／D.G.ゴース 6

DDDを始める前に ― 問題発見の技術 DDDの設計パターンを学んでも、「何を解くべきか」を間違えていたら、すべてがズレる DDDの"前"に"問題発見"をしっかりとすることが大事 7

1. 問題発見とは何か 8

「問題解決」と「問題発見」の違い問題解決：解決策を考える反応的な行為 → 明確に定義された問題ならAIが得意問題発見：解くべき対象を見極める主体的な行為 → 人間が担う（AIには不可能） 9

「問題解決」を急過ぎると失敗する例：バグをすぐに直そう！ → バグ修正のために表面的なパッチをあてる → 根本的な設計はそのままなので、バグが発生しやすい状態が継続する 10

AIは「正しそうな答え」をくれるでも問題定義がズレていたら？根本原因が違っていたら？ → 間違った問題 × 正しい解決 = ムダな努力（問題を誤ると、すべてがズレる）
AIは間違いを高速化する 11

「問題発見」が価値になる時代良い問いは、良いプロダクトを生む。問題発見のための3つの問い： 1. 誰の問題を解いていますか？（問題設定） 2. 何が起きないと理想ですか？（成功条件） 3. この解決が新しい問題を生んでいませんか？（副作用） 12

2. 『ライト、ついてますか？』 13

『ライト、ついてますか？』 G.M.ワインバーグ／D.G.ゴース第1部　何が問題か? 第2部　問題は何なのか? 第3部　問題は本当のところ何か? 第4部　それは誰の問題か? 第5部　それはどこからきたか? 第6部　われわれはそれをほんとうに解きたいか? 14

①問題とは、望まれた事柄と認識された事柄の間の相違である問題は欲求を変えること、または認識を変えることによって解決できる本当に解くべき問題の解を見つけるために、まず問題定義をしよう問題を抱えている人は誰か？その人にとって問題の本質は何か？その人にとって問題の解決はどういうものか？ 15

② クライアントが提示した解決案を、問題の定義と取り違えるな（実際の文章）解法を問題の定義と取り違えるな。ことにその解法が自分の解法であるときには注意問題の本質に目を向ければ、より良い本当の解が見つかるかも他に解くべき本質的な問題があるかも（やり遂げる必要が無い場合もある） 16

③ 「彼らの問題」にしてしまう例）トンネル前の標識でライト点灯を促す複雑な指示: 4パターンすべてを指示する（昼間は消す、暗いときはつける...）シンプルな問いかけ: 「ライト、ついてますか？」問題を「彼らの問題」にすることで、自発的に解決してもらう 17

3. システム開発現場での事例 18

「解決策」ではなく「不満の背景」を聞く例：要件定義での失敗ユーザー：「ボタンを増やしてほしい」 → その通り実装したが、UIが混乱してしまう本当の課題：「目的の操作が見つけにくい」 19

AIからの過剰な提案例：AIに出した最適化の指示「システムの可用性を高めたい」 → AI提案：高可用性構成を推奨 → コストが跳ね上がる AIは与えられた情報に基づいて最適化するが、制約を明示しなければ過剰な提案になる。例「可用性を高めたい。ただし、夜間はアクセスが少ないため縮退運用可。コス
トは現状維持」 20

解決策を要件と勘違いユーザー要望：「ダッシュボードにグラフを追加して」 → そのまま実装 → 使われない再定義： 1. なぜグラフが必要か？
→ データの傾向を把握したい 2. 誰が使うか？ → マネージャー層 3. 何が見えれば良いか？ → 「売上トレンド」と「異常値」 → 本当の課題：「異常値を素早く検知する仕組み」 → 解決策：アラート機能 + 簡易グラフ 21

事例のまとめ：共通パターンすべての失敗に共通するのは... 1. 解決策を問題だと思い込んだ 2. 制約条件を明示しなかった 3. 誰の問題かを確認しなかった → 問題発見の3つの問いが重要
22

4. 問題発見からドメイン駆動設計へ 23

問題発見はAIでは代替できない AIは：過去のパターンを模倣する意図や文脈は理解できない人間は：目的を再定義できるコンテキストを読み取れるエンジニアの価値 → どんな問題を解くためのソフトウェアかを理解すること
24

『ドメイン駆動設計をはじめよう』 ― ソフトウェアの実装と事業戦略を結びつける実践技法 Vlad Khononov　著第Ⅰ部　設計の基本方針第Ⅱ部　実装方法の選択第Ⅲ部　ドメイン駆動設計の実践
第Ⅳ部　他の方法論や設計技法との関係 25

ドメイン駆動設計とは価値のあるソフトウェアを開発するために、まず事業活動の目的を理解し、その事業目的を達成するためにどのような業務活動が行われているかを分析し、その分析結果を活かしてソフトウェアを設計する方法 → 問題発見で「何を解くか」を見極め、DDDで「どこに注力するか・どんな実装をするか」を判断する 26

ドメイン駆動設計の考え方他社との差別化を実現し競争優位を生み出す機能に焦点を合わせる競争に関わらない部分はできる限り手を抜く問題発見からDDDへ 1. 問題発見: 解くべき問題を特定する 2. DDD: その問題が中核・一般・補完のどこに属するかを判断し、その問題を解くた
めの実装方法を選択する 27

業務領域の差別化とロジックの複雑さで分類 28

ドメイン駆動設計 → 競争優位性に焦点を当てた実装方法の選択中核の業務領域が事業を持続させる他社とは異なる際立つ価値を提供するためには、業務ロジックは複雑になる競争優位性を維持・発展させるために、業務ロジックの変更を繰り返す 29

5. まとめエンジニアは「問題発見」で価値を生む問題発見 × DDD = 価値あるソフトウェア問題発見で「何を解くか」を見極める DDDで「どこに注力するか」を判断する
中核領域に注力し、競争優位を生む良い問いが良い設計を生む 30

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

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

kei4eva4

More Decks by kei4eva4

Other Decks in Technology

Featured

Transcript