システム開発と教育におけるアンラーンの重要性

概要

この記事では、

• アンラーンの重要性： システム開発・教育においてアンラーンがとても重要であること
• 具体的なアンラーンの方法、技術
• 教育とはなにか： 教育の重要な目的は記号接地であり、そのために積極的にアンラーンを促す必要もあること

についてシステム開発の文脈でDDDの用語を交えて説明します。と言っても深くDDDに依存しているわけではなく、システム開発全般・ひいては認知を合わせる必要のある仕事全般について共通することの説明になっています。
DDDに関連する部分については、『関数型ドメインモデリング ドメイン駆動設計とF#でソフトウェアの複雑さに立ち向かおう』という本から一部引用します。この本には開発者の誤解によってどのようにして認知のズレが生じるか、またそれをどうやって修正するかという具体的な場面が示されており、この具体例から「アンラーンがいつ必要になり、具体的にどう作用するのか」「アンラーンができなければどうなってしまうのか」ということを学んでいきます。

本文が長くなってしまったので、補足や追加的な情報については折りたたんであります。↓のような箇所はクリックで展開できます。必要に応じて参照ください。

この記事を書くまでの背景的情報（あらすじ：省略OK）

私はシステム開発の仕事をしていますが、より価値のある開発を、より早く行えるような組織を作るために必要なことを模索しています。その中でうまくいく場合とうまくいかない場合があり、要因が何で、どう対策をすればよいのかということを考え続けていました。
この要因には、純粋に技術的な事とそうでない事があります。純粋に技術的な事については、以下のようにして、ある程度基礎的な部分を学習できることがわかりました。

• コードを書いて自動化する感覚を掴む、身体感覚として馴染ませる
• コンピューターサイエンスを学ぶ
• ビッグテック企業の面接相当の模擬面接で対話をする
• 良いコードについてのメンタルモデルを持つ

「そうでない事」の部分については、知的な仕事の量と深さ - 10倍の成果とIQ、執念、知識、認知の記事、学ぶ力の正体と、その影響 - 学力喪失を読んでの記事、学習・認識合わせ・失敗・作業量あたりのメンタルモデルの記事などで述べた考察を経て、

• 学力喪失は教科の勉強以外でも発生し、それによって仕事の成果が出なくなる
  • 仕事の成果を出すには、学力喪失していない状態にする必要がある
• 認知を合わせることが重要であり、それには十分な時間をかけないといけない
  • 記号接地を避けることはできない（記号接地については後述）

という結論に至りました。こうして、「認知を合わせる」「記号接地する」という方針でチームの目標を整理したのですが、「では具体的にどう認知を合わせればよいのか？記号接地がうまくいかない場合の理由と対策は何か？」という問に対する答えは出ていませんでした。
実は、この問が生じるずっと前から、私が他者に対して記号接地できるよう働きかけても、最終的に記号接地できない場合が多くありました。記号接地に時間がかかる、というのは分かっているのですが、ただ私の失敗は時間の問題ではなく、むしろ時間をかけるほど単に疲弊して終わる、どれだけやっても進捗が全く生まれずお互いに疲弊する、というような状況でした。時間や根気の問題ではないのです。ただ、私の方法が全く通じない人がいる一方で、通じる人もいました。それはなぜか。具体的にどう認知を合わせればよいのか。その答えがようやくわかってきたので、整理して記します。（結論としては、アンラーンが大きく作用している、ということになります。）

★『関数型ドメインモデリング』の本は、ここで取り上げた話題以外にも多くの示唆があり、良い本だと思います。ぜひ読みましょう。
★この記事が長くてわかりにくいと思われた方、正解だと思います。 ぜひ、部分的でも良いので、わかりやすい記事を書いて拡散してください。いろんな方に届くようになると思います。

用語の説明

用語をいくつか簡単に説明しておきます。DDDに関する用語は基本的には『関数型ドメインモデリング』の本に倣っています。

まず、システムまたはプログラムが、効果を発揮する・問題を解決する対象となる領域のことを単に ドメイン(domain) といいます。domainという単語を英和辞典で引くと「領域」とあるとおり、特別難しい語を定義しているというよりは、もともと一般的な語で「領域」と呼び表している程度のことです。

一般に、 DDD(Domain Driven Design) と呼ばれる設計手法は、設計者および関係者はシステムを設計するにあたってこのドメインに注意を向け、ドメインを深く理解し、コードを含むプログラムの設計全般がドメインを反映した状態になるように設計をする、という手法です。その具体的な作法としては様々なものが提案されていますが、ここでは深くは立ち入らないことにします。

DDDにおいても、解決手段を作り出す人（例えばプログラミングする人）と、問題をもっともよく理解している人（例えばシステムを使って業務を行う人のうち、特に詳しい人）は一致するとは限りません。問題をもっともよく理解している人のことを ドメインエキスパート(domain expert) といいます。具体的にドメインエキスパートが何であるか、その満たす要件は、といったことについては深く立ち入らないことにしますが、本の言葉を借りれば「会えば一発でわかる、というやつです」！

ドメインモデル(domain model) とは、あるドメインにおいて、特定の問題に関連した側面を単純化して表現したものの集合です。特に、ドメインエキスパートが特定の問題を解決する際に頭の中に浮かべるモデルを指します。

メンタルモデル(mental model) とは、人間の認知を説明する際の用語の一つで、「外界の現実を仮説的に説明するべく構築された内的な記号または表現」ないし「頭の中にある「ああなったらこうなる」といった「行動のイメージ」を表現したもの」のことを指します。ドメインモデルは、ドメインエキスパートが特定の問題を解決する際に持つメンタルモデル、と言うことができます。

