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

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

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

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

fig.1 設計のプロセス

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

fig.2 設計のプロセス(実務よりのイメージ1)

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

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

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

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

fig.3 設計のプロセス(実務よりのイメージ2)

解決策を実装後は必ずテストする

解決策を実装後は、机上ではなく実際の振る舞い(システムの実動作)で、解決策が課題を満たすことをチェックしましょう。手間はかかりますが、机上検討時には予想もしていなかった有益な知見が得られます。

fig.4 実装した解決策の試験時の観点の考え方

脚注

[1] 設計観点表などでは、これをスプレッドシートに落とし込み管理をする。課題管理表等で扱う場合も「カテゴリ」等の仕組みでグルーピングをすることが望ましい。似ている複数の似ている課題を、同時並行的に検討することが可能になるため。