Column コラム

製品や装置開発における構想設計というプロセス。開発において非常に重要なポイントとして位置付けされますが、改めてその理由について確認してみましょう。この記事では開発ステップにおける構想設計の位置づけと、必要となる視点やフレームワーク、そして著者が体験した具体的な事例について紹介します。

そもそも構想設計とは？

構想設計は「概念設計」とも呼ばれ、製品のコンセプトを方向づける工程です。市場調査・競合分析などのデータから、機械の目的・使用者のターゲット・目標スペック・予算・開発期間・実現可能性・使用環境などについて、関係部署と議論を交わし共有化します。どのようなターゲットを設定するのか、ターゲットに見合ったサイズ・機能・デザインはどのようなものか、価格設定はいくらか、新技術を取り入れる場合その実現性は高いか、などを検討していきます。

検討した内容は「企画書」や「要求仕様書」といった資料として残し、関係部署・外注先との認識にズレが生じないようにします。
「大きすぎず、小さすぎず、ちょうどいいサイズ」「キビキビと走る」など、ここで決めたコンセプトがそのままその製品を象徴する特徴となります。

構想設計は設計部署にとって一番最初に行う重要な工程ですが、マーケティングや財務、過去の設計知見や他部署・外注先との交渉力といった複雑で高度なスキルが必要となるため、幅広い知識と経験を持ったベテラン技術者が担当することが多いです。

開発ステップにおける構想設計とDR（デザインレビュー）では、開発ステップにおける構想設計の位置づけとDRの重要性について解説します。

開発ステップ

一般的な開発ステップとしては以下の手順が主流です。

1.企画

市場ニーズの把握、競合他社の状況や特許の有無分析などを行い、商品のコンセプトを決めます。大まかなデザインや目標とする性能・有する機能・販売価格・投資額などを明らかにします。

2.構想設計

構想設計は企画の次に行います。企画した製品コンセプトに基づき、製品のコンセプトを方向づける工程であり、QCD（品質・コスト・納期）の8割が決定されるとまで言われる重要な工程です。

3.基本設計

構想設計をより具体的なイメージへと固めていく工程です。求められる機能を満たす部品のサイズ、質量はいくらなのか、コストは予算内に収まるかなど、工学的・数値的根拠で確認します。

4.詳細設計

製品を構成するすべての部品の仕様を確定させ、図面に落とし込んで後工程に渡す工程です。後工程や関連部署・外注先が迷わないよう公差や条件など詳細な情報を確定するため、繊細なチェックが必要となります。

企業や組織によって変わりますが、おおむね設計部の担当は上記の2～4をメインに担当します。そのため、設計部の一番最初となる重要なステップが構想設計です。

従来の開発プロセスでは実際に製品ができたから検討をしていたため、例えば部品の干渉や機能不足などの問題が発覚した場合、前工程に遡って確認や検証が必要となり、手戻りや修正に膨大な工数がかかりました。後工程に進めば進むほど問題発生時の工数が大きくなることから、そのようなやり方を「バックローディング」と言います。

一方で、製品ができる前の段階で課題を潰し込み、後工程の負担を軽減する「フロントローディング」という設計手法が現代では主流となっています。これが、「QCD（品質・コスト・納期）の8割が企画・構想段階で決まる」とも言われる所以なのです。

DR（デザインレビュー）の重要性

上記2～4の開発ステップを進める上で重要になるのが「DR（デザインレビュー）」です。各段階を終え、次のステップへ進む前に関係者を集めて本当に問題がないかを確認し、審査する重要なプロセスです。さまざまな立場の人たちから意見を募り、抜け・漏れがないよう議論し、修正があれば即座に対応します。手戻り修正は気の重くなる作業ですが、当該のステップで改めておかなければ、後工程に課題を先延ばしすることになり、前述の「バックローディング」型設計になってしまいます。

部品ごとにおける小DRなど、組織や開発製品に沿ったDRのスタイルを模索しましょう。

構想設計に必要な視点とフレームワークとは？

構想設計を進めるには使用目的を明確にし、設計書（仕様書）に落とし込む必要があります。では、設計書に必要な視点とはどのようなものでしょうか？ここでは3つの視点について紹介します。

6W2HとQCD