「記号接地」の概念について（先にケーススタディを読んでから見てください）

ところで、『関数型ドメインモデリング』の本では、ドメインについて

もっとわかりやすく言えば、単純に「ドメインエキスパート」が専門としているものごとを指します。

と書かれています。これは間違いではないのですが、例えば"北"という概念を、「"東"を向いたときの左の方向」と説明するのと似ていて、もし「ドメインエキスパート」の概念がわからない場合には、言葉の定義は理解できたとしても、その意味がよくわかりません。言い方を少し変えると、言葉の意味を本当に理解して使いこなすためには、言葉の間の関係性を知るだけでは不完全であり、その言葉がどういった意味を持つのか、言葉だけではない感覚や具体的な利用方法などと「接地」している必要があるのです。この、言葉がその他の感覚や利用方法などと繋がって使いこなせる知識になっている状態を 記号接地している といいます。記号的知識である言葉が、その他感覚に"接地"している、ということです。
例えば「北は東を向いたときの左の方向」「東は北を向いたときの右の方向」とだけ理解していた場合には、この知識は記号接地していない状態です。他の例としては、ドメインエキスパートの意味がよくわかっていない状態で、ドメインの定義として「ドメインエキスパートが専門としているものごと」ということだけを知っている状態も、ドメインの概念（およびドメインエキスパートの概念）を記号接地できていないと言えます。
対照的に、（日本において）「北に行くと寒くなる傾向がある」「夜に空を見上げ続けると、北の方向には位置が変わらない星が存在する（南にはない）」「日中の太陽の位置を北と南に分けて表現すると、必ず南にある」「地図は北を上に向けて書かれる事が多い」といった知識がある程度経験的な実感を伴っていて、イメージを伴って頭に浮かぶならば、北の概念は記号接地していると言えます。ドメインエキスパートについてもそうで、自分が開発している・してきたシステムの対象領域（ドメイン）について一番くわしい人、と言われてイメージする人がいれば記号接地できていて、その具体的な人のイメージができなければ記号接地はできていないといえます。一般論として、ある概念を言葉として理解しているつもりでも、それを具体的にイメージできないならば、それは記号接地ができていないことになります（断言はできませんが）。
ここで重要なのは、ドメインエキスパートの概念が記号接地されていれば、上記の説明によってドメインの概念もそれを通じて（部分的に）記号接地された状態になる、ということです。ドメインエキスパートを生き生きと想像できる人にとっては、「その人が専門としているものごと」という概念についても具体的なイメージを持ちやすく、自分の中で柔軟に使用できる知識として定着させることができるでしょう。
従来からある日本語としては、腑に落ちたというのが、記号接地に近い概念だと思います。
ただし、記号接地ができているからといって、その内容が「正しい」かどうか、他の人の持つ知識体系と整合的かどうかはわかりません。間違った知識が記号接地している場合もあります。
（厳密には、事実と接続されていないのだか間違った知識の場合には記号接地することはありえない、という考え方もあると思います。しかしここでは、知識として間違っていても当人の中で実感を伴って記号操作できる状態になっている概念については、記号接地しているものと解釈します。というのは、誤った記号接地もこの記事の重要なテーマだからです。）

アンラーン(unlearn) または アンラーニング とは、一度学習した知識や信念などを（意図的に）棄却することを指します。特に、なにか新しいことを学ぶ場面で、古い知識や誤った信念などを棄却することを意図していることがあります。

ケーススタディ

では、ケーススタディを始めていきます。『関数型ドメインモデリング』第1部 第2章 ドメインの理解 の中の、ワークフローについてのインタビュー例から一部引用します。

インタビューのはじまり

以下の話は、受注に関する注文確定のプロセスのワークフローを理解するためのインタビューです。
「あなた（開発者）」と「オリー（ドメインエキスパート）」の2人の登場人物が会話をしています。オリーは、次に示す紙の注文書について、現在は郵送で受領して処理をしているが、これをオンラインで処理できるようにしたい、という要望を伝えています。
以下、図と本文を引用します。

この時点で、これは典型的なEコマースモデルだと思われるかもしれません。

あなた：「なるほど。つまり、お客様はWebサイトの商品ページを閲覧し、クリックしてショッピングカートに商品を追加し、チェックアウトするということですね。」
オリー：「いえ、それは違いますね。私たちのお客様は、自分が何を注文したいかをすでに正確に知っています。私たちは、お客様が製品コードと数量を入力できるシンプルな入力フォームが欲しいだけなのです。一度に200～300個の商品を注文することもあるので、商品ページをクリックして各商品を探すのでは時間がかかり過ぎてしまうのですよ。」

これは重要な教訓です。あなたはドメインについて学ぶべきなのですから、（この場合）顧客がシステムをどのように使用するかなど、何かについて結論を急ぎたい衝動に駆られないようにしましょう。よいインタビューとは、相手の話をしっかりと聞くこと、それが大切なのです！　ドメインについて学ぶための最良の方法は、人類学者になったつもりで、先入観を持たないことです。

これは非常に示唆に富んでいます。以下、ここで強調しておきたい2つの点について説明します。

もしこの確認がなかったら、どうなっていたか

