開発部署を経験して身に付いたこと

こんにちは。ブログ筆者のKです。

私は技術系総合職として化学メーカーに入社してからの約8年間、開発の部署で仕事をしました。

仕事量も多くてなかなか大変な部署だったのですが、その分色んなスキルが身に付いたと思っています。

今回は開発部署を経験して身に付いたことをご紹介したいと思います。

製品の上市経験で製品化までのプロセスが学べた

私の所属していた開発部署ではとある素材の開発とテクニカルサポートをやっており、そこで3つの品種を上市することができました。

開発ならお客さんも見えているし何年かやってればいくつか製品化することもできるでしょ、という話もあるかもしれません。ですが、製品を工場で作るためのハードルは非常に高く、単にスケールアップすればOKってもんではありません。

安全・安定して生産できるか、スペックに対してCpkは大丈夫か、品質保証は可能か、コストと利益はどうか、など考えることは多数あります。

特に既存の工場で新品種を作る場合は、ベンチやパイロットの設備でやっていることが工場でも同じようにできるか？という点は非常に重要です。

この辺りで最初のころは非常に苦労した経験があります。当たり前ですが、入社して2,3年の人間が工場の設備や能力を隅々まで把握しているわけもなく、色々な問題が出てきてそれに対処するだけでも大変でした。

このような経験があったので、パイロット設備と工場のプロセスでどれくらい違いがあるか、能力はどうか、という点を最初から考えるようになりました。ラボでやっていることが工場実機のプロセスとどれくらい乖離があるのかを把握することで、製品化への実現可能性も判定しやすくなります。

あと工場試作やその準備は非常にハードで、製品化の最終段階の大変さというのを味わえましたね。。。

他部署との調整能力

製品の開発を進める上で、工場や関連する他の部署との関わり合いが必須です。研究であれば一人でやる部分も多いですが、開発では圧倒的に他の人にお願いすることや各種調整が多いです。

打ち合わせや実験の日程の調整、実験内容と得られたサンプルの評価内容など、限られた時間の中でやるべき内容を詰めていくことになります。

意見の食い違いも出てきますのでやるべき内容の優先順位をすり合わせて、工場で試作するまでの日程に評価が完了してレビュー出来るように各種検討の日程を調整して、工場とも事前に試作内容を調整して、というような感じでとにかく調整です。

製品化の最終段階は関わる人間が多い一方でスケジュールのおしりが決まっている場合がほとんどなので、致命的な抜け漏れがないように注意しつつ、スケジュール通りに進められるように調整していきます。

といっても途中でトラブルが発生したり、突発の変更があったり、というのも日常茶飯事。再調整をして工場試作に臨むということもしばしばあります。

私自身は調整業務とかそういうのはあまり得意ではなかったのですが、無理やり仕事を覚えさせられた感じですね。締め切りが決まっていると嫌でもやらないといけなので荒療治という感じでしたが、他部署と上手くコミュニケーションが取れるようになったと思います。

現場の人にやってもらう能力

地味なところですが、現場の人に動いてもらう、作業をやってもらうにはどうすればよいか、というスキルも付きました。私のいた部署はパイロット設備があり、そこを運転するのは現場の人でした（一般職のオペレータさんですね）。

私は運転計画書を作成して現場の人に配布してパイロットの運転は現場の人が基本的にやりますが、必要に応じて自分でも作業するようなスタイルです。

大学のときは合成系の研究室で一人で実験して分析して、というのが当たり前だったので、現場の人にお願いするというやり方が全く分かりませんでした。

最初はお願いしつつ自分でもやりながら基本的な作業内容を覚えつつ、というのをよく分からないなりにやってました。

ある程度慣れてくると基本的に作業をお願いしていたのですが、作業のやり方などをよくよく見ると、現場の人は定常的にする作業は非常にうまくやってくれるのですが、それ以外の作業では曖昧な指示だと何をしていいか分からず困ってしまい、間違った作業をしてしまう場合もあることが分かりました。

