MVCとはなにか

2019年12月9日 03:09

この記事は、2019年12月1日に開催されたPHPカンファレンスでの「MVCとはなにか」という題の登壇内容の書き起こしです。スライドはこちらです。

1. はじめに

MVCの悪かった点は、わたしたちがどう実装したかという点だ。それはあまりに機械的だった。
https://news.ycombinator.com/item?id=8841428

ある人がアラン・ケイに対して「MVCについてどう思うか」という質問をして、それに対するメールでの回答がHacker Newsというサイトにのっていました。前提をお話すると、MVCというアイデアは、だいたい40年以上まえにパロアルト研究所というところで、アラン・ケイがパーソナルコンピュータの開発をしていたときに、客員研究員としてトリグヴェ・リーンスカウクさんという人が訪れて、そのとき他の研究所のメンバーとも話あって作ったアイデアがMVCになります。

MVCは人間とそのメンタルモデルに関するものであり、オブザーバパターンに関するものではない。
https://digitalsoul.hatenadiary.org/entry/20100131/1264925022

アラン・ケイがMVCについて評価しているようなことと、だいたい似たようなことをトリグヴェ・リーンスカウクさんも言っています。こちらは「DCIアーキテクチャ」という、MVCのちょうど30年あとに書かれたテキストからの引用です。ここでメンタルモデルという言葉がでてきているのですが、これは今日の主題の一つです。

Smalltalk-80 のModel-View-Controllerの説明図

もうひとつオブザーバーパターンと言う言葉がでてきているのですが、こちらの図は1988年に書かれたMVCについての解説テキストです。このときアラン・ケイもトリグヴェさんもSmalltalkに関わっていなくて別な人が書いたテキストです。このテキストのなかではモデルは次のように定義されています。一つは、モデルは依存を抱えることができるということ、もう一つは自身の変更をその依存に対してブロードキャストすることができるということ。この２点がモデルの要件であるとこのテキストには書かれています。この２つの特徴は典型的にオブザーバーパターンですが、もちろんオブザーバーパターンが先にあったというわけではなくて、MVCの実装のなかからオブザーバーパターンというデザインパターンが取り出されています。鋭い方はお気づきかと思うのですが、入出力とデータ構造を分離するというアーキテクチャになっていて、いまでいうクリーンアーキテクチャや、単方向データフローという意味ではFluxとも同じになっています。Flux が古典的MVCの再発明だと言われるのはこの実装との類似性が指摘されているものと思います。こういった実装パターンとしてのMVCというのが、さきほどのアラン・ケイのコメントだったりトリグヴェ・リーンスカウクさんのコメントからすると、発案者たちからは機械的にすぎると評価されていることが伺えると思います。

ユーザーは皇帝だ。LRGで行われたすべてのことは彼をサポートすることだった。
http://folk.uio.no/trygver/themes/mvc/mvc-index.html

トリグヴェ・リーンスカウクさんがMVCについてまとめているページがあります。MVCの背景には、パロアルト研究所でのパーソナルコンピュータの開発があった。LRGとは Learning Research Group という、アラン・ケイがパロアルト研究所で率いていた研究グループのことです。パーソナルコンピュータの開発では、ユーザーを皇帝として扱っており、その背景においてMVCを理解してほしい、とトリグヴェさんはそのページで書いています。

2. ドメインモデル

エリック・エヴァンスのドメイン駆動設計の書影

この本はご存知のかたも多いと思いますが、エリック・エヴァンスさんという方がドメイン駆動設計という本を書きました。余談ですが、表紙絵はカンディンスキーという画家の絵で、本の中で抽象というアイデアがかなりフィーチャーされているので、世界で最初に抽象絵画を描いたと言われるカンディンスキーが表紙絵に選ばれていると思います。

複写式伝票。2枚あり、重ねて使うことで情報が複写される。

https://www.e-denpyou.com/blog.asp?entry=416