仮に、この注文書だけをインプットとして、詳しい会話をせずに開発者がシステムの要件の整理や、あるいは設計を始めてしまったとしたら、どうなるでしょうか？勘違いした「あなた」は、典型的なEコマースモデルで、200〜300個の商品を注文する想定のない、少数の商品を一つ一つ選びながらカートに追加するようなタイプのECサイトを構築してしまいます。たった一度の会話で解決するようなことで、とんでもない誤りが発生してしまうところでした。この記事を読まれている方も、自分自身や身の回りで、これに近いような誤解が大きな間違いを生んだという経験はないでしょうか。たった一言、自分が想像できて実現できそうなことであっても、その内容の確認を取るだけで防げることがあったのです。
（注意：ただし、ここで 確認をして修正するということをゴールにしてはいけません。 確認をして修正することは、事故が起こったときに救急車を呼ぶのと同じ意味で必要な工程ですが、ゴールではないです。もし継続的に一つの開発を行うならば、確認して修正することが減るように、最初に想像するものが80%〜90%一致する状態を目指すべき です。これは、関数型ドメインモデリングの本の内容ではなく私の主張です。）

確認をしたあとに誤った先入観を捨て去ること（アンラーン）

ここで付け加えておくと、先入観を全く持たない、仮説を全く持たないということは現実的には不可能です。ただし、自分がどこに先入観を持っているか、仮説を持っているか、ということをメタ的に認知しておくことはできます。 自分の考えていることのどこが仮説なのかを意識しながら会話すれば、仮説が間違っていたら速やかに仮説を捨てる、棄却することが可能 です。
実際に、この確認で仮説を持って提示することには、その場で認知のズレが明らかになり、その場で認知を修正できるという効果もありました。仮に「あなた」が以下のような質問をしていたとしたら、どうでしょうか？

１．「なるほど。つまり、お客様はWebサイトで商品を選択して、このフォームの内容を入力できればよい、ということですね。」

２．「なるほど。つまり、お客様がこのフォームに記入している内容を、WebサイトでなんらかのUIによって送信できればよい、ということですね。」

１の質問の場合、「Webサイトで商品を選択」という部分が、ひょっとしたらオリーに違和感をもたらすかもしれませんが、おそらく実現することに大きな嘘はありません。実際、コードを入力して実在するコードと一致（or部分一致）する商品を選択するというUIをオリーが想像したならば、それは間違いではないからです。
２の質問の場合は、もはや抽象度が高すぎて、間違いはありません。しかし、この「なんらかのUI」の部分が、まさに「Webサイトの商品ページを閲覧し、クリックしてショッピングカートに商品を追加し、チェックアウトする」という方式であったとしたら、どうなるでしょうか。この言葉自体に嘘はなくても、その具体的な内容として想像しているものが、「あなた」と「オリー」で大きく乖離していることになります。
したがって、１や２ではなくて、引用した内容のような質問をするということには、重要な意味があります。この事例での考察をまとめると、

• 具体的な質問による確認が重要であり、オリーから情報を引き出すためにはある程度は具体的な質問であることが望ましい
• 一方で具体的な質問はズレている可能性も高いので、ズレていて当然という認識を持ちながら質問をし、ズレを修正する
• ただし、このズレは少ないほうがよく、長期的には初手で80%〜90%程度は認識が合うようにしていくのが望ましい

ということになります。
この後も、先入観とそれが与える影響、および先入観を捨て去ることについてフォーカスをあてて、具体的にインタビュー事例を追いかけていきます。

残りのワークフローの整理（抜粋）

インタビューの続きを引用します。なお、引用箇所の前に、注文書フォーマットに記述があった製品コードについてのインタビューや、業務の頻度・量などについてのインタビューをしていますが、割愛しています。

以下、1件1件の注文書について何をするか、という会話の主要な部分からの抜粋です。（インタビューの部分だけを抜粋しています。）

オリー：「そして、個々の価格を合計して、一番下にある『合計』フィールドに記入します。オリジナルはファイルに保存しておきます。」
あなた：「その後は？」
オリー：「その後、注文をスキャンしてお客様にメールで送り、価格や支払い金額を確認してもらいます。これを『注文確認』と呼んでいます。」
あなた：「『見積』と『注文』と書かれたボックスは何のためにあるのですか？」
オリー：「『注文』にチェックが入っていれば注文、『見積』にチェックが入っていれば見積依頼です。見たままですね。」
あなた：「では、見積依頼と注文の違いは何ですか？」
オリー：「見積依頼とは、お客様が価格を計算するだけで、実際に商品を発送しないことを望んでいる場合です。見積依頼では、依頼書に価格を追加してお客様に返送します。発送部門や請求部門には何もしないので、コピーは送りません。」

実は、オリーの発言を受けて「あなた」が最後にコメントする内容が実は非常に重要なのですが、敢えて上記引用から外しています。記事を読み進める前に、「あなた」がどんなコメントをしたのか、想像してみてください。

見積依頼と注文の概念の違いを引き出し、それを違う概念として正しく理解する

「正解」はこうです。

正解

あなた：「なるほど。注文と見積依頼は似ているので、同じ依頼書を使えますが、それらに関連するワークフローは異なるということですね。」

これはめちゃくちゃ、ものすごく重要なことで、冒頭に記していたように今のインタビューの前提は 受注に関する注文確定のプロセスのワークフローを理解するためのインタビュー でした。そして、その中でドメインエキスパートから注文書をインプットとして受け取り、それについての確認をしていたのでした。にも関わらず、ここでは注文書という名前のフォーマットを使って、見積依頼と注文という別の目的のことを行っている、という話がサラッと出てきていることになります。
これは非常に重要なことで、ドメインエキスパートはドメインを熟知していても、そのドメインの理解の形が常にシステム化に即した・システム化に向けて整理された状態ということではありません。このドメインエキスパートの持つメンタルモデルを正確に理解するには、まずインタビューでこうして一つのワークフローを扱っている場合であったとしても、実は一つのワークフローではなかったという場合が普通にあるのです。ここでは、今扱っているワークフローが実は一つではなかった、というアンラーンがリアルタイムに必要になります。これぐらいの頻度で、リアルタイムにアンラーンが必要になるのです。

