• About

    設計プロセスを可視化して、新たな価値を見つけ出すお手伝いをします。

    私たちが目にする世の中の有形無形の現象や仕組みの中には様々な法則が隠されています。これらの法則を私たちが理解できるように記述することをモデリングと言います。
     

    設計プロセスを記述するモデリング手法である体系的RDCモデルは設計者の合理的な意思決定の流れを記録する方法論として考案され研究されてきました。
    この方法論は設計の要件、設計定義、および検証内容とその関連を記述することにより設計プロセスを記録し可視化します。

    一見、簡単そうですが、例えば、比較的シンプルな自動車の構成部品でも、その設計プロセスには数百の構成要素が存在し、互いに関連し合う複雑なネットワーク構造になっています。このようなプロセスを紙の上にフローチャートのような平面的な書式で書き出すことはできません。

    この記述の難しさから、設計作業と結果としての設計図面を残すことはできても、その過程がどのようなものであったのかを記録し利用する試みは行われてきませんでした。

    当社では、上述の体系的RDCモデルの考え方を用いて、実際の設計現場において設計を進める中で動的に設計プロセスを記録し、私たちが活用可能な書式で表すことのできるソフトウェアの開発を続けてまいりましたが、3年の開発期間を経て、ようやく最初のバージョンが提供できる準備が整いました。
     

    このソフトウェアを利用することにより設計プロセスの記録と検証への道が開けるとともに、曖昧になりがちな上流設計の品質の向上、より良い設計プロセスの追求と標準化、優れた設計プロセスのアーカイブ化と再利用、さらには属人的になりがちな設計プロセスをオープンでコラボレーティ、高効率な協調プロセスへと変化させることができるようになります。

     

    このホームページの最後には、弊社で行った検証プロジェクトの結果も紹介しておりますので、ぜひご覧ください。

  • 設計プロセスの課題と解決方法

    設計プロセスの課題

    設計は設計者の知識や経験を元にした多くの推論の集合ですが、限られた情報や時間という制約の中で行われるために、仮定や想定といった不確定な意思決定が入り込みます。​

    提案

    設計プロセスを設計を進める中で動的に記録し公開します。これは設計者の頭の中にある思考過程を公開状態にすることです。この思考過程の記録と公開により設計者自身の推敲と他の設計者によるレビューを効果的に行うことができるようになり、不確定要素が取り除かれ、設計の品質を高まります。

    また、記録され不純物の取り除かれた設計過程を標準過程として整備しておけば、時間と場所を超えて後に続く設計活動に活用することができます。

    方法

    設計プロセスを体系的RDCモデルに沿ってソフトウェアの記録画面上に時系列に記録します。

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

     

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

     

    ニーズを探す

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

     

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

     

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

     

    ニーズの検証

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

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

     

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

     

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

     

    アイデアを出す

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

     

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

     

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

     

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

     

    アイデアを検証する

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

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

     

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

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

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

     

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

     

    ターゲットの設定

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

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

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

     

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

     

    デザインの決定

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

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

     

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

     

    まとめ

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

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

     

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

  • ソフトウェア

    設計プロセスを構成する要素はお互いに関連を持っています。膨大な数の設計要素とその関連を記録するためには専用のソフトウェアが必要不可欠です。

    弊社では設計プロセスを構成する要素とその関連を記録する専用のソフトウェアを開発しています。このソフトウェアを使用することにより、設計者は設計作業の流れの中で設計プロセスを関連を持たせながら動的に記録し、設計者自身による推敲と他の設計者との共有やレビューに役立てることができるようになります。

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

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

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

  • ソフトウェアの効果

    このソフトウェアが提供する設計の体系的な考察とプロセスの共有環境は設計のエラーを減少させ、設計作業の手戻りを防ぎます。

    弊社ではこのソフトウェアが利用可能になった2017年半ばより、本ソフトウェアを離れた場所で作業する設計者とソフトウェアエンジニアの間の設計検討とコニュニケーションツールとして利用しています。

    下の統計は他社製の自由書式の非体系的コミュニケーションツールを利用していた段階と、本ソフトウェアの利用を開始した後の、ソフトウェア開発計画工数に対して実際の発生した手戻りへの対応を含む超過工数を表しています。

     

    この統計からもこのソフトウェアの利用が検討とコニュニケーションの精度を上げ、設計品質の向上と手戻りの防止に役立ったことがお分かりいただけると思います。

  • サービス

    設計プロセス記録ソフトウェアを応用したオープンデザイン支援サービスをクラウド上で展開中です。

  • コンタクト

    ソフトウェアとサービスについてのご質問、お問い合わせをお待ちしています。