ドメインモデルを考えるにあたって、最初にこのお話をしたいと思います。この写真は複写式伝票というもので、飲食店で使われるものです。友達と中華料理店でご飯を食べていたときに注文の処理フローが面白くて、その話をしようと思っています。複写式伝票というのは、この写真のなかでは２つに分かれているのですが、本来重ねて使うもので、左側のものもちぎれていない状態で使います。複写式という名前の通りで、上の紙に書いたら下にもカーボンでコピーされます。
どういった注文処理フローになっているかというと、最初にホールの人がお客さんから注文を取って伝票に記載していく。注文を取り終わったら伝票を持ち帰って、片方のミシン目で切れるほうを厨房に渡す。もう一方はホール側においておく。厨房のほうでは、ミシン目に沿ってちぎってオーダークリップに留め、これが調理の順になる。厨房とホールの間にあるカウンターはデシャップ(Dish up)というのですが、ここに順次調理をおいていって、厨房のほうでは調理をだしたらオーダークリップからチケットを外して破棄する。ホール側ではその料理を客席に出し、伝票を赤ペンで消し込む。伝票がすべて消し込まれたら、つまり料理を全部出し終わったらその伝票を客席に戻す。そういう処理フローになっている。お客さんのほうでも、注文を食べ終わったらこの伝票をもとにして支払いをする。

モデルとは、選び抜かれてシンプルにされ、意図的に組み立てられた知識の表現形式である。
-- エリック・エヴァンス、「ドメイン駆動設計」

この注文伝票をぼくが面白いとおもったのは、厨房の人とホールの人で情報構造が違っている点です。厨房の人にとってはこの料理をどの席にだすかは関心がない。どの料理をどの順番で出さないといけないかということに関心がある。ホールの人にとっては、席番号と料理の紐付けは非常に重要で、そういった情報構造がこの複写式伝票のなかに表現されていると思います。ここで引用しているのはエリック・エヴァンスさんのモデルについての説明なのですが、まさにここに書かれているとおりで、複写式伝票は「意図的に組み立てられた知識の表現形式」としてのモデルになっている。

自動券売機の画像

いっぽうで、こちらの場合はどうでしょうか。見ての通り自動券売機なのですが、業務フローは大きく違います。一番大きいのは、注文が完了した時点と支払いが完了した時点とが同時であること。お客さんのほうでも「お会計お願いします」とはいわないし、ホールのひとも「注文をとる」「会計をする」というタスクがない。
さきほどの複写式伝票でいうと、ミシン目でちぎるほうだけの情報構造になっている。ついでにいうと、大きく違っているのはキャンセル時の処理。注文伝票の場合だと伝票を破棄すればキャンセルとして取り扱えるが、券売機の場合だと別な情報システムが必要になる。支払いが完了しているので消込のための情報伝達が必要になるとおもいます。

杉本啓さんの資料。「ドメインとドメインモデル」という見出しで、SubversionとGitを比較し、「コミット」という言葉の意味が変わっていることに注目している。

杉本さんの資料。「ドメインに浸潤するドメインモデル」という見出し。「ドメインモデルは情報処理のモデル」とある。例えば、会計の場合複式簿記がドメインモデルである。

