システムコンサルの上流工程は、小規模案件で1〜3ヶ月、中規模案件で3〜6ヶ月、大規模案件で6ヶ月〜1年以上が目安です。
対象は要件定義から発注先決定までで、開発は含みません。期間を短く見積もると、後続ベンダーとの契約や稼働時期がずれやすいため、次の4項目を分けて確認します。
- 対象規模：小規模・中規模・大規模ごとに、上流工程の目安が変わります。
- フェーズ配分：現状業務分析・要件定義、RFP作成、ベンダー選定それぞれの期間
- 遅延要因：合意形成の停滞、要件の後出し、ベンダー回答の遅れ
- 依頼先の体制：業界の知見や実績、中立性、発注者側の協力工数
▼全体ガイドの記事
・システムコンサルの完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
システムコンサルの定義（ITコンサル・IT戦略コンサルとの違い）
システムコンサルは、特定の1つのシステム導入・刷新案件を対象に、現状業務の分析と要件定義、仕様策定（RFP・RFIの作成）、ベンダー選定支援を行う、個別プロジェクト単位の技術顧問サービスです。開発期間を正しく見積もるには、まずこの対象範囲を明確にしておく必要があります。
ここで大切なのは、システムコンサル自身は開発会社ではないという点です。実際のシステム構築・実装は、選定されたSIerやパッケージベンダーが担います。
つまり「開発期間」は、コンサルが担う上流工程、発注先を決めるまでの期間を指します。この見積もりを誤ると、設計・開発・テストを含むプロジェクト全体の納期計画が根本から崩れてしまいます。
システムコンサルの支援範囲（要件定義・仕様策定・ベンダー選定支援）
システムコンサルの支援範囲は、大きく4つの工程に分かれます。現状業務分析（As-Is分析）では、業務の手順や帳票、既存システムの制約を整理し、非効率や属人化を洗い出します。要件定義では、あるべき業務の姿（To-Be）を描き、機能要件と非機能要件を関係部門と合意します。
仕様策定・RFP作成では、要件を発注先が見積もれる粒度の文書にまとめ、予算・スケジュール・評価基準を明記します。ベンダー選定支援では、複数候補の提案書と見積もりを、機能適合性と技術力、コストと実績の観点で客観的にスコアリングし、発注先の決定を後押しします。
この4工程を通じて、システムコンサルは発注者側の代理人として、情報の非対称性を埋める役割を担います。ただし支援は「作るものを決める」ところまでで、実装は選定後のベンダーが担う点を理解しておくことが大切です。
ITコンサル・IT戦略コンサルとの対象範囲の違い
スケジュールを見積もるうえで混同を避けたいのが、ITコンサル・IT戦略コンサルとの対象範囲の違いです。ITコンサルは、複数システムや全社IT基盤全体を対象に、インフラ刷新、システム統廃合、IT投資対効果の評価までを技術の視点で扱う総合的なサービスです。そのため、対象が全社に及び、期間も半年〜数年単位になりやすいのが特徴です。
IT戦略コンサルは、情報システム部門が主体となって、組織全体の3〜5年単位の中長期計画を策定する、上流の意思決定支援です。中期IT計画やグランドデザインを描き、IT投資計画やITガバナンスまで含めて全社の方針を決めます。
これに対しシステムコンサルは、全社計画の中で方向性が固まった段階から関与し、要件定義、仕様策定、ベンダー選定支援に対象を絞ります。言い換えれば、IT戦略コンサルがいつどのシステムを刷新するかを決めるのに対し、システムコンサルは決まったシステムを誰にいくらで作らせるかを詰める、より下流・実行寄りの支援です。
システム規模・種別別の開発期間の目安
システムコンサルが担う上流工程（現状業務分析〜要件定義〜仕様策定〜ベンダー選定支援）の期間は、対象システムの規模、業務の複雑さ、関係部門の数によって大きく変わります。
ここで示すのは、コンサルが関与する要件定義から発注先決定までの期間です。その後にベンダーが担う設計・開発・テストの期間は、別途上乗せされる点に注意が必要です。
基幹システムやERPの導入・刷新は、開発・移行まで含めると中堅企業で半年〜1年半程度、大企業では1年〜2年以上を要するのが一般的です。コンサルが担う上流工程は全体スケジュールの出発点にあたり、ここでの見積もり精度が全体計画の前提になります。
小規模・中規模・大規模：規模別の期間の目安（1〜3ヶ月／3〜6ヶ月／6ヶ月〜1年以上）
小規模案件（単一部門の業務システム新規導入や、既製のSaaS・パッケージ製品の導入検討）は、1〜3ヶ月が目安です。単一部門に閉じるため、「絶対に外せない業務要件」を中心に整理し、標準機能で賄える範囲を見極めて絞り込むのが近道です。
中規模案件（基幹業務システムの部分刷新や複数部門にまたがる業務の刷新）は、3〜6ヶ月が目安です。部門間の要望調整やデータ連携方式の検討が積み重なるため、期間が延びます。このため、最初にスコープを明確に線引きすることが期間を守る鍵で、部分刷新のつもりでも対象が膨らみ、大規模案件並みの期間がかかるケースは少なくありません。
大規模案件（基幹システムの全面刷新・全社的なERP導入等）は、上流工程だけで6ヶ月〜1年以上を要することも珍しくありません。部門横断の合意形成、膨大なデータ移行方針の検討、ブラックボックス化した現行システムの解析が期間を押し上げ、新規導入よりも長期化しやすい傾向があります（出典: IPA「DXレポート」）。まず影響度の大きい管理系業務から段階的に広げるのが現実的です。
フェーズ別のスケジュールと期間配分
システムコンサルが担う上流工程は3フェーズに分けられ、最初に現状業務分析と要件定義、次に仕様策定とRFP作成を行います。最後はベンダー選定・評価・発注先決定です。仮に中規模案件で上流工程全体を5ヶ月と見積もる場合、現状業務分析・要件定義に約2.5〜3ヶ月、仕様策定・RFP作成に約1〜1.5ヶ月を配分します。残るベンダー選定・評価・発注先決定は、約1〜1.5ヶ月が標準的です。
最初の現状業務分析・要件定義に全体の半分以上の時間を割くのが定石です。ここを圧縮しすぎると、後工程で手戻りが必ず発生します。
3フェーズの作業内容と期間の目安
現状業務分析・要件定義（小規模0.5〜1.5ヶ月、中規模2〜3ヶ月、大規模4〜6ヶ月）は、最も時間を要する工程です。現場ヒアリングで現状を整理し、あるべき姿を描いて関係部門と合意します。工期遅延の理由は要件定義が上位で、約4割のプロジェクトが要件定義の問題で遅れたという調査もあります（出典: 一般社団法人 日本情報システム・ユーザー協会「企業IT動向調査」）。
続く仕様策定・RFP作成（小規模2週間〜1ヶ月、中規模1〜1.5ヶ月、大規模1.5〜2ヶ月）では、要件をベンダーが正確に見積もれる粒度のRFPにまとめます。記述が曖昧だと前提がばらばらな提案が集まり、比較評価が困難になるため、RFPの精度が手戻りを左右します。
最後のベンダー選定・評価・発注先決定（小規模2週間〜1ヶ月、中規模1〜1.5ヶ月、大規模1.5〜3ヶ月）では、RFPを複数候補に配布します。候補の評価は、機能適合性と技術力、コストと実績を、あらかじめ決めた配点でスコアリングして行います。価格の安さだけで選ばず、複数の評価者が同じ基準で合議することが、結果として納期と品質を守ります。
要件定義の期間を短縮する方法
要件定義の期間を縮める最も効果的な方法は、「決められる状態」を早くつくることです。要件定義が長引く原因の多くは作業量よりも、関係者の意見がまとまらず、要件がいつまでも確定しないことにあります。
そのため、期間の短縮は合意形成の進め方を設計し、意思決定を滞らせないことにつながります。具体的には、現場ヒアリングの対象者と論点を事前に設計して手戻りをなくします。集まった要件に優先順位を付け、意思決定者が短時間で取捨選択できるようにすることも有効です。
現場ヒアリングの設計と関係者の巻き込み方
行き当たりばったりにヒアリングを重ねると、同じ話を聞き直したり、後から重要な関係者が見つかって手戻りが起きたりして、期間が延びます。これを防ぐには、着手前に「誰に、何を、どの順番で聞くか」を設計しておくことが大切です。
実務担当者には業務手順や困りごとを、意思決定権を持つ責任者にはあるべき姿や優先方針を確認するように、相手に応じて論点を変えると効率的です。ヒアリングで得た内容はその都度要件に反映し、次回の冒頭で認識の相違がないか確認すると、後戻りを最小限に抑えられます。
プロジェクトの初期段階で各部門のキーパーソンを正式に巻き込み、「この人たちが合意すれば要件は確定する」という体制を明確にしておくと、後半での蒸し返しを防げます。逆に責任者を巻き込まないまま要件を固めると、最終段階で異論が出て、大きな手戻りになりがちです。
要件の優先順位付け（MoSCoW法など）と合意形成
要件定義を短縮するもう一つの鍵は、集まった要件に優先順位を付けて合意形成を進めることです。要望をすべて同列に扱うと要件が膨大になり、一つ一つの可否を延々と議論して期間が長期化します。ここで有効なのがMoSCoW（モスクワ）法です。
要件を「Must（必須）」「Should（推奨）」「Could（可能なら）」「Won’t（今回は見送り）」の4段階に仕分けます。これにより、今回実現すべき要件と見送ってよい要件の線が引け、限られた期間と予算の使い道について合意を得られます。優先順位が明確なら、途中でスケジュールが逼迫しても、CouldとWon’tの要件を落として納期を調整できます。
特に大切なのは、Must要件を絞り込むことです。あれもこれも必須だと主張しているうちは、要件は固まりません。たとえば在庫管理システムの刷新なら、「リアルタイムの在庫引き当て」はMust、「需要予測に基づく自動発注」はCouldと仕分けて、Mustだけで成立するかを検証します。
納期を左右する遅延要因と対策
個別のシステム案件で上流工程が遅れる原因は、全社IT基盤を扱うITコンサルの技術的制約とは異なり、「関係者間の合意形成の停滞」と「要件の後出し」が大半を占めます。特定業務のシステム化は現場部門の理解と協力がなければ前に進まないため、人と組織の動きがスケジュールを左右します。
裏を返せば、これらの遅延要因は進め方の工夫によって、発注者側でコントロールできる余地が大きいということです。
個別システム案件で典型的な3つの遅延要因
上流工程で納期が遅れる典型的な要因は3つあります。1つ目は現場の合意形成の停滞で、現場担当者や部門長の意見がまとまらず、要件が確定しない状態が続くケースです。工期遅延理由の上位は要件定義フェーズに集中し、その多くは合意形成の難しさに由来します（出典: 一般社団法人 日本情報システム・ユーザー協会「企業IT動向調査」）。
2つ目は要件の後出し・追加です。要件定義やRFP配布の後に「実はこの機能も必要だった」という要望が次々と出ると、要件定義に差し戻る往復が起き、上流工程だけで1〜2ヶ月単位の遅延を招きます。
3つ目はベンダー側の提案・見積もり回答の遅れです。RFPの記述が曖昧だとベンダーから質問が相次ぎ、想定以上の時間がかかります。
遅延を防ぐための実務対策
これらの遅延要因を防ぐ実務対策は、フェーズごとに異なります。現場の合意形成の停滞には、プロジェクト初期に意思決定者を明確に定め、各要件に締め切りを設けます。期日までに合意できない論点は、意思決定者がその場で裁定するルールにしておくことが基本です。
要件の後出し・追加には、要件定義の完了時に関係者全員でスコープと要件を正式に確認・合意する「要件凍結」のマイルストーンを設けます。それ以降の追加要望は原則として次フェーズに回すという運用ルールを徹底すると、効果的です。
ベンダー側の回答遅れには、RFPの精度を高めて曖昧さを排除することが最大の予防策です。さらに、要件の検討状況や未決事項を一覧にした管理表を用意し、週次の定例会で進捗を確認すると、問題が小さいうちに手を打てます。
依頼先（システムコンサル）選びが期間に与える影響
同じ規模・種別の案件でも、どのシステムコンサルに依頼するかで、上流工程にかかる期間は大きく変わります。対象業界の業務知見が豊富で、RFP作成やベンダー選定の実績も多いコンサルなら、勘所を押さえた進行で手戻りを減らし、スケジュールを短縮できます。
反対に、業界や業務への理解が浅いコンサルに依頼すると、現状業務の把握だけで想定以上の時間がかかることもあります。
選定時に確認すべきポイント（業界知見・RFP作成実績・中立性など）
期間の観点から確認すべきポイントは3つあります。1つ目は対象業界・業務の知見です。同種の業務システムの要件定義を手がけた経験が豊富なコンサルは、業務の勘所を理解しているため、現状業務分析や要件整理を効率的に進められます。
2つ目はRFP作成とベンダー選定の実績です。過去にどの規模・種別の案件でRFPを作り、ベンダー選定を支援してきたかを確認します。
3つ目は中立性です。特定ベンダーと資本関係や販売代理関係を持つ場合、公平にベンダーを評価できないおそれがあり、社内での再検討によって、かえって期間が延びることもあります。こうした点は、契約前の提案段階で過去の類似案件の概要（対象業務、規模、期間、役割）を共有してもらうと確認できます。
発注前に確認すべき体制・進め方
期間の見通しを立てるには、依頼先の体制と進め方も確認しておくことが欠かせません。担当するコンサルタントの経験とアサイン体制を確かめ、各フェーズで何を受け取れるか、完了の基準はどこかも聞いておきます。加えて、想定期間や、要件凍結と意思決定のタイミングをどう設定しているかを、事前に共有してもらいます。
発注者側に求められる協力工数（ヒアリングへの同席、資料提供、レビューや意思決定への参加）も、確認しておくべき事項です。上流工程は発注者の関与度が期間を左右するため、自社の人員をどれだけ割く必要があるかを事前に把握しておかないと、遅延を招きます。
契約形態（準委任か請負か）も、発注前に取り決めておくべき事項です。準委任契約は柔軟な一方で、進行管理を発注者側でも意識しなければなりません。請負契約は納期が明確になりますが、途中のスコープ変更に追加費用が発生しやすくなります。
まとめ
ここまで、システムコンサルの開発期間・スケジュール・納期について、規模別の期間目安やフェーズ別の配分、要件定義の短縮と遅延対策、依頼先選びの影響を見てきました。スケジュールを正しく見積もるには、ITコンサルやIT戦略コンサルとは異なり、特定の1システムを対象に、上流工程へ絞って支援するサービスだと理解しておくことが鍵です。
上流工程の期間の目安は、小規模案件で1〜3ヶ月、中規模案件で3〜6ヶ月、大規模案件で6ヶ月〜1年以上であり、現状業務分析・要件定義に全体の半分以上の時間を割くのが定石です。ただし、この期間はベンダーが担う設計・開発・テストを含まず、別途上乗せされる点を踏まえて全体スケジュールを描くことが大切です。
個別システム案件の遅延は、技術的な制約よりも合意形成の停滞や要件の後出しに起因することが多いものです。意思決定者の明確化、要件の優先順位付け、要件凍結と変更管理のルールづくりが、納期を守るうえで欠かせません。こうした点を踏まえ、対象業務の知見とRFP作成実績を持つ中立的なシステムコンサルに相談することをお勧めします。
▼全体ガイドの記事
・システムコンサルの完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。