このアンラーンが誰の仕事なのか - 当然、「あなた」

ここでさらに重要なことは、仮に「あなた」が一つのワークフローを考えるという姿勢をアンラーンできなかったとしても、おそらくドメインエキスパートはそれに気づかない ということです。というのは、オリーの業務としてはいずれの場合も注文書のフォーマットを一つ扱っており、もしオリーがワークフローの概念を強く持って明確に見積依頼の処理と注文の処理を区別して認識していなければ、ワークフローとして一つにまとめるということへの疑問はオリーからは発生しないこともあります。
これは、ドメインをワークフローに分解するプロであるところの「あなた」が拾えなければ、誰も拾えないことなのです。
したがって、「あなた」は、プロとして自分の認知がオリーの述べていることを正確に把握したものとズレていないかをチェックして、ズレていればアンラーン・修正する ということをしないといけません。

ここまでのインタビューが終わった時点で、すぐに設計について考えたくなる場合があると思いますが、それをやってはいけないという事が『関数型ドメインモデリング』の本に書いてあります。以下、2つの場合について、ドメインエキスパートのメンタルモデルがどのようにゆがめられるか、ということを具体的に指摘している箇所を引用します。

データベース駆動設計をしたいという衝動との戦い

注文書のインターフェイスなどから、次のような設計を考えてしまいがちですが、これにどのような問題があるか、という部分を引用します。

データベース駆動なモデルがもたらすゆがみの例として、前の図では注文と見積の違いをすでに無視しています。確かに、データベース上では両者を区別するフラグを立てることができますが、ビジネスルールや検証ルールは異なります。たとえば、Order〈注文〉には請求先住所がなければならないが、Quote〈見積〉には請求先住所がないことが後にわかったとします。これを外部キーでモデル化するのは困難です。同じ外部キーが両方のタイプの関連に兼用されているため、データベースの設計ではこの微妙な点が失われています。

今の時点では、例えば請求先住所や配送先住所など、注文書のフォーマットすべてについて掘り下げているわけではないので、見積依頼と注文で各項目の入力が必須か否か、といったことがわかっていません。また、見積依頼の業務がこのフォーマットで完結するのか、あるいは完結させるべきなのかということもわかりません。
本当に単純に、今の業務をWebで行えるようにするというだけであれば、全く同じ注文書フォーマットを実現すれば、業務をWebで行えるようにはなるでしょう。ただ、それがあるべき姿かというと、おそらくそうではありません。今は同じフォームで行えているとしても、実は別でやりたいことはあるかもしれません。あるいは、Orderの方を掘り下げていったときに、Orderには注文日を持たせたいとか、色々と検討事項が出てくるかもしれません。そうしたときに、Orderを現在の注文書フォームに対応する内容として一つのテーブルとして持つという方針、"先入観"を持ってしまうと、見積依頼も扱うテーブルとしては不適切な内容が出てくる可能性があります。このような先入観は、オリーの頭の中には無いでしょう。
もちろん、システムが全くできないということではないでしょうが、どちらの整理のほうがより筋が良いか、ということで、メンタルモデルをドメインエキスパートのそれと合わせる、ということを重視するならば、自然と設計に踏み込んではいけないことになります。

クラス駆動設計をしたいという衝動との戦い

類似のパターンとして、クラス設計をしてしまうという失敗もあります。以下、引用します。

上図の予備設計では、注文と見積を分離していますが、現実の世界には存在しない人工的な基底クラス、OrderBaseを導入しています。これはドメインのわい曲です。ドメインエキスパートにOrderBaseとは何かと聞いてみてください。 ここで学ぶべきなのは、要件収集の際にはすべてを受け入れる姿勢を保ち、自分の技術的な考えをドメインに押しつけないことです。

ここで重要なのは、OrderBaseが仮にそれっぽい別の名前であったとしても、ドメインエキスパートのメンタルモデルとは乖離しているということです。ドメインエキスパートは「見積依頼や注文の概念は、それらの共通の概念の汎化関係（継承）として定義される」と思ってはいないでしょう。注文書の明細行の構造が見積依頼と注文で同じというのは事実ですが、せいぜいフォーム、特に明細部分を共通と思っているだけであって、見積依頼と注文の本質は根本的に別と思います。（例えばクラスで表現するならば、注文と明細は根本的に別のクラスで、例えばその要素としてOrderLineのListみたいなものを持っていて、これは共通化できるかもしれない、というようなことですが、そもそもクラス設計に踏み込むこと自体がナンセンス、というのが言いたいことです。）

この時点で具体的なシステム設計に踏み込まない - フレームワークに落とし込まない