こちらの資料は2015年のPHPカンファレンスでの杉本啓さんの発表の資料です。これまで注文に関する２つの仕組みを比較してきたのですが、この資料でもおなじように一つのドメインに対する２つのツールの比較をしています。ここでは「ソースコード管理」というドメインに対するSubversionとGitという２つのツールが比較されていて、「コミット」という言葉がそれぞれのツールによって言葉の意味が変わっている。
杉本さんの資料は非常に刺激的でおもしろいのですが、ドメインとドメインモデルを区別していて、「ドメインモデルとは情報処理のモデルである」と述べられています。二枚目の資料にはドメインとして会計や貿易が並べられていて、それぞれに対応する情報処理の仕組みがある。これら情報処理の仕組みのことを、杉本さんはドメインモデルとして考えている。この資料のなかで杉本さんは、設計対象には物理的か情報的かの２種類あると指摘し、ドメインモデルは情報的な対象である、と考えます。
杉本さんはドメインというものを物理的な対象と考えるのですが、ぼくは目的と言い換えてもよさそうに思っています。先程の注文の例で言うと、ユーザーの側からみると「自分が食べたいものを食べる、そのためにお金を出す」という目的があります。サービスを提供する側からすると、料理を出すことによってその売上との差分が利益になる。この両者の目的が合致するところにビジネスが成り立っているといえると考えられます。
いっぽうのドメインモデルは手段と言えるもので、先程の注文伝票や券売機の例であれば、リプレイスが可能である。こちらは杉本さんの考えでは情報システムである。
こういった情報処理システムにどういったものがあるか考えてみると、国家などが例に挙げられるのではないかと思います。国家はいったいなにをやっているかというと、紛争解決をドメインとした情報処理のシステムで、民主主義という意思決定システムも紛争解決をどうやって効率化するかという情報処理のシステムであると言えると思います。

いっぽうで、ここで作られたモデルというのは一体誰にとってのモデルなのかということを考える必要があると思います。こういった情報処理の仕組みを入れたいと思っている人は経営者や管理者などが多いとおもいます。その結果として作業に携わる人は管理者のモデルを内面化することになると思います。

従来のシステムの設計では、強力な抽象化セットを選択すること、これらの抽象に適した表現を決定すること、すべてのユーザーがそれらに実質的に同じ意味を付けることを保証することに多大な作業が費やされます。システムがインストールされるやいなや、マン-マシンシステム全体に大きな慣性が発生し、それらが良いか悪いかに関わらず古い意思決定を固める傾向があります。
-- トリグヴェ・リーンスカウ, A note on DynaBook requirements

これはトリグヴェ・リーンスカウクさんがパロアルト研究所を訪れているときのテキストで、従来のシステム設計について書いてある箇所です。従来のシステム設計は「抽象化セットを選択すること」「抽象に適した表現を決定すること」「すべてのユーザーがそれらに実質的に同じ意味付けをすることを保証すること」、これらに大きなコストが費やされる。ほとんどDDDでいうユビキタス言語です。その結果としてシステムがインストールされると、人間とシステムとの関係に大きな慣性が発生する。この慣性という言い回しは面白いとおもうのですが、意思決定がなかなか起こりづらくなる。少し考えてみると、システムのリプレイスにどれだけのコストがかかるかを思い起こせば、ここで言っていることは妥当なことだと思います。

こういったことから言えるのは、「ドメインモデルとは社会的なシステムではないか」ということです。情報処理システムは業務の形を作り出し、個人を制約していく。ドメインモデルにはそういった社会的な性質があるのではないかと思います。

3. メンタルモデル

ドナルド・ノーマン「Design of Everyday Things」の書影

最初に、MVCは人間のメンタルモデルに関わるものであるというトリグヴェさんの言葉を紹介しましたが、この「メンタルモデル」という概念がどこからでてきたかというと、これは心理学の用語です。この画像は有名な本でドナルド・ノーマンという人の本です。ドナルド・ノーマンは心理学者ですが、この本のなかでいろいろデザインの分析をしていて、そこでメンタルモデルという言葉を多用しています。この本がよく読まれたのでメンタルモデルという言葉が広く使われるようになりました。この本は日本語でも「誰のためのデザイン？」というタイトルで出ています。

スーパーカブのウインカー。右にウインカーを出すためにはボタンを上に押す必要がある。

https://blogs.yahoo.co.jp/niconicocub/10300438.html

