社内独自フレームワークしか触っていないエンジニアの職務経歴書

使用技術の欄に並んだ「自社FW」の三文字を見て、私は思わず「これ、何ができる人なのか分からないですね」と口にしてしまいました。相談に来た方の職務経歴書を、初めて読んだときのことです。

私はIT・Web業界を中心に800名以上の転職支援に携わっていますが、社内独自のフレームワークやライブラリだけで長く開発してきた方の書類は、技術力があるのに読み手に何も引っかからない、というパターンを何度も見てきました。今回は、その経験を求人票の言葉に置き換えて書く手順を、守秘義務の線引きや面接での聞かれ方まで含めてお伝えします。

目次

1. 社内独自フレームワークの経験が職務経歴書で伝わらない理由
2. 「不利」というより「判断材料がない」状態
3. 求人票の言葉は、機能の名前でできている
4. 翻訳の手順は3段、機能の置き換えから始める
5. 第1段：機能を洗い出して一般名に当てる
6. 第2段：設計思想と、独自にした理由を書く
7. 第3段：保守・改修で下した判断を求人票の語に結びつける
8. 利用者・改修者・設計者で担当範囲を書き分ける
9. 利用者：FWの上で業務アプリを作った
10. 改修者：FWそのものにバグ修正や機能追加を入れた
11. 設計者：FWの方針や構造を自分で決めた
12. 守秘義務を守りつつ書ける粒度の線引き
13. Before/Afterで見る、落ちる書類と通る書類
14. Before：名前と動詞で止まった書類
15. After：機能・思想・判断で書き直した書類
16. 面接での聞かれ方と、答えるときの軸
17. 「なぜ独自のフレームワークだったのか」
18. 「今ならOSSで置き換えられるか」
19. 盛らないための線引き、触っていないものは触っていないと書く
20. 個人開発や独学で補った範囲は、実務と分けて書く
21. 技術の言い換えと、持ち運べる仕事のし方は分けて書く
22. 古い技術に偏った経験の見せ方は、他の転職とも共通する
23. よくある質問
24. まとめ

社内独自フレームワークの経験が職務経歴書で伝わらない理由

結論から書くと、書類で伝わらない原因は経験の質ではなく、読み手が検索も比較もできない固有名詞で書かれていることにあります。

採用担当者や現場の面接官は、職務経歴書を読みながら「うちの求人の必須要件と合うか」を探しています。Spring BootやRails、Laravelと書いてあれば、経験年数や規模感を想像して要件と照らせます。ところが「自社FW『◯◯』を用いた開発」と書かれていると、照らす相手がありません。検索しても出てこないので、読み手は想像で補うことすらできず、判断を保留したまま次の書類に移る。私の見る限り、書類選考ではそうした流れになりがちです。

「不利」というより「判断材料がない」状態

自社製フレームワークの経験は転職で不利だ、とよく言われます。私の感覚では、不利というより評価の材料がそもそも渡されていない状態です。

実際の現場では、独自FWの書き方次第で評価が大きく割れます。統計があるわけではなく現場感覚ですが、名前だけを並べた書類は見送られやすく、中身を一般的な言葉に直した書類は同じ経験でも面接に進みやすい、という差は何度も見ています。経験の価値が低いのではなく、価値が読み手に届く形になっていないのです。

もう一つ、独自FWには別の事情があります。フレームワークの中身が一部の担当者にしか分からず、使う側にはブラックボックスになりがちだという点です。これは社内の事情として自然に起きることで、本人の努力不足ではありません。ただ、書類を読む側は「中身を理解して使っていたのか、決まった書き方をなぞっていただけなのか」を見分けようとします。ここが本記事の核心で、後の節で書く「何を分かっていたか」を言葉にする作業がそのまま答えになります。

求人票の言葉は、機能の名前でできている

求人票の必須・歓迎要件を見ると、並んでいるのは「Spring Boot」「RDBの設計経験」「認証・認可の実装」「バッチ処理の設計」といった機能や技術要素の名前です。製品名だけでなく、機能の名前で要件が書かれていることが多い。

