正しくソフトウェアを作る、前提を疑うための認知の視点 / doubt-premise

こちらのイベントの登壇資料です

仕様書通りに実装したのに「そうじゃない」と言われる理由──ミノ駆動さんが語る"前提を疑うための認知の視点"
https://techplay.jp/event/995341

Transcript

1. © DMM © DMM 正しくソフトウェアを作る 前提を疑うための認知の視点 2026/06/08 TECH PLAY 合同会社DMM.com ミノ駆動
2. © DMM 自己紹介 ミノ駆動 ( @MinoDriven ) 合同会社DMM.com プラットフォーム開発本部 第3開発部 • コード品質チーム • PF-AX戦略グループ（兼務） 2
3. © DMM 著書紹介 『改訂新版 良いコード／悪いコードで学ぶ設計入門』 変更容易性の高い設計を学ぶ、 初級〜中級向け入門書 初版は12刷重版 初版：ITエンジニア本大賞2023大賞受賞 改訂版：ITエンジニア本大賞2026ベスト10入り 台湾版、韓国語版でも翻訳出版 3
4. © DMM 加速度的に広がるAI駆動開発 近年、AIによるソフトウェア開発が加速度的に広がっています。 AIオールインする、即ちあらゆる業務のAI化を試みる企業も 登場してきています。 AIエージェントも日進月歩でアップデートされ、 AI駆動のソフトウェア開発を進める上で便利な機能が 次々に追加されています。 4
5. © DMM AI駆動開発で直面する課題 しかし折角AIを使っても開発が上手く進まない、 といったケースを見聞きします。 たとえば次のようなものです。 • プロダクトの価値が上がらない • AIが混乱する ◦ 実装がいつまで経っても終わらない ◦ 変更してほしくないコードを変更したり、 既存環境を破壊するような変更をしてしまう etc.. 5
6. © DMM 「認識や解釈の歪み」が引き起こす問題 AI駆動開発が上手くいかない要因はさまざまです。 その要因のひとつとして、 「物事の認識や解釈が不正確だったり、歪みが生じている」 というのがあるとミノ駆動は考えます。 解釈に問題があると、 顧客がどうしたいのか要求の理解が不正確になったり、 ドメインモデルの構造が歪んで機能しなくなる、 といった問題が生じます。 6
7. © DMM 歪みを正す哲学と認知科学 そこで物事の認識や解釈の正確性を高めるのに役立つのが 哲学と認知科学です。 このセッションではソフトウェア開発で起こりがちな開発ミスを例に、 認識や解釈のズレを解説します。 そしてズレを正しプロダクト価値向上に役立つ哲学と認知科学について、 ミノ駆動が普段活用しているノウハウを紹介します。 7
8. © DMM 【前提】 エンジニアの役割変化
9. © DMM 9 要求定義 要件定義 設計 実装 よくある一般的な ソフトウェア開発プロセス
10. © DMM 10 要求定義 要件定義 設計 実装 設計、実装がAIに 置き換わりつつある
11. © DMM 11 要求定義 要件定義 設計 実装 顧客要求を定義し、AIの成果物が満 たすべき要件の定義へ人間の仕事は 必然的にシフトしていくことになる！
12. © DMM 12 要求定義 要件定義 設計 実装 「要求要件定義もAIに置き換わるの では？」という意見もある。 しかしそれは困難。 「ああしたい」「こうしたい」と要求す るのは誰？人間である。 目的や価値は天から降ってきたり AIが決められるものではない。 決められるのは人間だけ。
13. © DMM 13 要求定義 要件定義 設計 実装 【問題定義フェーズ】 人間 ： pilot(操縦士) AI : copilot(副操縦士) 顧客要求や提供したい価値を人間が 定義し、AIが並走しながら人間の考 えをサポートする。 【問題解決フェーズ】 AI ： pilot 人間 : copilot AIが設計実装して、その成果物を人 間がレビューする。
14. © DMM つまりAI時代のエンジニアの役割は 以下の2つに近づいていきます • 問題定義（どのような問題を解くべきか） • AIが設計実装した成果物の妥当性検証
15. © DMM しかし物事の認識や解釈に歪みがあると 問題定義も設計も上手くいきません 問題となる2事例を説明します
16. © DMM 問題発生の例　その１ 認識のズレ
17. © DMM 17 ユーザーが商品を購入した後、 類似するものを一覧表示する機能を加えてほしいです 承知しました ビジネス側 開発者
18. © DMM 数ヶ月後
19. © DMM 19 ん……？？ いや、購入したのと同じような商品を表示されても困ります 出来上がりました 【購入が完了しました】　　　　　【よく似た商品】
20. © DMM 20 購入した後似たような商品を出したところで 誰も買いませんよ でもあのとき『類似する』って言ってませんでした！？ 【購入が完了しました】　　　　　【よく似た商品】
21. © DMM 21 期待していたのは関連して使う商品だったのですが…… 【購入が完了しました】　　　　　【こちらもいかがですか】 （はじめからその意味が伝わるように言ってよ……）
22. © DMM 問題発生の例　その2 いびつなドメインモデル
23. © DMM 23 ECサイトの開発において、次のような仕様が追加。 急遽実装することになった。 ユーザーに関して以下の項目を登録できること。 • 所属会社 • 会社電話番号 • 所属部署 • ロール
24. © DMM 24 ユーザー ユーザーID アカウント名 email password_digest 誕生日 会社名 会社電話番号 所属部署 ロール 担当者は特に何も考えずに ユーザーモデルに追加
25. © DMM 25 ユーザー ユーザーID アカウント名 email password_digest 誕生日 会社名 会社電話番号 所属部署 ロール 実はこの仕様は法人顧客に対応するもの、 個人と法人とで別々にすべきモデルをひとまとめにしてしまった 顧客や運営から問合せや苦情が殺到 私は学生なんですが、会社名の登録が 必要なんですか？ 会社情報を登録するのに「誕生日」が 必要なんですか？会社設立日を入力 すればいいんですか？ 既存の顧客情報に関して「会社名がな い」といったシステムエラーになる！
26. © DMM なぜこんなことになったのか
27. © DMM それは 言葉の意味を正しく解釈できなかったから
28. © DMM 28 事例 開発者が解釈した意味 本当の意味 事例１： 「類似するもの」 購入商品と似た商品。 例えば台所スポンジを購入した 場合、他のメーカーの台所スポ ンジ 購入商品とセットで使うよう な関連商品。 事例２： 「ユーザー」 ユーザーはユーザーであり、区 別がなかった 個人顧客と法人顧客
29. © DMM こうした問題解決に役立つのが 哲学や認知科学です これらは物事をより正しく認識することに役立ちます
30. © DMM 哲学とは 物事の本質を突き詰めるために問いを立て、考えを深めていく学問。 「なぜそれが正しいか」「前提が間違っていないか」といった追求をする。 世界の仕組みや真理を理解したいという欲求や ルールや善悪判断の基準となる思考を整理する目的で生まれた学問、 とされています。 分野は多岐にわたります： 形而上学、認識論、意味論、語用論、倫理学 etc.. 30
31. © DMM 認知科学とは 知能や心の働きを、情報処理の観点から解明する学問。 知覚、記憶、学習、言語理解、感情など心的機能が関心事です。 哲学、人工知能、心理学、言語学などの分野とも 関係が深いと言われています。 31
32. © DMM 哲学も認知科学も非常に広汎です ミノ駆動も目下学習中であり 知っているのはごく一部です 本日はあくまでソフトウェアを開発する上で ミノ駆動が普段活用している方法を解説します
33. © DMM 本日は以下の2つを紹介します • 哲学 ： 言語ゲーム • 認知科学 ： スキーマ理論
34. © DMM 言語ゲーム 哲学者ウィトゲンシュタインが提唱した哲学概念。 「言葉の意味は単独では決まらず、用法や文脈によって決まる」 とする考え方。 たとえば「水！」という言葉は、文脈によって次の意味になります。 34 文脈 「水！」の意味 カレー店 （辛さを和らげるために）飲み水がほしい 火災現場 鎮火するための水を持ってきてほしい
35. © DMM 35 文脈 「殺す」の意味 ソフトウェア 動作中のプロセスを強制停止するkillコマンド 日常 人を殺める https://x.com/yontengoP/status/618392622860668928 より引用
36. © DMM 36 スキーマ理論 スキーマ理論とは認知科学に登場する理論。 人間の脳は、自分の知識や経験に当てはめて物事を解釈しようとします。 この知識の枠組みを「スキーマ」と呼びます。 スキーマがあるおかげで 「これは自分の知識に当てはめると◯◯だ！」 と瞬時に素早く認識や判断ができます。 例えば電車を見たときに「これは電車だ」と素早く認識するなど。 一方でこのスキーマが働いてしまうことで 誤った解釈をしてしまうことがあります。
37. © DMM 37 「ジャングルの原住民を都会に連れてきたらどんな反応をするか」 という昔のTV番組にて なんて巨大な なんだ！！ 原住民は「電車」という概念を知らない。 自分が知っている「ヘビ」というスキーマに当てはめて解釈したと言えます。
38. © DMM 38 その仕事、適当にやっといて （私のやり方を踏襲しつつ、要点をおさえてやって） （細かいこと気にしないでとりあえず形にすればいいんだな） 承知しました 出来上がりました なんでこんな雑なんだよ 「適当でいい」と言いましたよね？ 自分の文脈（スキーマ）で相手の意図を解釈した例
39. © DMM 39 言語ゲームやスキーマ理論の学びから、言葉の意味を理解するには、 少なくとも以下4つの確認が必要だと考えます。 確認すること 説明 アクター システム利用者、利害関係者 目的 アクターの目的 文脈 アクターの背景やおかれている状況 ルール 文脈内で生じるルール、制約、方針 人の言葉の裏には目的があります。 目的は文脈から発生します（例：寒い→上着が欲しい）。 そして各文脈にはルールがあります（例：身体のサイズ、予算上限）。
40. © DMM では アクター、目的、文脈、ルールの観点から 先ほどの事例がどうあるべきだったのか考えてみます
41. © DMM 事例１「類似するもの」 ではどうあるべきだったのか
42. © DMM 42 ユーザーが商品を購入した後、 類似するものを一覧表示する機能を加えてほしいです いくつか前提を確認したいです。ここでのユーザーとは、 どういうユーザーを指していますか？ ビジネス側 開発者 日用品をまとめて買うような層ですね アクターの確認 なるほど。ユーザーさんが「まとめて買う」という状況なんですかね。 具体的にどういう状況で、どうしてほしいのですか？ 文脈、目的の確認
43. © DMM 43 追加で商品を購入してほしいんです。商品購入後に 「そういえばこれも必要だった」と気付いてもらいたいのです。 おや、すると「類似する」の印象がだいぶ変わりますね。 「類似する」とは具体的にはどういう条件ですか？ 購入した商品とセットで使うような商品ですね ルールの確認
44. © DMM 44 分かりました。 たとえばユーザーが台所用スポンジを購入した場合 食器用洗剤や食器拭きなど 「一緒に使うもの」のことを指しているのですね？ それらをまとめて購入してほしいんですよね。 そのとおりです！合ってます。
45. © DMM 事例２「ユーザー」 ではどうあるべきだったのか
46. © DMM 46 仕様には会社電話番号や部署名などがありますが、 これはユーザーさんが所属する会社ですか？ はい、そうです。 ユーザーさんが学生の場合どうなります？ いや、学生はありえないです。 え、どういうことでしょうか。ここでいうユーザーとは どういうユーザーなんでしょうか。 アクターの確認
47. © DMM 47 ここでのユーザーは、法人のお客さんです。 なるほど、個人だけでなく法人顧客にも対応するんですね。 これ個人ではダメなんですか？ 法人でなければならない理由はあるんですか？ 法人さんが仕事で使う物品を 一括大量購入しやすくするためですね。 となると、購入するにしても個人と法人とでルールが 違いそうですね。何か大きな違いはありますか？ 文脈、目的の確認 ルールの確認
48. © DMM 48 個人のお客さんとは違って、 購入数に応じて割引が効きますので、 こちらから見積もりを出して、合意し、 請求書を発行する流れになりますね。 あと法人さんの担当者は、 1人じゃなく複数人になるケースもあります。 （……これは個人とは全く別物のモデルになるぞ）
49. © DMM 49 法人アカウント 法人アカウントID アカウント名 email password_digest ロール 会社 会社ID 会社名 代表電話番号 組織 組織ID 組織名 1..* 1..* 個人を意味するユーザーモデルとは別に、 法人対応するための以下のドメインモデルを設計しました
50. © DMM このように哲学や認知科学を活用すると 言葉の意味を解釈する正確性が向上します それによりプロダクトの価値を向上したり ドメインモデルを正しく設計できるようになります
51. © DMM 意味解釈で陥りがちな諸注意点
52. © DMM 誰もが陥りがちなのは、相手の文脈ではなく自分の文脈で言葉の意味を解 釈してしまうことです。 スキーマ理論によると、人間はどうしても「自分の知識や経験」という レンズを通して物事を見てしまいがち。 （※ちなみにSNSではバズったポストに対して噛み合わない、 不可思議なコメントが付くことがありますが、 その多くは自分の文脈で語ったと思わしき内容に見えます） 自分の文脈を捨て去る、「自分にとって当たり前だ」と思っていることを捨 て去る、相手の視座に立つ、という姿勢が重要です。 自分の文脈で意味解釈しないよう注意 52
53. © DMM 「言葉には厳密な定義があるはずだ」の罠 「言葉には厳密な一意の定義があるはずだ」と思い込んでいると、 文脈による言葉の意味の違いを理解できなくなります。 数学や科学など理系の学問は、用語の定義に厳格です。 理系出身の方ほどこの罠にハマりやすいのでは、と考えます。 （※ちなみに数学や科学の文脈においては「用語定義が厳格」というルール が伴うという話であり、他の文脈ではそうとは限りません） 「言葉の定義に無神経で良い」という意味ではありません。 「相手がどんな言葉を発しようと、その背後にある意図や意味は何か」を 正確に理解する姿勢が重要、ということです。 一般定義に拘泥すると意味への到達が困難になります。 53
54. © DMM さてこのセッションでは ソフトウェア開発に伴う 言葉の意味解釈について解説してきました
55. © DMM 「ソフトウェア開発」と「言葉」…… 皆さん何かに気付きませんか？ 勘の良い方はすでにお気付きではと思います
56. © DMM ここでタネ明かし 実はドメイン駆動設計に登場する 「ユビキタス言語」 の話をしていたのです
57. © DMM ユビキタス言語 開発の利害関係者同士で認識を揃えるために使う言葉。 但し「同じユビキタス言語を適用可能な範囲は、 境界付けられたコンテキストまで」とされています。 例えば同じ「ユーザー」でも、 コンテキスト（文脈）が違うと意味も取り巻くルールも違います。 57 文脈 「ユーザー」の意味 取り巻くルール 営業 サービス購入の可能性 がある見込み客 成約に至るまでのルー ル カスタマーサポート サービス内容の問合せ 客 問合せ対応フロー
58. © DMM ユビキタス言語 「文脈によって言葉の意味が違う」という理解があって、 はじめてユビキタス言語は完成するのです。 ……ところでユビキタス言語をドキュメントにまとめたり、 用語集的にリスト化している、というのをたびたび見聞きします。 そうしたドキュメントには、 「文脈」や「取り巻くルール」といった項目はありますか？？ ないなら追加した上でユビキタス言語を見直してみましょう。 58
59. © DMM 59 ## 基盤となる考え方 - 言語ゲーム - スキーマ理論 ## 踏まえるべき観点 - アクター: システム利用者 - 目的: アクターの目的 - 文脈: アクターを取り巻く状況 - ルール: 文脈において生じるルール ユビキタス言語の策定にAIを活用できます。 以下はプロンプトの例です。 ミノ駆動が作ったagent skillはもっと複雑ですが、 より的確で本質的な言葉の提案までしてくれます。
60. © DMM ところで 「なぜはじめから『ユビキタス言語』と説明しなかったの？」 と感じた方がいるかもしれません それには理由があります
61. © DMM それはユビキタス言語についての先入観を 持ってほしくなかったからです スキーマ理論ですね もしユビキタス言語について 「用語集だ」という先入観があった場合 そのスキーマに引きずられて 本セッションの意義の理解が歪んでしまうことを 危惧したからなんです
62. © DMM さてだいぶ遠回りになりましたが やっとここでAIとの関係です
63. © DMM 言葉の意味解釈が不正確なまま AIに開発を指示したところで プロダクトを正しく作れるでしょうか？
64. © DMM どう考えても難しいですよね
65. © DMM ミノ駆動もいくつか実験しましたが 文脈が不十分だとAIが意味を取り違えて混乱しますし、 ユーザーモデルに対しても何の疑いもなく フィールドを追加しようとします つまりこの資料で取り上げた事例1,2と 同様のことがAIを使っても起こり得るのです
66. © DMM 「AIは増幅器」と言われます 使い手である人間のスキルを増幅するのです 地に足のついた技術や能力が 人間に求められるのです つまり……
67. © DMM 基本こそ奥義
68. © DMM 物事を正確に理解するために言葉の意味を整理する そのために哲学や認知科学を活用する 理解した意味に基づき要件を定義し 設計と実装に落とし込む 鍛錬し磨いた基礎力があって はじめてAIで能力を増幅できるのです
69. © DMM ご清聴ありがとうございました