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

OMS改修が必要だと分かっても、その先には「保守を頼んでいるベンダーに追加で依頼するのか」「別のSIerやフリーランスエンジニアに外付けの連携開発を頼むのか」「自社のエンジニアやノーコードツールで内製するのか」という、対応方法そのものの選定が待っています。OMS改修の選定とは、特定チャネルの受注取込ロジック修正や特定帳票のレイアウト変更という限られた対象に対して、費用・納期・保守性の面で最も見合う依頼先と進め方を絞り込む作業を指します。

本記事では、OMS改修を検討する前に整理すべき自社の課題、対応方法の3つの種類、委託先・実施方法を比較する評価軸、見積り依頼から契約までの進め方、検証(モックアップ・プロトタイプ・PoC)の設計方法、フルスクラッチ・外付け開発を選ぶ判断基準を解説します。どこに何を依頼すればよいか迷っている担当者の方が、複数の候補を同じ条件で比較し、2〜3の候補まで絞り込めるように整理しています。

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

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

OMS改修を検討する前に整理すべき自社の課題

依頼先やツールを比較する前に、まず自社の改修がどの規模で、どこまでブラックボックス化しているかを言語化しておくことが、選定のやり直しを防ぎます。

特定帳票の軽微なレイアウト変更のように外部連携を伴わない小規模改修であれば、既存の保守ベンダーへの追加依頼や、社内の担当者による対応でも十分に完結します。一方、特定のECモールの受注取込ロジック修正のように外部連携を伴う中規模改修になると、技術検証の深さが増すため、外部連携の実装経験を持つ委託先を選ぶ必要性が高まります。

自社の改修がどちらに近いかを最初に判定しておくと、声をかけるべき依頼先の候補と、確認すべき技術力の水準が絞り込みやすくなります。

改修を依頼する前に、対象箇所が安定して稼働している部分なのか、設計書とソースコードの内容が乖離し当時の担当者がすでに退職しているような、触ると影響が読みにくい部分なのかを棚卸しします。ブラックボックス化が進んでいる箇所ほど、現行仕様の解析に時間がかかるため、見積り依頼の際にその実態を正直に伝えておくことが重要です。

この棚卸しを怠ると、依頼先が現行仕様を正しく理解しないまま着手し、想定外の手戻りが発生する原因になります。棚卸しの結果は、口頭で伝えるだけでなく、対象箇所の処理内容や関連するテーブル・外部連携先を簡単な資料にまとめておくと、複数の依頼先候補に同じ前提で説明でき、見積りの精度そのものが上がります。

OMS改修の対応方法の3つの種類

OMS改修の対応方法は、大きく保守ベンダーへの追加発注、外部SIer・フリーランスエンジニアへの外付け開発、内製・ノーコードツールでの対応の3つに分けられます。どれを選ぶかは、改修の規模と自社の技術リソースによって変わります。

現在の保守ベンダーは、既存OMSの設計や過去の改修経緯をすでに把握していることが多く、現行仕様の解析にかかる時間を短縮しやすい点が強みです。ただし、保守契約の枠外の追加案件として扱われる場合、通常の保守料金とは別に見積りが発生するため、費用感を事前にすり合わせておく必要があります。

既存OMS本体には手を加えず、外付けの連携プログラムとして開発する方法です。単一チャネルとのシンプルな連携追加であれば費用の目安は約100万〜300万円、期間は1〜3ヶ月程度、データ変換ロジックが複雑な中規模の連携・ミニリビルドになると約300万〜800万円程度、期間は4〜8ヶ月程度が目安になります。現行の保守ベンダーが対応しきれない技術要件がある場合や、費用の妥当性を他社と比較して確認したい場合に検討します。

技術的な不確実性がほとんどない帳票の軽微なレイアウト変更などは、社内のエンジニアや、ノーコード・iPaaSツールを扱える担当者が内製で対応できる場合があります。外部への発注費用そのものを抑えられる一方、対応できる担当者が限られていると、その人材が異動・退職した際に改修対応そのものが滞るリスクがあるため、属人化を避ける工夫も合わせて検討します。

この3種類はどれか一つに固定する必要はなく、改修の内容ごとに使い分けることも可能です。たとえば帳票の軽微な変更は内製で対応し、外部連携を伴う中規模改修だけを外部の委託先に依頼するというように、対象範囲ごとに最適な対応方法を組み合わせる企業も少なくありません。重要なのは、どの改修をどの方法で対応するかという方針を、依頼のたびに検討し直すのではなく、あらかじめ社内の基準として明文化しておくことです。