こちらの画像は、スーパーカブのウィンカーです。ぼくは昔、新聞配達をしていたのですが、カブのウインカーはよく間違えました。右ウインカーを出そうとするとボタンを上に押す必要があり、左ウインカーを出そうとするとボタンを下に押す必要がある。頭のなかに右左の観念があるのに、機械のほうがそれに対応しておらず、上下の関係にマッピングされている。ドナルド・ノーマンの言葉でいえば「対応づけ」がうまくいっていない例です。カブの名誉のためにいうと、このデザインになっているのは、昔そばやが片手運転で出前に行けるのがデザインのコンセプトになっていたようで、コントローラー類が右手によっていたり、親指だけで操作できるようになっていたりします。

メンタルモデルとはなにかというと、Wikipediaには「メンタルモデルとは、頭の中にある「ああなったらこうなる」といった「行動のイメージ」を表現したものである」とあります。人間はなにかしら行為をして生きているが、なにか行為をすると世界の側からなにかしらのフィードバックがある。その行為とフィードバックの関係というのが、因果関係などの形で人間の頭のなかに形成される。行為に対する結果があるということは対象の側になにかの構造性があると考える。この対象の構造性というのは頭のなかにあるが、これを基礎にして人間は行動している。そういったものがメンタルモデルといわれるものです。

ハサミを握っている画像

https://www.photo-ac.com/main/detail/2263511

こちらは見ての通りハサミですが、操作を間違える方はそんなにいないと思います。どこに指を入れればいいか、どう握れば対象物としての紙が切れるかという関係がわかりやすく、そんなに操作を間違わない。ハサミの機能する部分は目に見えているし、その意味するところは明らかであるから、ハサミがどのようなものかわかる。メンタルモデルを構築しやすい道具はこういった特徴をもつと、ドナルド・ノーマンは説明しています。

* 可視性
* よい概念モデル
* よい対応付け
* フィードバック

道具からメンタルモデルを構築するにはどうすればよいかということに対して、ノーマンはこういった原則をあげています。上３つはいままでの話でなんとなくわかるかと思います。フィードバックというのは、例えば自分がなにか行為をして、そのレスポンスが一年後に返ってくるようなことがあると、だいたい誰も何も覚えていないので、対象のメンタルモデルを構築できない。フィードバックはすぐに返ってくることが重要だといいます。

プログラマーたちは、自分たちの書いたプログラムがユーザーに暴威をふるっているということを知って驚愕している。
-- ドナルド・ノーマン

いっぽうで、僕たちの作っているソフトウェアはどうでしょうか。ドナルド・ノーマンは「誰のためのデザイン？」のなかでソフトウェアについて書いている箇所でこのように述べています。ぼくたちプログラマーにとってはグサッと来る言葉です。
これはプログラマーだけが悪いかというと難しいところがあります。アラン・ケイがソフトウェアについて書いてあるテキストがあり、そこで粘土とコンピュータを比較しています。粘土は手を突っ込んだだけでどのようにも変形できる、つまり直接的なメディアである。コンピュータは対照的に非常に間接的なメディアである。中でなにをやっているかわからないし、構造が自明ではない。そういう特徴から、人はコンピュータの操作に対してメンタルモデルを構築するのが非常に難しい。こういう特徴はソフトウェアのデザインにおいて基本的な特徴になっている。

そこでアラン・ケイが非常に重要視している考えが「ユーザーイリュージョン」です。ユーザーイリュージョンというのは、パロアルト研究所で非常に重視されていたのですが、「目の前にある知覚できるものがその人にとってのコンピュータである」。これが「ユーザーイリュージョン」であるとパロアルト研究所で呼ばれていました。

スプレッドシートはよく使われていますが、アラン・ケイもドナルド・ノーマンも「ユーザーイリュージョン」が働いている例として絶賛しています。「セル」という概念モデルがあり、そこになにかしら入力する。セルとセルの関係もわかりやすく、例えば、A1とB1の合計がC1に表示されているとして、A1の値を変えたらC1の値も変わる、というフィードバックがはっきりしているので、メンタルモデルが構築しやすい。そこにあるのが「ユーザーイリュージョン」だとアラン・ケイは考えます。

