「MVCとはなにか」あとがき

tenjuu99

PHPカンファレンス2019で、「MVCとはなにか」というやたら主語がでかいタイトルで話しました。

登壇じたいが２回目というのもあって、あとで動画を見直してみると、まったくマイク使えていないし客席をほとんどみていないしでひどいな...とおもいました。
それはともかく。

背景

今回の発表にあたって、MVC原案者のトリグヴェ・リーンスカウクさんの論文やウェブ上の資料を読み漁っていたのですが、DCIアーキテクチャのコミュニティ(トリグヴェさんとジェームズ・コプリエンさん主催)のメーリングリストに次のようなスレッドがありました。

https://groups.google.com/forum/#!topic/object-composition/oJgHZl19hUM

スレッドの発端は2016年のInfoQにMVCへの批判記事があがったことにあります。

この記事に対して、DCIアーキテクチャのコミュニティのメンバーの一人が、「MVCはもともとあなたが言うようなものではない」とコメント欄で反論し、この経緯をメーリングリストに投稿しました。

トリグヴェさんは、メーリングリストでの彼への返信で、アラン・ケイがよく "Nobody understands me." とボヤいていたといいつつ、こんなふうに言っています。

A very tired, very frustrated, and very old man. Nobody understands me.

この80代後半にもなる老いたノルウェー人の、悲しみと怒りのまぜこぜになった感情が、痛いほど伝わってきました。ぼくたちはいったいなにを批判した気になっていたのだろうか。

FacebookによるMVCの批判や、いわゆるMVC2への批判など、MVCは気軽に批判されてきました。トリグヴェさんの言う通り、誰も彼のことを理解しようとすらしていないのです。

トリグヴェ・リーンスカウクさんのMVC

今回のPHPカンファレンスでの話の骨格は、トリグヴェ・リーンスカウクさんが2003年のJavaZoneで話したときの資料から来ています。

http://heim.ifi.uio.no/~trygver/2003/javazone-jaoo/MVC_pattern.pdf

こちらは動画がないのですが、初期の論文等と突き合わせると、このときトリグヴェさんが話そうとしていた内容は想像がつきます。概ね次のような内容とおもいます。

彼はまず、組織が業務を遂行するための情報システムを、ドメインサービスとして複数に分割します。このドメインサービスは部署に対応しています。これは既存の情報システムの作り方です。
次に、ドナルド・ノーマンを引いてメンタルモデルについて考えます。メンタルモデルと情報システムが整合するためにはUMLのような概念モデリングツールが必要であるといいます。それから、パーソナルな情報システムについて語ります。これはアラン・ケイが主導したダイナブックのようなパーソナルなコンピューティング環境です。各作業者は複雑なタスクを抱えており、作業を行うための個人向けの道具が必要で、それがパーソナルコンピュータです。
これらを統合すると、ドメインサービスとユーザーの間にギャップが生まれることがあります。組織が持つ情報システム(ドメインサービス)と個人がもつ情報システムの間に齟齬が生まれることがある。この齟齬を埋めるために、パーソナルコンピュータのなかに、動くモデリング言語とそれを利用するツール群を導入しよう、そういったアイデアがMVCです。

資料を荒く要約するとこういうことになるとおもいます。今回のぼくのスライドの構成は、「ドメインサービス」を「ドメインモデル」と読み替えている事以外は、トリグヴェさんのこの構成に則っています。

JavaZoneでのトリグヴェさんのお話は、彼の経験に基づいています。彼はパーソナルコンピュータに出会う前に造船業向けの業務システムを作っていました。ある部署の若者が、そのシステム内のデータを使って単位の変換をしないまま鋼鉄をカットしてしまい、無駄な鉄くずを生み出してしまいました。このシステムを導入するまでは部署ごとの設計データを持っていたのですが、このシステムの導入によって、一元化されたデータベースシステムと実際の業務との間にギャップが存在するようになったわけです[1]。

トリグヴェさんはここに根深い問題を見出し、長いこと思索を重ねています。彼がMVCのアイデアを最初に出したのが1979年で、ジェームズ・コプリエンさんと共同で書いたDCIアーキテクチャというテキストが2009年、その間30年も同じ問題を考え続けているわけです。MVCとDCIは完全に地続きの問題に対する模索です。トリグヴェさんは「分散組織は分散コンピューターシステムによってサポートされるべきだ[2]」と考えており、MVCはこの分散コンピューターシステムの出発点として考えられているのです。