つまり、独自FWの経験を「機能の名前」に分解して書けば、製品名がなくても要件と照合できます。次の節から、その分解の手順に入ります。

ちなみに、似た構図は他の転職でも起きます。オンプレミス環境の経験をクラウドの概念に翻訳する話をオンプレ経験をクラウドの言葉に翻訳する方法で扱いましたが、今回の独自FWも「環境固有の名前を機能の言葉に直す」という点で同じ型です。

翻訳の手順は3段、機能の置き換えから始める

私が相談者に勧めているのは、次の3段階です。順番が大切で、先に思想や判断から書き始めると、読み手が何の話か分からないまま進んでしまいます。

まずは第1段の置き換えです。社内FWの機能を一つずつ洗い出して、世の中で通じる名前を当てていきます。

第1段：機能を洗い出して一般名に当てる

最初にやるのは、フレームワークの設計書やソースを開いて、「このFWは何をしてくれるのか」を機能単位で箇条書きにすることです。名前を気にせず、動きだけを書きます。たとえば「URLから担当クラスを探して呼び出す仕組み」「SQLを書かずにテーブルを操作する層」「ログイン状態を確認して画面を出し分ける仕組み」といった具合です。

洗い出しができたら、それぞれに一般的な技術名を当てます。ルーティング、ORM、DI（依存性注入）、認証・認可、バッチ基盤、共通部品、といった名前です。ここで迷ったら、SpringやRails、Laravel、Djangoのドキュメントの目次を眺めると、対応する機能名が見つかります。

次の表は、よくある社内FWの機能と、一般的な技術名、求人票でよく使われる語の対応です。あくまで一例で、自分のFWの実態に合わせて入れ替えてください。

この表を作るだけで、書類の見え方はかなり変わります。ただし、置き換えるのは機能として実際に等価なものだけです。社内FWの機能がSpringのそれと同じ水準かどうか分からないときは、「同等の役割」と書いて、同じものだと言い切らないでください。盛りの話は後で改めて書きます。

第2段：設計思想と、独自にした理由を書く

機能を置き換えただけでは、「この人は使えただけ」に見えます。次に書くのは、なぜそのFWはその形をしていたのかです。

独自FWが生まれた経緯には、必ず事情があります。当時は適当なOSSがなかった、顧客の環境が特殊で標準のFWが動かなかった、ライセンスの問題があった、開発者の入れ替わりが激しく書き方を強制したかった、といったものです。この理由を一言でも言えると、読み手は「ただ古いものを使い続けてきた人」ではなく「選択の背景を理解している人」と受け取ります。

注意したいのは、設計思想は「社内の誰かが決めた理由」を自分の理解として書くことです。自分が設計者でないなら、「と理解している」「と聞いている」と立場を分けて書いて構いません。これは次の節で述べる担当範囲の書き分けにつながります。

第3段：保守・改修で下した判断を求人票の語に結びつける

三つ目が、書類の説得力を最も左右する部分です。独自FWを長く触っていると、バグの調査、仕様の拡張、特定画面の性能改善、といった判断の場面が必ずあります。そこで自分が何を比べて、何を選んだかを書きます。

たとえば「バッチの処理時間が夜間枠に収まらなくなったので、ボトルネックをSQLのN+1に絞り込み、取得のまとめ方を変えて処理時間を短縮した」という経験は、FWが独自でも、そのまま「SQLチューニング」「パフォーマンス改善」という求人票の語に対応します。独自FWは舞台にすぎず、判断の中身は汎用です。

ポイント： 求人票に合わせて書くとは、FWの名前を変えることではなく、判断の中身を求人票の言葉で言い直すことです。名前を消しても成立する経験だけが、翻訳後の書類に残ります。

利用者・改修者・設計者で担当範囲を書き分ける

