設計をするときは要件、課題、解決策の順番で考える

『建築の設計力』という本の内容を元に考えた、設計をするときの思考プロセスについてのメモです。

設計をするときは要件、課題、解決策の順番で考える

設計をする時は、要件をもとにまず課題を設定し、それから解決策を考える 進め方が望ましいです。

f:id:smatsuzaki:20210223104415p:plain — fig.1 設計のプロセス

要件が与えられると、すぐに解決策の検討を始めたくなります。そこでぐっとこらえて、課題の整理にまず着手することが大事です。ここで整理される課題のことを「設計観点」と呼びます。

f:id:smatsuzaki:20210223105007p:plain — fig.2 設計のプロセス(実務よりのイメージ1)

「課題」と「解決策」の関係を事後的にチェックできるよう、設計時の検討事項をドキュメント化しましょう。1つの設計ドキュメント内で「課題」と「解決策」が併記されている状態が望ましいです。

※「解決策」の実装に集中していると、意識が次第に「課題」から離れていき最終的に何を実現したかったのか？が曖昧になっていきがちです。それを防ぐために課題を明文化しましょう。「解決策が課題の要請を満たしているのか？」という観点で試験を実施する際も、課題が明文化されていると試験観点の抽出がスムーズです。

実際は課題をサブ課題に分割することが多い

fig.2 では「課題設定」の箇所を簡略化して書きましたが、実際には複数の課題を親子関係に分割/グルーピングして検討することが多いです。(fig. 3) [1] 多くの場合こうやって課題をグルーピングしていくと、ある一定のスコープを持つ設計領域が浮かび上がってきます。 e.g. Fault-tolerant設計, 収容＆スケーラビリティ設計 etc..