「要件通りに作ったはずなのに、なぜか期待とズレる」。開発現場でたびたび起こるこの現象は、実装力ではなく「何を解くべきか」を捉える段階で生まれている。

『良いコード／悪いコードで学ぶ設計入門』の著者であり、合同会社DMM.comでコード品質改善とAI駆動開発推進の両輪を担うミノ駆動氏。哲学と認知科学のレンズを通して、開発現場に潜む認識の歪みとその正し方を解き明かした。AI時代のエンジニアに求められる「問題定義」の力を、具体的な失敗事例から掘り下げる。

「そうじゃない」を生む認識のずれの正体

AI駆動開発が加速する一方で、「AIを使っても価値が上がらない」「開発が終わらない」「破壊的変更が起きる」といった声も絶えない。ミノ駆動氏は、その背景には技術だけでなく、人間側の物事の認識や解釈の歪みがあると指摘する。同氏は、日常のショッピングサイト開発で起きがちなすれ違いを起点に、哲学と認知科学を実践で使う方法論を提示した。

合同会社DMM.com
プラットフォーム開発本部第3開発部 コード品質チーム／AX戦略グループ
ミノ駆動氏

AI時代に問われる「何を解くか」の力

近年、AIによるソフトウェア開発は加速度的に広がっている。AIエージェントは急速に進化し、企業によっては「AIにオールインする」と宣言するケースもある。しかし、せっかくAIを使っているのにプロダクトの価値が上がらない、実装がいつまでも終わらない、既存環境に破壊的な変更を加えてしまうといった問題が各所で報告されている。

ミノ駆動氏は、こうした問題の大きな要因の1つが「人間側の物事の認識や解釈が不正確、あるいは歪んでいること」だと指摘する。解釈に問題があれば、顧客の要求を正しく理解できず、ドメインの構造も歪んでしまう。

一般的な開発プロセスは「要求→要件定義→設計→実装」と流れるが、AIによって置き換わりつつあるのは後段の設計と実装だ。必然的に人間の仕事は前段へシフトする。DMM.comではこの流れを踏まえ、開発フェーズを2つに整理している。

• 問題定義フェーズ（要求・要件定義）：人間が主軸となり、AIが並走する
• 問題解決フェーズ（設計・実装）：AIが手を動かし、人間が妥当性を検証する

「ああしたい、こうしたいと要求するのは人間です。人の目的や価値は天から降ってくるものではなく、人が決めるもの」とミノ駆動氏。同氏は、AI時代のエンジニアに求められる役割として、「どのような問題を解くべきか」を定義することと、AIが生み出した成果物の妥当性を検証することの2つを挙げる。だからこそ、その入口である「認識」の正しさが決定的に効いてくる。

台所スポンジと法人ユーザーで起きた食い違い

抽象論を離れ、ミノ駆動氏はショッピングサイト開発の2事例を紹介した。

1つ目は「認識のずれ」だ。ビズ側から「ユーザーが商品を購入した後、類似するものを一覧表示する機能を加えてほしい」と依頼が入る。開発者は承知して数か月後に完成させた。台所用スポンジを買ったら他社の似たスポンジが並ぶ、よくある構成だ。しかしビズ側は難色を示す。「購入したのと同じような商品を表示されても、誰も買いません。期待していたのは、関連して使う商品だったんですが」。台所用スポンジに対して食器用洗剤や食器拭きを提示してほしかった、という話である。「初めからその意味が伝わるように言ってよ」と言いたくなる、開発現場で起こりがちなすれ違いだ。

2つ目は「いびつなドメインモデル」。急遽、仕様書に「ユーザーに関して、所属会社、会社電話番号、所属部署、ロールを登録できること」という項目が追加された。担当者は既存のユーザーモデルに素直にフィールドを足す。すると「私は学生ですが、会社名の登録が必要なんですか」「会社情報を登録するのに誕生日が必要なんですか」「既存の顧客情報について、会社名がないとシステムエラーになる」と苦情が殺到する。仕様が指していたのは法人顧客であり、従来のユーザーは個人顧客を指していた。本来は別モデルにすべきものを1つに束ねてしまったのだ。