委託先・実施方法を比較する評価軸

候補が絞れたら、見積りの透明性、外部連携タスクの管理体制、改修後の保守性という軸で横並びに比較します。

見積りが「一式」とまとめられている場合は、要件定義10〜15%程度、設計20〜25%程度、実装30〜40%程度、テスト20〜30%程度、プロジェクト管理10〜15%程度という工程別の比率に照らして内訳を開示してもらいます。テストの比率が10%以下しかない見積りは、検証不足のまま進める前提になっている可能性があるため注意が必要です。

中規模改修では、連携先のECモールの仕様変更やテスト環境の不具合など、自社だけではコントロールできない遅延要因が発生しやすくなります。外部連携に関わるタスクを最優先で着手する体制になっているか、全体スケジュールに10〜20%程度のバッファを見込んでいるか、遅延時のリカバリー策を事前に提示できるかを、委託先選定の段階で確認します。

改修のたびに設計書やソースコードのコメントを更新せずに進めると、次に改修が必要になった際のブラックボックス化が加速します。改修後の設計書更新やコメント整備を契約範囲に含めてもらえるか、次回以降の改修を別の委託先に依頼する場合でも引き継げる状態を残してもらえるかを、事前に確認しておくことが長期的な保守性を左右します。

これら3つの軸は、営業担当者への質問だけで済ませず、実際に改修を担当する技術者に同席してもらい、具体的な確認方法まで統一しておくことが有効です。「見積りの内訳は提案書で確認」「連携タスクの管理体制は過去の改修事例で確認」「ドキュメント整備は契約書の条項で確認」のように証拠の残し方をそろえておくと、候補ごとの回答の質を公平に見比べられます。

見積り依頼から契約までの進め方

対象範囲を明確にしたうえで複数社に同条件で見積りを依頼すると、金額だけでなく対応力の違いも比較しやすくなります。

見積り依頼の前に、対象範囲を「特定チャネルの受注取込ロジックのみ」のように具体的な言葉で絞り込み、必ず対応してほしいMust要件と、対応できれば良いWant要件を分けて整理します。この整理をせずに声をかけると、委託先ごとに異なる前提で見積りが作られてしまい、金額の単純比較ができなくなります。

同じ対象範囲、同じMust/Want整理を提示したうえで、現在の保守ベンダーを含む2〜3社に見積りを依頼します。金額だけでなく、現行仕様の理解度、質問への回答スピード、工程比率の妥当性を同じ基準で比較すると、営業説明の分かりやすさに評価が引っ張られにくくなります。

契約の段階では、SLA(サービス品質保証)を明記してもらうことも欠かせません。障害発生時に対応が始まるまでの時間、平日日中外の問い合わせ対応の可否、改修完了後の保証期間や不具合対応の範囲を契約書に明記してもらうことで、稼働後に「対応してもらえると思っていた」という認識違いを防げます。テストパターンの作成など、自社で巻き取れる工数をあらかじめ切り出しておけば、外注費を抑えつつ、委託先の作業範囲を明確にすることにもつながります。

検証(モックアップ・プロトタイプ・PoC)をどう設計するか

選定プロセスの中でも、検証をどこまで行うかは委託先任せにせず、発注側があらかじめ方針を決めておく必要があります。

帳票フォーマットの変更や単純な計算ロジックの修正など、技術的な不確実性がほとんどない改修であれば、モックアップによる現場確認だけで選定を進めて構いません。一方、新しく連携する特定チャネルの仕様が複雑な場合は、契約前にPoCを実施できる委託先かどうかを確認し、期間2〜8週間程度、費用は本開発の10〜20%程度という目安を踏まえて提案を評価します。

PoCを実施した場合は、本番データベースを使わずテスト用のダミーデータとモックで疑似的な受注データの送受信を行い、既存機能へのデグレードが起きていないかを確認します。PoCの結果、既存機能への影響や連携エラーが多く見つかった委託先は、たとえ見積り金額が安くても選定基準から外すという判断があってよいでしょう。

検証にかける期間が長引きすぎると、選定そのものに時間を取られ、本来2〜8週間程度で終えられるはずの検証が「PoC貧乏」と呼ばれる状態になりかねません。検証を依頼する段階で完了時期と合格条件をあらかじめ委託先とすり合わせておくと、選定プロセス全体のスケジュールが読みやすくなります。

