大手企業向けのシステム開発では、稟議・調達・合意形成・移行にかかる時間を見込んで納期を組みます。
期間を左右するのはコード量や処理量よりも組織や商習慣で、中小企業やスタートアップと同じ速さで進めると、着手前に想定が崩れてしまいます。
▼全体ガイドの記事
・大手企業向けのシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
大手企業向け開発で期間が読みにくくなる理由
大手企業向け開発では、作る時間より決める時間が全体の期間を左右します。複数の部門や階層が投資に関わり、承認と合意形成に時間がかかるためです。
中小企業やスタートアップでは、経営者一人が決め、要件や予算も短期間で確定することが多くあります。
期間を決めるのは組織の意思決定
期間を見積もるときは、作業工数と社内の意思決定にかかる時間を分けて捉える必要があります。
- 段階的な稟議：担当者から課長、部長、本部長、役員まで、承認を順に得ていく流れ。
- 差し戻し：各階層の質問や指摘への対応で、資料の修正が生じます。
- 工程への反映：誰がいつ決めるかを確認し、その待ち時間を工程表に見込みます。
承認だけで数週間から数ヶ月かかることも珍しくありません。こうなると、開発会社の作業は止まっていなくても、判断待ちで次の工程に進めません。
実際にプログラムを書く時間より、社内で判断を待つ時間がスケジュール全体に占める割合は大きくなります。
特に、意思決定のリードタイムを工程に含めないと、工数見積もりが正確でも納期はずれ込みます。
工数だけでなく、決定者と決裁の手順を把握することも欠かせません。
「大規模システム」とは異なる視点であること
大手企業向けシステムと大規模システムは、複雑さの種類が異なります。
- 技術的な規模：数十万行のコード、膨大な処理量、数十万人規模の利用者などが要因になります。
- 組織的な複雑さ：稟議、監査、グループ統制など発注者側の要件が要因です。
- 両方が重なる場合：技術と組織の両面を、別々に見積もります。
たとえば、大手企業の一部門で使う小規模なシステムは、技術的に巨大とは限りません。一方で、発注者の組織が複雑でガバナンスが厳格なため、稟議・決裁や情報セキュリティ監査、グループ統制が伴います。
大手企業が全社の大規模基幹システムを刷新する場合は、この二つが同時に働きます。
本記事が扱うのは、組織文化や商習慣が期間に及ぼす影響です。
この違いを押さえておくと、期間が長引く原因を技術だけに求めずに済みます。
稟議・決裁フローがスケジュールに与える影響
大手企業では、一定金額以上のシステム投資に社内承認が必要で、その承認は複数の階層や部門をまたぎます。
稟議の待ち時間は工程表に現れにくいものの、全体期間を左右する律速要因です。ここでは、承認と予算年度、部門間の認識差を取り上げます。
複数階層の承認と予算年度の制約
承認者の階層は、一般に投資額が大きいほど増えます。そのため、金額と予算年度の条件は早い段階で確認しておく必要があります。
- 少額の投資：部門長までの承認で足りる場合があります。
- 数千万円から数億円規模：役員会や取締役会の決議が必要なこともあります。
- 年度途中の未計上投資：翌年度の予算編成を待つことになります。
承認者ごとに予定を調整し、説明や質問への回答、指摘の反映を行うため、時間がかかります。
予算枠がなければ発注できないこともあり、年度途中に必要性が生じても、発注が翌年度4月以降にずれ込む場合があります。予算サイクルによっては、着手が数ヶ月から半年以上先になることも珍しくありません。
開発会社がすぐ始められると提案しても、着手時期は発注側の予算サイクルに合わせることになります。
まずは、希望時期から逆算して、稟議を上げる期限を早めに確認します。
経営層と情報システム部門の認識ギャップ
稟議では、経営層と情報システム部門の認識差が差し戻しを招きます。
- 経営層：費用対効果や投資回収の見通しを厳しく確認する立場です。
- 情報システム部門：現場の実態や技術的な必要性を把握しています。
- 説明の課題：必要性を経営層が納得する言葉で示しきれないことがあります。
ギャップが埋まらないと、費用対効果の再確認や他社事例の追加を求められ、意思決定が停滞します。
経営層や担当役員が数年単位で交代する文化もあり、中長期投資の決裁が先送りされる傾向が指摘されています。さらに、後任者の方針で投資が一から見直されることもあります。
トップダウンで刷新を決める例は少なく、障害や法改正など外部からの圧力をきっかけに動き出すのが実態です。開発会社は、意思決定の構造を踏まえて経営層向けの資料を整え、決定を前に進める支援もできます。
ベンダー選定・調達プロセスの長期化
大手企業では、ベンダー選定自体が独立した長いフェーズとなり、開発前に数ヶ月かかることもあります。
中小企業では知り合いに相談して発注することもありますが、大手企業では公平性・透明性・妥当性が問われるため、複数社を正式に比較します。
情報システム部門とベンダー選定委員会による調達
選定の進め方と評価範囲を早い段階で把握し、RFIやRFPへの対応時間を見込んでおくことが大切です。
- 情報提供依頼（RFI）：実現したいことを伝え、各社の実績や技術力を確認する段階です。
- 提案依頼書（RFP）：具体的な要件を記したうえで、正式に提案を募ります。
- 複数軸で評価：機能・価格・実績・サポート体制などの観点で比べます。
その後、ベンダー各社は提案書と見積もりを提出します。
多くの場合、情報システム部門が主導し、選定委員会や購買・調達部門も関わります。利用部門や購買が審査し、場合によっては監査やセキュリティ部門も加わります。
評価は、複数部署が加わる委員会形式で行うのが一般的です。部署が増えるほど、評価基準のすり合わせや意見集約に時間がかかります。また、公平性を保つため、発注側は質問期間やプレゼン機会を各社に均等に設けます。
選定の手続きを丁寧に進めるだけでも、数週間から数ヶ月かかることがあります。
開発会社も、RFPや質問への対応に人員を割く必要があります。一方で、こうした対応は受注と、その後の円滑な立ち上げにつながります。
要件すり合わせと選定に要する期間の実態
ベンダーを選ぶ前に、社内の要求や移行手法をすり合わせる時間も見込みます。
- 経営層の要望：できるだけ安く、早く進めたいという意向。
- 現場の要望：安全で確実な現行踏襲を求める声。
- 合意形成：コストと効果をシミュレーションして、関係者間で共有します。
要求の乖離を埋めないまま進めると、発注内容が定まらず、RFPが二転三転します。関係者間で合意を形成する作業にも、相応の時間がかかります。
選定フェーズだけで1〜2ヶ月かかることが一般的で、規模や関係者の数によってはさらに長くなります。
設計3ヶ月、開発6ヶ月という見積もりでも、その前に要件調整と選定で数ヶ月かかる場合があります。そのため、相談を始めてから稼働までの体感期間は長くなります。
現実的な日程を立てるには、着手前の助走期間も含めます。
レガシー基幹との並行運用が伸ばす移行期間
大手企業は、長年使い込んだ既存の基幹システムを抱えていることがほとんどです。これがいわゆるレガシーシステムや塩漬けシステムにあたります。
一斉切り替えは事業停止のリスクが大きく、現実的ではありません。そのため、新旧の並行運用が移行を長引かせます。
ビッグバンを避ける段階的移行と並行稼働期間
事業を止めるリスクを避けるため、移行方式と検証期間を分けて計画しておきます。
- ビッグバン方式：一度に切り替えると障害時に事業全体が止まりかねません。
- 段階的移行：影響の小さい機能や一部拠点から切り替えます。
- 並行稼働：新旧を同時に動かして安全性を確かめます。
経理・在庫・受発注・生産などを担う基幹システムは、障害時に事業全体へ影響します。そのため大手企業では、一斉移行を基本的に避けます。
段階的なインクリメンタル移行は安全性が高い一方で、新旧を維持しながら進めるため、完了まで長くなります。
並行環境の構築では、新旧の依存関係とデータの流れを整理して、接続テストを行います。さらに、切り替えのたびに処理結果が一致するかも検証します。
新システムの開発期間とは別に、安全な移行を完了するまでの期間を見込みます。段階的移行には時間がかかりますが、大規模障害からの復旧リスクを考えると、確実な計画といえます。
現行踏襲へのこだわりによる要件確定の遅れ
要件確定には、技術面だけでなく、現場の業務変更への合意も影響します。
- 現行踏襲の要望：機能や操作性を今までと同じにしたいという声が出ます。
- Fit to Standard：標準に業務を合わせる考え方でも、現場の抵抗が生じることがあります。
- 判断基準の共有：受け入れる要望と線を引く要望を事前に決めます。
長年同じシステムと業務で働く現場からは、同じ機能や操作性を求める声が出ることも珍しくありません。こうした声は要件定義の妨げになります。
発注側は、各機能が本当に必要か、なくすとどんな支障が出るかを確認し、現場を説得します。調整が続くと、要件が固まらず、設計や開発も遅れます。
合意した要件が別部門の反対で覆ることもあり、要件定義は行きつ戻りつ進みます。現場の合意形成にかかる時間は、事前に見積もりにくいものです。
発注側の推進担当者と開発会社が現行踏襲の範囲と判断基準を共有しておくと、要件確定の遅れを抑えられます。
現実的なスケジュールを守る発注側の役割
開発工数そのものより、稟議・調達・合意形成・移行などの組織的な工程が期間を左右します。
これらは開発会社だけでは動かせないため、発注側が主体的に関わることが納期を支えます。
意思決定のリードタイムの工程への組み込み
発注側は、意思決定の待ち時間を独立したタスクとして計画し、期限と次工程への影響を明らかにします。
- 承認会議：役員会の承認に3週間かかることがあります。
- 予算枠：確保のために翌四半期まで待つことになります。
- 選定委員会：審査に1ヶ月を要することがあります。
設計・開発・テストは計画に入りやすい一方で、意思決定の待ち時間は抜けがちです。
計画の初めから工程に含めて、何をいつまでに決めるかを明記します。そのうえで、会議日や予算編成から逆算して、資料準備や社内調整を始める時期を定めます。
開発会社も、意思決定の周期を早い段階で聞き取り、判断の遅れが全体を何日ずらすかを共有して、適切な時期の決断を促します。
待ち時間を見えないコストとして放置せず、工程上の項目として扱うことが、基本的な遅延対策です。
決裁権限とプロジェクトオーナーの事前設計
発注側は、開始前に最終決定者と裁定方法を明確にし、推進体制を整えます。
- プロジェクトオーナー：多くの場合、担当役員クラスを明確に立てます。
- 部門横断の体制：責任と権限を持つ代表者が要望を判断する形。
- 推進担当者の時間：レビューやテスト、社内調整に専念できる予定を確保します。
複数部門が関わる大手企業では、意見が対立したときの裁定者が曖昧だと、決定が長引きます。そのため、最終決裁者とルールを事前に定めておきます。
会議では、各部門の要望をその場で決められる運営を目指します。持ち帰りと次回回答を繰り返すと、意思決定が遅くなります。
発注側の担当者は、要件確認やテスト参加、成果物レビューを担い、社内調整にも関わります。
推進担当者が本業と兼任していると、作業が回らず停滞することがあります。
プロジェクトに専念する人材と時間を確保し、ベンダーと議論できる体制を作ります。そのうえで、発注側が主導し、開発会社に任せきりにしないことが納期を守る鍵です。
まとめ
大手企業向け開発の期間を左右するのは、コード量や処理量より稟議・調達・合意形成・移行などの組織的なプロセスです。これらの待ち時間は工数見積もりに現れにくく、工程に入れないと納期が崩れます。
複数階層の承認や予算年度の制約、部門間の認識差が期間を積み上げます。さらに、選定手続き、レガシーとの並行運用、現行踏襲の要望も、期間を押し上げます。
納期を守るには、意思決定の時間を工程表に明記し、決裁権限とオーナーを定めることが欠かせません。発注側は推進体制を整えたうえで、自社の意思決定の流れに沿う日程を開発会社とすり合わせます。
▼全体ガイドの記事
・大手企業向けのシステム開発の完全ガイド
▼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を創業。