どちらの事故も、根っこは同じ。「類似するもの」も「ユーザー」も、開発者は自分の解釈で言葉を受け取ってしまった。前者は「見た目が似た商品」と読み、後者は「ユーザーはユーザーだ」と区別しなかった。言葉の意味を正しく解釈できなかったから、機能もモデルも歪んだ。

言葉の意味は文脈で変わる──言語ゲームとスキーマ理論

ここでミノ駆動氏は、意味解釈の正確性を高める道具として、哲学と認知科学から2つの考え方を取り上げる。

1つは、哲学者ウィトゲンシュタインが提唱した「言語ゲーム」。言葉の意味は単独では決まらず、用法や文脈によって決まるという考え方だ。「水」という言葉も、カレー店では「辛さを和らげたい」の意味になり、火災現場では「鎮火のために持ってきてほしい」の意味になる。文脈が変われば意味も変わる。

分かりやすい例として、ミノ駆動氏はSNSで話題になったよんてんごPさん（@yontengoP）のエピソードを引いた。「親は殺せたんですけど、その後ろの子供が普通に生き残ってて」といった、一見すると物騒にも聞こえる会話だ。エンジニア同士ではプロセスの強制停止（キルコマンド）について話していると分かるが、カフェで耳にした人にはまったく違う意味に聞こえてしまう。

もう1つが、認知科学の「スキーマ理論」。人間の脳は、自分の知識や経験の枠組み（スキーマ）に当てはめて物事を素早く解釈する。ミノ駆動氏は、その例として、電車を見たことがない人が初めて電車を目にしたときのエピソードを挙げた。その人は電車を見て、「なんて巨大な蛇なんだ」と表現したという。電車という概念を知らないため、目の前にある未知のものを、自分がすでに知っているものを手がかりに理解しようとしたのだ。つまり、細長く動く巨大な物体を、自身の知識の中にある「蛇」のスキーマに当てはめて認識したのである。

日常の仕事でも同じことが起こる。上司が「適当にやっといて」と言い、自分のやり方を踏襲しつつ要点を押さえてほしい、と意図する。受け手の部下は「細かいことを気にしないで形にすればいい」と解釈して仕上げる。上司は「なんでこんな雑なんだ」、部下は「適当でいいと言いましたよね」となる。「この部下、僕のことです。昔こういうやらかしをしました」とミノ駆動氏は自嘲した。文脈と自分の持つスキーマがズレれば、同じ日本語でも噛み合わない。

言語ゲームとスキーマ理論を踏まえ、ソフトウェア開発で意味を揃えるためにミノ駆動氏が普段確認しているのが、次の4点だ。

• アクター：システムの利用者や利害関係者
• 目的：アクターが何をしたいのか、どういう思惑があるのか
• 文脈：アクターの背景や置かれている状況
• ルール：その文脈内で生じている制約や方針

ミノ駆動氏によれば、人の言葉の裏には目的があり、その目的は文脈から決まり、文脈にはルールが伴う。寒い状況では上着が欲しくなる（目的は文脈が決める）が、体のサイズや予算といったルールも背負っている。この4点を揃えれば、意味は輪郭を持つ。

先の2事例を4点で問い直すとどうなるか。「類似するもの」ではまずアクターを確認する。想定されるユーザーは日用品をまとめ買いする層だと分かる。次に文脈と目的を確認すると、購入後に「これも必要だった」と気づいてもらいたいのだと見えてくる。最後にルールを問えば、条件は購入商品とセットで使う商品だと明らかになる。ここまで揃えば、台所用スポンジに対して食器用洗剤や食器拭きを出すアプローチにたどり着く。

「ユーザー」も同様だ。アクターは法人顧客。文脈と目的は、仕事で使う物品を一括大量購入しやすくしたい。ルールは、購入数に応じた割引、見積もり、請求書発行が必要で、担当者は複数人になり得る。この情報がそろえば、会社の配下に複数の組織があり、さらにその配下に複数のアカウントが存在する、個人とは別物のドメインモデルにたどり着く。

