WMS改修の選定ポイント/選び方/種類

WMS改修を検討し始めると、月額保守の範囲内で対応できる軽微な修正から、個別に見積もりを取る部分機能改修まで、対象範囲も契約形態もさまざまな進め方があります。範囲や契約形態を曖昧にしたまま依頼すると、想定より費用や期間がかさんだり、影響範囲の調査が不十分なまま着手して手戻りが発生したりすることもあります。委託先を1社だけ見て決めてしまうと、他社であれば異なる契約形態や検証手法を提案していた可能性に気づけないまま進めてしまうことにもなりかねません。選定の出発点は、自社のどの機能・どの工程に課題が集中しているかを具体的に切り分けることです。

本記事では、WMS改修着手前に整理すべき自社の課題、改修の3つの種類、委託先を比較する評価軸、モックアップ・プロトタイプ・PoCの使い分け、費用感の比較の進め方、そしてフルスクラッチ開発・全面刷新への切替判断を解説します。これから改修を依頼する担当者の方が、見積もりの妥当性を判断し、自社に合った進め方を選べる内容です。すでに改修の依頼先を検討し始めている方にとっても、各社の提案を比較する際のチェック項目として活用いただけます。

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

▼全体ガイドの記事
・WMS改修の完全ガイド

WMS改修着手前に整理すべき自社の課題

改修を依頼する前にまず行うべきは、製品カタログや開発会社を探すことではなく、現場のどの工程で困りごとが起きているかを特定することです。課題を具体的に説明できれば、必要な改修範囲と不要な機能が見えやすくなります。現場担当者へのヒアリングだけでなく、実際の作業を観察して困りごとを洗い出すと、担当者自身が「当たり前」だと思い込んで報告されない課題にも気づきやすくなります。

特定のロケーションだけ移動距離が長い、ハンディ端末の入力画面が現場の手順と合っていないといった課題は、比較的狭い範囲の改修で解消できることがあります。どの作業のどの画面で、どのくらいの頻度・時間のロスが発生しているかを具体的に記録しておくと、改修範囲を絞り込みやすくなります。繁忙期だけ顕在化する課題もあるため、可能であれば繁忙期・閑散期の両方で現場の状況を確認しておくと、改修後に効果を実感しにくいという事態を防ぎやすくなります。

既存のロケーションマスタや上位のERP・販売管理システムとの連携部分でエラーや不整合が頻発している場合は、現場の画面だけでなく連携部分を含めた改修が必要になることがあります。どのタイミングで、どのデータ項目にずれが生じているかを、関係部門と一緒に洗い出しておくことが重要です。連携部分の課題は自社のWMS単独では解決できないことも多いため、上位システムの担当部門やベンダーと早期に情報共有し、改修の範囲と責任分担を事前にすり合わせておくと、着手後の調整がスムーズになります。

WMS改修の3つの種類

WMS改修は、契約形態で見ると大きく3つに分けられます。実際の依頼では複数の要素が組み合わさることもあるため、分類名よりも、自社の要件確定度や継続的な改修の見込みに合っているかを確認します。どの契約形態が向いているかは、改修の頻度と要件の固まり具合という2つの軸で整理すると判断しやすくなります。

既存の保守契約の範囲内で、軽微な修正を都度対応してもらう形態です。改修が保守契約に含まれると明記されているかどうかで、追加費用の発生有無が変わるため、契約内容を事前に確認しておく必要があります。月額固定型は、頻度の高い小さな修正依頼が発生する企業にとって、都度の見積もり依頼を省略できる点が利点ですが、対応範囲を超える改修については別途契約が必要になる場合があるため、対応範囲の境界線を具体的に確認しておくことが望まれます。

改修が必要になるたびに個別見積もりを取る、あるいはあらかじめ購入したチケットを消費して対応してもらう形態です。要件が比較的明確な単発の改修に向いていますが、依頼のたびに調整コストが発生するため、頻度が高い場合は他の契約形態と比較する価値があります。チケット制の場合は、1件あたりの改修に必要なチケット数の算定基準が委託先によって異なるため、過去の改修実績をもとに、自社の依頼頻度で年間どの程度のチケットを消費するかを事前に試算しておくと、契約プランの妥当性を判断しやすくなります。