フルスクラッチ・外付け開発を選ぶ判断基準

改修という選択肢の中でも、既存OMSを触らない外付け開発にするか、対象箇所をフルスクラッチで作り直すかという判断が必要になる場合があります。

対象箇所のブラックボックス度と現行の品質、全モジュールを残す・パッチで済む・フルスクラッチで置換の3分類、そしてその機能が競争力の源泉か標準業務かという3つの視点で判断します。自社独自の複雑な受注計算ロジックのように競争優位に直結する部分はフルスクラッチでの作り込みを検討し、標準的な業務は既存の仕組みの流用を優先します。

この判断は委託先に丸投げするのではなく、発注側があらかじめ社内で仮説を持ったうえで、委託先候補と協議する形が望ましいです。委託先によっては、フルスクラッチでの作り込みを提案した方が受注額が大きくなるという事情から、パッチ改修で十分な範囲までフルスクラッチを勧めてくる場合もあります。棚卸しの結果をもとに、自社としてどこまでを標準業務とみなすかをあらかじめ整理しておくと、提案内容を客観的に評価しやすくなります。

最も業務負荷が高い1つのチャネルに対象を絞ってMVP的に開発・リリースし、段階的に範囲を広げていく進め方や、Must/Wantの整理、着手前の業務フローの見える化が、範囲の膨張を防ぎます。具体的な製品・ツールの候補を知りたい場合は、OMS改修のパッケージ・クラウド製品一覧を参照すると、連携基盤を含めた選択肢を比較しやすくなります。

OMS改修の依頼先選びで確認しておきたいポイント

候補を絞り込んだ後も、規模や契約形態によって判断が分かれやすい点があります。

小規模な改修であっても、既存の保守ベンダー1社だけに依頼を決め打ちすると、費用の妥当性を判断する基準を持てません。金額の大小にかかわらず、対応できる範囲と費用感を把握しておく目的で、もう1社程度に相見積りを取ることをおすすめします。相見積りの結果、金額差がほとんどない場合でも、対応スピードやコミュニケーションのしやすさといった定性的な違いが見えてくることがあります。

現行仕様への理解度を重視するなら保守ベンダー、費用や技術力の比較を重視するなら外部委託先というのが基本的な判断軸です。ただし、保守ベンダーが今回の改修に必要な技術要件に対応しきれない場合や、外部連携の実装経験が乏しい場合は、外部の委託先を優先する方が結果的に手戻りを防げることもあります。迷った場合は、まず保守ベンダーに今回の改修が対応可能かどうかを打診し、その回答内容と見積りを踏まえたうえで、外部委託先への相見積りを並行して進めるという順序が現実的です。

内製で対応する場合は、担当者が異動・退職した際に改修の経緯や設定内容が引き継がれるよう、簡単な記録を残しておくことが重要です。属人化した内製対応は、費用を抑えられる反面、将来の改修や保守に必要な情報が失われるリスクを伴います。改修の依頼書や仕様メモを個人のメールやチャットだけに残さず、共有フォルダなど部署で参照できる場所に保管しておくルールを決めておくと、内製・外部委託のどちらの場合でも情報の散逸を防げます。

まとめ

OMS改修の選定は、規模の見極めと対応方法の比較、そして検証結果を踏まえた最終判断という順序で進めることが現実的です。

小規模改修か中規模改修かを見極め、保守ベンダーへの追加発注、外部SIer・フリーランスへの外付け開発、内製・ノーコード対応のどれを軸にするかを早期に決めることが、選定を短期間でまとめる鍵になります。見積りの内訳、外部連携タスクの管理体制、改修後の保守性という評価軸で候補を比較し、必要な場合はPoCの結果まで踏まえて最終判断します。優先順位を決めずにすべての依頼先候補を同時並行で深く検討しようとすると、比較そのものに時間を取られ、肝心の検証や契約条件の確認にかける時間が削られてしまう点にも注意が必要です。

まず対象範囲をMust/Wantで明確にしたうえで、現在の保守ベンダーを含む2〜3社に同条件で見積りを依頼することから始めてください。既存の保守ベンダーや既製のツールでは対応しきれない独自要件がある場合、フルスクラッチによる個別開発も現実的な選択肢になります。riplaはフルスクラッチ開発の立場から、改修の対象範囲整理や、依頼先候補の技術力評価、既存システムとの連携を含む個別構築まで支援しています。

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

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