6W2Hとは（Why、Who、Whom、Where、What、When、How、How much）の頭文字を取った用語で、それぞれの言葉に沿った回答をすることで目指すべき仕様を明確化するフレームワークです。この内「Why、Who、Whom、Where、What、How」の6つが製品のQ（品質）、「How much」がC（コスト）、そして「When」がD（納期）に深く関わる項目となるため、それぞれにおいてしっかりと定義を言語化し、共有する必要があります。

3C分析

商品力を高めるには他社との差別化が必要です。差別化を目指すプロセスにおいて有用なのが「3C分析」。Customer（市場・顧客）、Competitor（競合）、Company（自社）の頭文字を取った用語で、市場にあるニーズや将来性、競合他社の持つシェアと技術力、そして自社の持つ技術、課題点などをそれぞれの視点で客観的に把握していきます。

このときStrength（強み）、Weakness（弱み）、Opportunity（機会）、Threat（脅威）の頭文字を取ったSWOT分析手法を合わせて用いても効果的です。

FMEA／FTA解析を使った課題の洗い出し

FMEAとは「Failure Mode and Effect Analysis（故障モード影響解析）」の略称で、製品または部品が不具合を発生した際の発生率・検出率・影響度を評価する手法です。部品・材料の故障モードを列挙し想定外の問題を洗い出すボトムアップ式手法のため、新規設計となる要素が多い場合に向いています。

一方、FTAは「Fault Tree Analysis（故障の木解析）」の略称で、問題発生のトップ事象から発生経路を辿り、関連部分の把握と対策を講じることのできるトップダウン式手法です。望ましくない事象をトップに原因を深堀りしていくため、既知の製品や故障、あるいは流用度の高い製品の解析に向いています。

構想設計における成功体験と失敗体験

ここでは、実際に筆者が構想設計で経験した成功と失敗の事例を紹介します。

曖昧な指示による失敗体験

とある製品のマイナーチェンジを担当した際、製品の一部品について材料を変更することになりました。変更に当たっては、客先へ材料変更の申請や評価結果報告書など多くの書類作成が伴い、それは他部署が用意することになっていました。
しかし、以前に作成した経験とデータがあることから、事前の打合せではお互いに「前と同様に」との曖昧な意思疎通に終わりました。

数週間後、その資料の進捗を確認すると全く仕上がっていないことが分かりました。原因を探ると、どうやら以前の資料を作成した担当者は別部署に異動しており、引継ぎは行っていたものの、新しい担当者は書類の重要性や業務フローをしっかりと掴んでいなかったのです。

不安要素の事前確認による成功体験

製品内に印字される幅2mm程度の小さな2Dコードを読み取るシステムの構築を担当した際のこと。以前、3mm角のコードを読み取ることのできたカメラ・レンズを使用すればできる見込みはありましたが、実績はありませんでした。そこでカメラメーカーの営業を呼び、実製品での確認を行いました。すると、読み取り不可の製品が一部存在することが発覚しました。

結果的にはカメラの機能不足ではなく、製品側の印字不具合だったのですが、このことで読み取りエラー時があってもそれはシステム側の問題でない可能性もあること、そして製品側の印字品質について製造部と改善策を話し合うことができました。

どちらの事例も6W2Hの視点が非常に重要です。
失敗例では「誰が、何を、どのように、いつまでに」を確認していれば防ぐことができました。
一方、成功例では「なぜ、確認するのか？」という視点をしっかり持つことであらかじめエラーモードを特定することができました。

製品開発の実務上では厳しい納期のプレッシャーがあるため、どうしても意識が薄くなってしまうものです。人の意識のみに頼らず、フレームワークなどを用いて効果的にミスを防止していくことが求められます。

まとめ

製品開発ステップにおいて、「QCD（品質・コスト・納期）の8割が企画・構想段階で決まる」とも言われるほどに重要な構想設計。失敗事例にも記載したように、慣れてきたときこそ、基本に立ち返ることも必要です。本記事を通し、日頃の業務の重要さを再認識するのみならず、新たな視点・フレームワークを活用し、より良い製品開発を目指していただきたいと思います。

執筆者プロフィール
Kamijo
10年以上「ものづくり」に携わってきた機械設計エンジニア。ものづくり・機械設計・生産技術・哲学・歴史・経済が得意な分野。