在庫管理システム更改の開発期間・スケジュール・納期について

在庫管理システム更改の開発期間・スケジュール・納期を検討する際、まず押さえておきたいのが、同じ「在庫管理システム」というテーマを扱いながらも本記事が焦点を当てる論点は、記事「在庫管理システムのモダナイゼーション」や「在庫管理システム刷新」とはまったく異なるという点です。モダナイゼーション記事が扱うのは、リホスト・リプラットフォーム・リファクタリング・リビルド・リプレースという5つの技術的アプローチをどう使い分けるかという「どう技術的に刷新するか（HOW）」という論点であり、刷新記事が扱うのは、過剰在庫・欠品という経営インパクトをどう定量化し、なぜ・いつ刷新に踏み切るべきかという経営層の内発的な意思決定（WHY/WHEN）です。これに対して本記事が扱う「更改」は、保守サポート契約の満了時期、ハードウェアのリース期限、ベンダーが表明するEnd of Support/End of Life（EOS/EOL）という、自社の都合とは関係なく外部から強制的に迫ってくる「動かせない期限」がプロジェクトの起点になるという点で、他の2つの記事群とは根本的に異なります。経営判断が先にあって刷新に着手するのではなく、契約書やベンダーからの通知に記された期日が先にあり、そこから逆算して「そのまま契約を更新するか、この機会に刷新するか」を判断していくプロセスこそが、更改というテーマの核心です。

本記事では、在庫管理システム更改における開発期間・スケジュール・納期について、更改のトリガーとなる契約・ライフサイクル上の期限の種類、期限から逆算したスケジュール設計の考え方、ベンダー選定・RFP作成に要する具体的な期間、移行方式ごとの期間の違い、そして納期遅延を防ぐための実務ポイントまでを体系的に解説します。技術的な刷新手法の詳細は在庫管理システムのモダナイゼーションの記事に、経営層への説明や部門間合意形成の進め方は在庫管理システム刷新の記事にそれぞれ譲り、本記事では「動かせない期限までに、何を、いつまでに終わらせておく必要があるか」という逆算スケジュールに焦点を当てます。

本テーマに関する全体ガイドは、以下の記事をご覧ください。

▼全体ガイドの記事
・在庫管理システム更改の完全ガイド

在庫管理システム更改とは何か（契約・ライフサイクル起点という論点）

在庫管理システム更改の開発期間を検討する前に、本記事が扱う論点の位置づけを明確にしておく必要があります。同じ在庫管理システムというテーマでも、技術手法に重心を置く記事群、経営判断に重心を置く記事群、そして契約・ライフサイクルという外圧に重心を置く本記事とでは、スケジュールに影響する要因がまったく異なるためです。

「在庫管理システムのモダナイゼーション」は、リホスト・リプラットフォーム・リファクタリング・リビルド・リプレースという5つの技術的アプローチをどう選び、どれくらいの期間で実装するかというエンジニア・情報システム部門向けの技術手法論です。「在庫管理システム刷新」は、老朽化した在庫管理システムを放置することの経営インパクト（過剰在庫・欠品による損失）を定量化し、経営層の稟議承認と物流・経理・IT各部門の合意形成をどう進めるかという、経営層・プロジェクトマネージャー向けの内発的な意思決定プロセスです。これらに対して本記事が扱う「更改」は、そもそもなぜこのタイミングでプロジェクトを始めるのかという起点そのものが異なります。保守サポート契約の満了通知、ハードウェアのリース期限、ベンダーから届くEOS/EOLのアナウンスといった、自社の経営判断とは無関係に外部から一方的に設定される「動かせない期限」が先に存在し、その期限までに「契約をそのまま更新するのか、この機会に刷新に踏み切るのか」を判断せざるを得ない状況こそが更改の本質です。開発期間・スケジュール・納期という同じテーマを扱っていても、モダナイゼーション記事が「実装フェーズの工程別期間配分」を主眼とし、刷新記事が「経営判断・合意形成に要する期間」を主眼とするのに対し、本記事は「動かせない期限から逆算したときに、いつまでに何を終わらせておく必要があるか」という納期管理そのものを主眼としています。