部署ごとのドメインサービスという問題は、エリック・エヴァンスさんのドメイン駆動設計ふうにいえば、境界づけられたコンテキストにそってモデルを分割すべきだ、ということになります。とすると、ドメイン駆動設計とDCIは同じなのでしょうか？ぼくは違うと思っています。エリック・エヴァンスさんとトリグヴェさんのアイデアのなかでもっとも重要な差というのが、まさにパーソナルコンピュータの存在だと思うのです。

なぜパーソナルコンピュータなのか？トリグヴェさんは1979年にパロアルト研究所に客員研究員として訪れています。パロアルト研究所では、アラン・ケイがダイナブックという「パーソナルな」コンピュータの開発をしていました。そのときのトリグヴェさんが書いた論文で、ダイナブックの要件について記載したものがあります[3]。これは大変に面白いテキストなのですが、残念なことにすべてスキャンされていないようです。そのなかで、トリグヴェさんはとても印象的な言葉を記しています。

人権宣言に2つの新しい記事を追加することを提案します。人は自分の要求を知ることを強要されない。また、人はキーボードの奴隷労働で罰せられることなく、いつでも心を変えることができる。

システムと人間の関係についての、素晴らしい言葉ではないでしょうか。ぼくたちは、システムの要求に合わせて自分の仕事を強制する必要はなく、むしろシステムこそが自分の要求に合わせて変更可能であるべきである。これは人間の権利である。トリグヴェさんは、アラン・ケイのダイナブックのなかに、新しい人権宣言を読み取っているのです。

エリック・エヴァンスさんの「境界づけられたコンテキスト」との違いは明らかです。境界づけられたコンテキストは他の誰か(おそらくアーキテクトでしょう)が境界づけるよりほかありません。トリグヴェさんにとってあくまで主役はユーザー自身で、ユーザーが自身の業務を自分で構築できることが主題です。エリック・エヴァンスさんの「境界づけられたコンテキスト」が通常の意味でのデザインだとすれば、トリグヴェさんの考えるMVCとは、ユーザーが自力で問題を解決するためのメタデザインです。だからこそ、MVCはパタンランゲージなのです。

MVCについて考えるとき、ぼくは先程のトリグヴェさんの言葉を忘れたくないと思います。あれこれの実装の詳細のまえに、人間が楽しく仕事をできるということ。プログラマーもデザイナーもこれを人間の権利として考えるべきである。

そういったストーリーを頭に浮かべて資料を作っていると、上野学さんのModeless and Modalというブログが書籍化されたというツイートを見ました。

内容はウェブ版と同じなのですが、あとがきが新たに加えられ、そこにはこんな事が書いてありました。

10年がたって、UIデザインについての関心はずいぶん高まったと思います。モバイルアプリやウェブアプリがたくさん作られるようになり、UIデザイナーの数は数倍に増えているでしょう。しかし、もしくはだからこそ、“Afterword”に書いた疑問はますます大きくなっているのです。すなわち「そのデザインは、いったい誰に力を与えるものなのか」ということ。
Manabu Ueno. Modeless and Modal (Japanese Edition) (Kindle Locations 2461-2464). Kindle Edition.

ぼくたちはソフトウェアを作っています。ソフトウェアは人間の業務の形を変え、ある業務は廃棄され、また新しく生まれる業務もあります。人間の仕事は、ソフトウェアの台頭してきたここ10年で大きく形を変えてきたと思います。ソフトウェアとは人間の業務を作り出している当のものなのです。プログラマーは、人間の仕事を左右することができる権力を持った存在です。そういうぼくたちが、人間の権利について、仕事の楽しさについて考えないのは、そもそも片手落ちなのではないでしょうか。

89歳になるトリグヴェさんは、今年Personal Programmingという論文を書き上げました。全部読めていないのですが、さわりを読む限りMVCやDCIを超えて、いまのインターネット環境における「パーソナル」ということの意味についての思索を重ねているようです。この老いた偉大なコンピュータ科学者が、生きているうちに自分の理想を実現できると考えていないことは明らかです。ぼくたちはバトンを渡されています。

---
注
[1] The Roots of DCI( http://fulloo.info/Documents/2010DCI-Origin.pdf )より。
[2] 同上。
[3] A note on DynaBook requirements( http://heim.ifi.uio.no/~trygver/1979/sysreq/SysReq.pdf )

この記事が気に入ったらサポートをしてみませんか？