ECサイト運用保守の改修は、規模を見極め、期限から逆算してテスト期間を確保する順に進めます。
障害対応は数時間、機能追加は数週間〜数ヶ月が目安です。納期を誤ると、新商品発売やセールで機会損失や売上減を招きます。全体像は、ECサイト運用保守の完全ガイドもご覧ください。
▼全体ガイドの記事
・ECサイト運用保守の完全ガイド
Webサービス開発の種類・工程・費用・会社選定までの全体像については、無料ホワイトペーパー「Webサービス開発の完全ガイドブック」で詳しく解説しています。
ECサイト運用保守における開発期間・納期の全体像
ECサイトの開発期間というと、ゼロから構築する新規開発を思い浮かべる人も多いでしょう。しかし、運用保守の開発は、稼働中のサイトへの機能追加、不具合修正、外部環境への対応が中心です。
新規構築では、企画・準備に1〜2ヶ月、事業計画に2〜4週間、サイト構築に1〜6ヶ月を見込みます。一方で、運用保守の改修は、数時間のバグ修正から数ヶ月かかる基幹システム連携の刷新まで幅があります。そのため、案件ごとに規模を見極め、工程と日程を設計することが、納期管理の出発点になります。
運用保守フェーズの改修・追加開発の種類
運用保守の開発は、対応内容によってリードタイムが異なります。対応は大きく3種類に分けられます。
- 障害・不具合対応：セール時のサーバーダウン、決済エラー、在庫の二重引き当てなど、売上や信用に関わる緊急対応です。
- 日常的な更新運用：商品ページ、価格、在庫、バナーなどの更新です。
- 機能改善・追加開発：CVR改善のカート刷新、新決済、レコメンド強化、モール連携など、成長を支える改修です。
障害対応は数時間、日常更新は即日〜数日、機能追加は数週間〜数ヶ月が目安です。同じEC開発でも内容によって納期の目安は変わるため、発注側は依頼のたびに基準を分けて考えます。
これらが並行すると保守の人手を奪い合い、障害対応に人が取られて、計画していた機能追加が遅れることがあります。優先度と工数を一覧にしておかないと、機能追加が後ろ倒しになる場面も少なくありません。
商戦期デッドラインからの逆算という考え方
ECの改修は、商戦期の期限から逆算して組みます。前から開発期間を積み上げる順算と違い、期限を先に置いて各工程の日を決めます。
- セール本番に向けた負荷テストとリハーサルに、2週間を当てます。
- 結合テストと検収は、2週間で行います。
- 開発には1ヶ月を見込み、要件を固めて着手する日を決めます。
- セール直前の数日間は、コードフリーズ期間として空けておきます。
年末商戦、ブラックフライデー、スーパーセールといった商戦期の日付は、1年前から決まっています。新生活シーズンやブランド独自のアニバーサリーセールの日付も、事前に分かっています。たとえば、11月末の大型セールに決済手段を追加する場合は、遅くとも9月中旬に要件を固めて着手します。
コードフリーズは、本番直前の改修で新たな不具合が起きるのを避けるために設けます。テストや凍結の期間を先に確保し、残った時間に開発を収めることが、納期を守るうえで欠かせません。
プラットフォーム種別で異なる納期感
同じ改修でも、ECのプラットフォームによって納期は大きく変わります。
- ASP・SaaS型：軽微な機能追加は最短数日〜数週間です。
- モール型：提供機能内の調整は2週間〜1ヶ月が目安です。
- パッケージ型・コンサル伴走モデル：規模により数ヶ月かかります。
- フルスクラッチ型：小規模でも数週間、大規模なら数ヶ月〜半年以上です。
ShopifyやBASEなどのASP・SaaS型は、拡張アプリの導入や設定変更で済む場合があります。一方、楽天やAmazonなどのモール型は、モール側が提供する機能の範囲内で調整します。
EC-CUBEやecbeingなどのパッケージ型では、設計・開発・テストの工程が必要になります。フルスクラッチ型は自由度が高いものの、影響調査や回帰テストに時間がかかります。
同じ要望でも、実現までの速さは基盤によって何倍も違います。そのため、自社の環境を踏まえて計画を立てることが、現実的な日程につながります。
スピードを重視する施策は、SaaSの標準機能で進めます。そのうえで、独自性が競争力になる部分は作り込みます。
運用保守の改修案件の工程とスケジュール
一定規模以上の改修では、要件定義、設計・開発、テスト・リリースの工程を順に踏みます。稼働中のサイトでは、既存機能が壊れていないかを確かめる回帰テストと、実データを使った結合テストが欠かせません。納期を左右するのは、この工程の組み立てと日程の取り方です。
工程配分と結合テスト・検収の重要性
工程を配分するときは、改修規模に応じてテストの時間を十分に取ることが大切です。
- 要件定義：全体の20〜30%が目安です。
- 設計・開発：全体の40〜50%が目安です。
- テスト・リリース：全体の20%程度が目安です。
カート、決済、在庫の不具合は売上損失や顧客クレームにつながるため、ECの運用保守では、テスト・リリースを新規開発以上に手厚く確保します。
たとえば、決済改修では特定ブランドのカードが通らず、在庫改修では在庫がマイナスになることがあります。テストが十分でないまま本番に入れると、こうした決済や在庫の事故が起こり得ます。テストを削ると、リリース後の障害対応で時間とコストが膨らむことがあります。
実データを使って、決済、在庫減算、メール通知の結合テストと検収を行います。検収費用は5万〜15万円程度が目安で、配送メール通知も確認します。PC、スマートフォン、タブレットでは、本番を想定した検証も行います。
障害対応・改修のSLAと納期
運用保守の納期は、SLA（サービスレベル合意書）に基づいて対応時間を決めます。
- 重大障害：初回応答15分以内、解決目標4時間以内とする例です。
- 暫定対応：通常の改修・不具合で8時間以内とする例です。
- 恒久対応：根本原因への対応を5営業日以内とする例です。
重大障害は売上に直結するため、応答と復旧の期限を契約の段階で決めておきます。発注前には、各対応時間が保守契約のどこまで含まれるかも確かめます。ただし、24時間365日の監視と一次対応が契約に含まれていても、恒久対応の開発は別見積もりになることがあります。
バグ改修が無償か、仕様変更が有償かが曖昧だと、その調整に時間がかかり、復旧が遅れることがあります。そこで、SLAに応答時間、復旧目標時間、対応範囲を数値で定め、それに見合う保守体制を確保します。
商品・価格更新運用の日常的なリードタイム
商品ページの追加や価格・在庫の更新、セールバナーの差し替えは、頻度の高い作業です。開発というより運用作業に近いものの、即日〜数日でも運用の流れが納期に影響します。
- テキスト・画像差し替え：スポット依頼は1回3,000〜10,000円程度です。
- 月額保守内の更新：月額5,000〜15,000円程度が相場です。
- 新規ページ追加：1ページあたり10,000〜30,000円が目安です。
CSV一括登録や価格・在庫の自動連携を整えると、更新の手間を減らせます。数百点を手作業で入れ替えると数日かかるのに対し、一括処理なら数時間で済みます。
自社と保守ベンダーの担当範囲を明確にすると、納期のぶれを防ぎやすくなります。たとえば、軽微な更新は自社が管理画面で行い、システム改修はベンダーに依頼する分担があります。
納期・リードタイムを左右する要素
予定どおりに進まない原因は、技術の難しさより、連携の調整、曖昧な要件、素材準備の遅れにあることがあります。
モール・外部連携の追従とすり合わせ
外部連携では、開発そのものより仕様のすり合わせに時間がかかることがあります。
- データ定義：文字コード、桁数、税込・税抜、商品コードを決めておきます。
- 仕様合意：連携データの粒度と形式を仕様書にまとめます。
- 日程調整：外部先のリリースに合わせてテストの日程を組みます。
連携の対象には、ERPやWMSがあります。楽天やAmazonなどのモールや、決済代行サービスも含まれます。税抜の管理と税込の連携が食い違うと、表示価格や受注金額が合わないことがあります。
データ連携仕様書を作り、自社、連携先、開発ベンダーの三者で着手前に合意しておきます。この調整を後回しにすると、開発そのものより関係者間の調整が長引き、数ヶ月単位で遅れることがあります。
外部モールでは、相手のリリース時期に合わせて自社のテストや対応を進めます。早めに情報を得て余裕のある日程を組むことが、納期の短縮につながります。
スコープクリープとささげ業務の遅れ
開発途中の仕様変更や追加要件はスコープクリープと呼ばれ、納期を狂わせる要因のひとつです。たとえば、決済方法や複雑な送料、会員ランクの仕様を後から変えると、工数が倍増することがあります。
- 要件の具体化：改修内容をできる限り固めてから着手します。
- 変更管理：影響、工数、費用を確認し、承認後に実施します。
- 準備工程：コンテンツ担当者と期限をスケジュールに記します。
ささげ業務とは、撮影・採寸・原稿作成のことで、遅れると実データを使った最終テストができなくなります。商品画像、説明文、商品マスタCSVの準備は、開発と並行させて発注側のタスクに含めます。
コンテンツ準備の遅れもリリースに影響します。システム開発が順調でも、コンテンツ不足でリリースできないケースは現場で多くあります。
開発体制と契約形態の影響
専任チームか兼任エンジニアかによって、改修着手までの待ち時間が変わります。契約条件も、体制や対応開始時期に影響します。
- 対応体制：専任チームか、他案件と兼任かを確認します。
- 保守範囲：負荷対策やサーバー追加の費用条件を確認します。
- 契約定義：無償のバグ改修と有償の仕様変更を区別します。
キャッシュサーバー整備やサーバーリソース追加は、保守内か都度見積もりかを契約の段階で確かめます。商戦期のアクセス集中に備える負荷対策の契約条件は、トラブル時の納期と追加費用を左右します。
バグ改修が無償か仕様変更が有償かの定義が曖昧なまま進むと、見積もり調整でスケジュールが遅れることがあります。
首都圏の平均月額単価は約116万円、地方のニアショア開発は約87万円です。さらに、ニアショア開発では、専任体制を保ちながら単価を約25%下げる選択肢もあります。
継続して依頼する場合は、毎月一定のリソースを確保する契約にすると、優先改修の着手が安定します。契約は、コストだけでなく、納期を守る体制を確保できるかにも関わります。
短納期化と安定稼働を両立する方法
市場の変化が激しいECでは、競合より早く施策を打てるかどうかが売上を左右します。そのため、安定稼働とリードタイム短縮を両立させる工夫が必要になります。
テンプレート開発・AI駆動開発とMVP
共通機能にはテンプレートを、固有機能にはAI駆動開発を活用できます。
- テンプレート：会員認証、管理画面、注文一覧に流用します。
- AI駆動開発：検索、レコメンド、独自施策の構築に使います。
- MVP：最小限の機能セットで始め、後から広げる進め方です。
テンプレートとAI駆動開発を活用すると、独自機能の開発を従来の約3分の1に短縮できるとされています。MVP（最小限の機能セット）なら、全機能を一度に作って工期が長くなるのを避けられます。売上に直結する機能から早く出し、利用者の反応や運用データに応じて段階的に広げます。
検証の段階では、ノーコードで短納期・低コストの試作品を作り、効果を見てから本実装に進めます。
RFP・ワイヤーフレームの事前準備
発注前に要件を具体化しておくと、認識のずれや開発開始後の手戻りを減らせます。
- 機能の優先度：実現したい内容の順番をまとめます。
- 連携先一覧：必要な外部システムやAPIを整理します。
- 画面設計：ワイヤーフレームや画面遷移図を用意します。
これらをまとめたRFP（提案依頼書）は、開発会社との認識のずれを防ぐ材料になります。事前準備によって、開発開始後の手戻りコストを約40%削減できるとされています。
漠然とした要望のままでは、前提の確認に時間がかかり、着手が遅れることがあります。たとえば、購入フローの変更画面と既存機能への影響を図で示すと、見積もりの精度が上がります。準備で後工程の手戻りが減るため、全体のリードタイム短縮にもつながります。
ラボ型契約によるアジャイルな改修体制
細かな改修を継続する場合は、ラボ型（準委任）契約でチームを確保する方法があります。
- チーム確保：毎月固定のエンジニアリソースを確保します。
- 優先施策から実装：実装と検証をアジャイルに回します。
- テーマ変更：市場の変化に合わせて月ごとに改修内容を変えます。
都度見積もりと稟議が必要なスポット契約では、施策のタイミングを逃すことがあります。ラボ型なら、今月はカート離脱対策、来月は新決済の追加というように、進め方を柔軟に変えられます。
請負契約は完成を約束する一方で、仕様変更には弱い面があります。準委任契約は、実工数に応じて費用が発生し、仕様変更に対応しやすい契約です。
最終的な費用が変動するリスクはあります。ただし、優先度とスプリント計画を組むことで、予算内の成果を目指せます。
まとめ
運用保守では、商戦期から逆算して、テスト、リハーサル、コードフリーズを先に確保します。決済や在庫の結合テストを行い、SLAで障害時の応答と復旧の時間を定めておきます。
納期に影響する要因は、外部連携と要件変更、ささげ業務です。体制と契約条件も、納期に関わります。
テンプレートやAI駆動開発、MVPは状況に応じて活用でき、RFPの準備やラボ型契約も検討できます。保守体制と契約が納期を守れる内容かを確かめ、具体的な改修計画は、複数の開発パートナーに相談して比べます。
▼全体ガイドの記事
・ECサイト運用保守の完全ガイド
▼開発を相談する前に読みたい無料ホワイトペーパー
・Webサービス開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。