"The Essence of Software"が提唱する全く新しいソフトウェア設計の考え方
（6/22 注：書き足りないと思っていた箇所を補って加筆修正しました）
エンジニアのbonotakeです。Ideinに入ってかれこれ3年以上経ちますが、Ideinでブログ記事を書くのは初めてです。
今日は、ソフトウェア設計の全く新しい考え方について書かれた "The Essence of Software" という本の紹介をしたいと思います。
この本の著者はMIT教授でソフトウェア工学の世界的な研究者であるDaniel Jacksonです。形式手法Alloyの発明者、と言ったほうが通じる人には通じるかもしれません。形式手法とは、ありていにいえば、数理論理学を駆使してソフトウェアに潜むバグを論理的に駆逐する手法です。
（個人的な宣伝ですが、彼の書いたAlloyの本を以前翻訳して出版しました。）
そんな彼が昨年11月に新著を出版したというので、ほぼその日に買いました。……ですが、本を開いてみると、初っ端からとんでもないことが書いてありました。
My main research contribution in the 30 years since my PhD has been Alloy, a language for describing software design and analyzing them automatically. (snip) but I came to realize over time that the essence of software doesn't lie in any logic or analysis.
（私が博士号を取ってから30年の主要な業績は、Alloyという、ソフトウェアの設計を記述して自動的に解析のできる言語だった。（略）しかし時が経つにつれて、ソフトウェアの本質は論理や解析には存在しないことを悟っていった。
彼が今までやってきた自身の研究を全否定するかのような文章を読んで、頭をハンマーで殴られたかのような衝撃があったのを覚えています。
何とか気を取り戻して、その後1/4程度まで読み進めたのですが、その時点では正直彼が何を言いたいのか理解できませんでした。読むのが苦痛ですらありました。
ところがその後、唐突に、彼が何を言いたいのか理解できたのです。そこからは読むのがメチャメチャ楽しく、ワクワクしながらページをめくっていました。
彼が書いていたのは、今までにない着眼での全く新しいソフトウェア設計の考え方でした。ただあまりに新しく斬新であるがゆえに、僕はこの本の真意を掴み取ることがなかなかできなかったのです。
以下、この本が提唱する concept design の趣旨を、僕が理解した限りで書いておきます。
ソフトウェア設計というのは従来、誤解を恐れずに言えば全て、最終的に「どうプログラムを書くか」に集約されるものでした。建築の世界に例えるなら、最終的にどう建材を組み立てればよいか、という観点から設計するものでした。
その観点で言えば、この本の内容との比較対象になりうるものとしてオブジェクト指向設計（Object Oriented Design, OOD）と呼ばれるものがあります。オブジェクト指向というのは90年代から2000年代前半くらいまでに流行した考え方で、ソフトウェアをオブジェクトという仮想的な物体の集合体と捉えて、それらの関係性や相互のやり取りとしてソフトウェアを設計する手法です。
（OODのための記法で最も有名なのがUMLです。クラス図とか書いていくやつです。今でも使っている開発現場はあるかもしれません。自分の周囲ではもう全くといいほどお目にかからなくなりましたが……）
ただ、これはあくまで開発者、プログラマの観点からであって、それらのオブジェクトがユーザーに露出することは特に意図されていませんでした。
一方、ユーザーインタフェースやユーザー体験、いわゆるUI/UXといったユーザーに露出する部分のデザインは別途行われていて、いわゆるソフトウェア設計とは分離しているものでした。
Daniel Jackson が提唱したのはそうではなく、プログラムその他の実現方式から一旦離れて、ユーザーがそのソフトウェアに触れて得られるメンタルモデルをまず設計せよ、ということなんだと思います。
ソフトウェアは物理的な実体がないがゆえに、キーボードやマウスやモニタを通じて仮想的な実体（たとえば、Windows や macOS にある「ファイル」や「フォルダ」など）を操作するわけですが、そういった仮想的な実体、つまり概念（concept）を組み上げて作られるメンタルモデルをまず設計し、ソフトウェアの中心に据えよう、と言っています。
建築の例えで言えば、まず居住者にとってどういうものがあれば、どういう気配りがなされていれば居心地の良さや優れた体験を得られるか、をまずデザインしよう、ということです。
ここでいう概念の一番わかりやすい例が、本書にも挙げられているOSの「ゴミ箱」です。
あのゴミ箱、経験のあるエンジニアなら言われなくても薄々感づいていると思いますが、ファイルを捨てるためのものではありません。むしろ、うっかり捨てたファイルを簡単に復元するための機構です。
しかし、では「ファイルを復元できるようにしたい」と思った開発者がそこから「ゴミ箱」なる概念を思いつけるでしょうか？
「ゴミ箱」がUI/UXの面で優れているのはおわかりでしょう。もし大抵のエンジニアが「ファイルを復元できる」機能を設計しようとすると、せいぜい「ファイルの復元」なるメニューが、画面の端にあるメニューバーから辿れる多数のサブメニューの1つとしてぽつんと置かれるだけではないでしょうか。
これだと、あらゆる機能がひたすらネストしたメニューの奥底に眠ってしまうことになり、機能はきちんと実装されているのにユーザーにとってはわかりづらく見つけづらい、とにかく使い勝手の悪いソフトウェアになってしまいます。
更に言えば、これは実現方式としても優れています。OSレベルで削除したファイルを復元するのはなかなか大変ですし、場合によっては復元に失敗するでしょう。しかし「ゴミ箱」は削除予定のファイルを移動するための特別なフォルダというだけなので、復元もまたファイルの移動で簡単に実現できます。
この例だと割と典型的なUIデザインの問題と捉えることもできますが、そういった枠では説明しきれない例として、Dropboxの共有フォルダの事例が本書には紹介されています。ユーザーAとBがあるフォルダを共有している状態でBがそのフォルダを削除したとき、状況によって、Aの手元のフォルダも一緒に消えることもあれば、Aの手元には残ったままになる場合もあります。
どうしてこうなるかは本書を読んでもらうとして、これはバグではなく仕様です。しかし、Dropbox開発者の意図が一部のユーザーの抱くメンタルモデルとズレているため、とても奇怪な挙動を起こしているように見え、ユーザーを困惑させてしまうのです。
ここで扱うべき概念は「フォルダ」と「同期」です。特に想定すべき同期の性質がユーザーと開発者で異なっていて、それがメンタルモデルの齟齬を生み出しています。この問題はUIだけの問題でも、また実装だけの問題でもありません。
そういった、概念の積み重ねから得られるメンタルモデルを中心に据え、ユーザーインタフェースはそれを簡潔に表現したものであるべきだし（本書ではそれを concept mapping と呼んでいます）、裏側のプログラムはそれを実現する目的で記述されるべき、ということです。それによって、開発者
（プログラマ）、UI/UXデザイナー、そしてユーザーの3者がメンタルモデルを共有することが重要だ、としています。ソフトウェアを提供する側が意図するメンタルモデルとユーザが抱くメンタルモデルに齟齬がある場合、バグではないがユーザにとってはとても使いづらいソフトウェアになってしまいます。
以上が、僕が彼の本から読み取った、恐らく彼が主張したいことです。
ただ、全く新しい考え方の提唱であることもありますし、この本がその意図や意義を万人に認めさせる内容になっているかどうかはわかりません。また本書で提唱されている concept design やその進め方などは、本の中で彼自身が認めているように、まだまだ荒削りの部分があります。
たとえば本文中に登場する、メンタルモデルを記述するための概念の記法は、明らかにAlloyその他の形式的仕様記述言語の影響を受けていて、いわゆる事前条件や事後条件、不変条件を書くような体裁になっています。しかし、そういった条件は論理的な整合性を確かめるためのもので、メンタルモデルを記述する記法として常に必要なのか、疑問の余地があります。（ただし、Dropboxの例では恐らく必要になるかもしれません。Dropboxの問題は、過去にAlloyが解決しようとしてきた問題と極めて似ています。）
また、最近のUI/UXデザイン手法との関係も未整理か、少なくとも本書では多くは語られていません。
ただ、バックボーンとなる考え方は非常に共感できるものです。
実際、僕が上に書いた内容だいたいそのままを自分のFacebookに投稿したところ、かなり反響がありました。
ちなみに、このときFacebook上でもらったコメントで、かなり興味深いものがありました。
ゲーム業界での経験がある複数のエンジニアから「ゲームではそういったメンタルモデルでユーザが躓くことはあまりない」というコメントがあったのです。
理由の考察も様々挙がっていましたが、自分が考えたのは、おそらくゲームデザイナーはこの本でいう concept design に相当することを常にやっているのではないか、ということです。
ゲームにおいては、ユーザーに提供する機能の全てはゲームの世界観を壊さないようにゲーム内のオブジェクトに置き換えられていたり（セーブポイントがクリスタルになっていたりタイプライターになっていたり、など）、あるいはプレイヤーにストレスを感じさせないよう注意深くデザインされたUIを備えていたりします。これがまさに concept design なのでは、と。
つまりゲームデザインの中に、この本の観点でいう優れたソフトウェア設計のヒントが隠されているのかもしれません。
……といった風に、この本が提唱する方法論には追求すべき価値がたくさん詰まっているように思います。現在の内容はあまりに荒削りなこともあってか、日本でも現状ほとんど話題になっていないと思いますが、今後理解者・支持者が増え、彼の考え方が広まっていけば、数年先にバイブルになっている可能性はあります。
それくらいポテンシャルを秘めた本であるように僕には思えるのですが、さて、いかがでしょうか。