入出庫管理システム更改の開発期間と納期は、保守契約やリースの満了、EOS/EOLといった自社では動かせない期限から逆算して決まります。
期限の半年前から1年半前にプロジェクトを始動し、ベンダー選定や移行、初期流動管理までを順に組み立てます。技術手法や経営判断の進め方は、別の記事に譲ります。
- 更改の期限と開発範囲の整理
- 要件定義・設計・開発・移行・テストの進め方
- 遅延要因と関係者間で確認する判断材料
▼全体ガイドの記事
・入出庫管理システム更改の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
入出庫管理システム更改の位置づけ（契約・ライフサイクル起点という論点）
開発期間を検討する前に、更改という論点の位置づけを押さえておく必要があります。同じ入出庫管理システムのテーマでも、技術手法、経営判断、契約・ライフサイクルのどこに重心を置くかで、スケジュールに影響する要因は大きく変わるためです。
モダナイゼーション記事・刷新記事との違い（外圧型トリガーという軸）
「入出庫管理システムのモダナイゼーション」は、リホストやリプレースなど5つの技術的アプローチのうちどれを選ぶか、また出庫承認ワークフローと入出庫理由コード体系をどこまで引き継ぐかを扱う、技術手法の記事です。「入出庫管理システム刷新」は、老朽化を放置することの経営インパクト（過剰在庫、誤出荷対応コスト、月次決算の遅延）を定量化し、経営層の稟議承認と各部門の合意形成をどう進めるかを扱う記事です。
これに対して本記事の「更改」は、プロジェクトを始める起点そのものが異なります。保守サポート契約の満了や現場端末のリース期限、ベンダーのEOS/EOLといった「動かせない期限」は、社内の経営判断とは無関係に外部から設定されるためです。
その期限までに「契約をそのまま更新するか、この機会に更改するか」を判断せざるを得ない状況こそが、更改の本質です。同じ開発期間や納期を扱っても、モダナイゼーション記事は実装フェーズの工程別期間配分、刷新記事は経営判断と合意形成に要する期間が主眼です。本記事は、動かせない期限から逆算して、いつまでに何を終わらせるかという納期管理そのものが中心です。
「入出庫管理システム開発」（新規導入）との共通点・相違点
「入出庫管理システム開発」は、ゼロから入出庫管理システムを新規に構築するグリーンフィールドの文脈です。一方、更改は、モダナイゼーションや刷新と同じく既に稼働している入出庫管理システムを土台にするブラウンフィールドのプロジェクトであり、この点は共通しています。
更改には、新規導入にもモダナイゼーション・刷新にもない固有の制約があり、期限に交渉の余地がほとんどない点です。刷新であれば、社内の合意形成の状況次第で、着手時期を数ヶ月ずらす選択肢も現実的にあります。しかし更改では、保守ベンダーが「この日付をもってサポートを終了します」と一方的に通知すると、期限を過ぎた瞬間に障害対応や問い合わせ対応が受けられなくなるおそれがあります。
ハンディターミナルなど現場端末のリース契約では、満了後もそのまま使い続けることは契約上できず、返却か再リースかの判断を迫られます。そのため、「交渉の余地が乏しい外部期限」を起点にスケジュールを設計しなければならない点が、開発期間と納期を考えるうえでの最大の前提になります。
更改のトリガーとなる契約・ライフサイクルの期限
スケジュールを逆算する起点となる「期限」には、主に3種類あります。通知の届き方や交渉の可能性が種類ごとに異なるため、自社の入出庫管理システムがどの期限に当たるかを正確に把握することが、更改プロジェクトの第一歩になります。
保守サポート契約満了と現場端末のリース満了
最も身近な期限は、入出庫管理システムの保守サポート契約と、現場端末のリース契約の満了です。
- 保守サポート契約：オンプレミス型・パッケージ型では、初回導入時に3年や5年単位で保守契約を結び、満了のタイミングで更新するかを判断するのが一般的です。
- 現場端末のリース：ハンディターミナルなどのリース契約は、法定耐用年数や会計上の減価償却期間を踏まえて5年前後で組まれることが多いです。
保守契約には、承認ワークフローや理由コード体系の不具合に対する障害対応や、業務ルールの変更への追従対応が含まれることが多いです。保守契約が切れたまま運用すると、日々の入出庫業務が突然止まるリスクを抱えることになります。一方、リースの満了時には、返却して新規リースを組み直すか、購入に切り替えるか、クラウド型へ移行して端末を持たない選択をするかの判断を迫られます。
保守契約とリース契約は別々の期日で満了することも珍しくないため、どちらか一方だけを見ていると、もう一方の期限を見落とすおそれがあります。
ベンダーのEnd of Support/End of Life（EOS/EOL）
3つ目の期限は、ベンダーのEnd of Support（サポート終了）とEnd of Life（提供終了）です。これはベンダーが製品戦略として一方的に設定する期限のため、保守契約やリース契約の満了時期とは無関係に到来します。自社のどの部分が対象になるかを、まず洗い出しておく必要があります。
- 基盤ソフト：OSやデータベース、ミドルウェア
- 古い機器：汎用機・オフコン
- 基幹システムのアドオン：入出庫モジュールそのもの
- 現場端末のOS：ハンディターミナルに搭載された旧Windows系OS等。過酷な環境で使われるため本体の老朽化も早く、リース満了とほぼ同時期に来やすい
EOS/EOLを迎えた製品は、セキュリティパッチの提供が止まり、脆弱性が見つかっても修正されないまま放置される状態になります。入出庫管理システムは会計にも直結する取引記録と承認を担うため、セキュリティインシデントが起きると、トランザクションの改ざんや停止という形で業務全体に影響し、経営リスクに直結します。
EOS/EOL後も稼働は続けられるケースが多く、「まだ動いているから大丈夫」と先送りしがちです。しかし、その間はベンダーの特別保守（延長サポート）に頼らざるを得ず、通常の保守費用より大幅に高い費用を払い続けることになりやすい点も、見過ごせません。
期限から逆算するスケジュール設計
更改プロジェクトの日程は、要件定義から積み上げる通常のプロジェクトとは逆に、動かせない期限から各工程に必要な期間を差し引いていく「逆算方式」で組み立てるのが基本です。入出庫管理システムは日々の入出庫業務を止められないため、逆算がずれると、そのまま業務停止リスクに直結します。
逆算に必要な実務期間の内訳
絶対に動かせない期限から逆算する場合は、4つの実務期間を積み上げる必要があります。1つ目は開発・テスト・データ移行で、システムの規模や承認ワークフローの複雑さによって、数ヶ月から1年以上と幅があります。既存の入出庫トランザクション履歴、出庫承認履歴、承認者権限マスタをどこまで新システムに引き継ぐかによって、この期間は大きく変わります。
2つ目はベンダー選定・契約にかかる期間で、標準的なプロセスを踏むと約1.5〜2.5ヶ月を要します。3つ目はRFP（提案依頼書）の作成や社内稟議にかかる期間で、数週間から1ヶ月程度を見込む必要があります。
4つ目は、本番稼働直後の初期流動期間で、数週間から1ヶ月程度の特別な対応体制を敷く期間です。4つを単純に合算すると、最低でも「半年弱」の実務期間が必要になります。特に、既存の承認ワークフローの引き継ぎや周辺システム（在庫・基幹システム）との並行運用が絡む場合は、この最低ラインからさらに余裕を持たせて見積もるべきです。
プロジェクト始動のタイミング（半年前〜1年半前）
先ほどの実務期間の合算を踏まえると、少なくとも期限の半年前には次期システムのプロジェクトを始動させておく必要があります。保守サポート契約の満了やEOS/EOLといった期限に対して、業務停止や現場の混乱を避けるためです。
ただし、これはあくまで最短のラインです。社内稟議に時間がかかる企業や、対象拠点が複数にまたがり承認階層も複雑な入出庫管理システムでは、期限の1年〜1年半前から始動するほうが望ましいとされています。
逆に、EOS/EOLの通知を受けてから「まだ半年以上ある」と先送りを続けると、ベンダー選定の期間すら確保できなくなります。その結果、割高な特別保守を延長せざるを得なくなったり、十分な検証をしないまま拙速な移行を強いられたりしかねません。EOS/EOLの日付は事前に告知されるため、通知を受けた時点で社内の体制と大まかなスケジュールの仮組みを先に始めておくことが、納期を左右する最初の分岐点です。
ベンダー選定・RFP作成に要する期間と移行方式
逆算スケジュールの中で特に見落とされがちなのは、ベンダー選定・RFP作成のプロセスと、選んだ移行方式そのものがもつ期間特性です。ここを軽視すると、そのしわ寄せが実装フェーズに及び、結果として納期遅延につながります。
RFP作成からベンダー選定・契約までの標準プロセス
RFP（提案依頼書）の作成には、現行の入出庫管理システムが抱える課題の洗い出しと、更改後に求める要件の優先順位付けが必要です。そのため、準備には数週間から1ヶ月程度を見込むのが目安です。
RFPを複数のベンダーに提示してから契約に至るまでは、標準的なプロセスで約1.5〜2.5ヶ月を要し、大きく3つのステップに分けられます。まず1〜2週間かけて技術適合評価とRFI（情報提供依頼）の送付を行い、候補ベンダーを数社に絞り込みます。次に3〜6週間かけてPoC等を通じ、出庫承認ワークフローや理由コード体系の実装可否を検証します。
最後の段階では、1〜2週間かけてセキュリティ監査や契約条件の交渉を行います。加えて、既存の在庫管理システムや基幹システムとのデータ連携仕様も、この段階で確認しておくべきです。連携要件をRFPの段階で明記しておくと、後工程での手戻りを防ぎやすくなります。
一括移行・段階移行それぞれの期間特性
入出庫管理システムは日々の入出庫業務と直結するため、一括移行方式（ビッグバン移行）と段階移行方式（トリクルダウン移行）のどちらを選ぶかで、スケジュールの組み方が大きく変わります。一括移行方式は、現行システムから新システムへ一気に切り替える方式です。移行作業がシンプルなため、短期間かつ低コストで済むというメリットがあります。
ただし、移行中はシステムを完全に停止する必要があるため、長時間の業務停止を許容できない入出庫管理システムでは、採用のハードルが高くなります。段階移行方式は、拠点や業務単位で段階的に移行する方式です。移行中も業務を続けられるため、事業への影響が小さく、トラブル発生時の影響範囲も局所化できるというメリットがあります。
一方で、新旧システムを一定期間併用するため運用の手間が増え、移行完了までの総期間はビッグバン方式より長くなる傾向があります。動かせない期限までに全拠点の切り替えを終える必要があるのか、主要拠点の承認ワークフローさえ移行できれば残りは並行運用しながら順次切り替えてよいのかを、早い段階で固めておくことが、逆算の精度を左右します。
納期遅延を防ぐための実務ポイント
逆算スケジュールを組んでも、実際のプロジェクト進行では想定外の事象が起きます。そのため、動かせない期限を守るうえで特に重要な実務ポイントを2つ取り上げます。
初期流動管理の期間設定と終了基準
本番稼働直後は、テスト環境で検知しきれなかった想定外の不具合や、現場担当者の操作に不慣れなことによる問い合わせが集中しやすい時期です。この期間に特別な対応体制を敷くことを初期流動管理と呼び、一般的には稼働直後の数週間から1ヶ月程度が目安とされています。
入出庫管理システムの更改では、この期間に出庫承認が滞留したり、入出庫理由コードの入力ミスによる在庫差異が見つかったりするケースが多くあります。対応が長引くと通常の保守フェーズへの移行が遅れ、結果としてプロジェクト全体の締めくくりも遅延します。
期間は規模や重要度で変わりますが、長く設定しすぎるのは避けるべきです。そのため、「承認滞留や重大障害の発生件数が週に一定件数以下になった時点で終了する」といった定量的な終了基準を、計画段階で決めておきます。終了基準があれば、初期流動期間がなし崩し的に延び続けるのを防ぎ、通常の保守・運用体制へ計画的に移行できます。
入出庫トランザクション・承認履歴移行における遅延リスクへの備え
入出庫トランザクション履歴、出庫承認履歴、承認者権限マスタといった既存データの移行は、期限までに終えるべき作業のなかで、特に見積もりを誤りやすい工程です。長年運用してきたシステムには、退職者の承認者権限が残っていたり、理由コード体系が拠点ごとにバラバラに運用されていたりと、データの不整合が溜まっていることが多くあります。
これをそのまま移行しようとすると、エラーが多発し、動かせない期限に対して致命的な遅れを生む要因になります。そのため、移行の前に不整合を減らすことと、移行する範囲を絞ること、移行後の数値を確認することが必要になります。
- データ品質の評価：開発着手と並行して、クレンジングを先行して進めておきます。
- 移行粒度の決定：全量移行は停止時間が長引くため、「在庫差異の確認に必要な過去の年数」から残す範囲と切り捨てる範囲を定めます。
- パラレルラン：出荷・入荷を止められないため、新旧を一定期間並行稼働させて数値を照合します（2〜4週間程度が目安）。
動かせない期限までに間に合わないと分かった場合は、早い段階でRFPの見直しやスコープの絞り込みに踏み切ることが、納期を守る最終手段になります。
まとめ
更改の起点になるのは、保守サポート契約の満了、現場端末のリース満了、ベンダーのEOS/EOLという、自社では動かせない期限です。刷新やモダナイゼーションと違い、この期限は社内の経営判断より先に外から決まっています。
その期限から逆算すると、開発・テスト・データ移行とベンダー選定・契約に加えて、RFP作成・社内稟議と初期流動管理を積み上げます。ベンダー選定・契約は約1.5〜2.5ヶ月、初期流動管理は稼働直後の数週間から1ヶ月程度が目安です。
4つを合算すると最低でも「半年弱」が必要になるため、期限の半年前から1年半前にはプロジェクトを始動させるのが実務上の鉄則です。
移行方式は、一括移行なら短期間で済む一方で業務停止が必要になり、段階移行なら業務を続けられる代わりに総期間が長くなる傾向があります。納期遅延を防ぐには、初期流動管理の終了基準を計画段階で決めておくことも欠かせません。
EOS/EOLの通知は多くの場合事前に告知されるため、通知を受けた時点で社内の体制と逆算スケジュールの仮組みに着手することが、期限内に確実に更改するための最大の鍵になります。また、既存の入出庫トランザクション履歴や出庫承認履歴の移行、周辺システムとの並行運用に潜むリスクは、早い段階で洗い出しておきます。
▼全体ガイドの記事
・入出庫管理システム更改の完全ガイド
▼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を創業。