研究/開発/生産、技術職の実験の追い込み方についてまとめてみた

著者紹介：Nekoace（猫壱）, PhD, MoT 電機→素材と転職をまたいで一貫して新規事業畑。モットーは「組織で唯一無二のポジションを取り続ける」＆「社内政治を科学する」。社会人博士で培った専門性を使った技術コンサルと、新規事業プロマネが得意。学位取得をきっかけにSNSでの情報発信を開始。【経歴】修士(理学) ⇒　電機メーカーにて研究職10年(在籍中に工学博士と技術経営修士をダブルスクールし取得) ⇒　素材メーカーにて開発職(Now!!)

＊この記事はプロモーション広告を含む場合があります今回の記事のポイントはこちら

職種が変わって働き方の違いに戸惑っている技術系会社員の皆様
研究/開発/生産、その違いについて知りたい方

に対して技術系職種の働き方の違いについて解説します！

こんにちは、Nekoaceです。

4月ということで、新たな環境でお仕事始めている社会人諸氏がもしかしたら戸惑い始めているかも？な事柄についてまとめてみました。

PR
本記事のテーマは「職種の違いを理解する」ことですが、そのためには、自分のお仕事に対する理解が必要不可欠です。おすすめなのは職務経歴書を書くこと。「ビズリーチ」、転職アプリですが、こういうところで職務経歴まとめておくと、エージェントさんに加えて企業の人事担当者まで多様な方からコメント頂けて、転職市場からの自分がどう見られるか認識出来ておススメです。登録だけでもしとくといいよ。

技術系でお仕事されている皆さん、研究/開発/製造と色々職種はあると思うのですが、それぞれで似たような技術を扱うとしても、実は結構目的に至るアプローチが違うと思います。

研究さんは一歩一歩、着実に実験結果積み上げていく感じ。開発さんは効率的に詰めていって製造さんは工数かけて短期間でなんとかしちゃう印象があります。

この辺りを図示してまとめてつぶやいたのはこちら。

今回は、ツイッター上で注目頂いたこちらの内容について140字では伝えきれなかった内容について残していきますね！

改めて図解で説明

では改めて図を貼りますね。

理系の皆さんは当然ですが、技術的な目標値に向けてたくさんパラメータ有りますのでどのようにゴールに向かうかは結構センス別れる感じあると思います。
そこに至るアプローチって、プロジェクトの性質で決まると思いきや、職種の違いというか癖みたいなものが結構あるので、その辺注意必要です。

以下具体的に見ていきますね。

研究職のアプローチ

ある意味一番分かり易そうなのはここですかね。多くの方が大学/大学院で研究されていてそのイメージでまあ良いかと思います。大学/大学院の場合は、目標成果物が論文化することにあって、そのためには実験しました！だけじゃダメで、なぜそうなったのか？学理はあうのか？第三者でも納得できる論理展開になっているか、が重要ですので、実直にデータ貯める感じです。

最近の研究職は大分開発寄りになってきていて、特に超巨大企業の中央研究所とかじゃなければ、論文化とかは難しかったりします。それでも研究と名が付く以上仕事の進め方は似通っているので、ここではその前提で進めます。

博士の就職事情　企業で働く博士の生息地について考えてみた

博士課程修了者はアカデミアに進む方もいますがもちろん一定数は企業入社しています。しかし、どんな企業にどんな職種で入社しているのかご存じですか。この記事では、博士採用が多い業界と部署について著者が知る範囲でまとめています。よろしければ。

例えば図にあるように、条件Aと条件Bがあった時には、 Aでバーッと条件振ってみて良いところ/悪いところ傾向掴んで、 Bで条件振って傾向掴んで、 AとBでなんでそうなったのか理由についてしっかり考えて（場合によってはシミュレーションまでちゃんと回して）、最終的な目標条件と思われるところ中心に再度A/Bで条件振ってゴール！みたいな感じではないでしょうか。

ここまでデータ取れれば、シミュレーションのデータもあるので、先行文献からロジック作って論文発表！になりますね（or 学会ね）。

この場合、実直にデータ積むので誰から見ても納得感高いデータが得られます。会社とかだとやっぱりいろんな人がいて、ここが分かりやすい/わかりにくい、ああしろこうしろ一杯いろんな人から違うこと言われて、もう嫌だわ。。。みたいなことになりますが、研究的アプローチの場合、しっかりやれば確実に進みます。（研究ってそういうもんでしょ。）

ところがこのやり方わかると思いますが、すっごく時間がかかるので技術出来てGood条件見つかった時には残念遅すぎ他社が同じ技術発表しちゃいました！みたいなことになりますので、やっぱり一長一短です。そんなこともあって、最近企業内で研究は当たり強くて厳しいということですね。

開発職のアプローチ