データベース駆動設計、クラス駆動設計、いずれもある種のフレームワーク的な考え方をすることによって、ドメインエキスパートのメンタルモデルを捉え損なうということが重要な発見です。メンタルモデルを自分が正しく理解できていないのに、先にそうしたフレームワークを通して見ようとすると、どうしてもメンタルモデルが歪んでしまいます。
怖いのは、このようなメンタルモデルの歪みについて、開発者自身は気をつけないと自覚できないし、また ドメインエキスパートはシステム設計の話を必ずしも理解できないので、プログラムが出来上がるまでは認知のズレを指摘できない ということです。もっと怖いのは、とりあえず動く状態になったプログラムについては、プログラムが出来上がってからも、ドメインエキスパートが認知のズレをうまく指摘できない ということです。例えば新しい機能追加を行おうとしたときに、ドメインエキスパートの視点では簡単にできそうなことが開発上難しいというケースがあり、しばしばドメインエキスパートやいわゆる「ビジネスサイド」の人に開発者から説明をすることが課題になる場合があります。その要因がここで説明したような認知のズレの場合、それをドメインエキスパートの側ではうまく認知できず、一方で開発者の視点でも認知がどうズレているかを説明できません。そうすると、問題点を正しく把握したり修正することが難しいが、しかし機能追加がしにくいといった状態が発生します。メンタルモデルのずれがまさしく技術的負債を生じるということです。

こうした問題が起きないように、メンタルモデルがずれないようにすることが重要だとわかりました。

ケーススタディおわり・エクササイズ

ケーススタディはここまでです。ここで、理解を確認するためのエクササイズを用意しました。いずれの設問もイメージしながら回答することができれば、理解はOKだと思います。
（答はクリックで確認できます）

1. 「あなた」が「なるほど。つまり、お客様はWebサイトの商品ページを閲覧し、クリックしてショッピングカートに商品を追加し、チェックアウトするということですね。」とオリーに確認しなかったら、どうなっていた可能性があったか？

1. の答

その場で先入観による誤りに気付くことができず、誤った設計や実装をするなどして大失敗する可能性があった

2. この質問がもっと抽象的な内容で、たとえば「なるほど。つまり、お客様がこのフォームに記入している内容を、WebサイトでなんらかのUIによって送信できればよい、ということですね。」だったら、オリーはどう反応していたか？

2. の答

抽象的には間違っていないため、「そうですね」ぐらいの反応をしていた可能性があった

3. 継続的な開発の場合、理想的には、どれぐらいの率で「初手」＝自分が最初に考えることがドメインエキスパートと合うようになればよいか？

3. の答

80%〜90%

4. インタビューの中で必要となった、インタビューする側の開発者のアンラーンは、誰が主導して行うべきものか？

4. の答

開発者自身

5. データベース駆動設計の事例では、先入観に対してどのような悪い影響があったか？

5. の答

見積依頼と注文の間での、バリデーションなどの今の時点で明らかになっていないことについて勝手な制約を課すことになり、オリーの頭の中に存在しない勝手な先入観を持ってしまう

6. クラス駆動設計の事例では、先入観に対してどのような悪い影響があったか？

6. の答

用紙のフォーマットが同じだけで、概念的には本来異なる見積依頼と注文について、その共通部分を抽象化した概念を創造してしまい、オリーのメンタルモデルと乖離してしまう

7. このような先入観・メンタルモデルのズレを開発者が生んでしまった場合に、ドメインエキスパートはそれを明確に指摘できるか？

7. の答

できない

8. このような先入観・メンタルモデルのズレを一番早く修正できる可能性があるのは誰か？

8. の答

開発者自身

9. 開発者はどのような心構えでインタビューをするべきか？

9. の答

常にアンラーンが必要な可能性を意識しつつ、認知のズレに対するフィードバックを受けられるように具体的な質問をする

システム開発（DDD）でなぜアンラーンが必要なのか

ケーススタディでは、事前に変な先入観を持たないようにしたり、間違った先入観を修正していく、自分の認知が間違っている可能性をメタ的に意識する、といったアンラーンが暗黙のうちに自然と行われていました。
システム開発、もっと広く認知を合わせるためには、アンラーンが必要になります。以下、改めて、システム開発においてアンラーンが必要になるメカニズムの概要を述べます。これは、ケーススタディで見たことを別の視点で整理したもので、一部はケーススタディで述べていないような内容も含んでいます。
ケーススタディの冒頭でも考えたように、ドメインエキスパートと同じメンタルモデルを共有できていなければ期待されている内容と異なるシステムを開発してしまう可能性があるので、ドメインエキスパートと同じメンタルモデルを共有する ことを重要な目標として説明します。

• ドメインエキスパートと同じメンタルモデルを共有する、あるいは自分自身がドメインエキスパートになるには、そのメンタルモデルを自分の中に構築して、かつ生きた知識として扱えるようになる必要がある
  • 様々な刺激・ヒント・事象の解釈を経て、各自が自分の中に メンタルモデルを構築する
• 認識のズレがあると、そこから更にズレが広がったり、その先の知識が生きた知識にならなかったりする
  • 学校の教科の勉強が積み重ねであるのと同じように、どこかで躓くとその先すべてに影響する
  • 学校のテストで点を取れても応用が効くような理解ができていない（記号接地できていない）場合と同じように、メンタルモデルの構築においても記号接地できていない状態がある
• 自分の考えがドメインエキスパートと異なる場合に、ドメインエキスパートと同じメンタルモデルを構築しようとしたとき、「自分の考えと異なる結論だけを無理やり受け入れようとしているが、記号接地はできていない」という状態になり得る
  • この状態では、共有すべき知識が開発者の中で「生きた知識」にならず、知識を自動化して自由自在に使いこなすことができない
    • そのために開発が遅くなり、機能品質も低くなる
    • 一方で理解の度合に応じてできる作業もある
  • 自分自身では小さいと思っている考えの差が、思った以上に大きく作用する場合がある