独自FWの経験で、書類が一番ごちゃつくのが担当範囲です。「FWを使って開発」と「FWを開発」は全く違う経験なのに、同じ「FW開発」と一括で書かれることがよくあります。私は3つの立場に分けて書くよう勧めています。

利用者：FWの上で業務アプリを作った

利用者は、FWが提供する枠組みの上で業務ロジックを書いた立場です。この場合、書けるのは「FWの機能をどう使いこなしたか」です。FWの仕様に沿って画面とデータ処理を作った、という事実に加えて、FWの制約の中で工夫した点（たとえば標準の一覧機能に収まらない要件を、拡張ポイントを使って実現した）まで書ければ、単なる使用経験から一段上がります。

利用者としての経験は、そのままではフレームワークの内部理解を示せません。ですから「FWの内部は未確認、利用者として〇〇を担当」と範囲を明記するほうが、かえって誠実に読まれます。

改修者：FWそのものにバグ修正や機能追加を入れた

改修者は、FW本体のコードに手を入れた立場です。ここは評価されやすい経験で、「既存コードを読み解き、影響範囲を見極めて変更した」という能力が出ます。ソースが公開されていない独自FWの改修は、ドキュメントの乏しい環境での読解力の証明にもなります。

書くときは、修正の件数や頻度ではなく、影響範囲をどう見積もったかに重心を置いてください。たとえばFWのバリデーション部品を直すとき、既存の何十画面に影響するかをどう確認したか、という話です。テストが薄い環境で変更を入れた経験は、レガシーコードの保守の材料として、私は十分に評価できると見ています。

設計者：FWの方針や構造を自分で決めた

設計者は、FWの構造や仕様を決める側にいた立場です。ここまで来ると、職務経歴書では「アーキテクチャ設計」として直接アピールできます。何を共通化し、何を各アプリに任せるかを決めた、拡張点をどう設計したか、といった内容です。

ただし、設計者として書くなら、決めた根拠と結果を説明できる必要があります。面接で深掘りされる部分なので、実際に関わった範囲を超えて書かないようにしましょう。チームで決めた設計の一部を担当しただけなのに「設計した」と書くと、面接で一気に崩れます。

守秘義務を守りつつ書ける粒度の線引き

独自FWの話で書類に手が止まる理由の半分は、「どこまで書いていいのか分からない」ことにあります。私が支援で使っている線引きは、次のとおりです。社内の就業規則や契約が優先されるので、迷うときは上司や人事に確認してください。

基本の考え方は、何をしたか、どう判断したかは書き、どう作られているかの細部は書かないことです。「自社開発の業務アプリケーション基盤（Java）」のように汎用の表現に置き換えれば、名称を出さずに伝わります。

数字については、実測値を桁を丸めて書く程度で十分です。顧客や取引先が特定できる数字や、売上に直結する数字は避けましょう。それでも書き足りなければ、面接で口頭で補う前提にして構いません。書類は入口で、細部を詰める場所ではありません。

NDAや就業規則に関して、なおグレーなときは、書く前に人事や法務に「職務経歴書にこの粒度で書いてよいか」と聞いておくのが確実です。聞いたこと自体を隠す必要はなく、むしろ確認を取って書く姿勢は信頼につながります。

Before/Afterで見る、落ちる書類と通る書類

ここで、私が実際に支援した方の例を挙げます。

Sさんは30代半ばで、製造業向けの生産管理パッケージを自社で作って販売するソフトウェア会社に長く勤めたJavaのエンジニアでした。使っていたのは、社内で作られた独自の業務フレームワークです。画面遷移、DBアクセス、帳票出力、夜間バッチを一式提供するもので、Sさんは後半の数年、FWの保守担当も兼ねていました。

最初の職務経歴書には、使用技術の欄に「自社FW（Java）」、業務内容には「自社FWを用いたパッケージ開発」とだけ書かれていました。応募しても書類がほとんど通らない状態が続き、Sさんは「自社FWだから評価されないのは仕方ない」と考えていたそうです。

