基幹システム導入の進め方｜失敗しないための5つの判断ゲートと各フェーズの要点

基幹システム導入の進め方で一番大切なのは、次のフェーズに進む前に「進んでよいか」を判定する場面を決めておくことです。予算超過や工期遅延の多くは、計画と要件定義で決めるべきことが曖昧なまま先へ進むことから生まれます。この記事では、構想策定から稼働後の定着までの5つのフェーズ、各フェーズの終わりに置く5つの判断ゲート（進むか・見直すかを決める関所）の判定基準、公開調査を使った期間の見積もり方、フェーズ単位の発注を、大手コンサルティングファーム出身の専門家の知見と公的な調査をもとに解説します。

基幹システム導入はなぜ予定どおりに進みにくいのか

JUAS（日本情報システム・ユーザー協会）の「企業IT動向調査報告書 2026」（2025年度調査）は、システム開発プロジェクトの品質・予算・工期の状況をプロジェクト規模別に集計しています。調査対象は東証上場企業とそれに準じる企業（回答957社）で、大企業中心の調査である点に注意が必要ですが、傾向ははっきりしています。

「予定どおり以内」は、予算では「予定より抑えて完了」と「予定どおり完了」、工期では「予定より早期に完了」と「予定どおり完了」の合計。残りは「ある程度は予定どおり完了」。人月は、1人が1か月働く作業量の単位です。出典：JUAS「企業IT動向調査報告書 2026」図表7-1-4をもとに作成。

規模が大きくなるほど、品質への不満、予算超過、工期遅延の割合が高くなります。同じ調査では、予算超過・工期遅延の要因として「計画時の考慮不足」（予算51.0%・工期52.5%）、「想定以上の現行業務・システムの複雑さ」（同51.4%・48.8%）、「仕様変更の多発」（同48.6%・42.4%）が上位に挙がり、品質・予算・工期の悪化に影響した工程としては「要件定義」が57.4〜69.0%と高い割合でした。

つまり、つまずきの多くは開発の技術ではなく、計画と要件定義の段階で決めるべきことが決まっていないまま先へ進むことから生まれます。もう一つ読み取れるのは、規模を小さく区切るほど予定どおりに終わりやすいことです。対象業務を絞る、フェーズを分けて発注する、といった工夫は、この傾向を踏まえたものです。これを仕組みにしたのが判断ゲートです。

基幹システム導入の5フェーズと判断ゲート

導入は次の5つのフェーズに分けて進めます。期間は中小企業の基幹システム（販売・在庫・購買・会計など）を想定した目安です。

ポイントは、ゲート5が「稼働したか」ではなく「業務が新システムで回っているか」になっていることです。システムが完成したことと、業務が改善されたことは別物です。

もう一つは、費用が大きく動くのはゲート2とゲート3だということです。構想策定と要件定義にかかる費用は全体の一部ですが、ここで対象範囲と例外処理の扱いが決まらないと、開発以降の見積もりが固まりません。逆に、ゲート2で要件定義書が承認されていれば、複数の会社から同じ前提で固定見積もりを取り、ゲート3で比べて選ぶことができます。費用を抑えたいときほど、前半のフェーズを省かないことが近道になります。

例：従業員80名の卸売業が販売・在庫・会計を刷新する場合

※説明用の例です。期間と内容は対象範囲・データの状態・作り方によって変わります。

この例では、構想策定から稼働まで約13か月、定着まで含めて約17か月です。決算期と繁忙期を避けて総合テストと稼働日を置くと、全体の期間はその分だけ延びます。期間を短くしたいときは、各フェーズを急ぐより、対象業務を絞る方が安全です。

フェーズごとの詳しい進め方は、構想策定は基幹システムの構想策定とは、要件定義は要件定義の進め方、製品選定はRFPの書き方で解説しています。

5つの判断ゲートの判定基準

各ゲートでは、次の基準をすべて満たしたときだけ次のフェーズに進みます。満たさない項目があれば、そのフェーズに戻って詰めます。

ゲート1：構想書の承認

• 刷新の目的と、「刷新後にどの数字が変わっていれば成功か」が書かれている
• 変えてよい業務と、維持すべき業務の方針が決まっている
• 部門間で意見が分かれたときの最終判断者が決まっている
• 対象範囲（業務・拠点・部署）と対象外が書かれている