• 全く先入観のない状態であれば、時間を十分にかけさえすれば、ドメインエキスパートと同じようにメンタルモデルを構築できる
  • 所要時間はいわゆる頭の回転によって変化するが、だいたいは致命的なものではない
    • ドメインエキスパートが"天才"ばかりでなければ、普通に身につく知識
  • ただし構築の途中で先入観が入る可能性があり、その場合は途中で道筋を外れてしまう
• ドメインエキスパートとずれた先入観がある場合には、それをアンラーンしない限り、いくら時間をかけてもドメインエキスパートと同じメンタルモデルを構築できず、ずれたメンタルモデルに至ってしまう
  • いくら頭の回転が早くても、アンラーンができなければ永遠に同じメンタルモデルに到達できない
  • 双方が自覚していないほどの微妙な差異であっても、容易に本質を捉え損ねる（ケーススタディ参照）
• 最終的なシステムとしての「正解」がドメインエキスパートの持つメンタルモデルであるとは限らないが、現状を理解するためにはメンタルモデルを共有する必要がある
  • まずは現状について記号接地したほうがよい（守破離の守）
    • ドメインエキスパートの認知・ドメインモデルを変えて行くのは「次」のステップ
    • 例えば新しい物事については、新しいドメインモデルを開発者も提案していく必要がある
• DDDのメンタルモデル構築において、アンラーンは必要不可欠である
  • メンタルモデルが揃うまでは、アンラーンできることが開発成果に直結する
• 一般論として、記号接地を促すには、メンタルモデルを整理して示すだけではなく、積極的にアンラーンさせることが必要
  • 既に様々な人生経験を持つ人を教育するときには、特にアンラーンを促すことが重要になる

tips:このメカニズムは他の物事にもあてはまりますか？

ここではDDD/システム開発を軸として整理していますが、実際にはそれに限らない多くのことについて、この構造が当てはまると思います。ただし、例えばオペレーション等の仕事では、ドメインエキスパートとピンポイントにしか接点を持たないということはなく、普段の仕事を通して何度も繰り返し関わっている事が多く、そのようなことで自然と認知が統一され、ずれて考えることが少なくなると思います。その意味で、システム開発は特に影響を受けやすい部分があると思います。また、システム開発でも、例えば個人開発など、他の人と認知を合わせる必要がなかったり、あるいは自分自身がドメインエキスパートとして深堀りすることにメリットのあるような構造の開発の場合には、こうしたメカニズムは影響が小さくなります。個人開発では成果が出て、他にドメインエキスパートが存在するような開発では成果が出ないタイプの開発者は、まさにこの部分に課題があるかもしれません。

メカニズムの重要なポイント

このメカニズムの中の重要なポイントは、

• 自分の考えがドメインエキスパートと大きく異なる場合に、ドメインエキスパートと同じメンタルモデルを構築しようとしたとき、「自分の考えと異なる結論だけを無理やり受け入れようとしているが、記号接地はできていない」という状態になり得る

および

• ドメインエキスパートとずれた先入観がある場合には、それをアンラーンしない限り、いくら時間をかけてもドメインエキスパートと同じメンタルモデルを構築できず、ずれたメンタルモデルに至ってしまう
  • いくら頭の回転が早くても、アンラーンができなければ永遠に同じメンタルモデルに到達できない
  • 双方が自覚していないほどの微妙な差異であっても、容易に本質を捉え損ねる（ケーススタディ参照）

というところです。この2つの事象は似ているのですが、少し違っています。前者は、自分がドメインエキスパートの考えとずれていることを認知していて結論部分を受け入れようとしているが、結局受け入れられていないケースです。後者は、自分がドメインエキスパートと同じことを考えている、あるいは同じことを考えようとしているが結論がずれていて、本人の自覚はあったりなかったりするケースです。以下、前者を記号接地ができないケース、後者を記号接地した知識が誤っているケースとします。順番が逆になりますが、記号設置した知識が誤っているケースから補足説明していきます。

記号接地した知識が誤っているケースについての補足

ケーススタディの中では、例えばデータベース駆動設計やクラス駆動設計をした場合が、記号接地した知識が誤っているケースに相当します。自分の中で設計を考えてみたが、ドメインエキスパートの考えていることとずれているというパターンです。この場合、自分が根本的にずれているということに気づけないと修正ができず、かつ最初はケーススタディ中で示したような微妙な差異から始まっています。
また、ケーススタディ中のその他の認知が誤っていた事例についても、それが記号接地まで至っていたか否かはともかくとして、とりあえず知識が誤っていたという事例になっています。
このケースの場合、単純に誤っているのでアンラーンが必要になります。

記号接地ができないケースについての補足

上述のとおり、ケーススタディにおいては記号接地ができないケースに相当する事例は直接は出ていませんが、例えば

あなた：「なるほど。つまり、お客様はWebサイトの商品ページを閲覧し、クリックしてショッピングカートに商品を追加し、チェックアウトするということですね。」

と述べたときに、オリーから「いえ、そうではありません。」とだけ言われて、その後何の掘り下げもなく理解ができないと、「とりあえずオリーから言われたことを正とするしかないが、どうも意味がわからない」みたいな状態になってしまい、どういう方向のシステムを作ればよいかわからず、途方にくれながら暗中模索を続けることになります。実際、ケーススタディでは引用省略したのですが、オリーに誤りを指摘された「あなた」は、オリーのビジネスがB2Bであることなどを少し掘り下げて聞いて、今回作りたいシステムが何なのか、ということの記号接地を行っています。具体的には、「あなた」は次のようにして記号接地しています。以下、『関数型ドメインモデリング』からの引用です。

