[レビュー] 「高速道路計画におけるグラフィック・テクニックに関するスタディ」 4

ツール構造のグラフの作り方。

複雑な問題を要素に分解することで解きやすくなるということで、物事を要素に分けて考えましょうということです。複雑系科学1はまだ出てこないので、ずいぶん素直に要素分解していこうと言い切っています。

あるいは分解する理由として、このデザイン問題を解ける形に変形するとも行っています。例えば、最終的に得られたものが全部グレー一色だったら、なんでも言いわけで、そこから唯一一本通す理由になりません。なんでもいいんじゃんっていうのも一つの答えだけど、それだとプロセスというデザインの道具としては何をやってるのかわからなくなります。こうゆう何をやってるのか分からなくなって胸が痛くなるパターンというのはグレー一色だけではなく、確かに存在していて、例えば、東から西に線を弾きたいのに、縦の縞模様も困っちゃいます、これを避けられるようなプロセスがいいと。

あとは、全章の全てを一つの物差しに回収するのを避けるために、それぞれの段階での判断を使うしかないと行っています。とはいえ、判断するのに、一気に全ての要素は考えられないので、少しずつやっていくのが望ましいと、転じて自然にツリー構造になるのではと行っています。ただ、闇雲に小さく分割してやればいいかというとそうでもなく、できるだけ、干渉(conflict)が少ないようにやるべきだと述べています。いうまでもなく、プロセスの後半になるとそれはどんどん難しくなっていきます。ルービックキューブ解こうとするとわかるけど、最初の一面はそれ以外の依存関係がないから簡単だけど、後になっていくに従って、気にしないといけないから難しくなっていくし、一個合わせるための工数も増えますよね。藤村さんの超線形設計プロセスも実は同じで、線形にして簡単に見えますが、同じように後半戦はやっぱり難しいでしょうし、設計を繰り返していくうちに何を先に考えるべきかという経験は必要ですよね。2それが極力簡単にできる組み合わせをアレグザンダーは求めようとしています。

そのために、まず、26個の要素が、どのようにお互い干渉しあっているかを調べます。俗にいう隣接グラフなのですが、レポートでは超見辛い形で示されています。

そこからレンジでチンのごときツリー構造のダイアグラムがいきなりてくるわけです。

詳細はHIDECS23というプログラムをみよとのことで、レポートを別に書いています。それもMITに貯蔵されていたので、借りてみると、当時のプログラムなので、アセンブリ言語で書かれており、さすがに組み直すのは手に負えません。

で、アセンブリコードを再実装しても良かったんですが、ネットワーク科学の研究グループにいたクリスチャン4に話を聞いて、今だとこうゆうことするのに何を見たらいいだろうという相談をしました。ウェイトがかかっていない、無方向グラフならモジュラリティ係数が一番近いかなとアドバイスを受けました。ありがとうクリスチャン。モジュラリティ係数というのは結局ネットワーク内のコミュニティを計算するために使われるそうで、この場合、諸要求項同士の関係性を計算したいので、合致すると。その中で Louvian modularityとかInfomapが早いよとも教えてくれた。ありがとうクリスチャン。

で、アレグザンダーに戻ると、高速道路のスタディでやっていることを一般化すると、

条件がノード、それら条件の関連をエッジとしてネットワークがあったときに、それをどのようにクラスタリング(グループ分け)するのが一番自然か計算する。

ということです。ここで、自然とあえて、定義しづらい言葉を使ったのはやっぱりクリスチャンに聞いた話で、何を持って自然とするかによって、使うアルゴリズムが違うからのようです。

だから、アレグザンダーはこのスタディの要点はただただ条件要素を集めて適応地形を作ろうぜと言っただけではなく、考えやすいようにグルーピングしようぜと言っていたわけですね。グルーピングして、小分けにすれば、検証する順番ができるので、どの問題から考えるかプロセスを示すという、プロセスの中でのサブプロセスがあるよと言っているように僕には解釈できました。


  1. 英語のwikiによると、複雑系科学が、盛んになったのは、大体1970年代で明示的に研究され始めたのは1984年みたいです。ちなみに、「世の中そんなに単純で甘くないぜ」とこれの社会計画論で示唆したのがwicked problemは1973年にジョージ・チャーチから。この手の研究がいまだに、1962年の取組を超えられないのは、主に、こういった、もう世の中複雑すぎてもう全然手に追えないよ、もう詰んだ見たいな言われ方をされちゃったからとも思ったりします。とはいえ、今日のディープラーニングだって、超複雑に見えて、我々手に追えないけど、最終的にはハイパーパラメータに回収させてるわけだし、結局何よと言われれば、重みづけのベクターでしかないのですから、これを要素分解でないかと言われたちょっと考えさせられますよね。 [return]
  2. 例えば、(建物の大きさをざっくり知る過程である)ボリュームスタディをした後に部屋数や面積表が変わったりすると困るわけで、それらは順序もあるし、できれば近いスケールの話なので一緒に考えたいわけです。逆に、家具やドアのぶ見たいのは関係が遠いので、一緒に考えてもいいし、順序もあまり気にしなくていいかもしれません。あるいは、ディテール集や特記はプロジェクトではなく、事務所ごとに決まっているかもしれませんし。 [return]
  3. このHIDECS2ですが、アレグザンダーの博論『形の合成に関するノート』になると、 HIDECS3になっていて、2で計算できなかったエッジケースを4つのプログラムを通して解決しようとしています。僭越ながらいうと、バグってて安定してなかったんですね。 [return]
  4. スモールワールドネットワークのバルバシの弟子(Cesar Hidalgo)のお弟子さんで、僕のこうゆうネットワーク系で聞きたい時のホットラインです。クレジットしておきたく。 [return]