Before：名前と動詞で止まった書類

書き直す前の記載は、おおよそ次のようなものでした。

どこが問題かは、もう見えているはずです。FWの名前は読み手に何も伝えず、「開発・保守」は動詞で止まっていて、「深い理解」には中身がありません。求人票に書かれた語と照合できる箇所が、「Java」と「Oracle」の二つしかないのです。

After：機能・思想・判断で書き直した書類

そこで、先ほどの3段で全部書き直しました。

変わったのは、FWの名前が消えて、機能の種類と判断の中身が前面に出たことです。「MVC構成」「データアクセス層」「バッチ実行基盤」「影響範囲の洗い出し」「SQLの見直し」はどれも求人票に出てくる語で、読み手が要件と照合できます。

結果は、書き直し後は書類が通る会社が目に見えて増え、複数社で面接に進み、最終的に1社から内定が出ました。年収はほぼ横ばいでしたが、Sさんが気にしていた「FWしか知らない人」という自己評価が、面接で技術の話をするうちに変わっていったのが印象的でした。もちろん結果は人によって違い、書き直せばすべての書類が通るわけではありません。

面接での聞かれ方と、答えるときの軸

書類が通ると、面接ではほぼ必ず独自FWそのものを問われます。よく聞かれるのは次の2つです。

「なぜ独自のフレームワークだったのか」

聞いているのは、あなたが「選択の背景を理解して仕事をしてきたか」です。「当時は適当なOSSがなく」「顧客の環境の制約で」など、背景を一言で答えられれば十分です。分からない部分は「入社前の経緯なので詳しくは分かりませんが、運用していて感じた利点と課題は〜です」と、自分の観察に切り替えて答えられます。

「今ならOSSで置き換えられるか」

ここで「自社FWが最高です」と答えても、「置き換えは無理です」と投げても、評価は上がりません。見られているのは、今の自分の判断基準を持っているかです。保守コスト、人材の採用しやすさ、セキュリティ更新の追従など、どの観点で比べるかを自分の言葉で述べられると、独自FWを長く触った経験が強みに変わります。

こうした「聞かれ方」まで先回りして準備するのは、書類の書き方と地続きです。経歴を語る順序や、職務経歴書全般の書き方の注意点は、エンジニアが書類選考で落ちる職務経歴書の書き方でも整理しています。

盛らないための線引き、触っていないものは触っていないと書く

翻訳作業で一番気をつけてほしいのが、盛りすぎです。機能を一般名に置き換えるのは正しい作業ですが、使っていないものを使ったかのように書くのは別です。

たとえば社内FWにDIやルーティングの仕組みがあり、Springと似た発想で作られていたとしても、Spring Bootの実務経験があるとは書けません。「DIとルーティングを備えた自社開発のWebアプリケーション基盤を使用」のように、備えている機能だけを書くのが誠実で、面接でも自然に説明できます。Springの経験を問われても、「実務での経験はありません。役割の近い機能は使ってきたので、キャッチアップはできると考えています」と、事実と見込みを分けて答えられるからです。

個人開発や独学で補った範囲は、実務と分けて書く

独自FWだけの経験を補うために、個人開発でSpring BootやRailsを触る方は多いです。これは良いことですが、職務経歴書では実務と個人学習を別の欄に分けて書いてください。

実務経験の欄に混ぜると、面接で本番運用の質問をされて答えられなくなります。分けて書けば、「実務ではこれ、学習ではこれ」と整理された人として伝わり、学習意欲の裏付けにもなります。同じ線引きは、COBOLやVB6からモダン言語への転向でも、独学と実務を区別して書く場面で出てきました。

ポイント： 一般FWの実務経験がないことを隠さないほうが、翻訳した部分の信頼性が上がります。書けない部分を正直に認めている書類は、書けている部分も本当だと読まれます。

技術の言い換えと、持ち運べる仕事のし方は分けて書く

