  |
周りを見渡すと、何だかんだ同業種の人間が少ないような気がする。
そこで、この記事では経験談に基づいた研究開発職の特徴を簡単にまとめる。
成果を発表する場として、どちらの企業も内部展覧会での発表を重視している。
これはチームの成果を誇示して予算獲得への足掛かりを掴めるからである。
必然的に論文や特許の執筆を重視せず、この展覧会をチームの最終目標とすることが多い。
内部展覧会では研究者ではなくユーザと同等の目線で評価が下され、
私が入社した会社では、マネージャーが「研究所に必要な人間ランキング」を順に決定し、上位10%は出世対象となり下位5%はクビになる、という制度を採用していた。
周りを見る限り急にいなくなる人間はいなかったため、あくまで社員を焚きつける制度という印象だった。
こうした評価制度は研究開発競争を高めるために有益であり、研究開発界隈では一般的であるようだ。
自分が半期毎に取り組める研究は、マネージャーの一存で決まる。
なお、マネージャーが目指す研究の方向性は頻繁に変わり、柔軟性に富んでいる。
主に方向性が大きく変わるのは、
のいずれかである。
以上のイベントが発生したときにマネージャーの動向にアンテナを張る必要がある。
業務で専門性を活かしたり独自の専門性を培ったりすることを期待しなければ、研究開発職は気楽に働ける利点がある。
どの分野でもData Drivenな手法を目にする機会が増えている。
チームの方向性を模索するためには再現実装を行う必要が出てくるが、手法自体を実装できても、再現に必要なデータは得られない。
最近だとDataset自体を公開する論文も増えているが、全体としてはまだまだ少ない。
特にデータの取得自体に多額の金額が必要なDatasetに関しては、ごく少数のSampleが公開されていれば良い方である。
そのため、
2. 公開RepositoryにあるModel fileをそのまま使う
結果として、商用利用不可のデータに対しても「どの公開Model fileが『我々のProduct』に適しているのか」といった建設的な議論が生じる。
概念実証段階では問題がないという示唆に富んだ考えに基づいているのだろう。
なお、「将来的にデータを買えば良い」もしくは「将来的にデータを取得する設備を買えば良い」という有益な意見がマネージャーから得られることがある。
この意見は「独自に予算を獲得してデータを購入してほしい」という期待が込められている。
企業研究開発職は積極的に内外へ働きかけて、予算を獲得することも重要である。
そのため外部ネットワークと通信を挟むツールに関しては基本的に使えない。
どうしても使いたいツールに関しては外部部署へ使用許諾を投げると、慎重な審査の結果、稀に期待に添う結果を得られる。
特に公開Datasetが置いてあるような社外DBへのアクセスは漏洩リスクが大きく、アクセス自体禁じられている。
以上の点は意図しない誤操作による漏洩を予防しており、エンジニアは安心安全な環境で開発に取り組める。
企業で働いていると、同じテーマで一丸となって開発に取り組むことがある。
研究開発職でのチーム開発は作業分担を行わず、複数人で同じテーマに取り組み、蠱毒的に一番有用な手法を採用するという手順を取る。
結果として、6ヶ月程度の作業が弾け飛ぶことはあるが、有用な手法を採用し続けるには仕方がない。
なお、稀に複数人で 共有Productを開発する場合がある。
この場合も打ち合わせは基本的に少ないため、担当箇所に関しては互いに察する必要がある。
当然、作業箇所が被ってしまい、1週間程度の作業が消し飛びがちになる。
作業が被ってしまうと機嫌を損ねてしまうエンジニアへのケアも、企業研究開発職には必要な’スキルである。
また打ち合わせ不足の結果、特定開発者の作業負担が大きくなることが多い。
このような場合、Documentationをしっかり行い、作業負担の軽減を試みるのが入社以前の考えであった。
しかし、Documentationはエンドユーザ向けに用意するものであるという考えが中心的であった。
これは「作業担当者を特定の人材のみに限定して評価を容易にする」意図があるのだろう。
個人至上主義と複数人での楽しいチーム開発を両立するには仕方がないのかもしれない。
いじょうなチーム開発ができるのは研究開発職の醍醐味と言える。
知財以外は無関係な部署や閑職部署へぶっ飛ばされるのでこれ見てその感想にはならない
54