要件が明確に固まっている改修であれば、成果物を定めた請負契約が向いています。一方、現場の課題を継続的に洗い出しながらアジャイル的に改修を重ねていきたい場合は、稼働に応じて契約する準委任契約やラボ型の体制が適していることがあります。ラボ型の体制では、専属のエンジニアが自社のWMSやロケーションマスタの構造を継続的に把握してくれるため、改修のたびに一から仕様を説明し直す手間を省ける一方、稼働が発生しない月でも一定の契約費用がかかることが多く、継続的な改修需要が見込めるかどうかを見極めてから採用するのが望ましいです。

改修パートナー選定で比較すべき評価軸

改修を依頼する開発会社・SIerは、対応できる範囲や得意分野が異なります。同じ質問を各社に投げかけ、回答を同じ条件でそろえることで、営業説明の分かりやすさに評価が引っ張られにくくなります。評価結果は担当者の主観的な印象だけでなく、確認できた事実と未確認の事項を分けて記録しておくと、後から社内で説明する際にも根拠を示しやすくなります。

改修プロジェクトの手戻りは、変更の影響範囲を正しく洗い出せなかったことに起因するケースが多いとされています。委託先候補には、着手前にどのような手順で影響範囲を調査するか、既存のロケーションマスタや連携先システムまで確認対象に含めているかを具体的に確認します。可能であれば、影響範囲調査にどれだけの期間と工数を見込んでいるかを見積書に明記してもらうと、後になって「調査していなかった」という言い訳を防ぎやすくなります。

改修そのものだけでなく、変更していない既存機能に不具合が生じていないかを確認するデグレードテストの体制、そしてリリース前後の現場教育をどこまで支援してもらえるかも比較軸になります。改修規模が小さいからといって、これらの工程を省略する提案には注意が必要です。デグレードテストの範囲を委託先任せにせず、日常的によく使う画面・帳票のリストを自社側でも用意し、テスト項目に漏れがないかを一緒に確認する姿勢も重要です。

モックアップ・プロトタイプ・PoCの使い分け

WMS改修の検証手法には、見た目を確認するモックアップ、操作性を確認するプロトタイプ、技術的な実現性を確認するPoCがあります。改修の規模やリスクに応じて、どこまでの検証を行うかを見極めることが、無駄な工数を避けるポイントです。

画面レイアウトや帳票の見た目を確認するモックアップは、改修規模の大小にかかわらず、現場の認識を委託先とすり合わせるために欠かせません。完成後に「思っていた画面と違う」という手戻りを防ぐ、最も基本的な確認手段です。モックアップの確認は、情報システム部門の担当者だけでなく、実際にその画面を操作する現場担当者にも見てもらうと、専門用語の解釈違いによる認識のずれを早い段階で防げます。

実際に近い操作感を確認するプロトタイプは、必須ではないものの、現場の作業手順に沿って触ってもらうことで、リリース後の使い勝手のずれを事前に見つけやすくなるため推奨されます。特に、ハンディ端末のように画面が小さく、片手での操作を求められる場面では、モックアップの見た目だけでは分からない操作性の課題が、プロトタイプの段階で見つかることが少なくありません。

技術的な実現性を確認するPoCは、既存のロケーションマスタや上位システムとの連携方法が確立している通常の改修では、基本的に省略できることが多いとされています。ただし、新しいハンディ端末の独自通信方式を検証する必要がある場合など、技術的に前例のない要素を含む改修では、PoCを実施したほうが手戻りのリスクを減らせます。PoCを実施するかどうか迷った際は、委託先に「この改修で技術的に前例のない要素はどこか」を明確に説明してもらい、その部分に限定してPoCを行うことで、検証にかける期間を必要最小限に抑えられます。

見積もり・費用感を比較する進め方

複数社から見積もりを取る際は、金額の総額だけでなく、工程ごとの内訳や、保守契約との関係を同じ条件でそろえて比較することが重要です。同じ改修依頼内容を複数社に提示する際は、口頭説明だけでなく、対象範囲や現状の課題を簡潔にまとめた資料を用意しておくと、各社の見積もりの前提条件をそろえやすくなります。

見積もりを比較する際は、現状分析・要件整理、改修設計、開発・実装、テスト、リリース・現場教育のどこにどれだけの費用と期間を見込んでいるかを確認します。総額だけを比較すると、一部の工程を簡略化した見積もりを、丁寧に工程を積み上げた見積もりより安く見誤ることがあります。工程ごとの内訳が極端に大まかにしか示されていない見積もりは、着手後に「想定外の追加費用」が発生しやすい傾向があるため、内訳の粒度自体も比較のポイントになります。