また、お願いした人によっても違いがあって、以前に指示した内容（もしくはそれに近いこと）であれば上手くやってくれる器用な人もいれば、指示内容がきちんと理解できていない人もいます。

なので、頻度の低い作業や初めての作業では必ず私も作業を一緒にやっていました。作業の意味や内容もできるだけ丁寧に説明するようにしていました。

間違った作業をして実験が上手くいかなかっただけなら良いのですが、事故や労災に繋がると大事になります。なので、新しい作業では必ず一緒に作業していました。（簡単な作業の場合は自分だけでやることもありましたが。）

ここで分かったのは、現場の人は指示する人も主体的に作業をしないと動いてくれないということです。指示するだけでも基本的なことはやってくれるのですが、実験でやりたいことは定常作業から外れたものも多いです。

実験でやりたい定常から外れる作業を現場の人と協力してやるには、自分がこの実験を主体的に進めているので手伝ってください、というスタンスが必要です。

あとは「Kの実験なら手伝ってやろう」と思われていることも大事で、実験の度に適当な指示を出していると信用されなくなります。日頃からきちんとした実験計画を立てて現場の人とコミュニケーションを取っておくとスムーズに仕事が進められます。

段取りの大切さ

大学の時は段取りなんて考えずに実験していましたが、複数の人と協力して仕事をスムーズに進めるためには段取りが非常に大切ということが身に染みて分かりました。

パイロット設備ような大がかり実験になると実験を１つやるにしても、実験準備は前日やるのか当日やるのか、後片付けはどうするか、翌日の実験の準備はやるのか、現場の人の配置をどうするか、人数は足りているか、装置のメンテナンスの時間は取れるか、などなど考えることが多数あります。

このため、前の週末までに１週間分の運転スケジュールを決めて、現場の人に作業や出勤時間の調整のお願いをしていました。もちろん1週間分の運転スケジュールを決めるのには実験にかかる時間や次の実験への切り替え時間や作業内容なども把握している必要があります。

正直なところ、これができるようになるのに非常に時間がかかりました。実験内容ごとに必要な運転時間を頭にたたきこみつつ、切り替え時間や現場の人への負荷や勤務時間も考慮、実験に必要な資材の搬出入のタイミングも限られるので、前の週から準備しておくかどうかも考えていました。また依頼を受けてパイロットを動かす場合は納期もあるのでそれも考慮、、、というのを全部考えてスケジュールを決めるためには業務内容のほとんどを把握している必要があり、正直4,5年くらいかかった気がします。（それまでは行きあたりばったりになってしまうこともあり、現場の人に無理を言って迷惑をかけたことも。。。）

この段取りをきちんとやっておくことで、パイロット設備を無駄なく動かせますし、現場の人にも効率的に作業をしてもらえます。一人でやる作業であれば急な変更をしても大丈夫なんですが、チームで動いているときに急な変更すると作業予定がガラガラと崩れてやりたいことが全くできなかった、なんてことになります。

今の部署は一人で実験しているのでここまで厳密に段取りをする必要はないのですが、どうすれば効率的に実験を進められるか？という点では非常に役に立っています。

さいごに

開発部署で身に付いたスキルを棚卸してみましたが、厳しい部署だった分だけ仕事上のスキルが身に付いたように思います。

最後に一点。スキルではないのですが、チームとしていかに成果を出すか、という視点で仕事ができるようになったと思います。

個人で素晴らしい成果を上げるというよりもグループのメンバーと協力してパイロットを動かして成果を出していく部署だったので、チームとして効率的に動くためにはどうするべきか？ということを考えるようになりました。

今の部署は各々にテーマが与えられてそれぞれで実験するシステムなので、この視点がすぐに役に立つわけではないのですが、チームとして成果をより上げるためにできることはないか、という視点で他のメンバーと意見交換をしています。

開発の部署は製品化というプロセスを通していろんなことが学べましたが、その分大変な仕事でした。正直なところ、配属されてから開発の部署を抜けるまで辛いなぁとしか思っていなかったのですが、振り返ってみると経験という点では潰しが利くことを身につけられたと思っています。