あなた：「申し訳ありませんが、お客様のことを誤解していました。もう少し背景情報を教えてください。たとえば、誰がどのくらいの頻度でこのプロセスを使用しているかなどです。」
オリー：「私たちはB2Bの会社です。ですから、お客様は他の企業です。私たちには約1,000社のお客様がいて、彼らは通常、週に一度注文をしています。」
あなた：「すると一日あたりでは約200件ですね。ホリデーシーズンなど、それ以上に忙しくなることはありますか。」
オリー：「いいえ、一年を通してかなり安定しています。」
あなた：「それと、お客様は専門家だとお考えですか？」
オリー：「彼らは一日中、ものを買うことに費やしていますから、この分野の専門家と言えますね。欲しいものはわかっていて、それを手に入れるための効率的な方法を必要としているのです。」

「あなた」は仮説を立てながら質問をして、仮説が間違っていればすぐに棄却して正しい理解をする、ということを繰り返して、オリーのビジネスについての知識を生きた知識にする、つまり色々な活用ができる形で定着させるということを行っています。

このパターンの場合は、アンラーンが必要な場合も、そうでない場合もあります。特に既存の知識・メンタルモデルが邪魔をしている訳ではなくても、単純に記号接地できないという場合もありますし、既存の知識・メンタルモデルが邪魔になって記号接地できないという場合もあります。ただし、誤った知識が存在していなければ、時間をかけさえすれば記号接地はできるので、記号接地の過程で生じた知識も含めてどこかに誤った知識が存在している場合が特に問題になります。

具体的なアンラーンのやり方

さて、ではアンラーンを意識的に実施するには、どうすればよいでしょうか。
大前提として必要になるのは、人間はすぐに間違える、自分自身も当然すぐ間違える、ということを認知したうえで、「自分自身の認知」と「他の人の認知や事実」との違いをメタ的に認知して、違いのある部分を意図的に修正していく、という戦略（方略）を持つことだと思います。
アンラーンという概念を知っていた人も知らなかった人もいると思いますが、改めてアンラーンを具体的な行為として認識して、それを自分の"手札"に加えるということです。単純にアンラーンという戦略があるのだと理解するだけで、考え方が大きく変わると思います。結果として、例えば会話で得られる情報や結論の正しさも変わってくるでしょう。

その上で、具体的な方法としては以下のような事があると思います。（説明があまりこなれておらずすみません。以下、修正対象になる考え方の一部を信念と表現しています。私の場合は、本当に自分を捨てるぐらいの気持ちを持つようになってうまくいくようになった気がしているので、敢えて強めの言葉を使っています。）

• 自分が普段統計的・確率的にどれぐらい間違えるかを認知する
  • 正確な記録をつけて振り返りをする
    • あらゆる振る舞いの記録が難しい場合は、例えばある会議においては振る舞いをすべて記録するなどして、記録の時点での偏りが出ないようにする
• 自分が間違っている可能性のある箇所をメタ的に理解する
  • 間違っている可能性が小さくない箇所についての信念については、修正が必要になる可能性を意識する
• うまく会話が噛み合わない場合には、自分の信念が想像を超えたところで影響している可能性があるので、全く関係なさそうなことでもとりあえず自分の主観を挟まないようにする（完全に自分を捨てる）
  • 客観的に事実といえることはなにかを整理して考え、一旦はそれだけを正としてほかを忘れる
    • 事実に対して非論理的な飛躍がなにかあれば、それはすべて間違っている可能性のある対象・棄却対象としてマークする
  • 一般的に性格と言われるような部分についても、意図的なコントロールを試みる
  • 常に完全に自分を捨てるというよりは、何かしら指摘を受けてから考える、でもよい
• 自分や相手の意見を概念的に整理して、いくつかのメンタルモデルに分けて、それらの論理的なつながりで構造を捉える
  • このツリー的な構造を意識して、アンラーンする知識を選んで「切除」する、というような考え方をする
    • 庭木の剪定作業などと同じイメージ
• 暗黙のうちに前提としていることや、依存しているフレームワークがないか考える
  • 自分のどのような信念が理解を邪魔しているのか考える
• 単純に棄却することが難しい場合は、今置き換えようとしている新たな信念の正しい部分を理解する
  • 新たな信念についても、なんらかの適用限界があるといった現実的な制約を考える
• 細かい部分で相手の意見が受け入れられないような場合は、細かい部分の整合性を一旦無視する
• アンラーンすべき信念が自分に強く染み付いている場合、過去の経緯があるかもしれないが、まずは眼の前の相手を信じて信念を忘れる勇気を持つ
• 時間を十分に取れる場合には、自分の過去を深く振り返り、なぜその信念を持っているのかを振り返って、その理由を"解決"する
  • 例）単に自分の性格です -> なぜその性格になっているかを振り返ると具体的な事象に還元される場合がある、いつからその性格になったか？など
• 自分の意見と対立する意見を持つ立場でロールプレイする

動物が「歩く」という記号的な概念を持っていなくても四足歩行できるように、我々もアンラーンという記号的な概念を持っていなくてもアンラーンすることはできます。ただ、アンラーンという行為を切り出して記号化することにより、例えばそれを練習することができます。スポーツで走る練習をするときに走るための体の動きなどを分析して再構成して練習するのと同じように、アンラーンを技術として分析して再構成して練習して、より上手なアンラーンを身につけることができます。技術としてのアンラーンを身に付けていきましょう。

