メンタルモデルとソフトウェア開発
はじめに
メンタルモデルという言葉、ソフトウェア界隈でも最近よく耳にしますね。なんとなく雰囲気で使われていることも多い気がするので、一度整理をして、メンタルモデルのメンタルモデルを構築しよう（メタですね）というのがこの記事の主旨です。
メンタルモデルとは
認知心理学におけるメンタルモデル
メンタルモデルはもともと認知心理学の分野で使われてきた用語です。Wikipediaによると初めて用いられたのは1943年に遡ります。また、1983年には"Mental Models"というタイトルの本が2冊出版されたそうです。
メンタルモデルとは、現実世界の物事がどのように機能するかについて、個人が解釈して頭の中に構築したモデルであり、思考や推論を行う際の前提や枠組みとなるものです。
デザイン分野におけるメンタルモデル
メンタルモデルという言葉は、人間中心設計（HCD）などデザインの領域でもよく使用されます。
メンタルモデルは、その名からも分かるように人の頭の中にあって、モノがどう動作するかについてのその人の理解を表す概念モデルである。
ここで概念モデルは、デザインの対象となるモノがどう機能するかを説明するためのモデルです。デザイナーが持つ概念モデルそのものをユーザーに伝えることはできません。ユーザーはマニュアルを読んだり、デザインされたモノの構造を見たり、実際に触ってみたりすることで、頭の中にユーザー自身の概念モデルを構築します。それがメンタルモデルです。
概念モデルは、理解を助けたり、モノの動きを予測したり、モノが予定通りに動かないときにどうすればよいかを知るのに役に立つ。良い概念モデルがあると、自分の行為の結果を予測できるようになる。
デザイナーはユーザーに対して良い概念モデルを提供し、ユーザーが頭の中に正しいメンタルモデルを構築できるようなデザインをするのです。
ソフトウェアにおけるメンタルモデルの重要性
概念モデルとドメインモデル
ソフトウェア開発の文脈でも、メンタルモデルという言葉が使われるようになってきました。概念モデルという言葉はずいぶん前から使われているようです。
デザイン領域における言葉の使われ方とは若干ニュアンスの異なる部分もあるでしょうが、本質は同じです。何かしらの問題を解決することを目的にソフトウェアを開発するにあたって、現実世界の物事や仕組みを理解することが欠かせません。しかし、それらをそっくりそのままコンピューター上に再現することは不可能な上、その必要性もないため、抽象や捨象を行ってモデルを構築します。それが概念モデルです。
次に、ドメインモデルは概念モデルと同じでしょうか？ 文脈によってはほぼ同義で使われることも多いですが、ドメインモデルは、対象領域（ドメイン）の問題をソフトウェアで解決するために、解決空間上に表現されるモデルです。
概念モデルでは、たとえUMLを使って図式化しても、そこまで厳密性を求めません。たとえば、多重継承的な汎化の線を引くこともしばしばありますが、汎化関係というよりはカテゴライズの意味合いが強いです。クラス図は描かずに、概念や概念間の関係性を用語辞書という形で整理する場合もあります。その他、抽象度の高いハイレベルな業務フローなども一種の概念モデルと言えます。要は概念モデルとは、事業活動のあり様を捉えたものと言えるでしょう。
概念モデル→ドメインモデル
先に述べたように、ドメインモデルは、概念モデルの解決空間上における表現です。よって、実現手段として採用する技術の制約を考慮に入れて、モデリングする必要があります。たとえばオブジェクト指向設計を行う場合、多くの言語は多重継承をサポートしないので、単一継承でモデリングします。
ドメインモデルを洗練させていくには、ドメインエキスパートが持っている業務知識や経験が欠かせません。開発者は対話を通じてドメインエキスパートから情報を引き出します。
一般的には、UMLという解決空間用の記法を正確に理解することをドメインエキスパートに強いることは負担となるので、具体的な実例を用いて業務ルールの確認を進めることになります。認識の齟齬をなくすためには、ドメインエキスパートと開発者（その他、QAエンジニアなど開発に関係する人すべて）で共通の語彙を用いることが重要です（ユビキタス言語）。
ドメインモデル→ソースコード
開発者は、ドメインモデルや文書で表された仕様をインプットとし、実装を行います。すなわちソースコードへの変換を行います。その際、どのような構成要素に分割し、それらにどう責務を割り当てるか、ユーザー要求という振る舞いを実現するためにそれらをどう相互作用させるか、を考えるのが設計です。
ドメイン層のロジックをどう設計するかについては、マーチン・ファウラー氏が著書『エンタープライズアプリケーションアーキテクチャパターン 頑強なシステムを実現するためのレイヤ化アプローチ』の中で頻出するパターンを分類しました（トランザクションスクリプト、ドメインモデル、テーブルモジュール、サービスレイヤ）。
同書でドメインモデルは”振る舞いとデータの両方を一体化させたドメインのオブジェクトモデル”とあります。これは、オブジェクト指向分析で作成したモデルに対応する形で、ソースコードを構成しようというものです。（現在では、関数型でドメインモデルを実装することも、決して少なくはありませんが）。
メンタルモデル
なぜ分析結果としてのドメインモデルと、ソースコード表現としてのそれを一致させたいかというと、そうすることで見通しがよくなるからです。
実際にはこれらは完全一致はしません。ソースコードという詳細レベルの成果物になると、プログラミング言語やフレームワークが持つ技術的な特性や制約の影響を受けるので、その中で最適化されるべきだからです（それが詳細設計という行為であり、デザインパターンやイディオムはそのための道具です）。
それでも、基本構造として開発者が頭の中に構築するモデル（メンタルモデル）が合致していれば、大きなメリットがあります。
ソフトウェアに変更はつきものですが、その際の変更仕様と、直すべきソースコードの対応付けがしやすいのです。あるべきロジックが、あるべき場所に記述されていれば、素早く安全に改修を行うことができます（もちろん信頼できるテストコードの存在が前提ですが）。この乖離が大きいと、「どう修正すればよいか検討がつかない」「見積もりができない」「まずは影響範囲調査が必要」という事態が生じることになります。
ソースコードのユーザーは誰？
ソフトウェアの品質は、使い勝手や性能のようにユーザーが認識できる外部品質と、保守容易性や拡張性のようにユーザーには見えない内部品質とに分けられます。
内部品質の多くは、ソースコードで測定や評価を行うことができます。そしてそのソースコードの読み書きを行うのは開発者ですから、内部品質のユーザーは開発者だと考えることができます。
「デザイナーはユーザーが頭の中に正しいメンタルモデルを構築できるようなデザインをする」と述べましたが、開発者も同じようにデザイン（設計）を行うべきです。つまり、将来の自分自身や他の開発者をユーザーとして認識し、認知の観点から「使いやすい」ソースコードを書くことが大切です。
まとめ
この記事では、メンタルモデルという言葉について、その出所である認知心理学における意味合いと、デザイン分野での使われ方をまず確認しました。
我らがソフトウェア業界においては「モデル」と名のつくものが多々ありますが、概念モデル、ドメインモデル、メンタルモデルを取り上げてその関係性を考察しました。
ソフトウェア開発という営みをするのは人間である以上（AGIに取って代わられるのはまだ先でしょう）、人間の認知の仕組みを理解した上で、設計や開発プラクティスをより良いものにしていくことが重要だと最近感じています。
長くなってしまったので、具体的な手法についてはまた別の機会に記事化するか、勉強会などで発表していきたいと思います（興味がある方はぜひお声がけください）。
設計の原則やパターンについては、拙書もご参考にして頂けると幸いです。
いいなと思ったら応援しよう！
