事業会社のプロダクト開発の選考フロー・面接対策｜転職で押さえるべきポイント

事業会社のプロダクト開発 選考フロー・面接対策 更新日 2026/8/11

同じ「プロダクト開発」求人に、3つの役割が混ざっている

自社サービスを持つ会社の「プロダクト開発」ポジションは、求人票の見出しがほとんど同じです。プロダクトマネージャー、プロダクトオーナー、企画職、DX推進担当。ところが入社後に任される責務は会社ごとに大きく違い、面接で問われる論点もそれに応じて変わります。

この違いは、感覚の問題ではありません。経済産業省とIPAが策定する「デジタルスキル標準」が、2026年4月16日に公開されたver.2.0で役割の定義を組み替えており、そこに手がかりがあります。

本記事では、この改訂を軸に、事業会社の選考が段階ごとに何を確かめているのかを整理します。なお、記載は2026年8月時点の公開情報にもとづきます。最新の募集要項は各社公式サイトをご確認ください。

国の標準が2026年4月に分けた、3つの責務

IPAの発表によれば、ver.2.0では新事業開発・既存事業の高度化・社内業務の高度化／効率化という従来の3ロールが刷新され、「ビジネスアーキテクト」「ビジネスアナリスト」「プロダクトマネージャー」の3ロールとして再定義されました。DSS-P分冊版に記載された責務は次のとおりです。

注目すべきは最後の一文です。3つのうち、成果責任が明記されているのはプロダクトマネージャーだけです。分析と調整を担うビジネスアナリストの責務には、数字を負う記述が入っていません。

選考が始まる前に、どの責務の枠か確かめる

求人票の職種名からは、この3つを見分けられないことが多くあります。判別の手がかりになるのは、募集背景と評価指標の書かれ方です。

• 事業計画やロードマップの立案が業務内容の先頭に来ている場合、ビジネスアーキテクトに近い枠と考えられます
• 要件の整理・部門間調整・ベンダーとの折衝が中心なら、ビジネスアナリストに近い枠です
• KPIや売上・利用者数への責任が明記されていれば、プロダクトマネージャーの枠です

カジュアル面談の段階で「このポジションが達成を求められている数字は何か」「その数字の決定権はどこにあるか」を聞いておくと、以降の面接で何を語るべきかが定まります。この確認を省いたまま進むと、成果責任のない枠に成果責任の話をぶつけることになり、噛み合わないまま終わります。

一般的な選考ステップと、各段階の観点

公開されている募集要項では、書類選考、現場担当者との面談、部門責任者面接、役員面接という流れが取られていることが多いとされています。段階数や順序は会社と時期により変動します。

書類選考では、担当したプロダクトの規模より、意思決定の位置が見られます。「どの機能を作ったか」ではなく「何を作らないと決めたか」が書かれているかどうかです。

現場担当者との面談では、エンジニアやデザイナーとの働き方が確かめられます。job tagの「システムエンジニア（Webサービス開発）」の職業解説では、要件定義をプロダクトマネージャが担当するか共同で検討し、開発は4〜6人程度のチームで行われることが多いとされています。少人数のチームに入る前提で、役割の線引きをどう考えているかが問われます。

部門責任者面接では、既存システムとの関係が論点になります。事業会社のプロダクトは、単体で完結せず基幹システムや既存の業務フローに接続されます。

役員面接では、投資判断の観点が入ります。この機能にいくらかけ、いつ回収するのかという問いに、事業側の言葉で答えられるかどうかです。

内製の途中にある会社が、確かめていること

事業会社の開発組織は、完成した組織ではなく作っている途中の組織であることが少なくありません。IPAの「DX動向2025」によれば、日本企業はコア事業・競争領域において「外部委託による開発」を行っている回答率が4割弱で最も高く、米国では「内製による自社開発」が5割弱を占めています。

さらに、「必要な部分は内製化済みなので、現在は進めていない」と答えた日本企業は16.7％で、米国とドイツの半分以下にとどまります。内製化を進めるにあたっての課題では、日本は「人材の確保や育成が難しい」の回答率が突出しています。

つまり多くの事業会社にとって、この採用は「回っている開発組織の欠員補充」ではなく「これから内製を立ち上げるための採用」です。面接では、整った環境で成果を出した話より、整っていない状態から何をどう作ったかの話が効きます。