もっともよいコンピュータプログラムとは、コンピュータそのものは「消え去って」いるようなプログラムである。そこでは、人は作業そのものに取り組んでいるのであって、コンピュータを使っているという意識はなくなっている。
--ドナルド・ノーマン

ドナルド・ノーマンは先程の本のなかでスプレッドシートに触れながら、よいソフトウェアについてこのように書いています。よいソフトウェアとは「人が作業そのものに取り組んでいる」ような意識になるものである。これは「ユーザーイリュージョン」が成立している状態です。アラン・ケイは、ユーザーインターフェースについて書いているテキストの冒頭で、「エンドユーザーがどのように頭を使っているかをよく理解することが、インタラクションのパラダイムを完全に変える」といいます。メンタルモデルを理解することが重要なのだと。

4. パーソナルコンピュータ

アラン・ケイの「あらゆる年齢の子どもたちのためのパーソナルコンピュータ」に掲載されいているケイのイラスト。二人の子供がダイナブックでゲームをしている。

この絵は、アラン・ケイがパロアルト研究所でパーソナルコンピュータを開発しているときに書いた「あらゆる年齢の「子どもたち」のためのパーソナルコンピュータ」という論文のなかの絵です。ジミーとベスという二人が、アラン・ケイの考えていたダイナブックというパーソナルコンピュータを使って宇宙船ゲームをやっているところです。ジミーはこのゲームが弱くて、負け惜しみのように「本物の宇宙だったらこんなふうになっていないんだ」といいます。そこで二人は興味を持って宇宙について自分たちで調べはじめ、そうして理解したことをもとにダイナブックのゲームのプログラムを書き換える。そんなストーリーをアラン・ケイは書いています。

コンピュータが子供をプログラムするべきか、子供がコンピュータをプログラムするべきか？
-- シーモア・パパート

この引用は先程のアラン・ケイのテキストからの孫引きです。シーモア・パパートはアラン・ケイにおおきな影響を与えた人で、子供向けのコンピューティング環境を作っていた人です。この問いの立て方、前半部分では「コンピュータが子供をプログラムする」、つまりシステムが人間を強制するような状況であり、後半部分は「子供がコンピュータをプログラムする」、つまり子供の側がコンピュータを支配できるようにする、そういった問いのたてかたになっています。もちろん、シーモア・パパートもアラン・ケイも後者のほうに力点をおいています。

1984年発売のMacintoshのCM。Big Brotherが大きく映し出されている。

1984年のMacintosh発売のときのコマーシャルです。伝説的なCMで、リドリー・スコットという「ブレードランナー」の映画監督が作っています。元ネタはジョージ・オーウェルの「1984」という小説で、Big Brotherという独裁者に支配されるディストピアが描かれています。このコマーシャルではこのあと、アスリートの女性が警官に追われながら走ってきて、ディスプレイのBig Brotherに対してハンマーをぶん投げてディスプレイを破壊し、「1984年が小説「1984」に書かれているような年にはならないことを知るでしょう」というテロップが流れる。このコマーシャルは非常に象徴的で、パーソナルコンピュータの開発の背景に、システムによる支配から個人の解放という主題があるということをよく表しているコマーシャルだと思います。

人権宣言に２つのことを追加することを提案します。
人は自分の要求を知ることを強要されない。
人はキーボードの奴隷労働に罰せられることなく、いつでも心を変えることができる。
--トリグヴェ・リーンスカウク、A note on DynaBook requirements

こちらのテキストはトリグヴェ・リーンスカウクさんがパロアルト研究所を訪れているときの論文です。パーソナルコンピュータの開発に非常に強い感銘を受けていることが伺える一節です。いままで紹介してきたことと同じようなニュアンスでいっていると思います。これらの資料から、パーソナルコンピュータが変えようとしたのは、システムと個人の関係であるということがわかると思います。