ここまで話してからミノ駆動氏は種明かしをした。「実は今日のセッションは、ドメイン駆動設計に登場するユビキタス言語の話をずっとしていました」。エリック・エヴァンス著『ドメイン駆動設計』にある通り、ユビキタス言語が適用可能な範囲は境界付けられたコンテキスト（Bounded Context、業務や関心事の境界で区切られた領域）までとされる。例えば、ある組織では営業の文脈で「ユーザー」が成約に至る見込み客を指し、カスタマーサポートの文脈では問い合わせ客を指すこともある。同じ言葉でも文脈が違えばルールも意味も違う。「言語ゲームの考え方でいう文脈による言葉の意味の違いがあって、初めてユビキタス言語は完成します」。

現場では、ユビキタス言語を用語集としてリスト化している組織も多い。しかし文脈や取り巻くルールの項目が抜けているなら、それはユビキタス言語としては不完全だ、とミノ駆動氏は問いを投げかける。策定にはAIも活用できる。言語ゲームとスキーマ理論を基盤として与え、アクター・目的・文脈・ルールの4観点をプロンプトに含めれば、AIから文脈に応じた言葉の候補を提案してもらうこともできるという。

なお、ユビキタス言語の話をあえて最後に出したのも意図がある。先に用語を提示すればスキーマが働き、参加者の理解が用語集のイメージに引きずられてしまう。理論を先に、名前を後に。この設計自体がスキーマ理論の応用だった。

意味解釈で陥りがちな注意点として、ミノ駆動氏は2つを挙げた。1つは「自分の文脈で意味を解釈してしまう」こと。SNSでの噛み合わないコメントの多くも、書き手ではなく自分の文脈で語ることから生まれる。「自分にとって当たり前だと思っている思い込みを捨て、相手の視座に立つ姿勢が重要」。もう1つは「言葉には厳密な定義があるはずだ」という思い込み。数学や科学など理系の分野では用語定義が厳格だが、他の文脈ではそうとは限らない。「相手が発した言葉を一般定義に当てはめると、その人の本心に到達できなくなる」と注意を促した。

基礎があってこそAIは活きる

「散々言われているように、AIは増幅器です」とミノ駆動氏は表現する。使い手の解釈が適切ならAIはその能力を増幅する一方、解釈が歪んでいれば、その歪みも増幅される。ミノ駆動氏の実験でも、文脈が不十分だとAIは意味を取り違え、疑いもなくユーザーモデルにフィールドを追加した。ここまで紹介した2事例と同じ事故が、AIでも起こり得る。

だからこそ、地に足のついた基礎力が問われる。言葉の意味を整理するために哲学と認知科学を活用し、整理した意味に基づいて要件を定義し、設計の知識を落とし込む。この基礎の上に、AIによる能力の増幅が乗る。

続くQ&Aセッションでは、認識合わせを実務でどう回すか、ユビキタス言語のアンチパターン、基礎力の鍛錬とは何か、といった具体的な問いに答えていく。

Q&A セッション

Q. 哲学や認知科学をエンジニアが学び始めるとき、最初に読むべき書籍は何ですか。

ミノ駆動氏: 昨年のITエンジニア本大賞を受賞した『「何回説明しても伝わらない」はなぜ起こるのか？』がおすすめです。スキーマ理論について、日常生活を題材に、認識のずれやトラブル、解決の仕方が分かりやすく書かれています。

Q. ビズ側の考えを毎回引き出すのに疲れます。逆にビズ側から適切に表現してもらう方法はありますか。

ミノ駆動氏: 認知バイアスの1つに「投影バイアス」があります。「こんなこと言われなくても分かるでしょ」と、自分の世界観を相手に投影してしまうバイアスです。自分にとって当たり前のことが語られなくなるので、知らない相手からするととてつもなく重要な前提が抜け落ちます。ビズ側と話すときには、投影バイアスがあることを共有した上で、どんな初歩的な前提でもちゃんと話し合いましょうと約束することが大事ですね。

Q. プロンプトエンジニアリング以前に、人間側の文章作成能力を育てる方法はありますか。

ミノ駆動氏: 文章を書くことは自分の考えを整理することにつながります。デバッグ手法にラバーダッキング（疑問点を他者に説明しているうちに、自分で答えに気づく手法）という、先輩に相談しながら話しているうちに自分で解決策を思いつくテクニックがありますが、あれと同じです。特に大事なのは、言語ゲームで説明した通り、意味は文脈で変わるという前提のもと、今どういう状況に置かれているか、背景や状況を言語化した上で「この状況ではこうなんです」と書く練習をすること。前提を飛ばすと書き手も読み手も混乱します。まず「自分たちはどんな状況に置かれているか」を言語化するのがスタートです。

