【経験談】製品開発で起こった失敗・トラブル事例
メニュー
メニュー
この記事を読むべき人
こんにちは、リヴィです！
私は普段は機械設計の仕事をしているのですが、業務は一般的に、
などの特徴があります（でも立派な仕事ですけどね！）。
その一方で、
というように、能動的にものづくりをしたい、ゼロからイチを生み出したいと考える人もいるかと思います。
そんな人におすすめなのが「開発業務」です。
なんかキラキラした雰囲気を感じますよねー！設計業務ばかりが続くとマンネリ化したりもしますしー
開発業務は若手の機械設計者に特に人気が高い傾向にあり、配属先の倍率も高い傾向にあります。
開発業務には主に「研究開発」と「製品開発」とがあります。
研究開発は、大学でやっていたような研究を企業規模でやるというイメージで、決めたテーマに対してデータを取得し、学会で発表したり論文をだしたりするという感じです。
まさに「研究者」っていうイメージですね！技術ブロガーのしぶちょーさんも、研究開発の部署へ異動されましたよね！
一方で製品開発は、お客さんへの納入や販売をゴールとして、技術やアイデアを元に製品を創造していきます。
こちらは「発明家」っていうイメージですね！私が経験してきたのはこちらです！
私の経験した製品開発では、特に専用の部署などはなく、設計部署内で開発プロジェクトが立ち上がるというパターンでした。
運が良かったこともあり、開発プロジェクトチームの一員として活動をしましたが、やはり通常の設計業務とは異なる部分がたくさんあり、貴重な体験ができたなーと思っています。
ただその一方で、製品開発ではたくさんの失敗やトラブルがあり、もはやスムーズに開発が進むことの方が少なかったりします。
おそらく読者の方の中には、
ホントはちょっと製品開発とか憧れてるんだけど、なんか大変そうだな・・・
という方や、
製品開発の仕事してるけど、トラブルまみれで・・・自分には向いていないのかな・・・
と感じる方もいるかと思います。
そのようにして開発業務が自分に向いているのかどうかを考える上では、製品開発のキラキラした側面だけではなく、
なども知っておきたいですよね。
そこで今回は、私がこれまでの製品開発で経験したトラブル・失敗事例について事例を紹介していきたいと思います。
製品開発そのものでのトラブルはもちろん、それに付随するトラブルもたくさんあったので、それらも踏まえて参考にしていただければと思います。
私が大企業での開発で一番印象に残っていたのが、部署や会社の上司たちが開発にめちゃくちゃ消極的だということでした。
会社ではいつも企画部から、
「設計部署の皆さん！お願いですから、企画を出してくださーい！」
って言われます。
企画部って名前ですが、その部署から何か企画書が出ることはなく「設計部署から企画を集めて開発を承認する」のが仕事のようでした。これって普通なんですかね？
それに対して何か開発のネタがあれば、
というハンコリレーの末に開発がスタートします。
途中1回でも企画書をはねられたら、作り直してまた最初から承認もらい直しですからね・・・ベンチャーいたときは「社長・役員に相談する」→「承認もらう」で、企画書もハンコもなしでした。スピード感が全然違います笑
で、大企業ではA3用紙1~2枚に企画内容をまとめたものを企画書として提出するのですが、
これ、開発したところで確実に売れるの？
って言われてました（特に部長が消極的でしたね・・・）。
それに対して、展示会などで調査した内容や、売り込み先に話を聞きに行った報告書なども添付して説明するのですが、開発の中身や業界などへの興味は薄く、
需要はあるのはわかるが、ウチの商品が売れるという確証としては薄いんじゃない？ウチがわざわざ開発着手して売れる未来が想像できないんだけどー
と言われ、全然企画書が通らないという事態が発生していました。
100%売れる確証のある開発なんて、私は聞いたことないんですけどね笑
部長と話しをしていると、部長にとっての開発業務とは、
のように捉えているとしか思えませんでした。
部長は定例会議でいつも「ウチの部署も何かイノベーションを起こす必要がある！」とかって言ってましたが、実際に企画を持っていくと、重箱の隅をつつくようにダメな理由を列挙し始めるんですよね・・・半沢直樹かよって思ってました（白目
部署の部課長だけではなく、営業も開発には消極的でした。
一番驚いたのが、製品開発が終わり、お客さんを会社に呼んでPRする会があった際の営業の態度が、
という感じでした。
飲み会の愚痴りネタの一つとして定番化してましたね・・・
あくまで憶測ですが、これはおそらく「構造的な問題」のせいだと思われます。
どいういうことかというと、一般的に営業さんには「営業ノルマ」というものが設定されています。
そのノルマを効率よく達成しよう思ったら、「ホントに売れるかわからない開発製品」を必死に売り込むよりも、「そんなに必死にならなくても、収益が上がるような既存の主力製品」を売り込んだほうが圧倒的にラクだということです。
大企業の営業さんには、我々のような「技術への興味」はなかったですね・・・
そもそも開発プロジェクトの流れとして、プロジェクトが立ち上がる前に確認すべきことが山程あります。例をあげると、
頭の中ではうまくいくと思うんだけど、ホントにうまくいくかなぁ・・・。ネックになりそうなところを探るためにも、事前にちょっとテストしておきたい
となることのほうが普通です。
開発プロジェクトが立ち上がってからの確認になると、大きな問題が発覚するリスクが高く、開発予算もスケジュールもグダグダになってしまいますからねー
大企業では社内に立派な設備をたくさん揃っていて、資金的にベンチャーなどでは開発が難しそうなダイナミックなテストができる環境があります。
ですが、そういった設備を使わせてもらうためには申請が必要で、しかもその申請に非常に手間がかかる傾向があります。
大きい組織であるため社内設備の管理等が必要になるのは仕方がないことだとは思いますが、それでも
といった感じです。
また、設備を使う申請を出すと部課長から、
おいおい、何を企んどるや？開発のための事前確認？試してみてダメとわかったら、それにかかった費用や工数が無駄になるやろ？生産性の低いことをせず、ちゃんと仕事せー！
と言われることがしばしばあります。
パット見た感じ誰も使っていないので気軽に使えると思いきや、申請をするだけで平気で一週間ぐらいかかったり、そもそも使わせてもらえないなんてこともザラでした。
なので大企業にいたときには、正攻法ではなくいかに「しれっと」やるかが重要でした。後々聞いたら、実は上司たちも同じようにやっていたみたいです笑
働き方改革が流行りだした時期でもあったことから部長は「生産性おじさん化」していましたが、開発プロジェクトに対してもそれは同じでした。
もちろん、開発効率はある程度は重要です。ダラダラ開発していると、
といったことが起こるからです。
ただ、かといって開発効率を求めすぎるのもよくありません。
開発プロジェクトを進めていると、ふと、
というようにさまざまな感情が芽生えてきます。
こういった感情は開発業務をする上では非常に重要なものなのですが、
効率化を求めすぎたあまり、これらを排除して開発を完了させてしまうと、いざ「展示会でデモ機を動かす」「お客さんの設備へ納品する」などのタイミングで、
というように、重要な場面で失敗するリスクが非常に高くなってしまうのです。
そういうのを理解しない人が上にいたせいで、大企業では開発のための工数は年々削られていっていましたねー
この辺りの話は、IPAのメンバーでNTT東日本特殊局で筑波大学准教授など多岐に渡って活動をされている、登大遊さんの話を聞いて非常に共感した部分でした。
こういう方々の話って、面白いですよねー笑
ベンチャーで働いていたとき、一番大変だったのがこれでした。
開発プロジェクトをスタートした当時、関係者全員で「どれぐらいまで完成度を持っていくか？」という話し合いに基づいて取り組んでいました。
ですが、1~2週間ぐらい経つと、周知されたり、相談されたりすることなく勝手に目標が変わってます。
開発を進めていると突然、
と言われ、「え、なんか話が違うぞ？」となり発覚します。
ベンチャーの社長や役員って、土日祝日とかもフツーに仕事していたりするので、従業員が休んでいる間に考えがコロコロ変わったのかもしれません。
設計初期ならまだ対応は容易なのですが、部品発注後や装置が組み上がったあとでも平気でちゃぶ台返しが起こってましたねー。たぶん本人は自覚してないと思いますけど。
もちろんそれに対して皆さん、
いやいや、そんな話聞いてないんですが！もう部品発注しちゃってますし！？DRのときも、これでいいって確認しましたよね！？
といって揉め事になるのですが、なんやかんや社長がゴリ押しで対応するよう指示してました。
あとは実際に装置を組み立て終わった際に、
オレがイメージしていたのはこんなんじゃなかった！全然ダメ！すぐバラして！
なんていうパターンもありました。
私が2ヶ月ぐらいかけて設計・調達・組立した数百万の装置は、社長の一言で一度も動かすことなくバラされましたからね・・・その時は大喧嘩になりました・・・笑
実際に工程が進んでからの大幅な変更は、ハードウェア屋さんにとってはかなりの負担です。
といった労力がかかります。
さらにベンチャーではマンパワーがなく設計者自身が全部やる必要があるので大企業と比べると余計に時間がかかります。
ゲームのように「リセットしたらすぐやり直し」ができません。
トラブルの原因について、最初からイメージがズレていたのか、それとも社長や役員たちの中で勝手にイメージが変わっていったのかはわかりませんけどね・・・。コミュニケーションの重要性がよくわかります。
これも私自身、めちゃくちゃ苦労しましたし、結局仕事がぜんぜん軌道に乗りませんでした。
大企業で開発をしていたときには、「企画書」や「企画会議」にて、
などが連絡されていたのですが、ベンチャーで開発をしていたときはそのような具体的な企画・指示はほぼありませんでした。
指示の内容は、
という感じでした。
これじゃあ、設計できないんですが・・・。具体的な数字とか、せめて目安とかないんですか？
と何回か言ったことがあるのですが、それに対して、
開発をしながらじゃないとそんなもの決めきれないし、むしろそっちから提案してもらわないと困る！
という感じでした。
なんとか、
というように説明しに行くのですが、
おいおい、その想定や過程が何故正しいと言えるのかを、もっと論理的に考えて説明してよ。その想定から外れる場合だってあるわけでしょ？
と言われてました。
「あれ、開発の責任者って誰だっけ？」ってめっちゃ思いました笑。特に、汎用向けの開発だとか、ワークのばらつきが激しいもの（不定形ワーク）とかだと、答えのない答えを探すために、延々と議論している感じでした。
ただ、他の役員とかに相談をしても、
いやいや、むしろそこで最適な提案を出してもらわないと、この先うちの会社では厳しいよ？ウチらだってお客さんに対して提案するとき、そんな感じだしねー
と言われてしまっていました。
確かに、上からの指示通りにやる仕事ばかりしてたらダメなのかもしれないな・・・自分から提案ができるような設計者になっていかなきゃいけないのかもしれないなー・・・
と思い直し、なんとか試行錯誤してはいたのですが、気がついたら開発目標が勝手に変わっていた際や、テストしてみた結果設計変更が必要になった際に、
想定が甘すぎる！なんでもっとよく考えられないの？設計としてレベルが低い！
なんて言われていました。
「指示が曖昧すぎる」と言いえばそうですが、逆に「適切な提案をするまでが機械設計の仕事」と言われればそうである気もして・・・これはもうどうしたらいいのか全くわからなかったですね・・・つまりこの職場は私には向いてなかったってことでしょう（納得
ベンチャーにいると、大企業とは比べ物にならないぐらいのスピード感があったりするのですが、使い方を間違えるとそのスピード感が仇となることがあります。
事前にほとんど考えもなく、勢いで、
といって行ったものは、経験上やるだけ無駄になります。
「ほとんど考えもなく」というのがポイントです。その場の空気や、自分の気持ちの盛り上がりで「やっちゃえやっちゃえー！」って突っ走ったやつは、後々ふと我に帰ったときに何も成果が残っていないってなることが多いです。
確かに開発では「やってみないとわからないこと」もあるのですが、ホントに何も考えずにただ手を動かしていても、ただ時間だけが過ぎていく感じになってしまいます。
そうならないためには、実際に動き出す前に、まず
というふうに、的を絞ったり、その後の展開をイメージしておくのを、簡単でもいいからやるだけで、開発プロジェクトの効率がアップします。
さらに、テストをする前に自分の中で仮設を立てる（推測する）のが非常に重要です。
例えば、
「それがうまくいくかどうか」というのは、もうちょっと因数分解すると、これとこれとが本質的に影響してくるんじゃないかなー
といった感じです。
よく「大学で習った勉強なんて、仕事だとほとんど役に立たない」という人がいますが、大学の勉強を侮っている人はこの「仮説を立てる」ことができません。だいたいは「とりあえずやってみたらこんな結果になりました」とか「ちょっとでも関係ありそうなことを、ローラ作戦で調べました！」となります笑
この辺は、シン・ニホンの著者である安宅和人さんも、ブログや書籍「イシューからはじめよ」で語られています。
kaz_ataka, 圧倒的に生産性の高い人（サイエンティスト）の研究スタイル
この「仮設を立てる」ことの重要性は、ほかにもいくつかのビジネス書で述べられています。それほど強力なのですが、ただ身につけるのに時間がかかると言われています。自分も何度も書籍を読み直してますが、実践できているかと言われると・・・だと思います笑
1つのプロジェクトの中に複数の開発要素がある場合に起こっていた話です。
例えば私がA工程を担当していて、鈴木さんがB工程の設計を担当していたとき、私のA工程では設計がなんとか終わり、調達・組立調整・装置単体でのテストが終わっていたとします。
一方、鈴木さんのB工程でも装置単体でのテストをしていたのですが、単体テストで全くうまくいきません。
鈴木さんも部分的に設計変更をしながら、夜遅くまで試行錯誤をするのですが、それでも目標の性能が出ません。
みんなと話し合った結果、A工程の設計を丸々変更ができれば、性能が出る可能性が高いとなりました。
そのようにして、A工程のタスクが完了していたのが、未完に巻き戻り、大幅な設計変更と分解・再組立・再テストが必要となるのです。
これは鈴木さんが悪いということでは決してなく、複数の開発要素が絡むプロジェクトでは割とあるあるだということです。
私と鈴木さんとが逆の立場になっていたことも多々ありまし、さらには、機械屋と電気屋との間、機械屋とソフト屋との間でもよく起こっていましたねー。
リスクを抑えるのなら、開発要素は1プロジェクトにつき1つまでとするのが良いんでしょうが、スピードと野心が売りのベンチャーでは、階段をいきなり2~3段ぐらい飛ぶようなこともやってました笑
残業も終電まで作業するとかが日常茶飯事になっていたりもしてました。
なんやかんやで、当初の開発スケジュールは半年も遅れていたと思います。
流石に終電までやるような身を粉にする必要はありませんが、それでもやっぱりタスクの巻戻りは発生するもんだなーとは感じます。
っていう人は、こういう難易度の高いプロジェクトには向いていないと思います。
「まぁ、やってみないとわからなかったことも多いから仕方ないね！」と、どんなに睡眠不足でもメンバーの失敗を受け入れて前に進むような心構えが重要です（白目
ベンチャーでの開発プロジェクトは目まぐるしいぐらいのスピードで進行していきますが、それと同時に仕様変更や設計変更なども目まぐるしいスピードで発生していました。
本来は、開発だろうが通常の設計だろうが、
といった膨大な内容を管理しながらプロジェクトを進めていくのが非常に重要です。
規模の大きい企業だとISO9001の認証をされている企業も多く、定期的に「ちゃんと管理されていのかどうか」の監査を受けます。ずさんな管理によりISOの監査などで不適合となってしまうと、ISOの認証が剥奪されてしまったりします（こうなると、だいぶイタイです）
ほとんどの人はこういった管理をエクセル等で頑張って管理しているのですが、大企業でさえこういった管理はめちゃくちゃ大変です。
にもかかわらずベンチャーではそんなヒマがないぐらい、とにかく手を動かさないといけない事態がよく起こっているので、ほぼ管理なんてできていないのです。
ベンチャーではとにかくマンパワーがないですから、設計者だろうがプロマネだろうが役員だろうが、全員プレイヤー化してます笑。「そのうちISOの認証をとるために、ちゃんとしておかないといけないんだけどねぇ」とは言っていますけどね笑
中でも一番管理がずさんなりやすいのが「設計図書関連」で、
設計思想なんて、ちゃんと図面を読める人であれば、図面見ただけで理解できるやろ！
DRは一応しているけど、わざわざ記録に残したりなんかはしてないな・・・
機械の動作説明なんて文書や図面じゃ難しいから、会議で人集めて口頭でやってるわー。記録とかはとくにとってないけどー
って感じの人は多いです。
こういうのが横行しているから、新しく人が入ってきたり、逆に人が抜けていく度に大問題になるんですよねー・・・ただ、これらを手間なく管理できるツールがないっていうのもまた問題なんですけどねー
開発が終わって新製品発売のリリースの際、「〇〇がxx%アップ！」なんてPRをしたりすることも多いのですが、ものによっては「条件を最適化させないとその性能が出ない」というものもあります。
確かにデータに虚偽はないのですが（コンプライアンスがちゃんとしている前提ならですけど）、開発で取得したデータは動作条件を最適化させたチャンピオンデータであることもしばしばあります。
なので、実装環境に機械を持っていった途端、
あれ！？思っていたよりも全然性能が出ないんだけど！これじゃ、使い物にならないじゃん・・・
なんてこともなくはないです。
製品PRを受けたときに、たまに「それ、ホンマかいな！？」って思うことまで「何でもできます！」と言ってくる取引先がいますが、私は結構疑いにかかります笑
なんだか騙されたような気分になるのもよくわかりますが、かといって実装環境なんてお客さんによって千差万別なので、ある程度は仕方がないのです（そこら辺の塩梅はガチで程度問題です笑）。
ただ度が過ぎると流石にお客さんからの信用を失っていきますから、ちゃんとしたメーカーの場合、
などをしていたりします。
ただ「どういった条件下なら、チャンピオンデータに近い性能が出るか？」が明確になっていればかなりマシな方です。
もっと質が悪いのが、その条件がわかっていないことです。
例えば、
といった感じです。
不具合の起こる原因を特定するのは難易度が高い場合もあり、その条件がわかるまで機械屋・電気屋・ソフト屋みんな揃って帰れないなんてこともあります。
中には「1万回に1回起こる不具合」とかもあります。不具合が再現しにくいやつは、特にヤバいですね・・・。原因がわからないと正しい対策が立てられないですから。
開発プロジェクトでは設計変更もよく発生していましたが、その都度部品を設計・作り直しをしていたらスケジュールは延々と遅れていきます。
すると設計者はそういう事態をなるべくさけるために、取付け調整の機構をたくさん取り入れたくなります。
とかを、ついどんどん取り入れたくなります。
最初から寸法をバチッと決めてしまうと、うまく行かなかったときに作り直しになっちゃうんで、なかなか難しいんですよねー。
調調整箇所が多いと、例えばセンサーの取り付け位置について、
というように、1箇所ごとに測定&計算をしないといけなかったりしますし、開発を進めていく過程で調整量が変えていったりした際には、もうわけがわからなくなります。
実際にはこんなにきれいな寸法にはなっていないですし、角度でもぐちゃぐちゃになってたりすると、もう収集がつかないですね・・・
ですが、装置の場所を移動したり・どこかへ出荷をする際に一度でも分解すると、再組立て時の再現がめちゃくちゃ大変になります。
調整時の寸法などをメモ帳に控えればなんとか再現はできるものの、その調整箇所が多ければ多いほど調整値の控えが大変になるので、あまりいい方法とは言えません。
しかも、開発をしながら繰り返し調整をしたりすると、図面とモデルとの齟齬がどんどん大きくなっていくんで、実態を正確に把握するためには毎回現物を見に行かないといけなくなるんですよねー
そのため、
などを考えながら設計することが、スキルアップへの一歩です。
開発をやっていてついなってしまうのがこれです。
開発が進むにつれて、チームメンバーから様々なアイデアや意見が飛び交うようになってくるのですが、
と市場のニーズやお客さんの要望を置き去りにして、どんどんアップデートしていってしまいます。
そのようにして無意識のうちに「自分たちが良いと思う製品＝売れる製品」という勘違いが生まれてしまいます。
その結果、お客さんからしてみれば、
というふうになってしまい、せっかく開発したものが売れなかったり、「使いにくい・使えない」というクレームが発生します。
そのためにも、
と、常にお客さんの意見や市場の動向と向き合いながら開発を進めることが良い場合もあります。
自分たちがいいと思うことだけしか考えていない製品開発のことを、私の師匠は「ただの趣味。芸術家のやること。」という風に批判してましたね・・・笑
ものづくりのススメでは、機械設計の業務委託も承っております。
ご相談は無料ですので、以下のリンクからお気軽にお問い合わせください。
機械設計の無料見積もり
機械設計のご依頼も承っております。こちらからお気軽にご相談ください。
構想設計 / 基本設計 / 詳細設計 / 3Dモデル / 図面 / etc...
機械の開発や設計で役立つ便利ツール「Devel Hub」の特徴を解説！
