体系的RDCモデルによる設計プロセスの書き出し例を具体的な事例を使って説明します。

この事例での設計目標は、「冬場の寒冷地でも外部エネルギーなしでも凍結しない家を設計する」こととします。

設計を開始するにあたって、設計者は設計対象が満たさなければいけないありとあらゆる条件を見つけなければなりません。例えば、顧客の明示的な要求はその最たるものですが、顧客自身が気が付いていない要求もあります。また、設計対象物が使用される場所の環境条件や製造や利用、保守に係る法規制なども重要な要求です。

設計者の外側に源があるこれらの要求をニーズと呼ぶことにします。ニーズは設計者が設定することはできませんが、商品の対象セグメントから外すなどの方法により選択したり、選択しなかったりすることはできます。

設計者は、「冬場に凍結しない家」の設計を依頼した顧客から家の利用者の情報や予算など条件とともに、冬場の最低気温が-20℃であるとの情報を得るかもしれません。これらは典型的なニーズです。

ニーズにはそのニーズが確かに存在し、その内容が正しいことをテストする必要性が生じる場合があります。

ニーズは以降の設計の前提となりますので慎重な検証が必要です。設計者の立場からすると顧客や営業部門、生産部門など直接アプローチが難しい情報源から提供されることが多く、そのまま受け入れてしまう傾向があるかもしれませんが、この時点でのニーズの理解が甘いと、最終的に設計された商品やサービスが市場に投入された際に危機的な状況を招く可能性があります。

例えば、家の建設場所の最低気温が-20℃であるというニーズが顧客から提供されたとしても、設計者はその情報をそのまま鵜呑みにするのではなく、過去の気象データを調査し、その値の確からしさを検証する必要があるでしょう。

下のデータは建設予定地の過去10年間の気温データです。このデータから最低気温は-18℃であったことがわかりますので、-20℃というニーズの確からしさが検証できたことになります。

設計目標やニーズが明らかになると、ニーズを満たし設計目標を実現できそうなアイデアを出すことができます。このプロセスは合理的に説明をすることが難しい直感的なヒラメキによっています。設計者は過去の経験や知識に基づいた様々なアイデアの元を引き出しの中に持っており、その引き出しからニーズという制約下で設計目標の具体的な実現手段となる可能性のある方策を取り出すものと考えられます。

一人の設計者が持っている知識や経験には限りがありますので、アイデアを出す設計者の数を増やせば増やすほど数多くのアイデアを得ることができます。

アイデアが出された段階でそのアイデアに係わる新たなニーズが必要になる場合があります。

この例では地熱で家を温めるというアイデアが出されましたが、ここまでに地熱に関する環境条件がニーズとして調査されていませんでしたので、このデータをニーズとして追加する必要があります。

アイデアが設計目標の実現手段として有効であるかどうかの判断には検証が必要な場合があります。アイデアがニーズを満たし設計目標の実現手段として有効かどうかを確かめるのがアイデアのテストです。

検証を経て有効性が確かめられたアイデアはコンセプト（設計構想）になります。

ここでは、数値計算モデルを作成して室内外の熱収支を計算することにします。

アイデアのテストには文献の調査、他の設計者によるレビューといった定性的なものから、理論式に基づいた計算、コンピュータ上のシミュレーション、実験などの定量的な方法まで様々な方法があります。

昨今では数値計算モデルを作成してコンピュータシミュレーションを行うモデルベース開発の手法も発展してきており、そこで用いられたアイデアの成立条件となる係数などの設定値はそのまま設計対象の特性目標値として扱うことができます。

熱収支の計算モデルを用いたシミュレーションを行った結果、冬場の最低気温の時でも適切な熱交換を行えば室温が0℃を下回らないことが確認でき、このアイデアは成立することが確かめられました。

ターゲットは設計者が設定することのできる設計対象の特性目標です。ターゲットはなるべく定量的であることが望ましいのですが、定性的な特性目標もターゲットになります。

モデルベース開発の手法においてアイデアのモデル化の過程で設計者が設定する係数もターゲットの部分を構成します。

多くの設計現場では’設計仕様’という言葉が一般的に使われていますが、設計仕様の構成情報の大部分はターゲットかもしれません。しかしながら、設計仕様という言葉は製造部門への指示的な意味合いであったり、製品の組立メーカーが構成部品のメーカーに対して伝達するあらゆる要求事項を指すこともあり、厳密にはターゲットと一致しません。

シミュレーションモデルの成立条件として用いた熱交換係数や空気循環量は設計パラメータの目標性能値として用いることができます。

定量的、定性的なターゲットを実現する具体的なパラメータがデザインです。デザインはターゲットという目標値に従ったコンセプトの厳密化であるとも言えます。

他の設計プロセスの構成要素と同様にデザインもターゲットを満たしているかどうかの検証が必要な場合があり、それをデザインのテストと言います。

デザインではターゲットで設定された熱交換係数を満たす壁の構造、材質、板厚、空気循環量を満たすファンサイズや回転数などを採用する意思決定を行い、決定内容を図面などの書式に記録します。

ここまで解説してきた設計プロセスの構成要素を以下にまとめました。全体を眺めて、どのような要素によって設計プロセスが構成されているのか理解を深めてください。

ここでは、ニーズ→アイデア→ターゲット→デザインという順で説明してきましたが、設計は設計者の頭の中で行われる作業のため、設計者が暗黙的に段階を踏んで一足飛びにデザインが導き出されることもあります。このような場合でもその暗黙的なデザインの前提となった他の要素もきちんと書き出すことにより、設計の不確実性を低減し設計品質を高めることができるようになります。

ここでは考え方が理解し易いように簡素化した事例で説明していますが、実際の設計プロセスではこのような関連を持ったプロセスが複層的に進行します。

設計者はソフトウェアのユーザーインターフェース上で設計要素を書き出しながら設計検討を進めることができます。

書き出された内容は設計者自身の推敲に用いられると共に、他の設計者へ公開することにより協調設計環境を構築し様々なアドバイスや支援の交換を行うことが可能になります。

このソフトウェアはLinuxサーバー上で稼働するように開発されており、UbuntuやRed HatといったディストリビューションのLinux OSが稼働しているサーバーに移植しオンプレミス環境で利用することができます。