基幹システムの刷新は決まったものの、社内に要件をまとめられる人がいない。経営層からは「コンサルを入れたほうがいいのでは」と言われるけれど、コンサルと大手SIer、いつも頼んでいる開発会社の違いがはっきりしない。費用感も見えないまま、どこに相談すればいいのか迷う。この段階で検索している方は多いと思います。
判断の軸はひとつです。コンサルに頼むかどうかは会社の規模や予算ではなく、上流・進行管理・実装という3つの層のうち、どの層が自社に欠けているかで決まります。欠けていない層まで外に出すと費用が跳ね上がり、判断のたびに他社の意見待ちになって進みも遅くなります。この記事では、依頼先ごとの役割の違い、外に出せる範囲と自社に残る仕事、費用の構造、丸投げを防ぐ依頼書の書き方、そして使わないほうがよいケースまで整理します。
この記事のポイント
- コンサルに頼むかは、上流・進行管理・実装のどの層が社内に欠けているかで決まる
- 業務要件の確定と最終的な意思決定は外に出せず、必ず自社に残る
- 費用は人月と期間で決まるため、頼む範囲を区切ることが唯一の抑え方になる
- 社内に要件を書ける人がいて対象範囲も小さいなら、開発会社に直接頼むほうが早い
目次
基幹システム刷新でコンサルに頼める範囲
まず、依頼先の種類と役割を整理します。看板の違いよりも「実際にどの工程に入ってくれるのか」を見たほうが判断しやすいので、そこを軸に見ていきます。
コンサル・大手SIer・専業開発会社の違い
刷新の相談先は、大きく3種類に分かれます。それぞれ得意な領域と費用の重さが違います。
| 依頼先 | 得意な役割 | 向いている規模 | 注意点 |
|---|---|---|---|
| ITコンサル | 現状分析・構想策定・要件定義の伴走・選定支援・進行管理 | 全社横断や複数部門にまたがる刷新 | 実装は別会社になるため引き継ぎが発生する。単価は高め |
| 大手SIer | 上流から実装・運用まで一括で請ける | 大規模・複数拠点 | 実装に協力会社が入ることが多く、体制が大きい分費用も重い |
| 専業の開発会社 | 実装と、業務に踏み込んだ設計 | 単一業務から中規模 | 社内調整や全社の構想づくりまでは支援が薄い場合がある |
ただし、この区分は年々あいまいになっています。SIerが上流の業務分析や構想策定に踏み込む一方で、コンサル側も実装に近い支援を手がけるようになりました。会社の看板で判断せず、提案書に書かれた担当範囲と、実際に入る人の役割で見てください。
相談の順番としては、まず今の開発会社や取引のあるSIerに「上流から入れるか」を聞いてみるのが早いです。そこで対応できないと分かった範囲が、外部の支援を検討する対象になります。
外に出せる仕事は上流・進行管理・実装の3層
刷新プロジェクトの仕事は、3つの層に分けて考えると整理しやすくなります。上流は「何を作るか」を決める層で、現状業務の棚卸し、要件の整理、移行方式の選定が入ります。進行管理は課題管理やスケジュール、複数ベンダーの調整を回す層です。実装は「どう作るか」で、設計・開発・テスト・データ移行の作業そのものを指します。
大事なのは、自社に欠けている層だけを外に出すことです。たとえば実装の管理は情シスでできるけれど業務要件をまとめる人がいないなら、上流だけを支援してもらえば足ります。逆に要件は書けるが複数ベンダーの調整が回らないなら、進行管理だけを外に出す形になります。
3層すべてを1社に任せると、判断のたびに同じ会社の見解しか出てこなくなります。特に、上流を担った会社がそのまま実装も請ける場合、その会社が作りやすい方式に寄った提案になっていないかを自社で検証できません。全部任せる前に、どの層なら自社で持てるかを一度書き出してみてください。
外に出しても自社に残る仕事
どこまで外部に頼んでも、自社から動かせない仕事が2つあります。ひとつは業務要件の確定、つまりどの業務をどう変えるかの決定です。もうひとつは意思決定で、費用と期間、優先順位をどこで線引きするかの判断です。
コンサルは選択肢と論点を整理し、比較材料を用意してくれます。ただ、決めるのは自社です。ここを「専門家が決めてくれる」と期待して依頼すると、報告書は出てくるものの社内の合意が進まないという状態になりがちです。プロジェクトの最初に「決める人」を1人立てて、その人が週次で判断する形を作ってください。
IT側の判断ができる人が社内にいない場合は、支援の形そのものを変える選択肢もあります。プロジェクト単位のコンサルではなく、継続的に相談できる技術責任者を外部から迎える形です。役割と費用感はレンタルCTOとは？役割と費用相場・選び方で整理しています。
丸投げにならない依頼書に書くこと
支援を依頼するときにいちばん効くのは、頼む前に条件を文章にしておくことです。ここが曖昧なままだと、成果物が報告書1冊で終わったり、稼働が想定より薄かったりといったズレが起きます。
支援を依頼するときに先に決めること
- 成果物の形（現状業務フロー図・要件一覧・RFP・評価表など、何が納品されるか）
- 判断権の所在（どの決定を自社が行い、どこまでを提案にとどめるか）
- 稼働の量と体制（週何日・誰が入るか。担当者の名前と役割まで）
- 引き継ぎ条件（実装を担う会社へ何をどの形式で渡すか）
- 期間と終わり方（どの状態になったら支援を終えるか）
特に見落とされやすいのが引き継ぎ条件です。上流支援の成果物が抽象的な報告書だけだと、実装会社が読んでも見積もりが作れず、要件定義をもう一度やり直すことになります。実装会社がそのまま使える粒度で受け取ることを、契約前に条件として書いておいてください。
進行管理を外に出す場合は、支援会社が持つ権限も明確にします。課題の管理と報告までなのか、ベンダーへの指示まで含むのかで動き方が変わるためです。この線引きの実務はPMOでベンダーコントロールを強化する役割と導入ポイントで詳しく扱っています。
基幹システム刷新のコンサル費用と選び方
次は費用と選び方です。ここでは会社名の順位付けはせず、何に対して払っているのかという構造と、見極めるための確認事項を整理します。
コンサル費用は人月と期間で決まる
支援の費用は、単価×投入人数×期間で決まります。多くの場合は成果物に対してではなく稼働に対して払う形なので、期間が延びればそのまま費用が増えます。ここが実装の請負契約と大きく違う点です。
金額の目安としては、構想策定や要件定義の伴走で数百万円から1,000万円超、全社規模で長期間の支援になると数千万円に達する例もあります。期間の感覚は、構想策定で2〜3か月、要件定義の伴走で3〜6か月、進行管理は開発期間中ずっと、というのが一般的です。ただしこれはあくまで一般的な目安で、範囲と体制によって大きく変わります。実際の判断は個別の見積もりで確認してください。
見積もりを受け取ったら、前提になっている期間と投入人数を必ず確認してください。「6か月・シニア1名とメンバー1名」といった前提が変われば総額も変わります。刷新そのものの費用構造とあわせて考えたい場合は、基幹システム刷新の費用相場はいくら？内訳と見積もりの読み方で内訳の見方を整理しています。
費用を抑えるなら頼む範囲を区切る
稼働に対して払う契約では、値引き交渉より範囲の区切り方のほうが効きます。全工程の伴走をやめて、必要な部分だけに絞る発想です。
区切り方の例を3つ挙げます。ひとつ目は、最初の2〜3か月だけ上流に入ってもらい、以降は自社と開発会社で進める形。ふたつ目は、自社で作った要件のレビューだけを依頼する形。みっつ目は、選定に使う評価表と質問状の作成だけを頼み、実際の面談は自社で行う形です。
どの区切り方でも共通する条件は、支援が終わったあとに自社で続けられる状態で終わることです。成果物を「自社の担当者が説明できる形」にしてもらうよう依頼時に伝えておくと、支援終了後に手が止まりません。
支援会社を見極める4つの確認事項
提案を比べるときは、実績の社名リストではなく次の4点を確認してください。
- 同業種・同規模の実績で、どの工程をどこまで担当したか
- 実際に入る担当者の名前・経験年数・稼働率（提案時の説明者と着任者が違うことがある）
- 成果物の実物サンプル（守秘の範囲で、粒度が分かるものを見せてもらう）
- 実装を担う会社との関係（系列や紹介手数料があるかどうか）
4つ目は特に注意して確認してください。支援会社が特定の製品や実装会社と強くつながっている場合、選定支援が形式的なものになり、比較の意味が薄れます。「今回の選定で紹介手数料が発生する関係先はありますか」と直接聞いて構いません。
比べ方としては、同じ質問を各社に投げて回答を並べるのが確実です。会社ごとに提案の書式が違っても、質問をそろえれば差が見えます。RFI（情報提供依頼書）テンプレートを使うと、会社情報・実績・対応方針・概算の費用感を同じ形式で集められます。
コンサルを使わないほうがよいケース
支援を入れないほうが早く進む場合もあります。次の条件が重なるときは、いったん外部支援なしで検討を進める判断もあり得ます。
| 条件 | そう判断できる理由 |
|---|---|
| 社内に要件を書ける人がいる | 上流の層が埋まっているため、支援の主目的がなくなる |
| 対象が単一業務で範囲が小さい | 関係部門が少なく、調整に第三者を挟む必要が薄い |
| 予算が限られている | 稼働に払う費用が、実装に回せる予算を削ってしまう |
| 既存の開発会社が業務を理解している | 現状の棚卸しにかかる時間が短く、上流から任せやすい |
使わない場合の代わりの手として、開発会社に要件定義から入ってもらう形があります。提案を受ける段階で「上流の整理も支援できるか、その担当は誰か」を確認しておけば、実務上はコンサルに近い役割を担ってもらえることもあります。
もうひとつは、要件定義書や見積もりが固まった時点だけ第三者にレビューを依頼するスポット活用です。全期間の伴走より費用が軽く、判断の妥当性は確認できます。全部か無しかで考えず、必要な瞬間だけ借りる発想を持っておくと選択肢が増えます。
基幹システム刷新のコンサルに関するよくある質問
- Q. 大手SIerと専業の開発会社では、どちらに頼むべきですか？
- A. 対象範囲の広さで決まります。複数部門にまたがり、拠点も分かれているなら、上流から運用まで一括で持てる大手SIerのほうが調整の手間が減ります。一方で対象が販売管理など特定の業務に絞られていて、その業務に詳しい会社が見つかるなら、専業の開発会社のほうが費用も意思疎通の速さも有利です。規模で自動的に決まるものではないので、まず対象範囲を確定させてから相談先を絞ってください。
- Q. 進行管理だけを外部に頼むことはできますか？
- A. できます。PMOという形で、課題管理・スケジュール管理・複数ベンダーの調整だけを支援してもらう契約は一般的です。この形を選ぶときは、支援会社がどこまでの権限を持つのかを先に決めておいてください。報告と課題整理までなのか、ベンダーへの指示まで含むのかで、社内の負荷も費用も変わります。
- Q. コンサルを入れると刷新の失敗を防げますか？
- A. 防げる部分と防げない部分があります。要件の抜けや進行の遅れは、経験のある支援が入ることで見つかりやすくなります。ただし、業務のやり方を変える社内合意や、現場が新しい運用を受け入れるかどうかは外部では動かせません。失敗の原因が社内の合意形成にある場合は、支援を入れても同じ場所で止まります。
- Q. 支援の契約はどの形が一般的ですか？
- A. 稼働に対して払う準委任契約が中心です。成果物を確定させて請負にする形もありますが、上流の支援は範囲が動きやすいため、準委任で期間と人数を決める形が多くなります。準委任では期間が延びると費用も増えるので、契約時に前提の期間と、延長する場合の条件を確認しておいてください。