「在庫管理システム開発」がゼロから在庫管理システムを新規に構築するグリーンフィールドの文脈であるのに対し、本記事が扱う更改は、モダナイゼーションや刷新と同じく、既に稼働している在庫管理システムを土台にしたブラウンフィールドのプロジェクトである点は共通です。しかし更改には、新規導入にもモダナイゼーション・刷新にもない固有の制約があります。それは「期限に交渉の余地がほとんどない」という点です。経営判断としての刷新であれば、社内の合意形成の状況次第で着手時期を数ヶ月後ろにずらすという選択肢も現実的に存在します。しかし更改の場合、保守ベンダーが「この日付をもってサポートを終了します」と一方的に通知してくれば、その期限を過ぎた瞬間に障害対応や問い合わせ対応そのものが受けられなくなるリスクを抱えることになります。ハードウェアのリース契約であれば、満了後もそのまま使い続けることは契約上できず、返却か再リースかの判断を迫られます。この「交渉の余地が乏しい外部期限」を起点にスケジュールを設計しなければならない点こそが、更改というテーマの開発期間・納期を考えるうえでの最大の前提です。

更改のトリガーとなる契約・ライフサイクルの期限

スケジュールを逆算する起点となる「期限」には、主に3つの種類があります。それぞれ通知の届き方や交渉可能性が異なるため、自社の在庫管理システムがどの期限に該当するのかをまず正確に把握することが、更改プロジェクトの第一歩になります。

最も身近な期限が、在庫管理システムの保守サポート契約の満了です。オンプレミス型・パッケージ型の在庫管理システムでは、初回導入時に3年や5年といった単位で保守契約を結び、その満了のタイミングで更新するかどうかの判断を求められるのが一般的です。この保守契約には、システムに何らかの不具合が生じた際の障害対応や、法改正（在庫評価に関わる会計基準の変更など）への追従対応が含まれていることが多く、契約が切れた状態で運用を続けることは、業務停止リスクを放置することと同義になります。もう一つの身近な期限が、在庫管理システムを稼働させているサーバーやハンディターミナルなどのハードウェアのリース満了です。リース契約は法定耐用年数や会計上の減価償却期間を踏まえて5年前後で組まれることが多く、満了時には現有機器を返却して新規リースを組み直すか、購入に切り替えるか、あるいはこの機会にクラウド型へ移行してハードウェア自体を持たない選択をするかという判断が発生します。保守契約とリース契約は別々の期日で満了することも珍しくなく、どちらか一方だけを見ていると、もう一方の期限を見落としてしまうリスクがある点にも注意が必要です。

3つ目の期限が、在庫管理システムを構成するOS・データベース・ミドルウェア、あるいはパッケージ製品そのもののEnd of Support（サポート終了）・End of Life（提供終了）です。これはベンダー側が製品戦略として一方的に設定する期限であり、自社の保守契約やリース契約の満了時期とは無関係に到来します。EOS/EOLを迎えた製品は、セキュリティパッチの提供が止まり、脆弱性が発見されても修正されないまま放置される状態になります。在庫管理システムは販売・生産・購買・会計と連携する経営に近いレイヤーを担っているため、ここでセキュリティインシデントが発生すれば、在庫データの改ざんや停止による出荷・入荷業務全体への影響という形で経営リスクに直結します。EOS/EOLを過ぎても稼働自体は継続できるケースが多いため、「まだ動いているから大丈夫」と先送りしてしまいがちですが、この間もベンダーによる「特別保守（延長サポート）」に頼らざるを得ず、通常の保守費用より大幅に高い費用を払い続けることになりやすい点は、次章以降で扱う保守・運用費用の観点からも見過ごせません。EOS/EOLの日付は多くの場合、製品ベンダーが公式サイトやサポート契約書で事前に告知しているため、更改プロジェクトの起点としては最も早い段階から把握できる期限でもあります。

期限から逆算するスケジュール設計

更改プロジェクトのスケジュール設計は、要件定義から積み上げていく通常のプロジェクトとは逆に、動かせない期限から逆算して各工程に必要な期間を差し引いていく「逆算方式」で組み立てるのが基本です。在庫管理システムは日々の入出庫業務を止められないため、この逆算のズレがそのまま業務停止リスクに直結します。