ゲート2：要件定義書の承認と、作り方・固定見積もりの提示

• 機能要件に優先度（必須／あれば／後回し）がついている
• 例外処理（特定の取引先、月末だけの締め方など）が洗い出され、残すかやめるかが決まっている
• 移行するデータの範囲と、現行データの品質の確認結果がある
• 標準機能に合わせる業務と、独自に作る業務の線引きができている
• 要件定義書をもとに、作り方の候補と開発・導入の固定見積もりが出せる状態になっている

ゲート3：発注先・作り方・固定見積もりの確定

• 複数の提案を、同じ費目・同じ年数（5年程度）の総費用で比べた
• 対象外項目・前提条件・発注側が担う作業を全社分確認した
• 実際に担当するメンバーの経験と体制を確認した
• 追加要望が出たときの費用の決め方が契約に書かれている

ゲート4：総合テストで重大な不具合なし

• 機能単位の確認だけでなく、見積→受注→出荷→請求のような業務シナリオで通しのテストをした
• 実際に入力する現場担当者がテストに参加した
• 移行リハーサルで件数・金額・残高が照合できた
• 残っている不具合に、稼働を止めるほどのものがない

ゲート5：稼働3か月後の定着

• 対象業務の大半（目安として8割以上）が新システムで処理されている
• Excelなどとの二重管理が残っている業務を把握している
• 使われていない機能・入力負担の大きい画面の改善計画がある
• 構想書で決めた「成功を測る数字」を測り始めている

※ゲート5の「8割以上」は説明用の目安です。自社の対象業務の数え方（業務の件数、処理件数など）を構想策定の段階で決めておきます。

判定会議の進め方

1. 判定基準を事前に配る
   会議の1週間前に、上のチェック項目ごとに「達成／未達／一部」を記入した資料を出席者に配ります。
2. 未達の項目だけを議論する
   達成した項目の説明に時間を使わず、未達と一部達成の項目について、影響と対応策を話し合います。
3. 「進む・条件付きで進む・戻る」のどれかを決める
   条件付きで進む場合は、残った項目の担当者と期限を決め、次の会議で確認します。
4. 決定を議事録に残し、関係者に共有する
   誰が何を根拠に判断したかを残しておくと、後で同じ議論を繰り返さずに済みます。

ゲートで止まったときの判断

判断ゲートは「通すための儀式」ではありません。基準を満たさないときに、どう動くかを先に決めておきます。

特にゲート4は、日程の圧力で「とりあえず稼働」となりやすい場面です。重大な不整合が残っていれば稼働を延期する、または切り戻すという判断ができるよう、移行の判定基準をゲート2の段階で決めておきます。テストシナリオと合否基準の作り方はユーザー受入テスト（UAT）の進め方、稼働の可否を決める基準と切り戻し計画は稼働判定と本番切替で解説しています。

ゲートの判定を誰がするかも決めておきます。中小企業では、経営者・業務部門の責任者・プロジェクト責任者が集まる会議体を月1回程度開き、ゲートの判定もそこで行う形が回しやすい方法です。会議体の作り方はステアリングコミッティとはをご覧ください。

設計・開発の期間に見当をつける方法

5フェーズのうち、設計・開発・設定の期間は対象範囲と作り方で大きく変わるため、表では「規模により個別」としました。ただし、要件定義が終わって工数（人月）の見積もりが出れば、公開されている調査で期間の見当をつけられます。

JUASの「ソフトウェア・メトリクス調査2025」は、開発プロジェクトの実績（232件）から、標準工期を「3.23×工数の立方根」（か月）と示しています。同じ調査では、標準工期を超過したプロジェクトが全体で49%、50人月未満のプロジェクトでは56%でした。調査は、50人月未満のプロジェクトでは標準工期に対して余裕を持って工期を計画することが望ましいとしています。

※標準工期はJUAS「ソフトウェア・メトリクス調査2025」の式（3.23×工数の立方根）で計算した説明用の例です。工期に含まれる工程の範囲は調査の定義によるため、自社のスケジュールと比べるときは、どの工程からどの工程までを比べているかをそろえてください。

