「超線形プロセス」あるいはプロトタイプモデル建築設計
「超線形プロセス」は当初の要求定義を具体化するだけのプロセスにはならないのだろうか？レグレッションは？
by goh_minakawa6 fav 2178 view
まとめ
メニューを開く-
.@ryuji_fujimura 今日はレクチャー＆講評ありがとうございました。レグレッションについては以前から疑問だったので、一度お話を伺いたいと思っていました。ある意味、近くて遠かった藤村さんと僅かながらお話しできて嬉しかったです。 -
超線形プロセスはソフトウェア開発のプロトタイプモデルを建築設計に移し替えたものだと理解しているのだけど、この手法の最大の利点は①実際の挙動を事前確認できる②（専門的知識の有無に拘わらず）ステークホルダーと協議しやすい、ということ。 http://bit.ly/beWFgb
-
建築設計の場合、いまのところ施工後の空間を設計時点で再現する①は不可能なので（物理演算するアプリやARで視覚的な要素は類推可能 http://bit.ly/vknCY）、主要なメリットは②だろう。これは大規模な建築物で特に大きなメリットになる。（建築は「取り返しが付かない」から）
-
超線形プロセスへの最も大きな疑問は、設計が最初に決めた要求定義を具体化していくプロセスにしかなり得ないことだ。もしそうであるならば、既知の辞書から建築を作り出していくことしかできず、結果としてクオートの集合にしかなり得ない。つまり、技術や概念の拡張は見込めない。
-
（この部分に関しては建築設計者が最先端の工学を扱わなくなって久しい、との反論があるのかも知れません）
-
また、「設計＝最初に決めた要求定義を具体化する」というスタンスは超線形プロセスの「後戻りしない」「枝分かれしない」にも通じているけれど、設計途中で価値（建材の単価や用途）の変化が起きない前提のもとに成立している。でも、そんなことばかりでは無いのでは。
-
もう一つの疑問はレグレッション（退行）について。http://bit.ly/d6KvlP これも開発のタームだけど、梁で頭を打つから階段を動かしたらトイレの収まりがつかなくなった、というような、ある問題を修正したら他の問題が起こることだ。建築関係者は何度となく経験しているでしょう
-
このレグレッションがbuildingKのチャートを見る限り起きていない（確実に１ステップずつ要件を回収して退行がない）。質問時には、小さなレグレッションがあるとの回答をいただいたけど、それでは「後戻りしない」の原則とどう折り合いをつけるのだろうか。
-
たぶん最初に要求定義は決めないと思います。具体化していくプロセスというより統合していくプロセスでは。途中の変化も受け入れていくと思います。例えばビルディングKでは最後、住民の意見かなにかで高さを抑えたりしていたはず。RT @goh_minakawa: -
僕はそのような後発の要求に対して超線形プロセスは脆弱性を持っていると考えています。はじめに決定した21個の要件を（他のオプションを作らず）目指していたのに、突然ひっくり返されるようなものなのですから。 QT @orihihs0y: たぶん最初に要求定義は決めないと思います
-
あのチャートは後でつくっているはずです。RT @goh_minakawa: このレグレッションがbuildingKのチャートを見る限り起きていない（確実に１ステップずつ要件を回収して退行がない）。質問時には、小さなレグレッションがあるとの回答をいただいたけど、それでは「後戻りしな
-
だとすれば、何を基準に「後戻りしない」と評価するのでしょうか。「前に進む」という時点で既にクライテリアを持ち込んでいるはずなのです。 QT @orihihs0y: あのチャートは後でつくっているはずです。
-
何か噛み合わない返事をしてしまったので… ①超線形プロセスでは最初に評価基準となりうるもの（＝要求）を定義している（そうでなければ前後は語れない）。②そして、後発の要求に応じようとするときには、積み重ねてきたものがスポイルされる可能性を回避できていない。
-
見てくださっているのか分からないけれど、@ryuji_fujimura さんからの返事を待つとしよう。とにかく今日はもう寝なければ…
-
あと戻りはするんですよ。その後戻りというのは全部なしにしてはじめからはやめましょうという感じだと思います。RT @goh_minakawa: だとすれば、何を基準に「後戻りしない」と評価するのでしょうか。「前に進む」という時点で既にクライテリアを持ち込んでいるはずなのです。
-
@goh_minakawa 僕は超線系のいい悪いや実際の有効性などはわかりませんというかまだきちんと判断できませんが、模型をログとして保存して、コミにケーションをはかるところなど、そこで起こっている効果みたいなものに注目しとります。実際課題としてやったので、教育プロセスとしても。
-
質問ありがとう。 RT @goh_minakawa .@ryuji_fujimura 今日はレクチャー＆講評ありがとうございました。レグレッションについては以前から疑問だったので、一度お話を伺いたいと思っていました。ある意味、近くて遠かった藤村さんと僅かながらお話しできて嬉し -
@goh_minakawa レグレッションと「後戻りしない」をどう折り合いつけるのか、という質問はよい質問ですね（答えがないのが残念）。 ところで、「要求定義」というのもまた聞きなれないイディオムですが！？ http://togetter.com/li/15054 -
.@hkohno_abbr 遅くなりましたが、コメントありがとうございます。「超線形プロセス」の『後戻りをしない』とレグレッションが相反するとの指摘は、教条的な設計プロセス論への批判を含んでいます。「条件設定」というタームは初めて見ましたが、要求定義と同等の意味だと思います。
-
設計プロセス論は教条として思考を制約するような使い方をするのではなく、純粋にチームやクライアントとの協議の道具に使えば良いはずだ。「超線形プロセス」を用いた講義では『考えるな』が1つのルールだそうだが、プロトコルの盲信を教育するのは極めて危険だと思う。
-
これは了解です（初等トレーニングとして「まぁ、がんばってください」程度のものですね） RT @goh_minakawa 「超線形プロセス」の『後戻りをしない』とレグレッションが相反するとの指摘は、教条的な設計プロセス論への批判を含んでいます。
-
.@hkohno_abbr 「要求定義」はシステム開発プロセスを囓った時に知った言葉でした。建築でも同等の言葉があるのは知りませんでしたが、PM系のタームでしょうか。衒学的な言葉遣いをする気は毛頭ありませんが、ご指摘ありがとうございました。http://bit.ly/sk6qn
-
.@goh_minakawa なるほど。でもシステム開発では普通に使われるのか。requirement ~~なんと言うのだろう？「条件設定（分析）」は、PMでなくても設計監理の実務一般で使われますよ。デザインのスタートのときとか契約のときにも。
-
.@goh_minakawa ex) Design Condition, Condition Analysis....それから、「もはや必ずしも設計条件（の設定・分析）からデザインをスタートしない」というように、反語的にも使われる（これは80年代後半くらいから）。
-
なるほど、分かりきったことからしか設計できなくなるからですね。＝クオートの集合になる危険性。 QT @hkohno_abbr 「もはや必ずしも設計条件（の設定・分析）からデザインをスタートしない」というように、反語的にも使われる（これは80年代後半くらいから）。
-
Content from Twitter
コメント