その中の「第1章 ソフトウェア・デザイン宣言」は、1980年代初頭にロータス1･2･3の開発時にインタラクションをデザインするという役割を担い、自分の仕事をソフトウェア・デザインと定義した最初の人間のひとりであるミッチェル・ケイパーによる論文です。
デザインが実現する３要素：「堅実さ」「商品性」「喜び」
そのケイパーがソフトウェア･デザイン理論の発端としたものが建築のデザインであることはなかなか興味深いなと感じました。ローマ時代の建築評論家ヴィトルヴィウスは、すぐれたデザインの建物は堅実さと商品性、そして喜びを持ち合わせていると言った。
同じことがソフトウェアにも言えるかも知れない。堅実性とは、プログラムに機能を妨げるバグがないこと。商品性とは、そのプログラムが意図した目的に合っていること。喜びとは、そのプログラムを使うことが嬉しい経験であるということだ。ソフトウェア･デザイン理論の発端は、ここにある。ミッチェル・ケイパー「第1章 ソフトウェア・デザイン宣言」
テリー・ウィノグラード『ソフトウェアの達人たち―認知科学からのアプローチ』
この論文は1990年に発表されたものということですが、まだ「ソフトウェア・デザイン」という言葉さえ存在しなかった時点で「堅実さ」「商品性」「喜び」という３つの要素をケイパーがあげているのは、今の時点から考えてもとても先見的だと思います。
現在の「ユーザビリティ」という言葉を捉える上でもこの３つの要素は核となる要素だと考えられるからです。
そして、これがローマ時代の建築評論家にすでに見出されていたという点もまた驚きです。
専門性と総合的な知識
情報アーキテクチャ、システム・アーキテクチャという言葉が普通に使われるように、Web開発においても、システム開発においても、デザインの際に建築の手法を参照することはいまではめずらしくありません。このケイパーによる論文がその起源にあるものかは定かではありませんが、建築を参照したきわめて早い段階のものであり、かつ、それを構造的な点だけではなく、ヴィジュアルなどの体感的なものまで含めたデザインと関連付けて語っている点は、現在の情報アーキテクチャ、システム・アーキテクチャが参照する以上のものを含んでいると言えます。
ケイパーは「ソフトウェア・デザイナーは、コンピュータ科学者よりも建築家に近い方法で教育を受けるべきである」と言っています。
どういう意味かといえば、商品性や喜びにつながる見た目や体感的なデザインに長けていることはもちろん、「製品化のクオリティを持つほどのコードは書けなくても」「技術的にはしっかりした基礎を持っている」という総合的なスキルを磨く必要があるという意味で。
このケイパーの論文を受けて、編者のテリー・ウィノグラードは以下のような考察を行っています。
近代の建築においては、たいてい建築家、建設者（あるいは請負業者）、そして個々の作業員という作業分担が成立している。建築家は、その課題に見た目や触感的なポイントから取り組みが、これはヴィトルヴィウスが言うところの商品性と喜びの部分である。エンジニアや建設者は建設の堅固さに関わり、経済性、安全性、建設可能性などを併せて考慮する。テリー・ウィノグラード『ソフトウェアの達人たち―認知科学からのアプローチ』
実際、建築における教育は大学の建築学科のカリキュラムでも総合的に建築に関する知識を学ぶと同時に機能分化された１つの領域を極める形の２軸で成り立っています。
僕が学生の時には、1、2年で総合的に建築を学び、3、4年では意匠、構造、施工、設備に機能分化された形で分かれた研究室での学びを中心に行うという流れになっていました。
しかし、
もちろん、建物の世界でもそれぞれの役割がそれほどきっちり分割されているわけではない。テリー・ウィノグラード『ソフトウェアの達人たち―認知科学からのアプローチ』
それゆえに専門性だけでなく、総合的な知識が必要になるのでしょう。
ケイパーがデザイナーも「プログラム言語のうち少なくともひとつはしっかり使える知識を持つべき）と言っているのも現場においては必ずしも厳密な機能分化は成立しにくいし、成立させようとするクオリティやスピード感を担保する際に歪みが発生してしまうのだと思います。
デザインは"デザイン"の下流工程ではない、再び
建築のデザイン・プロセスを考えると、いわゆる見た目や体感的なデザインが決して下流工程に位置すべきではないという主旨をうたった「デザインは"デザイン"の下流工程ではない」のエントリーがあながち無茶なことを書いたわけではないのだなと思います。デザインするものの「堅実さ」「商品性」「喜び」を実現するため、そして、「デザインにより人びとの生活を豊かにすることを真剣に考える」ためには、「デザイン・プロセスのデザイン」で書いたように、固定した「プロセスに縛られてしまうことによって、参加メンバーの創造性が失われたり、組織的にも発想が硬直してしまい、新しいものが生み出せなくなってしまう可能性」をプロセスそのものをデザインするという柔軟さを導入する視点が必要になってくると感じます。
そのためには、デザイナーには建築家のような統合的な視点や知識が必要なのでしょうし、そのための教育も必要になってくるのではないかと思います。
その意味では、プロジェクトによっては、誰がデザイナーになってもいいような気がしたりします。
もちろん「製品化のクオリティを持つほどのデザインはできなくても、技術的にはしっかりした基礎を持っている」ことは最低限必要なのでしょうけど。
関連エントリー
この記事へのコメント