現場主体で作った結果に、答えを持っているか

同じ「DX動向2025」では、現場主体のDXについても日米独が比較されています。日本はメリットとして「業務ユーザーの声が反映されやすい」「自ら問題解決に取組む等のより良い企業文化が醸成される」の回答率が米独より大幅に高い一方、デメリットの回答率が項目を問わず全体的に高く、とくに「システムが乱立し、システム全体の管理が複雑化し、コストが増加する」「現場が独自に導入したシステムで基幹システム等とデータ連携できない」「現場が独自に導入したシステムのセキュリティ対策が不十分」が高くなっています。

この状態に置かれた会社の面接では、作った経験と同じくらい、整理した経験が問われます。乱立したツールを統合した、重複した機能を止めた、権限設計をやり直した——こうした話は華やかさに欠けますが、受け入れ側の課題そのものです。

プレイヤー別に、選考の重心が変わる

事業会社のプロダクト開発は、受け入れ側の類型によって選考の重心が異なります。

自社サービス専業の例としてはメルカリの評判、ディー・エヌ・エーの評判、カカクコムの評判、LINEヤフーの評判が参考になります。非IT事業会社の内製部門についてはクレディセゾンの評判、ファーストリテイリングの評判、イオンの評判を、IT・デジタル子会社についてはJR東日本情報システムの評判、第一生命情報システムの評判をご覧ください。SaaS側の比較にはアンドパッドの評判、カミナシの評判が挙げられます。

見送りにつながりやすい受け答え

• 担当プロダクトの説明が機能一覧になっており、誰のどの行動を変えたのかが出てこない
• 「ユーザーの声を聞いて改善した」と述べるが、聞かなかった声の話がない
• 既存システムや既存部門との調整を、他部署の仕事として切り離して話す
• 内製化への意欲を語る一方で、外部委託を続ける判断があり得ることに触れない
• 志望動機が「事業会社に行きたい」で止まり、その会社のプロダクトの現在地に触れていない

最後の点は志望動機の書き方で詳しく扱っています。

受託開発・SIerから受けるとき

受託側からの応募は珍しくありません。ただし、実績の翻訳が要ります。受託では「仕様どおりに、期日までに、予算内で」が評価軸ですが、事業会社では仕様そのものを決める側に回ります。

職務経歴書では、要件定義の上流に関わった案件を選び、顧客の要望をそのまま実装しなかった場面を書きます。要望を削った理由、代わりに提案したもの、その結果どうなったか。この3点が揃っていれば、決める側の経験として読まれます。

なお、隣接する職種との比較はITコンサルタントの選考フロー、PMOコンサルタントの選考フローも参考になります。

まとめ

事業会社のプロダクト開発の選考は、職種名ではなく責務の枠で理解すると見通しが立ちます。国の標準が2026年4月に分けた3つのロールのうち、成果責任が明記されているのはプロダクトマネージャーだけです。自分が受けている枠がどれかを早い段階で確かめ、それに合わせて語る材料を選ぶことが準備の中心になります。

内製化の途上にある会社が多いという前提も外せません。整った環境の話より、整っていない状態を整えた話が届きます。選考フローや評価の観点は時期により変動しますので、最新の募集要項は各社公式サイトでご確認ください。

よくある質問

Q. プロダクトマネージャー経験がなくても応募できますか。

A. 応募自体は可能です。ただし前述のとおり、募集の枠が分析・調整寄りか、成果責任を伴う枠かで求められるものが変わります。未経験から入る場合は、業務知識を持つ側から要件を決めた経験を軸にするのが現実的です。詳しくは転職難易度で扱っています。

Q. 選考で技術的な質問はどの程度出ますか。

A. 会社と枠によって幅があります。実装を担当しない前提の枠でも、技術的な制約を理解して優先順位を判断できるかは問われる傾向があります。設計の細部より、できないと言われたときにどう扱うかを整理しておくほうが役立ちます。

Q. カジュアル面談で聞いておくべきことは何ですか。

A. 達成を求められる数字、その数字の決定権の所在、開発体制が内製か委託かの構成比、この3点です。いずれも入社後の働き方を左右する一方、求人票には書かれていないことが多い項目です。