研究開発職の転職ポートフォリオ|論文だけで戦わない見せ方
- 研究開発職のポートフォリオは論文リストだけでなく、担当範囲・課題・打ち手・数値成果の4点を1件あたり300字前後で言語化することが起点になると僕は考えています。
- ディープテック採用では、公開できない研究内容を抽象化して見せる技術が重要で、成果の粒度を「何を何%改善したか」の目安値で示すと選考通過率が体感的に上がります。
- 論文がない実務エンジニアでも、社内非公開プロジェクトを守秘に配慮して構造化すれば、研究者と同じ土俵で評価される職務経歴書を作れます。
「論文はそれなりにあるんですが、書類選考で落ちるんです。何が足りないんでしょうか」——先日、ある材料系の研究者の方からこう相談を受けました。
研究開発職やロボティクスエンジニアの転職では、こうした声を本当によく聞きます。論文数も学会発表も申し分ないのに、なぜか書類で止まる。逆に、論文はほとんどないのにスムーズに面接まで進む実務エンジニアもいる。この差はどこから来るのか。今日はその話を、僕なりの整理でお伝えできればと思います。
0.(結論)論文は「材料」であって「見せ方」ではない
先に結論から言ってしまうと、僕が個人的に考えているのは、研究開発職の転職書類で足りていないのは業績ではなく「翻訳」だ、ということです。論文リストは技術力の証拠にはなりますが、採用担当者が知りたいのは「うちの事業で、この人が何をどう動かしてくれるか」です。そこを埋める作業を、僕はポートフォリオと呼んでいます。
ここで言うポートフォリオは、デザイナーが作品集を並べるような華やかなものではありません。担当した研究や開発を、課題・打ち手・成果という因果でつなぎ直した、いわば「翻訳文書」です。これがあるかないかで、書類の通過率は体感的にかなり変わると感じています。
1. なぜ論文リストだけでは伝わらないのか
論文には論文の作法があります。新規性・再現性・客観性を重んじ、自分の貢献をあえて抑制的に書くことも多い。共著であれば、どこまでが自分の手柄なのかも外からは分かりません。これは学術の世界では正しい振る舞いですが、転職市場では情報が欠落しているように見えてしまいます。
採用側の目線に立つと、彼らが知りたいのはおおむね次の三つです。
- この人は、どんな種類の課題に強いのか
- 行き詰まったとき、どう突破する人なのか
- その成果は、事業や製品にどう効いたのか
論文タイトルの羅列からは、この三つがほとんど読み取れません。だからこそ、別の文書で補う必要があるわけです。身近なたとえで言えば、料理人が「作ったメニューの名前」だけを並べても、その人がどんな厨房を回せるかは分からない。仕込みの段取りやトラブル対応まで語って初めて、雇う側は安心できる。ポートフォリオはその段取りを見せる書類だと考えています。
もう一つ付け加えると、論文が評価される場面は限られています。大学発スタートアップや研究所に近い環境なら論文の重みは大きいのですが、量産や事業化のフェーズに入っている企業では「製品にどう効いたか」のほうが優先されます。応募先がどのフェーズにいるかで、論文の位置づけは変わる。ここを読み違えると、せっかくの業績が空回りしてしまうと感じています。
2. 1プロジェクトを300字で構造化する
では具体的にどう書くか。僕が薦めているのは、主要プロジェクトを1件あたり300字前後で、次の四つの要素に分けて言語化する方法です。
- 担当範囲:チームの中で自分が何を持っていたか。役割と裁量を明示する。
- 課題:何が技術的な壁だったか。ここが物語の核になる。
- 打ち手:その壁に対して、自分がどう考え、何を試したか。
- 成果:結果としてどうなったか。可能な範囲で数値を添える。
この四つが因果でつながっていることが大切です。「課題が難しかった→こう考えた→こう手を動かした→こう改善した」という流れが一本の線になっていると、読み手はあなたの再現性を信じられます。逆に、成果だけが唐突に出てくると、運が良かっただけに見えてしまう。
件数の目安は、主要プロジェクト3〜5件。全体でA4換算2〜3枚に収まる程度が、僕の体感では読み手に負担をかけない分量です。多ければ良いというものではなく、むしろ焦点がぼやけて逆効果になることが多いと感じています。
作業の所要時間についても触れておきます。慣れていない方だと、1件を300字にまとめるだけで最初は1〜2時間かかることが多い印象です。ただ、2件目、3件目は型が固まって速くなります。全体で半日から1日を見ておけば、応募に耐える初稿は仕上がると考えています。一気に完璧を目指さず、まず粗く4要素を埋めてから磨くほうが、結果的に早く終わります。
3. 公開できない研究をどう見せるか
ディープテック領域で必ずぶつかるのが、守秘義務の壁です。「成果は出したが、内容は一切話せない」というケースは珍しくありません。ここで多くの方が、書けないから空欄にしてしまう。これは非常にもったいない。
僕が提案しているのは、抽象化して見せるという技術です。固有名詞や図面、具体的な設計値そのものは伏せる。しかし成果の「性質」と「桁感」は残す。たとえば製品名を出さずに「量産ラインの歩留まりを二桁パーセント改善」「センサ処理の遅延を約半分に短縮」といった書き方であれば、守秘に配慮しつつ実力の輪郭は伝わります。
大事なのは、書類はあくまで輪郭を示すもので、詳細は面接で口頭補足する前提にしておくことです。書類に全てを書き込もうとすると守秘リスクが上がりますし、逆に何も書かないと読み手が判断材料を持てない。この中間、「桁感と課題構造は見せるが固有情報は伏せる」あたりが安全圏だと考えています。心配な場合は、公開範囲を採用側に確認しながら段階的に開示する姿勢を示すと、それ自体が誠実さの評価につながることもあります。
4. よくある失敗と対処
ここで、僕が実際に相談を受ける中でよく見る失敗を、対処とセットで整理しておきます。自分に当てはまるものがないか、確認してみてください。
| よくある失敗 | 対処の方向性 |
|---|---|
| 論文タイトルだけを羅列 | 各論文に「事業でどう効くか」の一文を添える |
| 成果だけ書いて過程が抜ける | 課題→打ち手→成果の因果を必ずつなぐ |
| 専門用語が多すぎて人事に伝わらない | 一次読者が非専門家である前提で言い換える |
| 守秘を恐れて空欄が多い | 桁感と課題構造だけ残して抽象化する |
| 全応募先に同じ内容を送る | 応募先の事業に効く経験を前面に入れ替える |
特に多いのが、二つ目の「成果だけ書いて過程が抜ける」パターンです。優秀な方ほど結果に自信があるので、そこだけを大きく書いてしまう。ですが読み手は再現性を見たいので、どう辿り着いたかが抜けると評価しづらい。逆に言えば、過程を丁寧に書くだけで印象が変わることが多いと感じています。
5. 論文がない実務エンジニアの戦い方
ここまで論文を持つ研究者を前提に書いてきましたが、ロボティクスや先端製造の現場には、論文をほとんど書かずに高度な実務を積んできたエンジニアの方が大勢います。こうした方々こそ、ポートフォリオの効果が大きいと僕は思っています。
論文がないと不利に感じるかもしれませんが、実は「動かした実物」があるという強みがあります。社内の非公開プロジェクトでも、前章の抽象化の作法を使えば、研究者と同じ土俵に立てる職務経歴書を作れます。むしろ、事業会社の採用側から見れば「学術論文よりも、製品に近い経験のほうが即戦力として読みやすい」という声もある。ここは自信を持っていいところだと考えています。
実務エンジニアの場合、次のような軸で成果を整理すると伝わりやすい印象があります。
| 整理の軸 | 書き方の例(抽象化済み) |
|---|---|
| 性能改善 | 制御周期の高速化、精度誤差の低減幅 |
| コスト・工数 | 開発期間の短縮、部品点数の削減 |
| 技術的難所 | 他社が実現できていなかった条件をクリアした経緯 |
| 横展開 | その技術が別製品・別ラインに波及した範囲 |
数値はいずれも「目安値」で構いません。正確な機密数字を出す必要はなく、桁感と改善の方向が分かれば十分です。研究者とエンジニアを比べると、研究者は「なぜ動くか」の理解の深さ、エンジニアは「確実に動かした範囲の広さ」がそれぞれ武器になります。自分がどちらの色を持っているかを自覚して、そこを厚く書くのが得策だと考えています。
6. 出す前に確認したいこと
最後に、ポートフォリオを送り出す前のチェックについて触れておきます。技術的な正しさに気を取られて、読み手への配慮が抜けることがよくあるためです。
まず、専門外の人事担当者が最初に目を通す可能性を意識してください。研究職の採用でも、一次スクリーニングは技術に詳しくない担当者が行うことが少なくありません。専門用語を並べるだけでなく、「何のための技術で、どんな価値を生んだか」を一文で添えておくと、この段階での取りこぼしが減ると感じています。
次に、守秘義務の再確認です。前職の契約内容によっては、抽象化しても触れてはいけない領域があります。判断に迷う部分は、無理に載せず面接での口頭説明に回すのが賢明です。この線引きの慎重さ自体が、次の職場での信頼につながります。
そして、応募先ごとに強調点を入れ替えること。同じポートフォリオでも、材料開発の会社とロボティクスの会社では、前面に出すべきプロジェクトが変わります。全社に同じ内容を送るより、応募先の事業に効く経験を頭に持ってくるだけで、印象は大きく変わると考えています。この差し替えは10分程度の作業ですが、効果は大きいと感じています。
(結論)翻訳できる人が、選ばれる
あらためて整理すると、研究開発職の転職で問われているのは業績の多寡そのものよりも、その業績を採用側の言葉に翻訳できるかどうかだと僕は考えています。論文リストは材料。ポートフォリオは、その材料を「事業にどう効くか」へ翻訳した文書。この翻訳ができる人が、結果として選ばれていく場面を、僕は何度も見てきました。
論文があってもなくても、公開できてもできなくても、やるべきことは同じです。課題・打ち手・成果を因果でつなぎ、桁感で示し、読み手の目線で並べ替える。地味な作業ですが、ここに時間をかける価値は十分にあると感じています。
皆さんいかがでしたでしょうか。ご自身の経験をどう言語化すればいいか迷う場面もあるかと思います。ディープテッククエストでは今日もがんばりましょう。
よくある質問
Q. 研究開発職の転職に論文リストは必須ですか
必須ではないと僕は考えています。論文は技術力を裏づける有力な材料ですが、企業側が本当に見たいのは「どんな課題を、どう解いて、どれだけ動かしたか」です。論文がない実務エンジニアでも、担当範囲・技術的な壁・打ち手・数値成果を1件300字前後で構造化すれば十分に戦えます。むしろ論文だけを並べて実務貢献が見えない書類のほうが、事業会社では評価されにくい印象があります。
Q. 公開できない研究内容はポートフォリオにどう書けばいいですか
抽象化して書くのが基本です。製品名や具体的な数値そのものを伏せても、「歩留まりを二桁%改善」「処理時間を約半分に短縮」のように成果の性質と桁感は伝えられます。守秘義務に触れる固有名詞や図面は載せず、課題の構造と自分の思考プロセスを見せることが大切だと僕は考えています。面接で口頭補足する前提で、書類は輪郭を示す程度に留めるのが安全です。
Q. ポートフォリオはどのくらいの分量が適切ですか
僕の体感値では、主要プロジェクト3〜5件を各300字前後、全体でA4換算2〜3枚が目安です。多すぎると読み手が焦点を絞れず、少なすぎると再現性が伝わりません。件数より、1件ごとに課題・打ち手・成果の因果がつながっているかが重要です。技術スタックや役割は箇条書きで補い、本文は成果の物語に集中させると読みやすくなると考えています。
IT人材業界20年、ギークリー創業を経て現職。個人として通算4,200名のキャリア面談を実施してきた経験に基づき監修しています。本文中の年収・難易度等は独自ガイドの目安値であり、個人の経験・企業により変動します。