- 自分に開発業務が合っているかどうか知りたい人
- 製品開発やってみたいけれど、実態はどんな感じなのか気になる人
- 開発業務でトラブルの渦中にいるけど、ウチの会社だけの話なのか、業務の性質上しかたないのかを知りたい人
こんにちは、リヴィです！
私は普段は機械設計の仕事をしているのですが、業務は一般的に、
- 「お客さんの要望にあう機械の構造を考える」と受動的な側面が強かったり、
- 「過去に実績のある機械をベースにちょっと構造を変えるだけ」と新規性が薄かったり、
- 「すでに一度設計されたものをベースに一部作り変える」と若干クリエイティブ色が薄かったり、
などの特徴があります（でも立派な仕事ですけどね！）。
その一方で、
- iPhoneみたいに、世界中で使われるヒット商品を作り出したい！
- 社会的な課題に対して、自分で生み出した機械を使って解決したい！
- まだ誰も考えたことがないような、最先端のものを作ってみたい！
というように、能動的にものづくりをしたい、ゼロからイチを生み出したいと考える人もいるかと思います。
そんな人におすすめなのが「開発業務」です。
なんかキラキラした雰囲気を感じますよねー！設計業務ばかりが続くとマンネリ化したりもしますしー
開発業務は若手の機械設計者に特に人気が高い傾向にあり、配属先の倍率も高い傾向にあります。
開発業務には主に「研究開発」と「製品開発」とがあります。
研究開発は、大学でやっていたような研究を企業規模でやるというイメージで、決めたテーマに対してデータを取得し、学会で発表したり論文をだしたりするという感じです。
まさに「研究者」っていうイメージですね！技術ブロガーのしぶちょーさんも、研究開発の部署へ異動されましたよね！
一方で製品開発は、お客さんへの納入や販売をゴールとして、技術やアイデアを元に製品を創造していきます。
こちらは「発明家」っていうイメージですね！私が経験してきたのはこちらです！
私の経験した製品開発では、特に専用の部署などはなく、設計部署内で開発プロジェクトが立ち上がるというパターンでした。
運が良かったこともあり、開発プロジェクトチームの一員として活動をしましたが、やはり通常の設計業務とは異なる部分がたくさんあり、貴重な体験ができたなーと思っています。
ただその一方で、製品開発ではたくさんの失敗やトラブルがあり、もはやスムーズに開発が進むことの方が少なかったりします。
おそらく読者の方の中には、
ホントはちょっと製品開発とか憧れてるんだけど、なんか大変そうだな・・・
という方や、
製品開発の仕事してるけど、トラブルまみれで・・・自分には向いていないのかな・・・
と感じる方もいるかと思います。
そのようにして開発業務が自分に向いているのかどうかを考える上では、製品開発のキラキラした側面だけではなく、
- どういった失敗やトラブルがあるのか？
- 自分のプロジェクトだけ異常なのか、それとも開発ではあるあるなのか？
なども知っておきたいですよね。
そこで今回は、私がこれまでの製品開発で経験したトラブル・失敗事例について事例を紹介していきたいと思います。
製品開発そのものでのトラブルはもちろん、それに付随するトラブルもたくさんあったので、それらも踏まえて参考にしていただければと思います。
大企業編
会社や部署が開発に消極的
私が大企業での開発で一番印象に残っていたのが、部署や会社の上司たちが開発にめちゃくちゃ消極的だということでした。
会社ではいつも企画部から、
「設計部署の皆さん！お願いですから、企画を出してくださーい！」
って言われます。
企画部って名前ですが、その部署から何か企画書が出ることはなく「設計部署から企画を集めて開発を承認する」のが仕事のようでした。これって普通なんですかね？
それに対して何か開発のネタがあれば、
- 企画書を書く
- →所属部署の管理職に説明し、承認もらう
- →所属部署の部課長に説明し、承認もらう
- →企画部に説明し、承認をもらう
- →役員に説明し、承認をもらう
- →開発スタート
というハンコリレーの末に開発がスタートします。
途中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段ぐらい飛ぶようなこともやってました笑
残業も終電まで作業するとかが日常茶飯事になっていたりもしてました。
なんやかんやで、当初の開発スケジュールは半年も遅れていたと思います。
流石に終電までやるような身を粉にする必要はありませんが、それでもやっぱりタスクの巻戻りは発生するもんだなーとは感じます。
- 「あいつのせいで、オレの仕事が水の泡になった！」と反発をしたり、
- 「なんでもっとちゃんと考えておかなかったんだよー！」と結果論をいい出したりとか、
- 「開発のスケジュールが遅れるの、どう責任とってくれるんだよー！」と責任問題をしだしたりとか、
っていう人は、こういう難易度の高いプロジェクトには向いていないと思います。
「まぁ、やってみないとわからなかったことも多いから仕方ないね！」と、どんなに睡眠不足でもメンバーの失敗を受け入れて前に進むような心構えが重要です（白目
仕様変更・設計変更が起こりすぎて、管理がずさんになる
ベンチャーでの開発プロジェクトは目まぐるしいぐらいのスピードで進行していきますが、それと同時に仕様変更や設計変更なども目まぐるしいスピードで発生していました。
本来は、開発だろうが通常の設計だろうが、
- どんな仕様の製品開発を目指すのか。
- お客さんとの打ち合わせやメール連絡等の中で、どのような変更・要望があったのか？
- プロジェクト全体のスケジュールはどうなっているのか？
- プロジェクトメンバーそれぞれが、今何のタスクを抱えていて、どれぐらい終わっているのか？
- 設計した機械はどういった思想に基づいて設計をしているのか？
- DR（デザインレビュー）はされているのか？また、その記録は残っているのか？
- 強度計算や能力計算はしているか？また、その計算内容は妥当なのか？
- 設計した機械は、どのタイミングで、何がトリガーになって、どのように動くのか？その間、干渉等はないのか？
- 設計した装置の組立調整について、組立手順書はあるのか？また必要に応じてジグは設計されているのか？
- 装置の部品について、何が何個必要なのか？
- CADモデルのうち、今何が最新版なのか？
- 何の試験をして、どこまでの動作を確認しているのか？検討漏れの項目はないか？
- 試験の結果どんな問題が発覚しているのか？それは誰がいつまでにどのようにして解決するのか？
といった膨大な内容を管理しながらプロジェクトを進めていくのが非常に重要です。
規模の大きい企業だとISO9001の認証をされている企業も多く、定期的に「ちゃんと管理されていのかどうか」の監査を受けます。ずさんな管理によりISOの監査などで不適合となってしまうと、ISOの認証が剥奪されてしまったりします（こうなると、だいぶイタイです）
ほとんどの人はこういった管理をエクセル等で頑張って管理しているのですが、大企業でさえこういった管理はめちゃくちゃ大変です。
にもかかわらずベンチャーではそんなヒマがないぐらい、とにかく手を動かさないといけない事態がよく起こっているので、ほぼ管理なんてできていないのです。
ベンチャーではとにかくマンパワーがないですから、設計者だろうがプロマネだろうが役員だろうが、全員プレイヤー化してます笑。「そのうちISOの認証をとるために、ちゃんとしておかないといけないんだけどねぇ」とは言っていますけどね笑
中でも一番管理がずさんなりやすいのが「設計図書関連」で、
設計思想なんて、ちゃんと図面を読める人であれば、図面見ただけで理解できるやろ！
DRは一応しているけど、わざわざ記録に残したりなんかはしてないな・・・
機械の動作説明なんて文書や図面じゃ難しいから、会議で人集めて口頭でやってるわー。記録とかはとくにとってないけどー
って感じの人は多いです。
こういうのが横行しているから、新しく人が入ってきたり、逆に人が抜けていく度に大問題になるんですよねー・・・ただ、これらを手間なく管理できるツールがないっていうのもまた問題なんですけどねー
共通編
なんらかの原因で、開発時よりも性能ががくんと落ちる
開発が終わって新製品発売のリリースの際、「〇〇がxx%アップ！」なんてPRをしたりすることも多いのですが、ものによっては「条件を最適化させないとその性能が出ない」というものもあります。
確かにデータに虚偽はないのですが（コンプライアンスがちゃんとしている前提ならですけど）、開発で取得したデータは動作条件を最適化させたチャンピオンデータであることもしばしばあります。
なので、実装環境に機械を持っていった途端、
あれ！？思っていたよりも全然性能が出ないんだけど！これじゃ、使い物にならないじゃん・・・
なんてこともなくはないです。
製品PRを受けたときに、たまに「それ、ホンマかいな！？」って思うことまで「何でもできます！」と言ってくる取引先がいますが、私は結構疑いにかかります笑
なんだか騙されたような気分になるのもよくわかりますが、かといって実装環境なんてお客さんによって千差万別なので、ある程度は仕方がないのです（そこら辺の塩梅はガチで程度問題です笑）。
ただ度が過ぎると流石にお客さんからの信用を失っていきますから、ちゃんとしたメーカーの場合、
- 機械の性能に若干余裕をもたせた値を仕様として公開する
- データを取得した際の動作条件について、きっちりと明記する
- 出荷前にきっちり検査をしている
- 無償でデモ機を貸し出す
- 保証期間を設ける
などをしていたりします。
ただ「どういった条件下なら、チャンピオンデータに近い性能が出るか？」が明確になっていればかなりマシな方です。
もっと質が悪いのが、その条件がわかっていないことです。
例えば、
- 今まで動作に問題なかったのに、急に性能が出なくなった
- 散々いろんなテストをしたのに、お客さんにPRする日に限ってエラーで動かない
- 出荷間近のときに限って、急に装置が暴走した
といった感じです。
不具合の起こる原因を特定するのは難易度が高い場合もあり、その条件がわかるまで機械屋・電気屋・ソフト屋みんな揃って帰れないなんてこともあります。
中には「1万回に1回起こる不具合」とかもあります。不具合が再現しにくいやつは、特にヤバいですね・・・。原因がわからないと正しい対策が立てられないですから。
組立の再現性がない・再現しにくい
開発プロジェクトでは設計変更もよく発生していましたが、その都度部品を設計・作り直しをしていたらスケジュールは延々と遅れていきます。
すると設計者はそういう事態をなるべくさけるために、取付け調整の機構をたくさん取り入れたくなります。
- 長穴での調整を採用したり、
- バカ穴の径を大きめにしたり、
- 調整ねじで位置を変更できるようにしたり、
とかを、ついどんどん取り入れたくなります。
最初から寸法をバチッと決めてしまうと、うまく行かなかったときに作り直しになっちゃうんで、なかなか難しいんですよねー。
調調整箇所が多いと、例えばセンサーの取り付け位置について、
- A部で長穴センターから5mmオフセットの位置になったけど、
- B部で長穴センターから10mmオフセットの位置になっているから、
- 結局センサーは基準から15mmの位置になっていて、
というように、1箇所ごとに測定&計算をしないといけなかったりしますし、開発を進めていく過程で調整量が変えていったりした際には、もうわけがわからなくなります。
実際にはこんなにきれいな寸法にはなっていないですし、角度でもぐちゃぐちゃになってたりすると、もう収集がつかないですね・・・
ですが、装置の場所を移動したり・どこかへ出荷をする際に一度でも分解すると、再組立て時の再現がめちゃくちゃ大変になります。
調整時の寸法などをメモ帳に控えればなんとか再現はできるものの、その調整箇所が多ければ多いほど調整値の控えが大変になるので、あまりいい方法とは言えません。
しかも、開発をしながら繰り返し調整をしたりすると、図面とモデルとの齟齬がどんどん大きくなっていくんで、実態を正確に把握するためには毎回現物を見に行かないといけなくなるんですよねー
そのため、
- 調整箇所は必要最小限とする
- 調整が必要な箇所については調整要領を確立したり、調整ジグを設計するなどして、誰でも再現ができるようにしておく
- バカ穴などによる組立誤差を最小限に押さえられるよう、部品組付け時にしっかり位置決めできるような構造にしておく（段差や角あてを上手く利用する）
などを考えながら設計することが、スキルアップへの一歩です。
「自分たちが良いと思う製品＝売れる製品」という勘違い
開発をやっていてついなってしまうのがこれです。
開発が進むにつれて、チームメンバーから様々なアイデアや意見が飛び交うようになってくるのですが、
- 絶対こういう構造にした方が便利！
- やっぱり、この機能も追加した方がいいかも！
- ワークのバリエーションも増やしたほうがいいかも！
と市場のニーズやお客さんの要望を置き去りにして、どんどんアップデートしていってしまいます。
そのようにして無意識のうちに「自分たちが良いと思う製品＝売れる製品」という勘違いが生まれてしまいます。
その結果、お客さんからしてみれば、
- 「そんな余計な機能いらないから、もっと安くしてほしい」とか、
- 「機能うんぬんよりもさぁ、メンテナンスしやすいかとか、設備が止まりにくいかとかはどうなの？」とか、
- 「機能をごちゃごちゃつけるんじゃなくて、機能絞っていいから業界最高レベルのものがほしいんだけど？」とか、
というふうになってしまい、せっかく開発したものが売れなかったり、「使いにくい・使えない」というクレームが発生します。
そのためにも、
- 小さく開発をして、お客さんの反応を見る
- お客さんからのフィードバックや、業界の動向を見ながら、製品をアップデートしていく
と、常にお客さんの意見や市場の動向と向き合いながら開発を進めることが良い場合もあります。
自分たちがいいと思うことだけしか考えていない製品開発のことを、私の師匠は「ただの趣味。芸術家のやること。」という風に批判してましたね・・・笑
