業務コンサル出身者がIT案件に越境するための具体的ステップ
フリーコンサル市場で最もチャンスが大きいのは、業務とITの境界を越境できる人材だと前の記事で書きました。しかし「越境すべき」と言われても、具体的に何をすればいいのかがわからなければ動けません。
この記事では、業務コンサル出身者がIT案件に参画するための具体的なステップを、PERSONAの案件実態に基づいて解説します。逆方向——IT出身者が業務案件に越境するケースについても最後に触れます。
なぜ今、越境が必要なのか
業務案件とIT案件の境界が曖昧になっています。PERSONAの案件でも「バックオフィス業務のDXにあたり、業務の見直しとSaaS選定を同時に行う」という案件が増えており、これは業務案件ともIT案件とも分類できます。PERSONAでは案件の3分類（戦略・業務・IT）をおおよそ1:1:1の比率で常時100件以上保有しており、両方の要素を持つ案件も増加しています。
企業側も「業務がわかる人」と「ITがわかる人」を別々にアサインするよりも、両方わかる1人にまとめて任せたいというニーズが強まっています。越境できる人材は、案件の選択肢が広がるだけでなく、より上流のポジションで参画しやすくなります。
実際の企業の声：なぜ越境人材を求めるのか
PERSONAを通じてアサインされた企業の担当者から聞かれる典型的なコメントをいくつか紹介します。
製造業のCIO： 「IT部門だけでシステム導入を進めても、現場の業務を理解していないため要件がズレる。業務コンサル出身でITもわかる人に橋渡しをしてもらいたい」
金融機関のDX責任者： 「システム会社の提案は技術的には正しいが、我々の業務の複雑さを理解していない。業務の現実を踏まえてIT要件に落とし込める人が欲しい」
このように、企業は技術的な実装よりも「業務とITの翻訳」ができる人材を強く求めています。
業務コンサルがIT案件に入るための3ステップ
ステップ1：「IT案件」の中身を正しく理解する
業務コンサル出身者がIT案件を敬遠する最大の理由は「自分はコードが書けない」という思い込みです。しかし、フリーコンサル市場のIT案件の大半は、コーディングを求めていません。
IT案件で求められるのは以下のような役割です。
PMO： プロジェクト全体の進捗管理、課題管理、ステークホルダー間の調整。業務改革プロジェクトのマネジメント経験があれば、IT PMOにも十分対応できます。
要件定義の上流： ユーザー部門のニーズを整理し、システムの要件に落とし込む工程。これはまさに「業務を理解した上でIT要件を定義する」仕事であり、業務コンサルの経験が直接活きます。
ベンダー選定・コントロール： SaaSやパッケージの選定、導入ベンダーとの折衝。業務側の要件を把握した上で、ベンダーの提案を評価する能力が求められます。
実例：業務コンサル出身者のIT PMO成功事例
PERSONAの登録者で、Big4出身の業務プロセス改善コンサルタントが、大手製薬会社のERP導入PMOを担当したケースがあります。彼は最初「ERPの技術的な詳細はわからない」と不安を感じていましたが、実際の業務では以下のような場面で業務コンサル経験が威力を発揮しました。
- ユーザー部門が「現在の業務フローを変えたくない」と主張した際に、業務の本質的な目的から整理し直し、システム要件との合理的な着地点を見つけた
- ベンダーの提案内容を、技術的な詳細ではなく「実際の業務運用で問題が生じないか」の観点から評価し、致命的な見落としを事前に発見した
- プロジェクトの遅延要因が技術的問題ではなく「部門間の業務責任の境界が曖昧なこと」だと特定し、組織面から解決策を提示した
結果として、このPMOは「IT専門家よりも現実的で実行可能性の高いマネジメントをしてくれる」とクライアントから高く評価され、プロジェクト完了後も別のIT案件で継続してアサインされています。
ステップ2：SaaSツール1つを使い倒す
IT案件に参画する上で最も実践的な準備は、1つのSaaSツールを自分で使い込むことです。
おすすめはSalesforce、ServiceNow、SAP S/4HANA（デモ環境）、あるいはkintoneのようなノーコード/ローコードプラットフォームです。すべてを学ぶ必要はありません。1つだけで構いません。
目的は「システム導入プロジェクトで何が起きるかを体感する」ことです。設定の難しさ、カスタマイズの限界、データ移行の手間——これらを自分の手で経験していれば、IT案件のクライアントやベンダーとの会話で具体的な議論ができるようになります。
具体的な学習アプローチ
単にツールを触るだけではなく、以下のような実践的なアプローチを推奨します。
1. 自分の業務で実際に使ってみる： たとえばSalesforceなら、自分のコンサル営業活動の案件管理に使用する。kintoneなら自分の経費管理アプリを作成する。実際の業務で使うことで「システムに合わせて業務を変える必要性」を体感できます。
2. 困りポイントを記録する： 「この設定がなぜこんなに複雑なのか」「なぜこのデータ形式でないと取り込めないのか」といった疑問を記録する。これらは実際のIT案件で必ず出てくる課題であり、体験していれば的確な助言ができます。
3. 他人に教えてみる： 同僚や知人に基本的な使い方を教えてみる。教える過程で「ユーザーがどこでつまづくか」がわかり、これがIT案件での要件定義やユーザートレーニング設計に直結します。
ステップ3：低稼働のIT案件で経験を積む
いきなりフルタイムのIT PMO案件に入るのはハードルが高いです。まずは稼働率20〜40%のIT関連案件でサブの立場で参画し、実務経験を積むことをおすすめします。
PERSONAでは稼働率10%から案件を取り扱っているため、メインの業務案件を60%で回しながら、IT関連案件を20%で並行することが可能です。こうすれば収入を維持しつつ、新しい領域の経験を積めます。
低稼働案件での効果的な学び方
低稼働のIT案件では、以下の点を重視して経験を積んでください。
専門用語の習得： IT案件特有の用語（API、インターフェース、マスタデータ、ワークフロー等）を文脈で理解する。辞書的な知識ではなく「この場面でこの言葉が使われる意味」を掴む。
ベンダーとの会話パターン： ベンダーがどのような提案ロジックを使うか、どこで曖昧な表現を使うかを観察する。「カスタマイズ要否の判断基準」「追加費用が発生するタイミング」など、パターンを覚える。
プロジェクト特有のリスク： 業務案件にはない「技術的なボトルネック」「システム間連携の複雑さ」「データ品質問題」などのIT案件特有のリスクを体感する。
越境の自己評価チェックリスト
IT案件への参画前に、自分の準備度を確認してください。
「業務コンサル→IT案件」越境の準備確認：
| チェック項目 | ✓ | コメント | |---|---|---| | SaaSツールを1つ自分で設定して使った経験がある | ☐ | Salesforce、ServiceNow、kintone等 | | 「要件定義」という工程が何をするのか説明できる | ☐ | 業務要件をシステム要件に落とす作業 | | ベンダーの提案書を評価した経験がある | ☐ | どのポイントを見るかわかるか | | IT PMOの役割を一言で説明できる | ☐ | プロジェクト全体の進捗管理・課題管理 | | クラウド（AWS/Azure等）の基本的な概念を知っている | ☐ | IaaS/PaaS/SaaSの違い程度 |
全項目に✓がつかなくても参画できます。3つ以上あれば「IT案件の中の業務側ポジション」への参画は十分可能です。0〜2個の場合は、PERSONAのエージェントに相談しながら、まず低稼働のIT関連アドバイザリーから始めることを推奨します。
越境しやすいIT案件のタイプ
業務コンサル出身者が最初に狙うべきIT案件のタイプを3つ挙げます。
1. 業務部門主導のSaaS導入プロジェクト。 情報システム部門ではなく、業務部門がオーナーとなるSaaS導入は、業務理解が最も重要です。業務フローの設計、ユーザー要件の整理、導入後の定着支援——業務コンサルの経験がそのまま活きます。
2. DX推進の企画フェーズ。 「何をデジタル化すべきか」を検討する上流フェーズは、業務のどこに課題があるかを特定する仕事であり、IT知識よりも業務理解が優先されます。
3. IT PMOの中の業務側ワークストリーム。 大規模システム導入プロジェクトのPMOの中で、業務側のステークホルダー管理や業務要件の整理を担当するポジション。IT全体を見る必要はなく、業務側の橋渡し役としての参画です。
失敗しやすいパターンとその対策
越境を目指す際によくある失敗パターンと、その対策を整理します。
失敗パターン1：技術知識の不足を過度に心配する
症状： 「プログラミングができないから」「データベースの知識がないから」と参画を諦める。
対策： IT案件の9割は技術的な実装ではなく、要件整理・プロジェクト管理・ステークホルダー調整が中心。業務コンサルの経験で十分対応できる領域に焦点を当てる。
失敗パターン2：IT専門用語に圧倒される
症状： 会議でAPI、DB、UIなどの専門用語が飛び交い、議論についていけなくなる。
対策： 事前に基本的な用語集を作成し、プロジェクト開始前にクライアント・ベンダーに「業務側の観点から参画するため、技術的な詳細は他のメンバーに任せ、業務要件の整理に集中したい」と役割分担を明確化する。
失敗パターン3：ベンダーの提案を技術面で評価しようとする
症状： ベンダーの技術的な提案内容を理解しようと無理をし、本来の強みである業務面での評価を疎かにする。
対策： 「技術的な実現可能性は他のメンバーに判断してもらい、自分は業務運用面での実現可能性・リスクを評価する」と割り切る。むしろ業務面での厳しいチェックこそが、越境人材としての価値。
IT出身者が業務案件に越境する場合
逆方向の越境についても触れておきます。
IT出身者が業務案件に入るためのポイントは「クライアントの業務を自分の目で見る経験」を持つことです。システムの裏側ではなく、ユーザーが実際にどう業務を回しているかを観察する。この視点の転換が越境の鍵です。
具体的には、業務ヒアリングの経験、業務フロー図の作成経験、現場のファシリテーション経験。これらを持っていれば、業務案件への参画ハードルは大きく下がります。
IT出身者の越境成功事例
PERSONAのアクセンチュア出身の登録者で、もともとSAP技術者だった方が、業務プロセス改善案件で成功したケースがあります。彼の場合、SAP導入プロジェクトで常にエンドユーザーの業務を詳細にヒアリングしていた経験が、純粋な業務改革案件でも活きました。
「システムありきで考えない業務設計」「現場の実態を踏まえた実現可能性の評価」など、IT経験があるからこそできる業務コンサルティングとして、クライアントから高く評価されています。
まとめ
業務コンサルからIT案件への越境は「コードを書けるようになること」ではありません。IT案件の中にある「業務理解を必要とするポジション」に入ることです。
PERSONAでは業務案件とIT案件がおおよそ同じ比率で存在し、AI関連案件も全体の10〜20%を占めています。登録者1,200人以上の大手ファーム出身者（MBB・Big4・アクセンチュアがほぼ等分）の中には、すでに越境を実現している方も多数います。越境に興味がある方は、ファーム出身のエージェントに「今の経験でどのIT案件に入れるか」を相談してみてください。
▶ あなたの業務経験が活きるIT案件を、具体的にご提案します：https://persona-consultant.com/