改修費用は、既存の保守契約の範囲に含まれるのか、別途費用が発生するのかによって実質的な負担が変わります。軽微な改修が保守契約に含まれると明記されていない場合、1件あたりの最低作業料金が別途請求されることがあるため、契約書や見積もり条件を事前に確認しておくことが望まれます。保守契約の更新時期にあわせて、過去1年間に発生した改修の件数と金額を振り返っておくと、次年度の契約プランを見直す際の具体的な材料になります。

フルスクラッチ開発・全面刷新への切替判断

改修を繰り返すうちに、部分改修では対応しきれなくなっていくケースもあります。委託先選定と並行して、切替の判断指標を持っておくことが重要です。

年間の保守費用や追加改修費が、初期の開発・改修費用に対して大きな割合を占めるようになってきた場合は、部分改修を積み重ねるより、全面的な見直しを検討したほうが結果的にコストを抑えられることがあります。改修のたびにかかった費用を記録し、累積で管理しておくと、この判断がしやすくなります。委託先の選定と並行して、社内でも改修費用の累積状況を定期的に棚卸しし、判断のタイミングを逃さないようにしておくことが望まれます。

改修を重ねるうちにシステムの構造が複雑化し、一つの変更が別の箇所に予期しない影響を及ぼすようになってきた場合や、当時の担当者が異動・退職して仕様が分からなくなっている場合は、改修より全面刷新やリプレイスを検討する時期に近づいている可能性があります。具体的な製品・移行先の比較はWMS改修のパッケージ・クラウド製品一覧で解説しています。

WMS改修導入前に確認しておきたいポイント

委託先を絞り込んだ後も、契約形態や検証範囲、教育計画まで含めて確認することで、着手後の想定外を減らせます。契約締結の直前に慌てて確認するのではなく、選定の初期段階からチェックリストとして持っておくと、複数社を比較する際の抜け漏れを防げます。

小さな画面修正であっても、影響範囲の調査やテストを省略した見積もりでは、後から不具合対応の追加費用が発生することがあります。規模が小さいからこそ、工程の内訳を確認する価値があります。「軽微だから大丈夫」という説明だけで済ませる委託先よりも、小さな改修でも最低限の影響範囲確認とテストを行う姿勢を持つ委託先のほうが、長期的な付き合いでは安心材料になります。

月額固定型で軽微な修正を吸収しつつ、規模の大きい改修だけ請負契約で個別発注するといった組み合わせも可能です。すべてを一つの契約形態に無理に当てはめる必要はありません。同じ委託先に両方の契約形態を任せるだけでなく、日常的な軽微修正は保守契約内の会社に、規模の大きい改修だけ別の専門会社に発注するという使い分けも選択肢の一つです。

既存の通信方式や連携方法をそのまま使う改修であればPoCは基本不要ですが、新しい端末やこれまでにない連携方式を採用する場合は、着手前にPoCで実現性を確認したほうが手戻りを防げます。判断に迷う場合は、委託先に技術的なリスクの有無を明確に説明してもらい、リスクが低いと判断できる根拠を確認したうえで、PoCを省略するかどうかを決めることが望ましいです。

まとめ

WMS改修の選定では、まず現場のどの工程に課題が集中しているかを切り分け、月額固定型・スポット改修・請負/準委任という3つの契約形態から自社に合う形を選びます。そのうえで、影響範囲調査の進め方やデグレードテスト・現場教育の体制を評価軸に委託先を比較し、モックアップ・プロトタイプ・PoCを規模に応じて使い分けることが重要です。どの評価軸も、一度の選定で終わるものではなく、次回以降の改修依頼でも継続して確認していく項目として社内に残しておくと役立ちます。

見積もりは総額だけでなく、工程ごとの内訳と既存の保守契約との関係をそろえて比較してください。保守費用や追加改修費が累積して開発費に対する割合が大きくなってきた場合は、フルスクラッチ開発や全面刷新への切替も選択肢に入れます。

自社の課題が改修で解決できる範囲かどうかを見極めたら、次は具体的な委託先・開発基盤の候補を比較する段階です。既製のローコード基盤や部分改修では対応しきれない独自要件がある場合、riplaはフルスクラッチ開発の立場から、既存WMSや上位システムとの連携を含む改修・開発を支援しています。改修と全面刷新のどちらを選ぶべきか判断がつかない段階でも、現状の課題を整理した状態であれば相談しやすくなります。

▼全体ガイドの記事
・WMS改修の完全ガイド

株式会社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を創業。