在庫管理システム更改において絶対に動かせない期限から逆算する場合、以下4つの実務期間を積み上げる必要があります。1つ目は、開発・テスト・データ移行にかかる期間で、システムの規模や複雑さによって数ヶ月から1年以上と幅があります。既存の在庫マスタ・ロケーション情報・入出庫履歴をどこまで新システムに引き継ぐかによって、この期間は大きく変動します。2つ目は、ベンダー選定・契約にかかる期間で、標準的なプロセスを踏むと約1.5〜2.5ヶ月を要します。3つ目は、RFP（提案依頼書）の作成や社内稟議にかかる期間で、数週間〜1ヶ月程度を見込む必要があります。4つ目は、本番稼働直後の初期流動期間で、数週間〜1ヶ月程度の特別な対応体制を敷く期間です。これら4つの期間を単純に合算すると、最低でも「半年弱」の実務期間が必要になる計算です。在庫管理システムのように既存データの移行や周辺システムとの並行運用が絡む場合は、この最低ラインからさらに余裕を持たせて見積もるべきでしょう。

前述の実務期間の合算値を踏まえると、保守サポート契約の満了やEOS/EOLといった期限に対して、システム停止や業務への悪影響を回避するためには、少なくとも「期限の半年前」には次期システム検討のプロジェクトを始動させておく必要があります。ただし、これはあくまで最短ラインであり、社内稟議に時間がかかる企業文化であったり、データ移行対象が複数拠点・複数商品カテゴリにまたがる規模の大きい在庫管理システムであったりする場合には、余裕を持たせて「期限の1年〜1年半前」からプロジェクトを始動させることが望ましいとされています。逆に言えば、EOS/EOLの通知を受け取ってから「まだ半年以上あるから大丈夫」と先送りを続けてしまうと、あっという間にベンダー選定期間すら確保できなくなり、結果として割高な特別保守を延長せざるを得ない、あるいは十分な検証をしないまま拙速な移行を強いられるという事態に陥りかねません。EOS/EOLの日付が事前に告知されているという更改の特性を活かし、通知を受け取った時点でまず社内のプロジェクト体制と大まかなスケジュールの仮組みだけでも先に着手しておくことが、後々の納期遵守を左右する最初の分岐点になります。

ベンダー選定・RFP作成に要する期間と移行方式

逆算スケジュールの中でも特に見落とされがちなのが、ベンダー選定・RFP作成のプロセスと、選定した移行方式そのものが持つ期間特性です。ここを軽視すると、実装フェーズにしわ寄せが行き、結果的に納期遅延につながります。

RFP（提案依頼書）の作成には、現行の在庫管理システムが抱える課題の洗い出しや、更改後に求める要件の優先順位付けが必要であり、数週間から1ヶ月程度の準備期間を見込む必要があります。RFPを複数のベンダーに提示した後、実際に契約に至るまでの標準的なプロセスは約1.5〜2.5ヶ月を要し、3つのステップに分解できます。ステップ1は技術適合評価・RFI（情報提供依頼）の送付段階で、1〜2週間かけて候補ベンダーを数社に絞り込みます。ステップ2は実地検証の段階で、後述するPoC等を通じて3〜6週間かけて実際の精度や使い勝手を検証します。ステップ3はコンプライアンス・契約精査の段階で、1〜2週間かけてセキュリティ監査や契約条件の交渉を行います。在庫管理システムの更改では、既存の販売管理システムや会計システムとのデータ連携仕様の確認もこの段階で行っておくべきであり、後工程での手戻りを防ぐためにも、RFPの段階で連携要件を明記しておくことが望ましいプロセスです。

