どしろうと製作所:WebLog

どしろうと製作所のBlogバージョンです。
「どしろうと製作所」のHPの記載内容とはあまり関係無いです。
気が向いたときのみ更新します。
SEが読んでみる「クリストファー・アレグザンダーの思考の軌跡」その
書籍紹介として「クリストファー・アレグザンダーの思考の軌跡」について記載しました。

この書籍内容に関しては、IT系の開発や活動においても役立つ考え方が多数ありますので、特に気になった項目を中心にいくつか紹介しておきます。
そのい箸靴董屐峽舛旅臉に関するノート」の手法」というトピックに対して考えてみます。あわせて、要求から構造の考え方に対しても考察を入れております。

なお、ここで記載する「ノート」とはアレグザンダーの「形の合成に関するノート」という論文を意味しています。

今回の内容も、要求から構造を構築する際の考え方について言及しているため、ITの開発における要求分析から方式設計と呼ばれるような部分に置き換えて考えると面白いです。
コンテンツは以下。
・「ノート」の方針
・「ノート」の方法
・「ノート」の課題(書籍より)
・勝手な考察
・まとめ


■「ノート」の方針
さて、前回のトピックは「構造」に対する分析・綜合・枚挙でしたが、アレグザンダーはこの手法をさらに洗練させております。おさらい含めて順に紹介してみます。

デザインは「コンテキストと形の適合」を目的としております。
アレグザンダーは、まずはコンテキストが形に対して提示してくる要求条件を分析して、デザイナーにとって明白で個々の形を提示できるほど単純に分解する、という考え方を行いました。
要求における課題は、要求の数よりも要求同士の相互依存関係である、と記載されています。
その依存関係が無くなるほど小さく切り分ければよい、というものです。

さて、この方法は2つのポイントがあると思われます。「要求」における分析の実施。そして、小さくした要求は単純であり、デザイナーは形を簡単に導くことが出来る、というものです。


■「ノート」の方法
要求を上手に小さくすることで、簡単に形を導くことが出来るということですが、実際は以下のように進めております。

本の内容の写経となりますが、例として以下のような要求があります。
1.住戸へのプライベートな入口
2.効率の良い駐車スペース
3.安全な戸締り
4.緊急時の接近及び避難路の確保

これらは独立していればよいですが、相互に依存している要求がある場合には解決方法を見つけなければいけません。例えば、1と2は相互に依存というか対立しているような項目になります。片方が立つと片方が立たない。
この関係を要求の依存関係がある、としております。

アレグザンダーの「ノート」の方法は以下のようになります。
A) 要求の依存関係を表に整理する
要求関連

B) 依存関係をグラフ表記にする
グラフ理論1

C) グラフをより小さな(グラフ理論で使われる)グラフ構造に分割する
こちらは「分析」にあたる内容ですね。
グラフ理論2

この際、「情報理論的相関関係分析」で一意に決めるというコトですが、この謎の分析方法、ざっくりで説明すると…
・切断される辺の数が少ない
・切断される後に出来るグラフの辺の数の差が最も小さい
ようにする感じです。

これらによって以下のように分解します。こちらについては「分析・綜合・枚挙」の手法です。
ノートの方法

この分解した要求に対して形を作成して逆方向に綜合するという方法です。
分析・綜合・枚挙の考え方を法則的に決定した内容(形式操作の段階)となります。


■「ノート」の課題(書籍より)
見事に法則性を活用して整理された方法となりますが、2つの大きな問題がある…とされています。

1.(分解された)要求から形を導く方法が無い
ある程度小さくなった要求は形を導くことが出来るだろう…ということですが、この方法が無かったようです。機械的な法則で導かれた要求はいろいろなカタチになります。その形を生み出すことは難しいでしょう。
アレグザンダーはこの問題に対して、「パターンランゲージ」を用いた検討を行っております。

2.分析のツリーと綜合のツリーは同じ(対称的)ではないはず
「ノート」の方法では、要求を分解した構造がそのまま建築の構造1つ1つになります。
この分析した形をそのまま綜合して組合わせることが出来るのでしょうか?IT業界でこの手法を使ったとして、要求に対して対応する構造(例えばクラス)をそのまま結合することは難しいです。
こちらも、「ノート」では言及されていない内容であったため「都市はツリーではない」にて「セミラティス構造」の提案がされております。


■勝手な考察
さて、要求を分解する、小さく分解した要求を形に置き換える、その形を(同じようなツリーで?)綜合して組合わせる…という方法ですが、実際のIT系の開発でイメージすると「あれあれ?」という部分が有りそうです。

あれ?1.要求を分解した単位で形が出来る?
1つの形がいくつもの要求を満たすような場合があります。また複数の形で1つの要求を満たすことも有ります。また、「複数の問題を一気に解決することがアイデアだ(宮本茂氏)」といった言葉もあるように、1つ1つの問題をそれぞれの形で解決している訳でもありません。この関連性が難しい世界です。

あれ?2.構造も分解はするがツリー構造では無い
IT開発ではSWの構造はクラス図なりで(なんとか)表しています。…が、こちらの構造はネットワーク形式です。
一度構造が出来てしまえばツリー上に分解可能な部分が多くなり、考えやすいかもしれません。しかし、どちらかと言うと「セミラティス」な構造であれば説明がつくかもしれませんが、ツリーではありません。


以上の「あれあれ?」は、IT系だけではなく、建築業界においても同様な指摘が行われていたかもしれません。

この辺は「要求と構造の関係」によるものとも考えます。特に要求⇒方式設計(構造設計)と呼ばれる部分は「分析」の作業に対応するかもしれませんが建築の構造分解で紹介されたような「分解」的作業とは異なります。
実際にはドメインにあわせたフレームワーク、要求と構造をの間をTM(トレーサビリティマトリクス)で埋めるなど、プロセスや手法で対処しているはずです。
まだ決定的な手法は出来ていない部分であると思われますので、むしろ考える事が楽しい部分かもしれませんね。


■まとめ
色々議論すべき箇所も有りますが、実際には依存関係を明らかにしてグラフ理論で分割して考える方法はシステムの構造を考える際には有効ではないかとも考えます。

まとめてみます。
アレグザンダーの「ノート」の手法は「分析・綜合・枚挙」の方法を活用しつつ新しい方法を取り入れていました。
それは、
要求を整理して依存関係を明確にする。
グラフ理論を用いて分割する。
分割したサイズで形に置き換える。

…というもの。これは有効な手法にも見えますが、課題が多く考える事が多い状況でした。
アレグザンダー自身はさらに「セミラティス構造」や「パターンランゲージ」の手法を用いて課題に取り組んでいます。

さて、次回はパターンランゲージについて簡単に考えてみます。
| パターンランゲージ | 17:16 | comments(0) | - |









 123456
78910111213
14151617181920
21222324252627
28293031   
<< October 2018 >>
+ SELECTED ENTRIES
+ RECENT COMMENTS
+ CATEGORIES
+ ARCHIVES
+ LINKS
+ PROFILE
+ OTHERS
このページの先頭へ