ここまでの翻訳は、機能の名前を一般的な技術名に直す作業でした。これは専門知識や技術にあたる、いわゆるテクニカルスキルの言い換えです。一方、厚生労働省はポータブルスキルを「業種や職種が変わっても持ち運びができる職務遂行上のスキル」と定義し、「仕事のし方（対課題）」と「人との関わり方（対人）」で構成されるとしています。マイナビキャリアリサーチLabの解説でも、プログラミングのような技術はテクニカルスキル、課題解決力やコミュニケーション力はポータブルスキルとして区別されています（参考：マイナビキャリアリサーチLab）。

この区別は、職務経歴書の書き方にそのまま使えます。私は、独自FWの経験を2つの層に分けて書くことを勧めています。

FWの名前は社内でしか通じませんが、技術の層を一般名に直し、仕事のし方の層を具体的に書けば、他社の読み手にも通じます。第3段で書く判断の例は、まさに後者の材料です。

技術スタックの欄そのものの書き方は、dodaのエンジニア向け解説も参考になります。独自FWの欄は、「基盤の種類」と「関わった期間」を添えて書くと、ほかの欄と並べたときに見栄えが揃います。

古い技術に偏った経験の見せ方は、他の転職とも共通する

最後に、独自FWに限らず、特定の環境に最適化された経験をどう見せるかという視点で、関連する話をまとめます。

古いPHP環境で長く保守してきた経験を転職先の選び方にどう結びつけるかは、PHP保守の経験を持つ人が転職先の技術負債を見極める方法で扱いました。モダン化の提案経験を面接でどう語るかは、SIerから自社開発へ移るときの技術的負債の語り方が参考になります。また、環境ごとに言葉が違う点では、ゲームエンジニアのWeb系転職にも似た構図があります。

どの場合も共通しているのは、環境固有の名前で書かず、判断と機能の言葉で書くことです。

よくある質問

独自フレームワークの名称は書かないほうがいいですか。 正式名称は伏せて、「自社開発のWebアプリケーション基盤」のように機能で書くほうが安全で、伝わりやすくもなります。名称が一般に知られているなら書いて構いませんが、社内規定の確認が前提です。

ソースコードやクラス構成をポートフォリオとして見せてもいいですか。 社外に出せるコードではないことがほとんどなので、見せないのが原則です。代わりに、同じ考え方を小さなサンプルとして自作して公開すれば、守秘義務に触れずに設計の理解を示せます。ただし、実務と別物であることは明記してください。

FWの保守担当だった経験は、設計者として書いてもいいですか。 決めた根拠を説明できないなら、改修者として書くのが正確です。保守で下した判断を具体的に書いたほうが、設計者を名乗るより信頼されます。

一般的なフレームワークの経験がまったくなくても応募できますか。 応募できます。ただし、必須要件に特定のFWの実務経験があるものは通りにくいため、歓迎要件にとどまる求人や、言語・設計経験を重視する求人から当たるのが現実的です。

個人開発で補ったことを職務経歴書に書いてもいいですか。 書いて構いません。実務とは別の欄にして、期間と範囲を明記してください。

まとめ

社内独自フレームワークしか触っていない経験が書類で伝わらないのは、価値が低いからではなく、読み手が照合できる言葉で書かれていないからです。機能を一般名に置き換え、設計思想と独自にした理由を書き、保守で下した判断を求人票の語に結びつける。この3段で、同じ経験が全く違う書類になります。

守秘義務は、「何をしたか、どう判断したか」を書き、「どう作られているか」の細部は書かない線引きで守れます。そして、一般FWを触っていないなら触っていないと書き、個人学習は実務と分けて書くこと。この誠実さが、翻訳した部分の説得力を支えます。

独自FWの名前は転職先では通じませんが、そこで磨いた判断力は通じます。「FWしか知らない」と自分を評価している方ほど、まずは自分のFWの機能を箇条書きにするところから始めてみてください。それが、書類を書き直す最初の一歩になります。