次、開発。この辺りになると研究所っていうよりも事業部の中の部隊のお仕事だったりするので、良くも悪くも速度が大事です。そういう時によく使うのが「品質工学」というやつで、これはこれで深い話なので興味ある人調べてみてほしいのですが、いかに効率的に実験計画組んでいくかです。キーワードとしては「タグチメソッド」とか「L18直行表」とかそんなのが書いてある本で勉強したらいいんじゃないかと思います。（ツイッター上だとこの辺結構突っ込みがあったのでNekoaceが下手なこというと誤情報渡しちゃう気がするのであえてこれ以上触れません）

基本的には最小限の実験回数で条件散らして計画していく考え方なので研究のところでやった特定条件でばーっと条件振るみたいなことはあんまりないですね。条件的には明らかに傾向出るところで大振りしていく感じです。

これで一旦条件振ったら全体の傾向を分析します。しっかりデータあったら重回帰くらいはするかもですが、もっとざっくり最良条件選んじゃうかも。そしたらその条件近傍でまた細かく条件振るのを第２段にしてゴール！ですね。

この開発のケース、短時間でゴール到達できるのがいいところですが、何を隠そうNekoaceもこれあんまり得意じゃないのです。だって、総当たりしないと確実性の観点から不安じゃないですか。つまり条件散らすと論文書けないんですよね。。。研究やってた人が品質工学始めるとココが結構気になるのかなと思っていて、Nekoaceも日々戸惑ってます。「え、ここしか立証してないけど先進んでいいの？」みたいなことね。やっぱり職種変わるとこういうベーシックな考え方的なところ結構大変ですよね… 後は、最後に良条件で細かくデータ振りますが、まれに条件散らした時にめっちゃいい結果得られたとして、実はその条件がたまたま良かっただけな場合…いわゆるローカルミニマムというやつで、たまたま一点だけ良くて全体の傾向からはいまいち最良条件に届かなかったりしますのでその辺も注意がいるかもね。次。

製造職のアプローチ

自分の身の周りでも残業時間一番長いのって製造職だったりするんです。やっぱりいざ量産開始、歩留まり向上！みたいなところなので、一日改善するのが速いとそれだけ業績にダイレクトに効くので、なんとか既存の製造ラインを止めずに性能改善していかなければならない…ということで、時にライン止めてる夜中/休日に改善試作インラインしたりしますし、当然現場からも圧力が強いので早く改善しなきゃ！の気持ちになりがちです。

なのでここは、大体実績のある条件からスタートして、良さそうなところで再度詳細条件振りになります。この時開発であったようなローカルミニマムあたると困るので条件多め、かつ、確実性担保するのでN数多めで必然的に工数多くなる傾向有りそうです。

良いところとしては、着実にできるところでやっていくので大きな失敗は少ないです。が、同時に工数多くなるので大変。デスマーチとか言いますけども。

（記事の途中だけど）オススメの本！
・転職した時
・社内でも仕事の中身が変わる時
・プロジェクトが変わる時
人間関係が変わるときに起きる問題って大体がコミュニケーションに起因してます。相手の立場に立って理解しやすいように話をする。そんな当たり前のことが出来てないと環境が変わった時に困ります。
そんな悩みを抱えたことがある方は一度本で勉強してみてもいいかもしれません。
ベストセラーですが、「伝え方が９割」。
いい本なので手に取ってみて。　

職種が変わった時のコツ

最初の趣旨に戻ります。お仕事変わるタイミングって大事ですよね。転職した方は勿論ですが、社内移動した方でも新しいところの仕事の進め方のキャッチアップが最重要だと思います。やはり人間、経験あるところをベースで考えてしまいます。 Nekoaceが研究的アプローチで今の開発部署で慣れるのに苦しんだように（汗）、研究→製造の方は原理考える時間全然なかったりしますし、逆に製造→研究になったら根性だけじゃ認められないのが分かるでしょう。この辺り、今の職場のゴールが何で納期がどれくらいで、かつどんな進め方なら円滑にプロジェクトが回るのか考えながらお仕事進められると良いと思います。

各職種の間に入ってしまったら

これツイッターでコメントされてる方がいました。 チームのメンバーが研究/開発/製造それぞれのアプローチ方法好きな人で全然プロジェクトが進まない、みたいなこと。 絶対大変なやつです（苦笑）。一つの部署しか経験したことない、みたいな人って、このやり方で当然！みたいになるので柔軟性なくてよろしくないんですよね。理想的には、研究/開発/製造それぞれのやり方を一覧化して、今はこのやり方を取りましょう！みたいなのがいいのですが、そもそもそこまで時間が取れるのかということであれば、自分個人のレベルで最適化する手法を考えたらいいと思います。例えば個人では品質工学的にやりつつ、総当たり好きな人には総当たりした部分的なデータ見せてゴリ押すとか。シミュレーション求める人にはシミュレーション外注検討中ですお金くれ（笑）と言ってみるとか。プロジェクト回すにはそういう考え方違う人まとめていくみたいなのって必須スキルではあるので、そのもがきこそがスキルだと思いますね。