製品開発

事例Ⅲの与件文で、新製品の企画という言葉が出てきた瞬間に、ちょっと身構えてしまうことってありませんか。

その答案、本当に多いんです。1次で学んだ知識は誰でも持っている。でも二次で問われるのは、この会社は開発のどこが詰まっているのかを与件文から特定する力なんですよ。

今日はそこだけに絞りましょう。事例Ⅲでいう製品開発は、企画から設計、試作、生産の立ち上げまでの一連のプロセスと、それを支える社内の体制。この二つのセットです。

この二つに分けられるかどうかが、実は解答の骨格を決めます。まずは、この論点が二次でどう出るかから見ていきましょう。

大きく二つの型があります。一つ目は、強みを生かして新しい提案をさせる型。設計提案力や技術力、小ロット対応力といった強みが書かれていて、受注生産中心の今のやり方から、自社製品の企画開発や提案型営業への転換を助言させる問題です。

逆に、開発体制そのものに課題がある型です。専任部署がなく開発が属人的、あるいは片手間になっている。営業部門と設計部門の情報共有が弱い。そういう弱みを指摘させて、体制構築や情報連携の仕組み化を助言させる問題ですね。

そうなんです。どちらもあり得るからこそ、与件文の記述がどちらの型かを最初に見極める必要があります。

典型的な失点パターンです。では、与件文のどこを見ればこの論点だと気づけるのか、着眼点にいきましょう。

一つ目は、顧客からの要望やクレーム、改善要求が、営業担当や現場に個別に届いているという書き方。これは顧客ニーズの情報源が社内にあるという合図です。

多いんですが、個別に届いているという表現が肝です。届いてはいるけれど、まとまっていない。そこに伸びしろがあるんですよ。

二つ目は、新製品や自社ブランド製品の企画開発に関する記述。すでに着手しているのか、検討中か、まだ構想段階か。この温度差も読み取ってください。三つ目は、開発を特定の技術者や設計担当者が兼任、片手間でやっているという記述。体制が弱いというサインそのものです。

出題者はそこを狙っています。四つ目は、営業部門と設計・製造部門の情報のやり取りが少ない、会議体がないという記述。五つ目は、試作やサンプル出しで手戻りや修正が多いという記述で、これは設計段階の検討不足のサインです。

違います。上流の設計に原因があると読んでください。六つ目が、展示会への出展や、取引先からの技術評価・引き合いに関する記述。市場性を確かめる機会が手元にある、というプラスの材料です。

だから、拾ったあとの整理の型を決めておくんです。製品開発は、企画、設計、試作、生産立ち上げ、販売という時系列で進む活動です。関連記述を、どの段階の情報かに仕分けていきます。

料理で考えましょう。家で好評だった料理を、毎週の定番メニューにしたいとします。家族が何を食べたいかをどこで拾っているか。作り方を決めるとき、材料が近所で買えるか、鍋ひとつで作れるかまで考えているか。そして実際に作って、毎回味がぶれないか。全部別の話です。

そのとおりで、本番で見分けるのもそこです。企画段階の情報は、どこから顧客ニーズを拾っているか。営業現場か、クレームか、市場調査か、取引先からの相談か。設計段階の情報は、設計を担うのは誰か、そして生産のしやすさ、作りやすさまで考慮して設計されているか。

次に試作・生産立ち上げ段階の情報。試作から量産への移行がスムーズか、手戻りが起きていないか。最後に体制面の情報で、専任の担当や部署があるか、定例会議や情報共有の仕組みといった部門間連携の仕組みがあるか。

プロセス全体を横から支える軸だと思ってください。この仕分けで、どの段階に課題があるのか、逆にどの段階の強みを伸ばすべきかが見えてきます。

決まります。解答の基本形は、体制面とプロセス面の両方から助言を組み立てることです。

体制面はこうです。専任部署やプロジェクトチームを設置して、属人的・片手間な状態から組織的な取り組みに変える。そのうえで、営業・設計・製造が部門を横断して情報を共有する定例の場を設ける。

そこがつながると強いです。プロセス面は、顧客ニーズを収集する窓口を明確にして、そのニーズを設計に確実に反映する。さらに設計段階から生産のしやすさ、作りやすい構造や共通部品の活用を考慮して、試作段階での手戻りを減らす。

そうです。食べたい料理がそれぞれ別々に伝わって誰も把握していなければ、献立は決められません。ニーズを一か所に集める仕組みが要るんです。

新製品の投入スピードが上がる、顧客満足度が高まる、受注生産中心の事業構造から高付加価値な自社製品への展開が進む。この方向でまとめると収まります。

体制面の施策とプロセス面の施策をそれぞれ簡潔に述べて、最後に効果を一文で締める。これが基本の型です。効果を書き忘れて施策の羅列で終わる答案が多いので、最後の一文の枠は先に確保しておくといいですよ。

多いんです。字数に余裕があれば、日程計画やマイルストーンの設定、開発の進捗情報を一元管理して共有する仕組みも、体制面の引き出しになります。

では最後に、混同しやすいポイントを三つ。ここを外すと、丁寧に書いても点が伸びません。

研究開発との混同です。研究開発は新しい技術や要素そのものを生み出す活動を指すことが多い。製品開発は、既存技術や保有技術を組み合わせて、顧客に売れる製品に落とし込むプロセスです。

ほとんどが後者、保有技術を生かした製品化のプロセスです。新技術の研究に投資すべきだと書くと、聞かれていないことを答えることになります。

強みは生かす対象であって、増やす対象ではないことが多いんです。二つ目は、事例Ⅱの共同開発との混同ですね。

共同開発は、自社だけでは投資負担やノウハウが不足する場合に、外部の取引先や研究機関と連携して開発リスクを分散する話です。視点は、誰と組むかにあります。

それに対して事例Ⅲの製品開発の視点は、自社の中で企画から生産立ち上げまでの流れをどう整えるか。体制とプロセスの整備が中心で、視点は内側です。

設問文で見極めます。体制やプロセスの改善を聞いているのか、外部連携の活用を聞いているのか。設問の言葉に手がかりがあるので、与件文に飛びつく前に設問を読み切ってください。

VA・VEとの混同です。設計段階でのコストダウンや機能向上を検討する考え方で、製品の価値を機能とコストの関係で捉え直す視点ですね。

重なります。ただしVA・VEは、製品開発プロセス全体の中の設計段階で使われる一つの視点にすぎません。製品開発そのものを問われている設問で、VA・VEの話だけに寄せると論点がずれます。