設計プロセスと創発特性

昨日は日本建築学会の「建築夜学校」にコメンテーターとして登壇させてもらった。正直、建築の人たちとは最近交流が増えたものの、そもそも予備知識もない完全な門外漢なので、講義を休んでまで出て行く必要があるのか悩んだのだけれど、こちらが勉強させてもらういい機会にしようと思って出席することにした。というか気がついたらまた挑発しすぎた。反省。翌日の昼には大学に戻っていなければいけなかったので、打ち上げでもほとんど深い話はできなかったけど、とても興味深い会だった。ちゃんと咀嚼した感想はそのうち書くとして、とりあえずは事前に考えていた自分用のメモを公開しておこうと思う。ただし当日話したとおり、一部については報告を聞いて考えを改めてコメントしている。

ウェブと建築の設計プロセスの類似点、ということがモデレーターのお二人の関心にあって、僕のような人が呼ばれたのだと思う。実は僕自身はウェブでの振る舞いの細かな話にはもうあまりコミットしていなくて、今はどちらかというと消費社会の歴史や郊外について調べているので、その意味であまり適当な人選ではないのかもしれないけど、さしあたり、実際にウェブサイトの構築・運用に関わった立場から、少し考えてみたい。

ウェブと建築は似ているのか？と考えたとき、確かにその制作プロセスには、いくつかの共通点がある。まず、どちらも「発注→要件定義→定義確定→制作→納品→検収→納金」の手順を踏むものであるということ。制作前に綿密な打ち合わせがあって、青写真ができて、できたものをチェックしてもらって、OKが出てようやくお金になる。まあ何でもそうだけどね。だからこうした専門技能を必要とする制作プロセスで常に起こる、クライアントの要求とクリエイターの個性とのバランスが問題になる。全体として、発注前の段階から制作工程を通じて適切な情報共有や円滑なコミュニケーションがなければ、トラブルを抱え込むリスクが増すというわけだ。

もちろん相違点もある。事前に確認しとけって話なんだけど、ウェブサイトの場合、どうしても公開後の改修、修正、アップデートの要求というものがつきまとう。自前で更新できるシステムまで用意する場合もあるけど、昔はそういうのがあまりなくて、また納品先にもそういうスキルがなくて、やたらと苦労した思い出がある。いまではウェブサイトも作って投げっぱなしってわけにはいかないから、こうしたリリース後のマネージメントをどうするか、そこまで考えなきゃいけない。打ち合わせで藤村君と話をしていて、最近は建築もそうらしいことが分かったのだけど、ウェブの場合、究極的にはマネジメントに主眼を置いて「ベータ版でリリース」っていうこともアリなわけだ。

さて、ずっとウェブ、ウェブって言ってきたのだけど、実は上記のプロセス、むしろ共通点の部分に注目すれば、これはウェブ構築よりもソフトウェア開発のプロセス、それもB2B向けのそれに近いのではないかと思う。ソフトウェアの場合も改修やカスタマイズの要求はあるけれど、それだって必要な人月を算定してきちんとコスト化し、追加受注という形にできる。まあ実際には営業さんとの折衝の結果、アレがコレしたりナニがソレしたりするのだけど。

で、こうしたプロセスの中で、設計というか開発の際に重要になるのが、コードのバージョン管理だ。別にコードに限らなくて、仕様書にも常に日付が入るし、ソースコードには、CVSのようなバージョン管理システムがあって、コードもリポジトリに蓄積されている。「履歴の残る設計プロセス」としては、ウェブというよりソフトウェア開発の方が、建築設計プロセスに対するインプリケーションは深いんじゃないだろうかと思う。

じゃあ、ウェブの世界に、ソフトウェア開発と異なるインプリケーションを提供できる要素はあるか？と考えたとき、ひとつ特徴的なのは、ウェブの場合、サイトを構築してもユーザーの閲覧環境に依存する度合いが高いので、設計側の意図を「正しく」ユーザーに届けるのが難しいということだ。その代わり、そうしたユーザーに対する依存度の高さゆえ、ウェブの開発者はそもそも自分たちの成果物を、DTPのように決まり切ったデザインを押しつけるのではなく、ユーザーと協働して創りあげていくものだ、と考えがちだったりする。初期のウェブデザインにDTPの人たちが入ってきた頃、彼らに口を酸っぱくして言ってたのはそういうことだった。

こうした独特の設計思想は、ウェブの世界でまま起こる「秩序の創発」を、設計側がある程度制御しうるデザインへと高めていく、近年の傾向に繋がっていると思う。確かに、ウェブの行動特性や文化は創発的で、無理に制御しようとすると「炎上」したり、逆に閑古鳥が鳴く結果になったりする。ウェブの創発性に期待するヘビーユーザーほど、こうしたコントロールには否定的だけど、成功したウェブサービスの全てが「やってみたらたまたま当たった」わけではない。そこではユーザーの行動を細かく把握し、分析し、それに応じて細かく設計をアップデートする、設計側の巧妙な営みがあるはずなのだ。

ソフトウェアとウェブ、ふたつの設計プロセスを、極端に抽象化して図示してみよう。ソフトウェアの場合、コードのバージョン管理は一元的に行われ、プログラマーはリポジトリのコードをチェックインすることで、コードを修正し、修正が終わったらコミットし、チェックアウトする。このとき、コードに対して複数の人間がコミットしていても、最終的にアップデートされるコードはひとつで、その過程はリニアなものだ。場合によってはコードのバージョンが分岐する（フォークする）こともあるらしいけど、少なくとも特別な事情がない限り、プロダクトとしてのソフトウェア開発においては、リニアなコードの修正が行われる。

それに対してウェブの場合は、そもそもその特性の現れ方や遷移に、リニアな特徴は見られない。むしろ、個別バラバラに違う意図を持って振る舞う人々の選択が、互いに一定の方向性へと秩序立てられたり、あるいは「流れに沿う振る舞い」と「そうでない振る舞い」の間の線引きが発生したり、そうした秩序や線引きが時間と共に変化したり崩壊したり、そういう動的な特性が生成されるのだ。それを方向付けるのは確かに難しい。でも、無秩序な発言の中から、何がその場の「空気」に合致した発言なのかを判断し、そうしたものから外れた「空気の読めない」発言を意図的に無視する、そういう振る舞いなら、僕らは日々行っているはずだ。ウェブ的なプロセス、というのであれば、むしろこうした点を挙げるべきだと思う。

これは別に、抽象的なモデルの描き方の問題じゃない。「ウェブ的な設計プロセス」に参加するメンバーの資格の問題に大きく関わるのだ。つまり、ソフトウェア的なプロセスであれば、そこに参加できるのは、設計ができる人間、要するにプログラマーとか建築士のみ。広く取っても、そうした事情を理解できる人間だけ、ということになる。しかしウェブ的な設計プロセスを採用するというのなら、そうした知識のない、あるいは設計そのものに反するような人々の振る舞いまでも、プロセスの中に投入する必要があるはずだ。つまりいずれのプロセスを採用するかは、設計に関わる政治的な問題でもあるのだ。

その「政治」をどのように解決するか。見取り図の書き方はたくさんあるけれど、まずは建築の側にいる方々の応答を待って考えたい。さしあたり僕が考えているのは、そうした政治問題を解決する軸として、一方に、パーソンズのパターン変数で言うところの「業績性対帰属性」の軸を、他方に設計者中心か参加者中心か、という二つの軸を設定し、両者の組み合わせで得られるパターンから、最適なものをその都度現場に合わせて選ぶ、というものだ。その話が役に立つかどうかも含めて、まずは討議に投げ返したい。