在庫管理システムは日々の入出庫業務と直結するため、一括移行方式（ビッグバン移行）と段階移行方式（トリクルダウン移行）のどちらを選ぶかによって、スケジュールの組み方が大きく変わります。一括移行方式は、現行システムから新システムへ一気に切り替える方式で、移行作業がシンプルなため「短期間」かつ低コストで済むというメリットがあります。ただし移行中はシステムを完全に停止する必要があるため、長時間の業務停止が許容できない在庫管理システムでは採用のハードルが高くなります。段階移行方式は、拠点や商品カテゴリなど機能・業務単位で段階的に移行していく方式で、移行中も業務を継続できるため事業への影響が小さく、トラブル発生時の影響範囲も局所化できるというメリットがあります。一方で、新旧システムを一定期間併用するため運用の手間が増え、移行完了までの総期間はビッグバン方式より長くなる傾向があります。動かせない期限までに全社の在庫管理業務を完全に切り替え終える必要があるのか、それとも期限までに主要な機能さえ移行できていれば残りは並行運用しながら順次切り替えてよいのか、この方針を早い段階で固めておくことが、逆算スケジュールの精度を左右します。

納期遅延を防ぐための実務ポイント

逆算スケジュールを組んだ後も、実際のプロジェクト進行では想定外の事象が発生します。ここでは、動かせない期限を守り抜くために特に重要な2つの実務ポイントを解説します。

本番稼働直後は、テスト環境では検知しきれなかった想定外の不具合や、現場担当者の操作の不慣れによる問い合わせが集中しやすい時期です。この期間に特別な対応体制を敷くことを初期流動管理と呼び、一般的には稼働直後の数週間から1ヶ月程度が目安とされています。在庫管理システムの更改では、この初期流動期間中に在庫数量のずれや、周辺システムとの連携エラーが発覚するケースが多く、対応が長引くと通常の保守フェーズへの移行そのものが遅れ、結果的にプロジェクト全体のクロージングも遅延します。プロジェクトの規模やシステムの重要度によって適切な期間は変わりますが、漫然と長く設定しすぎるのは避けるべきです。「重大障害の発生件数が週に一定件数以下になった時点で終了する」といった定量的な終了基準を、計画段階であらかじめ設けておくことが重要です。終了基準を事前に決めておくことで、初期流動期間がなし崩し的に延び続ける事態を防ぎ、通常の保守・運用体制へ計画的に移行できます。

更改プロジェクトの実装期間の中でも、在庫マスタ・ロケーション情報・入出庫履歴といった既存データの移行工程は、期限までに終わらせるべき作業として特に見積もりを誤りやすいポイントです。長年運用してきたシステムには、廃番商品コードの残存や単価・ロケーション情報の欠損といったデータの不整合が蓄積していることが多く、これをそのまま移行しようとするとエラーが多発し、動かせない期限に対して致命的な遅れを生む要因になります。対策としては、開発着手と並行してデータ品質の評価とクレンジングを先行して進めておくことが有効です。また、日々の出荷・入荷を止められない在庫管理システムでは、新旧システムを一定期間並行稼働させて数値を照合するパラレルランが必要になるケースも多く、この並行運用にも2〜4週間程度の期間を確保するのが目安です。動かせない期限に対してこれらの工程を後ろから積み上げたときに、どうしても間に合わないと判明した場合は、早い段階でRFPの見直しやスコープの絞り込みといった意思決定に踏み切ることが、納期そのものを守るための最終手段になります。

まとめ

本記事では、在庫管理システム更改における開発期間・スケジュール・納期について、保守サポート契約満了・ハードウェアリース満了・ベンダーのEOS/EOLという契約・ライフサイクル起点のトリガー、そこから逆算するスケジュール設計の考え方、ベンダー選定・RFP作成に要する具体的な期間、移行方式ごとの期間特性、そして納期遅延を防ぐための実務ポイントを体系的に解説しました。更改は経営判断としての刷新やモダナイゼーションとは異なり、動かせない外部期限が先に存在するという特性上、開発・テスト・データ移行、ベンダー選定・契約、RFP作成・稟議、初期流動管理という4つの実務期間を合算した「半年弱」を最低ラインとし、期限の半年前〜1年半前にはプロジェクトを始動させることが実務上の鉄則です。EOS/EOLの通知は多くの場合事前に告知されるため、通知を受け取った時点で速やかに社内のプロジェクト体制と逆算スケジュールの仮組みに着手し、既存の在庫データ移行や周辺システムとの並行運用に潜むリスクを早期に洗い出しておくことが、期限内での確実な更改を実現する最大の鍵となります。

▼全体ガイドの記事
・在庫管理システム更改の完全ガイド

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。