では、パーソナルコンピュータのもつべき言語はどうあるべきか。アラン・ケイはこのように言います。「デバイス所有者からかけ離れた言語的なコンセプトを使った言葉であってはいけません」。親密な言葉で構成されていなければ、自分のデバイスを操作したり書き換えたりできない。

「Smalltalkの底に流れる設計思想」の図。二人の人間のコミュニケーションが模式化されている。人間はBodyとMindの組である。Body同士はexplicit communicationと書かれた実線で繋がれ、Mind同士はimplicit communicationと書かれた点線で繋がれている。

この図は、アラン・ケイと一緒にSmalltalkを開発していたダン・インガルスさんという方が書いた「Smalltalkの底に流れる設計思想」というテキストのなかの図です。人間のコミュニケーションを模式化した図です。上の実線で描かれた矢印が "explicit communication"(明示的なコミュニケーション)、下の点線で描かれた矢印は "implicit communication"(暗黙的なコミュニケーション)。これらが何を意味するかというと、explicit communication は記号や絵画など、なにかしら具体的に知覚可能な表現物のことで、これが身体間を流れる。こういった記号表現は、暗黙のもの、つまり文化や文脈をもとにして解釈がなされる。なぜダン・インガルスさんが人間のコミュニケーションを説明しているかというと、コンピュータの言語はまさに人間のコミュニケーションのようでなければならない、と考えているためです。

トリグヴェさんのModel-View-Controllerの図。UserとModelの間にTool(Controller+View)が配置されている。Userのところにはmental modelとあり、Modelのところにはcomputer modelとある。

MVCの図と比較してみると、ダン・インガルスさんの図の右側をコンピューターに差し替えればそっくりです。explicit communication のところに来るのはControllerとView、つまりToolです。この図が似ているのは、おそらくダン・インガルスさんの図を参照しているとおもいます。モデルは人間とコミュニケーション可能でなければならない、とトリグヴェさんは考えている。

要件は時間とともに進化するため、新しいシステムを前もって設計するのは難しいことでよく知られています。解決策は、モデリング言語をプログラミング言語にすることです。
--トリグヴェ・リーンスカウク

トリグヴェさんが2003年にJavaZoneでMVCについて話したときの言葉です。要件は変化するため、前もってシステムを設計することは難しい。そのためには、モデリング言語をプログラミング言語にする必要がある。ユーザーがコンピューティングできるためには、ユーザーが理解できる言語を作る必要がある、ということを言っています。

5. MVCとはなにか

いったんまとめます。

* ドメインモデルは情報システムがもつモデル。社会的システムとして個人を束縛する。
* メンタルモデルは個人が世界に抱く内面的なモデル。メンタルモデルを形成するためには良い道具が必要、特にコンピュータにあってはユーザーイリュージョンが重要。
* パーソナルコンピュータは社会と個人の関係を変えようとした。自分の力でシステムを書き換えられることが重要だった。そのためにはコンピュータの言語を個人が理解できなければならない。

以下は、最初に紹介したHacker Newsのアラン・ケイのMVCについてのコメントの前半部分です。

MVCはもともとPARC(パロアルト研究所)でだいたい40年前に作られた。良いところは哲学的だったことだ。45年前にユタ大学で私が関わっていた3Dグラフィックスでの「カメラ」と「ワールド」という観念によく適合するアイデアだった。
https://news.ycombinator.com/item?id=8841428

アラン・ケイは大学院時代にアイヴァン・サザーランドが教授で3Dグラフィックスを研究していたのですが、3Dグラフィックスの「カメラ」と「ワールド」の関係に、MVCのアイデアはよく適合すると評価しています。