Q. なだれ込む情報を遮断する能力は、意志ですか、仕組みですか。

ミノ駆動氏: 前提が読み取れないので推察でお答えします。人間は不安を覚えると白黒はっきりつけたくなる性質があるので、短絡的に答えを求めがちです。ただ、哲学者の千葉雅也さんの言葉に「真実はグレーゾーンの中にある」というものがあります。本質的に難しいものは混沌として複雑なものの中にあって、白黒つけずに分からないものと一緒に踊りながら、ああじゃないか、こうじゃないかと考えていくことが大事だと思います。

Q. ビズ側のスケジュールが詰まっていて、擦り合わせが不十分なまま開発が進んでしまいます。どう改善すればよいですか。

ミノ駆動氏: それはタイムマネジメントや仕事のやり方の問題ですね。認識が揃わないまま出してちゃぶ台返しになれば、多大な工数、下手すれば再開発です。ちゃんと機能するものを作る方が大事なので、「認識を揃えないとまずいものを作ってしまう」ということをまず共有した上で、スケジュールやコミュニケーションのあり方を見直すべきだと思います。そこがボトルネックですから。

Q. 経験されたユビキタス言語のアンチパターンを教えてください。

ミノ駆動氏: よくあるのは「最初に決めた言葉に固執する」ことです。この意味はこの言葉だと固定してしまい、より良い言葉や概念があるはずなのに気づけない。周囲の認識もソースコードの構造まで歪んでいきます。例えばブログ投稿サイトで「記事」というモデルを置くと、みんな「記事」で考えてしまう。でも実は、投稿前と投稿後では振る舞いや制約が違います。下書き段階ではタイトル0文字でもよいが、公開時には1文字以上が必要、といった具合です。本当は「下書き」と「完成稿」に分けるべきかもしれない。「記事」に囚われていると、そこにたどり着けません。だから僕は言葉というものを信じていません。自分が言葉に囚われているのではないか、もっと複数の概念に分けて考えるべきではないか、と常に疑うことが大事です。

Q. 言語ゲームやスキーマ理論を忠実に実行すると「面倒くさい人」と思われて擦り合わせが進まなくなる怖さがあります。話し方で意識していることはありますか。

ミノ駆動氏: 「面倒くさく思うなよ、大事な話なんだから」と伝えますね。「認識が揃わないと正しい機能の開発に支障が生じる可能性があるので、揃えたい」と絶対に伝えます。ただ本質的には、これは心理的安全性やチームビルディングの話です。個人でいくら戦ってもダメで、チームリーダーやマネージャーも巻き込んで、私たちの仕事をどう進めるか、どう改善するかを常に話し合う。そういう場を作ることが大事だと思います。

Q. 絵や映像で理解するタイプの人には、どう説明したらよいと思われますか。

ミノ駆動氏: いい着眼点ですね。実は僕自身も、絵で解釈する側の人間です。認知科学に「身体性認知」という概念があって、人が物事を正しく理解するには五感を働かせる必要があると言われています。オフィスにこもって仕事するだけでなく、実際にシステムを使うお客さんのところに足を運んでみると、本当の困りごとが分かることが多いですよね。情報の伝達手段、入手手段にはいろいろな方法があります。絵、言葉、現場で体感する、その人と場に一番ふさわしい手段を取るのがよいと思います。

Q. 基礎力の鍛錬には何が必要ですか。

ミノ駆動氏: 技術は問題解決の手段です。「こういうことで困っている」という問題があって初めて、どんな技術で解決するかが決まる。問題と技術は両輪です。だから基礎を知るためには、まず誰がどう困っているかを知ることが大事です。同時に、技術そのものを知ることも大事です。技術によって理想的な状態がどう作られるかを知って初めて、そのギャップとして問題を認識できるからです。技術的負債も、変更容易性の高い理想的な構造を知っていて初めて、どこが負債かを認識できます。「私たちは何で困っているのか」と「技術で問題解決した先の理想はどこにあるのか」、この2つを知ることが基礎力の鍛錬につながると思います。