-----------------------
	概念設計についてのノート

         (SEAMAIL Vol.14,No.4)
	-----------------------


0．はじめに

このノートは，昨年の１０月２〜４日に山形県遊佐町で行われた第１３回
テクニカル・マネジメント・ワークショップでの「概念設計」についての
短いプレゼンテーションのスライドをもとに，とりあえずメモ書きしてみ
たものである．草稿をワークショップ参加者およびSEA 幹事の ML に投げ
てみなさんからいろいろなコメントをいただいた．それを取り入れてもう
少しまとまった形にしようと考えていたのだが，雑事に追われてなかなか
手がまわらない．ほとんど未定稿の状態だが，異論・反論・Objection を
いただければ幸いである．

1．設計の本質

ソフトウェア・システムとは，それが対象とする世界（それは，われわれ
を取りまく全世界の一部分でしかないが）を何らかのかたちでモデル化し
たものに他ならない．

設計問題に関してわたしが愛読しているネルソン・グッドマンの名著：
Ways of Worldmaking (邦訳は「世界制作の方法」みすず書房）の冒頭に
引用されているエルネスト・カッシーラーのことば：

  − 記号を用いて，数え切れないほどの世界が無から創り出される

が示すように，世界のモデル化にはさまざまなやり方が可能であり，結果
として複数の世界が同時並列的に創り出されることになる．Ｍ.Ｍ.レーマ
ンのＥ型プログラム（現実世界のアプリケーションに組み込まれるプログ
ラム）のプロセス・フレームワーク [*1] では，それを複数のシステム・
ビューと呼んでいる．

	[*1] 関連論文を集めたレーマン先生の Web Page は；
		www-dse.doc.ic.ac.uk/~mml/

そうした複数のモデルあるいはビューの解釈として，ひとつの現実世界を
異なる視点あるいは枠組みでとらえたものと考えるか，または，グッドマ
ンのように複数の世界のバージョンが同時に存在すると考えるかは哲学上
の未解決の課題である．わたし個人は，グッドマンの考えにほぼ同調した
いと感じているが，そのことをいまは論じないことにしよう．

問題は，複数の世界（そのモデルあるいはビューあるいはバージョン）が
どのようにして創られるのか，である．カッシーラーは，それらが「無か
ら」創りだされるといったが，それは単なることばのあやであって，事実
は異なるであろう．グッドマンが指摘したように，新しい世界のバージョ
ンは，すでに存在しわれわれに与えられた古いバージョンを少しあるいは
大幅に手直しするかたちで創られるのであって，決して無からではない．

何らかの記号（ことば）を用いて書かれたモデルあるいはビューを媒介す
る以外に，われわれは世界にアクセスする手段を持っていない．はじめに
まずわれわれに与えられるものは、ひとつあるいは複数のモデルによって
記述された世界（群）なのであり，それをいくつかの視点から眺め，分析
的に考察することによって，われわれは新しい「世界」を創りだすのであ
る．その意味で，「設計」とは既存の世界モデルを利用して，その上に構
築される「再設計」（設計のやりなおし）なのである．少なくとも設計の
出発点で  ある概念設計には，そうした色合いが濃い．

2．設計のプロセス

ネルソン・グッドマンは，多くの論議を呼んだその著書のなかで，かれの
いう世界（あるいは世界のバージョン）を創りだすプロセスを構成する活
動を次の５つのカテゴリに分類している：

(1) Composition and Decomposition (構成と分解）
(2) Weighting (重みづけ）
(3) Ordering (順序づけ）
(4) Deletion and Supplementation (削除と補充）
(5) Deformation (変形）

何年か前，初めてこの本を読んだとき，わたしは，この分類は単に「世界
制作」あるは「設計」のプロセスを構成する諸活動をただそれぞれの性質
に応じて種類わけしただけのものにすぎないと考えていた．しかし，その
後，グッドマンが提起した問題をテーマに開催されたシンポジウムの記録
"Starmaking" (MIT Press, 1996) に再録されたかれの文章 "Words, Works,
Worlds" を読み直してみて，その解釈は誤りだと感じた．この分類は，単
なる設計活動のカテゴリ分けではなく，設計プロセスを構成する５段階の
サブプロセスの論理的な順序（それはあくまで論理的な順序であって現実
の設計が行われる時間的順序ではない）を暗示していると考えたほうがよ
い．グッドマン自身の文章は，絵画そのほかの芸術分野における世界制作
の場合を数多く例示していて，ひとことも「設計」については言及してい
ないが，わたしにとって，それらの例示は示唆に富むメタファのように感
じられた．

2.1. 構成と分解


あらゆる設計は，無からの創造ではなく，何らかの既存の設計をベースに
した再設計である．ひとつの新しいソフトウェアの設計を始めようとする
とき，われわれに与えられるものは何かといえば，対象とするシステム（
それはあるアプリケーションかも知れないし、ある機能を意図したパッケ
ージかも知れない）のイメージなのであるが，それはきわめて曖昧で多義
的な「仕様」と呼ばれる仮想的なモデルのかたちで提示されるのがふつう
である．そうした仕様は，当然ながら記号（コトバ）を用いて記述されて
おり，その背景には，おそらく，何らかの設計意図が隠されている．

したがって，「概念設計」と呼ばれるわれわれの仕事は，まず，この「仕
様」という名の曖昧で暗示的な「設計（もどき）」を注意深く吟味し，そ
れがどのような構成要素からなっているか，それらがどのようなアーキテ
クチャを構成しているかを分析することから始まる．

また，ほとんどの場合，そうした「仕様」は，既存の類似ソフトウェアを
土台として書かれていることが多い．したがって，われわれの概念設計の
作業は、それらの類似ソフトウェアの設計を再吟味し，分解することから
始まることになるであろう．

この分解と「再」構成こそが，概念設計のスターティング・ポイントだと
考えられる．

ソフトウェア開発方法論の短い歴史を振り返ってみると，たとえば，いわ
ゆる構造化プログラミングの方法論は，既存のプログラムの機能的構成要
素に着目して，それらを，連続・分岐・反復という基本構造に分解するこ
とから出発し，最終的には，ソフトウェアの機能(計算上の意味論)とは独
立した構造パターンを見出すことに成功をおさめた．また，オブジェクト
指向技法は，シミュレーションのためのプログラミング言語から出発して，
ソフトウェアが対象とする世界を，データとプロセスの両側面を兼ね備え
たオブジェクトの集まりとしてモデル化するというアプローチで，いくつ
かの分野でかなりの成功をおさめたが，そのひとつの理由は，対象世界の
分解と再構成という概念設計の自然な流れにそのアプローチが自然なかた
ちでマッチしていたからである．

ただし，マイケル・ジャクソンが「ソフトウェア博物誌」で指摘している
ように，構造化プログラミングの後継者として登場した SASD 技法やオブ
ジェクト指向のアプローチは，もともと，コンピュータの内部におけるプ
ログラム実行プロセスの意味論的側面を体系的に整理する手段としてのプ
ログラミング技法に由来しているがゆえに，現実社会のなかのアプリケー
ション・プロセスを対象とする一般的なシステムの分析や設計に応用しよ
うとした場合には，ある種の限界がある．

2.2. 重みづけ

概念設計の第２の論理的ステップは，前の段階で明らかにされた対象シス
テムの構成要素に対して，それぞれ適当な重みづけを行うことである．

この「重みづけ」すなわち対象システムの構成要素のうちで何が重要であ
り何が重要でないかを評価することは，概念設計においてもっとも中心的
な仕事である．それは，設計者が対象システムをどのようにとらえて
いるかを示すからである．

世のさまざまな開発方法論のちがいは，このステップにおいてあらわれて
くる．プロセスあるいは機能中心のアプローチ，データ中心のアプローチ，
あるいはオブジェクト指向アプローチ，etc, etc. それらの各方法論のあ
いだには別に優劣があるわけではない．ただ単に概念設計の「重みづけ」
ステップにおける考え方のちがい（対象システムのどのような側面を重視
して世界をとらえるか）をあらわしているだけである．

グッドマンはそのあたりのことを次のように述べている：

  ひとつの世界（注：かれの用語「世界」は「設計」と読み替えること
  ができよう）における重要なものたち（Relevant Kinds) が他の世界
  には見あたらない場合に，われわれは，ふたつの世界はおなじ種類の
  ものから成り立っていて，しかし，それらが重要か重要でないかとい
  うそれぞれの評価にしたがって，異なるかたちに整理されているだけ
  なのだと考えたほうがよいだろう．ひとつの世界において重要視され
  ているものたちは，もうひとつの世界に存在しないというわけではな
  く，ただあまり重要でないものとして隠されているだけなのだ．ふた
  つの世界の相違は，構成要素の違いというよりは，それらに対する重
  みづけの違いであることが多い，そしてそうしたアクセントの違いは
  かなり本質的なのである．ある単語を発音する場合に，すべてのシラ
  ブルにアクセントを置くことは，どのシラブルにもアクセントを置か
  ないのと同じことになってしまう．

ここでいわれている「世界」の違いは，ひとつの現実を眺める視点あるい
は Frame of Reference の差ではないかというのが常識的な考え方であろ
うが，非実在論者のグッドマンは，そうではなくふたつの現実世界が同時
並列的に存在するのだと主張する．哲学に疎いわたしは，まだかれの主張
を全面的に納得し受け入れているわけではないが，.....

2.3. 順序づけ

設計の成果物は第三者（顧客 etc) に見せて評価を受けなければならない．
概念設計の第３のステップは，そうしたプレゼンテーションの大まかな計
画を立てることである．

設計が，設計者自身の自己満足のために創られるのではない以上，このプ
レゼンテーション計画は，その設計を具体化させる上で，きわめて重要だ
と考えられる．

「あらゆる言説は，それが書かれた瞬間から，筆者の意図とテキストの意
味とは合致することをやめる」と，ある哲学者が述べている（注：子安宣
邦「事件としての徂徠学」＜ちくま学芸文庫＞の冒頭に引用されている P.
リクールのことば）．設計のプレゼンテーションにおいてもっとも注意を
はらうべきは，設計者の意図とそれを「読む」第三者の理解とのあいだの
乖離をなるべく小さくすることであり，そのためには設計を構成する要素
の「順序づけ」を慎重に行う必要がある．

ソフトウェア設計において用いられるさまざまな図表（流れ図，木構造図，
etc）の主な機能は，この順序づけを支援することなのである．

「およそ，言に類あり，世あり，人ある」というのは，富永仲基 [*2] の
鋭い指摘であるが，言語表現のスタイルが「世および人」すなわち時代や
環境によって変化することは，たとえば現在の UMLブームの状況をみても
明らかである．しかし，より重要なのは「類」すなわち言語それ自身が持
っている変化への要因であろう．

ソフトウェア設計のさまざまな表現図式の特質を，富永が仏教の経典や儒
教の四書五経に対して行なったように，かれのいう「五類」すなわち「張
・偏・泛・磯・反」のカテゴリ分けに照らして分析してみたら．きわめて
おもしろい結果が得られるものと想像される．

   [*2]とみなが・なかもと．１８世紀初めに浪速の商人たちが作った
   私塾「懐徳堂」が生んだ天才的思想家．３２才で夭折したが，荻生
   徂徠の言語哲学的方法論を批判的に発展させ，宗教思想史を題材と
   してかれが発案したユニークな分析アプローチは，周囲に大きな影
   響を与えた．主著は「出定後語」および「翁の文」（岩波書店刊「
   日本思想体系」第43巻．現代語訳は中央公論社刊「日本の名著」第
   18巻）．江戸思想史に富永が占める位置の重要性についての解説と
   しては，宮川康子「富永仲基と懐徳堂 − 思想史の前哨」 (ぺりか
   ん社）がすぐれている．

2.4. 削除と補充

概念設計におけるこの論理的ステップは，やがて開始されるであろう具体
化 (Implementation) に向けての準備を行なうものである．前のステップ
で選択された設計の諸要素のうちで，不要なものを削除し，また新たに必
要な要素を追加することが，ここでの主な活動になる．

もともとあいまいで不確定な要求仕様から出発する概念設計の作業におい
ては，このステップにおける活動は，そうした仕様の曖昧さあるいは不確
定性を少なくする働きを持つ．

プロトタイピングは，そのために用いられる有効な技法のひとつであろう．

目的とするシステムについてユーザのイメージがはっきり固まっていない
場合には，仕様は「あれもこれも」と過大に膨らむ可能性が高い．したが
って，新しい要素の「補充」はなるべく控えめに，不要と思われる要素の
「削除」は大胆に行うことが望ましいだろう．

2.5. 変形

概念設計の論理的最終段階は，設計の基本的なアイデアをブラッシュアッ
プし，それを第三者に性格に伝達するために，それぞれの要素に「変形」
を加えて，プレゼンテーションを仕上げることである．

そのさいに注意すべきは，先にあげたリクールの指摘にあるように，どの
ような表現も作者の手から離れた瞬間に，とんでもない誤解を招く可能性
があるということであろう．つまり，そうした誤解もまた理解の一種でし
かないという居直りの精神が設計者の側には必要とされるのである．

きわめて逆説的なニュアンスを含むこの「変形」作業の例を文学の分野で
拾えば，和歌や詩などでよく見られる「本歌取り」の作品群があげられよ
う．美術の分野における極限的なサンプルは，ボブ・ラウシェンバーグが
著名画家のデッサンに対して１個の消しゴムを用いて行った作業，大きな
話題を呼んだ「消されたデクーニング」がある．ソフトウェア分野におい
て世間的な成功を収めた例は，Unix の変形としての Linux だろうか？

3. 創造的設計とは？ (結びに代えて)

今回のワークショップの１週間前に，大学時代の友人たちと毎年開いてい
る絵のグループ展があった．ここ数年，エッチング・プレスで作った版画
もどきを原材料とし，コラージュその他の手法による加工を加えて，アク
リル絵具およびメディウムで仕上げるというプロセスで作品を創っている
のだが，昨年は SARS の影響で秋の ISFST会議が中止になり，例年夏に中
国で開かれている PC ミーティングがなくなって，かなり時間の余裕がで
き，実際に手を動かし始める前に「どんな手順でどのような作品を創るか
」についてのいわば「概念設計」をする時間がとれた．

そのことが，ワークショップを前にグッドマンの文章にもう一度目を通し
てみようという気持ちを起こさせたのである．

絵のグループのメンバーで建築学者の島田良一が，その著書「かたちに見
る造形の構成」（鹿島出版会）の巻頭エッセイで提示している「かたち先
行仮説」が，ソフトウェア・システムの概念設計を考えるさいに気にかか
っている．

島田の指摘は，シドニー湾に建つ有名なオペラハウスのデザインは，「オ
ペラハウス」というものの機能から生まれたものではなく，父親の仕事の
関係で造船所で幼年時代をすごした設計者の「かたち」の心象風景から浮
かび上がってきたものだということであった．

ソフトウェア・システムの概念設計において，そうした「かたち」のイメ
ージというものの働く余地はあるのだろうか．もし，あるとしたら，その
「かたち」とは何か？

シドニー・オペラハウスの例は，「設計」というより「意匠」の問題では
ないかというコメントを何人かの方からもらったのだが，そうしたコメン
トに，わたしは少し違和感を感じている．

ネット上の和英辞典で「意匠」を引くと "design" という単語が出てくる．
しかし "design" を英和でひくと「設計」とか「図案」とかは出てくるが
「意匠」は出てこない．「辞書とはコトバの定義をあたえるものではなく，
コトバが人びとによってどう使われているかを記録しただけのものである」
ということに照らしていえば，この現象は，「設計」についての考え方が，
ものを作る人の視点（ソフトウェアの場合にはプログラマの視点）にかた
よっていて，具体的なもの作り以前の「どんなものを作るか」それを「ど
んなふうに見えるようにするか」という視点がなおざりにされているので
はないかということを示しているかのように思われる．

ソフトウェア以外の設計，たとえば建築設計や家具の設計においては，「
どうやって作るか」以前に，「どんなものを作るか」すなわち意匠の設計
がきわめて大切だと考えられている．おそらく，わたしが違和感を感じた
原因は，プログラマになる以前に，抽象絵画を描くための方法論をパウル
・クレエの造形講義[*3}で勉強したせいであろう．

  [*3] Paul Klee, "Das bildnerische Denken": 美術史を専攻した友
  人の卒業研究の手伝いで，500ページもあるこの分厚いドイツ語の書
  物の私的日本語訳を作る作業には，ほぼ１年半の時間がかかった．
  邦訳（「造形思考」新潮社）がでたのは１０年以上も後の話である．
  どんな外国語も辞書を頼りに忍耐強く100ページも読み進めば一応は
  マスターできるというのが，このボランティア作業のもうひとつの収
  穫だった．その成果の応用の１つとして始めた英文翻訳のアルバイト
  でプログラミング入門書を訳したのが，わたしがプログラマになるき
  っかけだった．

６０年代の終りから７０年代の初めにかけて，わたしがまとめあげた構造
化プログラム設計のアイデアは，他人の書いたさまざまなプログラムを読
んで，「どうしてみんなはこのような形にプログラムを書くのだろうか」
という心に浮かんだ疑問を，抽象絵画の画面構成法と比較しながら思案し
た結果であった． Dijkstra や Jackson あるいは Warnier などの人たち
の構造化プログラミングもやはり同じように，プログラムの「意匠」に着
目して考え出されたものだと思われる．

構造化とは機能的モジュール化のことだという解釈が一般に広く行き渡っ
ているようだが，それは誤解である．構造化プログラミングが目指してい
たのは，プログラムが対象とする処理の意味論的機能のモジュール化では
なく，それとは無関係な意匠の構造化であった．そのあたりが，SASD や
OO の方法論と構造化プログラミングの思想とを区別する本質的なポイン
トなのである．

シドニー・オペラハウスの設計は，「建物をどうやって作るか」とか「こ
の建物の機能は」とかいった視点ではなく，「どんな建物を作るか」とい
う発想から生まれたものだと思う．「概念設計」(Conceptual Design) と
いうコトバからわたしが連想しているのは，ソフトウェアの設計において
そうした「意匠」の設計とはいったい何だろうかということである．

島田のエッセイの冒頭には，かれの主張する「かたち先行仮説」について，
次のような文章がある：

  −　わかりやすい言葉でいえば「かたちを先に考える」あるいは「か
      たちを独立して考える」ということである．もっと身構えていい
      なおせば，かたちだけを独立して教育したり，研究したりできる
      ということである．また，この仮説は，もう少し欲張った内容を
      含んでいて，建築設計や芸術制作の過程においても，機能とかテ
      ーマとかよりも，かたちが先行して選ばれるのではないかという
      ことも含んでいる．機能の分析や構造の選択の結果として，かた
      ちが決まるのではない．かたちが選ばれてそれから構造や機能と
      の調和が図られる方が，おもしろいものができるということを考
      えているのである．

建築や絵画のように「かたち」があるものとは違って，もともと「かたち」
がないソフトウェアに，そんな仮説を適用するのは無理な話だという声が
聞えてきそうだが，書かれたプログラムの「かたち」に興味を抱いてプロ
グラマ生活をスタートしたわたしには，建築家であるこの友人の主張が，
きわめて暗示的に響くのである．