理想的なMVCのソリューションは、ユーザーがドメインの情報を直接見て操作するという、ユーザーイリュージョンをサポートすることでした。
http://folk.uio.no/trygver/themes/mvc/mvc-index.html

MVCについてトリグヴェさんが言っている箇所の抜粋です。「ドメインの情報を直接見て操作する」ことが「ユーザーイリュージョン」であると言われていることに注意してほしいのですが、ここにはドメインの情報とユーザーの間に基本的には距離がある、ギャップがあるという前提があります。それを前提として、そのギャップを埋めるためにはユーザーイリュージョンが必要である、ユーザーイリュージョンがあることによって、ドメインの情報を直接みて操作することができるようになる。そういうことをトリグヴェさんは言っていると思います。

これはどういうことでしょうか。いまの業務の基本的な形はこのような図になっているかとおもいます。

中央の情報システムに対して複数人がパーソナルコンピュータを通じてアクセスしている。

中心に何かしらの情報システムがある。今日のお話ではドメインモデルとよんできたものです。これに対して各人がパーソナルコンピュータでアクセスしている。プログラマーであればGithub、営業であればSalesforceをつかっていたり、そういったシステムに対してパーソナルコンピュータでアクセスしている。

情報システムとメンタルモデルの間にはギャップがある。

トリグヴェさんが言おうとしていることは、こういった情報システムと個人の間にギャップが存在しているということです。例えばSalesforceが使いづらいとか、自分の業務にシステムがあっていないといった場合にギャップが発生する。

ギャップを解消するためにパーソナルコンピュータのなかに「概念モデル」と「ツール」を導入する

それではどうすればよいかというと、自分が操作可能になるように、パーソナルコンピュータにツールとモデリング言語を入れるべきである。これがMVCの形ではないでしょうか。あとでトリグヴェさんが展開しているDCIという考えも同じ形だと思います。

これは一言で言えば分散情報システムと言えると思います。

ふたたびトリグヴェさんのMVCの図

MVCの図は、基本的にパーソナルコンピュータ内での図です。そしてこのコンピューターモデルの奥に、ドメインモデルがある、という想定の図になっている。

トリグヴェさんの資料。Personal Information System Where Many Business Domains Meetという見出し。Domain Serviceにパーソナルコンピュータからアクセスしている。作業者のコンピュータにはEffective, Enjoyable, Instructive Information Environmentと書いてある。

こういったことは、トリグヴェさんが2003年のJavaZoneで説明しています。この図の右側に "Domain Service" とあります。これは今日の発表ではドメインモデルとよんできたものです。この Domain Service に対して各作業者がパーソナルコンピュータを通してアクセスするような図になっている。

この図でぼくが注目してもらいたいとおもっているのは "enjoyable" という言葉です。タスクをこなすためには、仕事は楽しくなければならない。先程ご紹介したトリグヴェさんのこの言葉を思い出していただきたい。

人権宣言に２つのことを追加することを提案します。
人は自分の要求を知ることを強要されない。
人はキーボードの奴隷労働に罰せられることなく、いつでも心を変えることができる。
--トリグヴェ・リーンスカウク、A note on DynaBook requirements

人間が楽しく仕事をするとはどういうことでしょうか。システムによって自分が業務を強制されないということ、なにかしら自分がシステムをちゃんとコントロールできているということ。これは人間の権利であると、トリグヴェさんは言います。

これとほぼおなじことを、デザイナーの上野学さんが言っています。今年のWorld IA Dayでの「OOUIの目当て」というタイトルの発表で、上野さんは次のように言います。仕事の対象が見えていること、それをコントロールすることができるということ。そういった仕事は楽しいものである、と。

そのデザインはいったい誰に力を与えるものなのか
-- Modeless and Modal

最後になりますが、ぼくたちプログラマーもこのように問うべきではないでしょうか。「そのデザインはいったい誰に力を与えるものなのか」と。

---

あとがきもお読みいただけると嬉しいです。