同じ調査は、工程ごとの標準的な比率として、工期で「要件定義20：設計〜結合テスト50：総合テスト30」、工数で「15：60：25」を示しています。提示されたスケジュールで要件定義や総合テストの期間が極端に短い場合は、その理由を確認します。特に総合テストは、現場担当者が業務シナリオで通しの確認をする期間です。ここを削ったスケジュールは、ゲート4で止まる可能性が高くなります。

ゲートごとに発注する：一括発注との違い

判断ゲートを置くと、発注もフェーズ単位で区切れます。IPA（情報処理推進機構）の「共通フレーム2013」のガイダンスでは、一定規模以上の取得では多段階の見積り方式や、工程に応じた契約形態（準委任型・請負型）の採用を検討することが望ましいとしています。また、経済産業省の「情報システム・モデル取引・契約書」が工程ごとに委託料を定める多段階契約と再見積りのモデルを採用していることも紹介しています。この考え方は、IPAが2020年12月に公開した同契約書の第二版にも引き継がれています。

なお、要件定義書の内容に責任を持つのは発注側です。前述のIPAのガイダンスが参照する「超上流から攻めるIT化の原理原則17ヶ条」にも、「要件定義は発注者の責任である」という原則が挙げられています。作業を外部に頼んでも、目的・優先順位・対象外を決めるのは自社です。同じガイダンスは、契約後の変更を扱う場として、発注側と受注側が定期的に集まる連絡協議会を設け、変更管理の手続きに沿って決めることも勧めています。ゲートで「条件付きで進む」と決めた項目や追加の要望は、この場で費用と期日を決めてから作業に入るようにします。要件定義書の書き方は要件定義書の書き方、見積もりの比べ方はERP・基幹システムの費用で解説しています。

導入プロジェクトの体制と、社内で担う役割

判断ゲートを機能させるには、誰が判定し、誰が中身を詰めるのかを決めておく必要があります。中小企業の基幹システム導入では、次の役割を置きます。1人が複数の役割を兼ねてもかまいませんが、空欄の役割を作らないことが大切です。

※関わり方の目安は説明用の例です。

特に、キーユーザーの時間が確保できないと、要件定義は管理者の要望中心になり、総合テストは機能の確認だけで終わります。キーユーザーの通常業務を一時的に誰が引き受けるかまで決めておきます。外部に任せる範囲の決め方はPMOとはで解説しています。

着手前にやっておく5つのこと

1. プロジェクト責任者と決裁者を決める
   全体の責任者と、販売・在庫・購買・会計など業務領域ごとの決裁者を決めます。決める人がいないと、会議の決定が次の回で覆ります。部門をまたぐ論点（たとえば在庫の引当を受注時にするか出荷指示時にするか）は、どの決裁者が決めるかもあわせて決めておきます。
2. 「誰が何をしているか」を書き出す
   中小企業では、特定の担当者しか知らない処理が残りがちです。部署ごとに日次・月次の作業を一覧にします。
3. 現行データを一度見てみる
   取引先や品目のマスタを出力し、同じ会社が別名称・別コードで登録されていないか、使われていないコードがどれくらい残っているかを確認します。件数と重複の多さが分かれば、データ移行にかかる手間の見当がつき、要件定義で移行の範囲を決めるときの材料になります。
4. 現場担当者の参加時間を確保する
   要件定義の打合せ、総合テスト、研修に、実際に入力する人が参加できるよう業務の調整をします。繁忙期と総合テストが重ならないよう、年間の業務カレンダーと照らし合わせておきます。
5. 成功を測る数字を1〜3個決める
   月次決算の締めにかかる日数、受注入力の時間、在庫の照合にかかる時間など、刷新前後で比べられる数字を決めて、今の値を測っておきます。

よくある質問

まとめ

基幹システム導入の進め方は、構想策定・要件定義・製品選定とRFP・設計開発・導入定着の5フェーズで進め、各フェーズの終わりに判断ゲートを置いて、基準を満たしたときだけ次へ進むのが基本です。予算超過や工期遅延の多くは、計画と要件定義の段階で決めるべきことが曖昧なまま進むことから生まれます。ゲートごとに見積もりを取り直し、開発期間は工数と公開調査で見当をつけ、最後は「稼働したか」ではなく「業務が新システムで回っているか」で判断します。

自社がいまどのフェーズにいて、次のゲートで何が足りないかを知りたい方は、無料診断で現状を整理します。