教育の意味、教育とはなにかの一つの答

システム開発の文脈で、ドメインエキスパートと同じメンタルモデルを持つ、認知を合わせることの重要性は、この記事に限らず広く言われていることです。ゼロの状態からそれを実現していくには、開発者がインタビューをして理解を深めていくということがありますが、既に開発が進んでいる状態においては、教育が重要になります。たとえば、新規参画した開発者の自主的な学習だけではなくて、新規参画者を教育して学習スピードを速く、また内容を正確にするということがあります。
ここまでに述べてきたことを踏まえると、教育というのは以下のように整理できます。

教育とは、（しばしば体系的な）知識を対象者が学習して確立することを目的として、対象者が持つメンタルモデルに対してどうやって生きた知識として接続していくのか、対象者のメンタルモデルにフォーカスしたうえで単純な教授に限らずアンラーンも含めて実現方法を検討・実践すること。

この「教育とはなにか」という考え方は、システム開発の文脈に限らず、広く言えることだと思います。この実現のうえで、例えば教科書を読むということは、体系的な知識の教授という意味で必要なことですが、対象者のメンタルモデルを踏まえて記号接地できるとは限りません。学校の教科の授業の場合には、特に事前の知識不足・積み重ねができていないことが原因で、記号接地ができずに落ちこぼれが発生することが多くあります。しかし、現実の落ちこぼれパターンはそれだけではなく、すでに自分が確立しているメンタルモデル等との不整合や微妙な認知のズレによって、記号接地できなかったり誤った記号接地をしたりします。話が噛み合わないという事象はこうしたことが原因で起こっていて、それを防ぐためにアンラーンも駆使して記号接地するための具体的な方法を検討・実践することこそが、教育なのです。

むすび

• アンラーンの重要性： システム開発・教育においてアンラーンがとても重要であること
• 具体的なアンラーンの方法、技術
• 教育とはなにか： 教育の重要な目的は記号接地であり、そのために積極的にアンラーンを促す必要もあること

ということについて、この記事の本文で示したような具体的な解像度での理解が深まったとすれば、この記事の目的は達成できたと思います。
最近の私の発見をほぼ全部入れたので、ボリューミーになってしまいました。自分の理解の整理も兼ねて書いたため、色々と過不足があると思っており、そのあたりが改善された記事が出てくるとすごく嬉しいです。 課題を感じられた方、ぜひ記事を書いてください。いろんな方に届くようになると思います。

以下、私の個人的な反省ですが。

これまで、システム開発に限らず様々なことで、教育しようとしてうまく記号接地ができなかった場合がしばしばありました。当時は記号接地という言葉は知りませんでしたが、実感としてうまく伝わっていないということはわかっていました。このとき、実は既存知識やメンタルモデルが邪魔をしていて、それをアンラーンすることも含めて方法を考える必要がある、というのを全くわかっていませんでした。特にアンラーンが必要な場合には、前提知識が何もない場合よりも理解に時間がかかったり、アンラーンができなければいつまでも完全な理解に至らず、その次のステップにおいてさらに躓くといた構造があり、そのような場合に助けることができる人の幅にかなり限りがありました。それを助けるために必要だったことが、ようやく理解でき、20年来の課題の謎が解けました。

メンタルモデルというのは、一般論としてはどこかが必ず間違っています。必ずと言ってしまってよいでしょう。現実の受け皿としては不完全で、どんなに丁寧なモデルを作ったとしても、何かは歪んでいます。
その上での話ですが、アンラーンが上手にでき、かつゼロの状態から理論を構築するのが得意な場合、「できるだけ正しいメンタルモデルを最初に構築するようにしたほうが、アンラーンの回数が少なく効率的でよい」と考えます。実際、メンタルモデルの間違っている部分を直そうとすると、たとえアンラーンが他者と比較して相対的に上手であったとしても、苦労はします。
ところが、もっとアンラーンが下手でかつゼロの状態から理論を構築できない場合は、そもそも仮説・メンタルモデルが何も存在しない場合に理論を構築することができないのです。また、構築しようとしている理論から距離があると、その場合でも構築ができず、無駄なように見えても一度中間メンタルモデルを構築しないといけないのです。
このメンタルモデルとメンタルモデルを遷移する間のギャップについては、人によって適切なギャップ量に差があります。したがって、それらが上手な人から見ると無駄に見える間違ったメンタルモデルの構築が、じつは苦手な人達からすると理解を深めるために必要な工程である、という場合もあるのです。このギャップ量を決めるのは、いわゆる頭の回転の速さとは全然別の要素で、例えばアンラーンの上手さが作用します。私はずっとその正体がわからなくて、回転の速さと混同したりすることもありましたが、今になってようやく、「間違ったことでも教える意味がある」ということの本当の意味がわかった気がしました。解像度の粗さの意味で間違ったことを教えることに価値があるのは昔からわかっていましたが、そうではなくて、本質的に間違ったメンタルモデルを作ることについて、私からは無駄に見えるし実際に私自身がやるなら無駄であったとしても、その人にとって意味がある、という具体的なメカニズムがようやくわかりました。敢えて深く言及しませんが、たとえば「掛け算の順序」などもそうです。対象とする人によって、間違ったメンタルモデルを教える意味がある場面もあります。

アンラーンは難しいですが、おそらく後天的スキルとしての側面が大きいと思っています。私の中では、ある程度技術として整理されているので、言語化できて練習することが可能な能力であると思っています。今後、アンラーンに関する研究が進むことを願っています。