※本記事には広告・プロモーションが含まれています。
発注・要件定義・ベンダ管理・プロジェクト運営・経営層への説明——事業側からシステムを動かしてきた経験は、IT系の転職市場でも評価される実務経験です。手を動かしてコードを書く仕事ではなくても、その経験は職種によって明確な評価軸を持っています。
一方で、「コーディングができない自分は、IT転職メディアの情報を参考にしていいのだろうか」と感じる方も少なくありません。実際、多くのIT転職記事はエンジニア職を前提に書かれているため、発注・企画・推進側の経験がどう評価されるかは分かりにくいのが実情です。
本記事では、事業会社側のIT実務経験を「評価される言葉」に変換する3つの軸と、自己PR・面接で伝える際の注意点を解説します。
本記事は、事業会社側でシステムの企画・発注・プロジェクト運営を担ってきた運営者自身の実務経験をもとに構成しています。市場動向・求人傾向に関する部分は公式情報・公開データを参照しています。
この記事でわかることは、次のとおりです。
- 実務経験の種類によって評価軸が変わり、コーディング経験の有無だけでは測れないこと
- 発注・企画、ベンダ調整、経営層への説明という3つの経験を評価される言葉に変換する方法
- 自己PR・面接で誇張せず具体性を出すためのポイント
発注・調整・経営層説明の経験は、それぞれ別の評価軸で見られる
IT系の求人は、実装を担うエンジニア職だけではありません。事業会社側でシステムを動かしてきた経験は、次のような職種で評価対象になります。
- IT企画、DX推進、社内システム企画
- ITコンサルタント、PMO、ビジネスアナリスト
- プロダクトマネージャー（実装は伴わない立場）
- プリセールス、カスタマーサクセス
これらの職種で見られるのは、コーディングスキルではありません。「事業の課題をどう整理したか」「複数の関係者をどう動かしたか」「技術の話をどう意思決定につなげたか」という実務経験です。
評価される経験は、大きく次の3つに整理できます。
- 事業の課題を整理し、システムの企画・発注につなげる力
- 複数のベンダー・関係者を調整し、プロジェクトを前に進める力
- 技術の話を経営層の判断につなげる力
まずは、この3つの評価軸の全体像を見ていきます。
評価される3つの実務経験
この3つの評価軸は、それぞれ求められる場面が異なります。
| 評価軸 | 評価される場面 | 相性のよい職種例 |
|---|---|---|
| 事業の課題整理・企画発注力 | 新規システム導入、業務改善プロジェクトの立ち上げ期 | IT企画、DX推進、ITコンサルタント |
| マルチベンダ調整力 | 複数の開発会社・運用会社が関わる大規模プロジェクト | PMO、プロジェクト推進、社内システム |
| 経営層への説明・投資判断力 | 投資稟議、経営会議での意思決定支援 | ITコンサルタント、DX推進、事業企画 |
3つすべてを高いレベルで持っている必要はありません。自分の経歴の中でどの軸が強いかを見極め、その軸を中心に職務経歴・自己PRを組み立てることが、転職活動を進めやすくするポイントです。
ここから、それぞれの軸を具体的にどう言語化するかを見ていきます。
①事業の課題を整理し、システムの企画・発注につなげる力
システムを「作る」立場ではなく「動かす」立場だからこそ見えてくるのが、業務の課題です。現場で何が非効率なのか、何が経営判断のボトルネックになっているのかを理解したうえで、それを解決する手段としてシステム導入・改修を企画します。発注先を選定するまでの経験は、エンジニアには代替しにくい一次情報です。
筆者も事業会社側でシステムの企画・発注に携わる中で、業務部門が抱える課題をヒアリングし、それを技術的な要件に翻訳する場面がありました。そのうえで、ベンダーへの発注要件としてまとめる、という流れを繰り返してきた場面が多かったように思います。技術的に正しい提案かどうかだけでなく、実際の業務でどう使われるかまで見据えて要件を整理する必要がある、と感じることが多くありました。
この経験は、次のように言語化できます。
- 課題を主語にする：「システム導入を担当」ではなく、「業務部門の◯◯という課題を整理し、システム導入によって解決する企画を立案した」のように、課題→解決策の流れで書く
- 発注先選定の判断軸を示す：コスト・実績・技術力のどれを重視して選定したか、複数候補をどう比較したかを添える
- 業務側の視点を強調する：技術の詳細ではなく、「現場でどう使われるか」まで踏まえて要件を整理した経験は、事業会社側ならではの強みとして伝わりやすい
②複数のベンダー・関係者を調整し、プロジェクトを前に進める力
大規模なシステムプロジェクトほど、開発ベンダー、運用ベンダー、業務部門、情報システム部門など、関わる相手が多くなります。それぞれの立場で優先順位や言い分が異なる中、プロジェクトを前に進める力は、コーディングとは別の専門性です。
筆者自身も、複数のベンダーが関わる案件で、各社の主張や進捗報告のフォーマットがそろわず、全体像が見えづらい場面を経験してきました。関係者ごとの論点を横並びで整理し、「今どこで意思決定が必要か」を明確にすることを意識していました。そうすることで、プロジェクトが前に進みやすくなる、という実感を持つことが多かったように思います。
この経験は、次のように言語化できます。
- 調整した相手と論点を具体化する：「ベンダーと調整」ではなく、「開発ベンダーと運用ベンダーの間で生じた仕様認識のずれを整理し、業務部門を交えた合意形成の場を設計した」のように書く
- 役割の範囲を明確にする：指示・決定権があったのか、調整・提案にとどまったのかを明記する
- 難しい局面での行動を示す：意見が対立した場面で、何を基準に落としどころを見つけたかを添えると、再現性のある力として伝わる
③技術の話を経営層の判断につなげる力
技術的に正しい提案でも、経営層が投資判断できる形になっていなければ、プロジェクトは前に進みません。技術の内容を、コスト・効果・リスクという経営判断の言葉に変換する力は、事業会社側の実務を長く担ってきたIT×ビジネス人材の強みです。
筆者も、機械学習・数理最適化を使った検証プロジェクトに、発注者側のPMとして携わってきました。データサイエンティストの検討結果を、経営層への説明資料に落とし込む役割を担ってきました。技術的な精度の高さだけを説明しても、投資判断にはつながりません。業務上の効果、実施しない場合のリスク、費用、実現時期を並べて、意思決定できる形に整理する必要がある、という場面が多かったように思います。
この経験は、次のように言語化できます。
- 判断材料をセットで示す：「経営層へ説明した」だけでなく、効果・リスク・費用・時期のどれを軸に説明したかを添える
- 技術領域を明記する：機械学習、クラウド移行、基幹システム刷新など、扱った技術領域を具体的に書くと、担当できる案件の幅が伝わりやすい
- 結果につながったことを示す：説明した結果、投資承認・稟議通過・方針転換など、何が決まったかまで書く
自己PR・面接で伝える際の注意点
3つの評価軸を言語化できたら、自己PR・面接では次の点に注意すると、内容の具体性と信頼性が高まります。
- 「課題→役割→行動→成果」の順で話す：抽象的な「調整力があります」ではなく、具体的な案件を1つ挙げ、この順序で説明すると伝わりやすくなります
- 成果を数字だけに頼らない：売上・コスト削減額を出せない案件でも、「合意形成にかかった期間が短縮された」「手戻りが減った」など、変化を具体的に説明できれば十分です
- 技術の深さを誇張しない：実装経験がないことを隠すのではなく、「技術を動かす側」としての役割を明確にし、必要な場面では「実装はエンジニアが担当し、自分は要件整理・調整・経営層説明を担った」と正直に伝えるほうが、面接での信頼につながります
- 3つの評価軸のうち、強い軸から話す：すべてを均等に語ろうとせず、自分の経歴で最も具体的なエピソードがある軸を中心に組み立てると、話に一貫性が出ます
職務経歴書への落とし込み方（フォーマット・記載例）は、別記事「IT×ビジネス人材の職務経歴書の書き方」でも詳しく解説する予定です。
まとめ
事業の課題整理・企画発注力、マルチベンダ調整力、経営層への説明・投資判断力という3つの評価軸があります。この軸に沿って言語化すれば、コーディング経験がなくても実務経験を武器にできます。
自分の経歴の中でどの軸が強いかを見極め、「課題→役割→行動→成果」の順で具体的に言語化することが、自己PR・面接での説得力につながります。
転職エージェントを利用する際も、この3つの評価軸を面談で伝えることで、担当者が求人と結びつけやすくなります。まずは総合型エージェントで市場全体の求人を確認し、経験が明確な領域では特化型エージェントも併用するとよいでしょう。
あわせて、「dodaのIT転職での評判・口コミ」「Geeklyの評判・口コミ」「リクルートエージェントのIT転職活用法」も確認してみてください。エージェントごとの特徴を把握する際に役立ちます。
