保守開発の納期は、改修の緊急度、システムの複雑さ、保守体制によって変わります。障害対応は分や時間、計画改修は数か月が単位になり、新規開発と違って完成がありません。
限られた体制と予算で保守を長く健全に保つには、改修の種類ごとの時間軸と納期の見方を押さえる必要があります。
▼全体ガイドの記事
・保守開発の完全ガイド
Webサービス開発の種類・工程・費用・会社選定までの全体像については、無料ホワイトペーパー「Webサービス開発の完全ガイドブック」で詳しく解説しています。
保守開発のスケジュールの捉え方：「点」ではなく「継続」
新規開発は、要件定義からリリースまでを一本のスケジュールに並べ、終点から逆算できます。一方、保守開発には、そうした一本のラインがありません。
保守開発では、稼働中のシステムに大小の改修が並行して、断続的に発生します。改修ごとに独立したスケジュールがあります。
緊急障害が割り込むと計画改修は後ろにずれ、要望が増えるとリリースの優先順位も変わります。そこで、限られた体制で要求を整理し、安定したリズムで回す設計が必要です。
「いつ終わりますか」とだけ尋ねると、保守ベンダーとの間で認識にずれが生まれます。このため、保守開発では、一件ごとの納期よりも、継続的な対応の見通しを共有します。
保守開発は納品して終わらない継続的な開発
システムのリリース後も、運用環境や利用条件の変化に合わせた改修が続きます。
- 市場とユーザー：市場の変化やユーザーの要望を受けた改善
- 法令：法改正に合わせたシステムの修正
- 連携先：連携先システムの仕様変更にあわせた調整
- セキュリティ：新たな脅威への備え
保守費用の一般的な相場は、初期開発費の年間5〜15%程度です。たとえば、初期開発に1,000万円かかった場合は、年間50万〜150万円が目安になります。
月額では、数万円から十数万円程度の費用が継続して発生します。高度なカスタマイズ、外部API連携の多さ、古いレガシーコードなどがあると、比率が最大20%程度まで上がる傾向があります。
この費用は、納品物への一度きりの対価ではなく、システムを使い続けるためのランニング費用です。新規開発は納品で区切りがつきますが、保守開発には終わりがなく、予定の単位も異なります。
一件ごとの改修日数だけでなく、月ごとの改修量とリリースのリズムも計画に含めると、現実的で破綻しない納期を組めます。
障害対応・バグ修正・小改修・計画改修の時間軸の違い
保守作業は、緊急度や必要な期間によって時間軸を分けて考えます。各類型の目安を先に共有しておくと、優先順位を決めやすくなります。
- 緊急障害対応：停止や重大な業務支障に分・時間単位で応じ、原因の切り分けと暫定対応を先に行う
- バグ修正：稼働中だが不具合のある機能を、数日から1〜2週間で直すのが一般的
- 小改修：利便性向上や細かな要望を、2〜4週間のスプリントにまとめて対応
- 計画改修：機能追加やリファクタリングを、あらかじめ計画して数か月単位で進める
すべてを至急扱うと、かえって全体が滞ります。そのため、類型を分けて優先順位を付けることが、スケジュール設計の出発点になります。
保守開発の期間を読みにくくする要因
画面に項目を一つ足す、ボタンの動きを変えるといった依頼でも、想定の何倍もの期間がかかることがあります。工数の多くは新規の作成以外の作業に使われ、その理由は既存システムの理解と変更の影響調査が必要になるためです。
長年の仕様や例外処理によって、独立して見える機能がデータや処理を通じて結び付いていることがあります。そのため、安全に変更できる範囲を見極める作業が、期間を左右します。
既存コード理解と影響範囲調査が占める期間の大半
保守の見積もりには、新規開発にはない調査や確認の工数が加わります。内訳を分けて見積もると、納期の見通しを立てやすくなります。
- コード解読：既存コードを読み、現在の挙動を把握すること
- 影響範囲の調査：変更が及ぶ機能や処理の確認
- 回帰テスト：変更で既存機能が壊れていないかを調べる作業
機能追加を重ねたシステムや、仕様書のないシステムでは、変更の影響を読み取りにくくなります。販売管理や会計など複数の他システムと連携している場合も、影響の範囲は見通しにくくなります。
一箇所の変更が、別画面の表示や帳票出力、夜間バッチ処理へ連鎖する可能性もあり、その影響は見えにくい場所に及ぶことがあります。
影響を正確に予測しにくいため、見積もりには不確実性が残ります。特に、保守性が極端に低い複雑なシステムを別会社が引き継ぐ場合は、コードの解読だけで膨大な時間がかかることがあります。
その結果、ゼロから読み解くより作り直す方が安くなる、という逆転も起こり得ます。このため、改修工数とは分けて、調査・影響分析の工数も見積もりに含めてもらいます。
ドキュメント不足と属人化による見積もりの不確実さ
ドキュメントと担当者の知識をどう管理するかは、保守開発の期間と見積もりに関わります。
- 最新の設計書：資料が古いと、コードを一行ずつ読んで挙動を推測することになり、調査の長期化を招く
- 知識の共有：担当者の異動・退職後に、誰も全体像を把握できないブラックボックスになる恐れ
- 改修記録：改修のたびに設計書と変更履歴を更新すること
- 事前レビュー：修正前に、影響しそうな機能をチームで確認する
資料や担当者の知識が不足すると、軽微な修正でも影響を読み切れず、安全側に大きなバッファを取る必要があります。
ドキュメントとレビューへの投資は、長期的に開発速度と見積もり精度を高めます。保守開発では、費用対効果の高い取り組みと言えます。
類型別の期間目安と対応サイクル
保守開発の期間は、修正の内容によって変わります。緊急障害、バグ、小改修、計画改修には、それぞれ適した速度と対応サイクルがあります。
同じ枠で扱うと、緊急対応に追われて計画改修がいつまでも進まないことがあります。また、小さな要望を待たせすぎると、ユーザー満足度が下がる場合もあります。
類型ごとに目標対応時間を決め、それに合わせて体制とリズムを設計します。自社で各類型の発生頻度を把握しておくと、保守体制を選ぶ手がかりになります。
緊急障害対応の時間の区切り方：トリアージとSLA
障害対応では、影響度に応じた速度と、緊急時の目標を事前に決めておきます。
- 影響度：トリアージによる、障害の影響範囲の確認
- 目標時間：SLA（サービスレベル合意）で定める、緊急時の対応目標
- 復旧方針：まず暫定復旧を行い、根本対策は落ち着いてから進める
全業務が止まる重大障害か、一部機能だけの軽微な障害かによって、必要な対応速度は変わります。
保守契約のSLAには、受付後の目標を明記します。たとえば、重大障害では、受付から30分以内の一次対応と4時間以内の暫定復旧を目指す例があります。
暫定対応で業務を止めない状態に早く戻せば、業務への影響を抑えられます。反対に、SLAを定めずに都度対応すると、復旧時期が分からない状況になりかねません。
小改修は2〜4週間スプリント、計画改修は数ヶ月
小改修と計画改修では、期間も管理方法も異なります。日常の割り込みで遅れないよう、工数の配分を決めておく必要があります。
- 小改修：要望ごとに着手せず、2〜4週間ごとに可能な分をまとめて開発・テスト・リリース
- 計画改修：大規模な機能追加、データ構造の見直し、古い技術基盤の刷新を、数か月単位で進めること
小改修のタスクは細かく分け、優先度順に設計・実装して回帰テストします。短い周期で反復するため、ユーザーは改善を定期的に実感できます。
計画改修は中期プロジェクトとして、要件定義からテストまで積み上げていきます。ただし、小改修や障害対応が割り込み、計画が後ろ倒しになることもあります。
工数を一つの枠で管理すると、日常対応に押されて重要な計画改修に着手できないことがあります。そこで、開始時から工数を分けておくと、この事態を避けやすくなります。
継続的な小規模リリースと納期遅延の防ぎ方
新規開発では、利用前のトラブルの影響は限定的です。一方、稼働中のシステムでは、リリースの失敗が業務を行う全ユーザーに及びます。
そのため、一度に大きく変更を出すビッグバンリリースを避け、小さく分けて公開します。スピードと安全性を両立する仕組みが、保守を長く続けるうえでの鍵になります。
各リリースでは、既存機能が壊れていないかを確認します。
回帰テストを織り込んだ段階的リリース
回帰テストは、改修によって既存機能が壊れていないかを確認するものです。単体・結合・システムテストの各工程の後と、リリース前の最終確認で繰り返し行うことで、変更が思わぬ箇所へ悪影響を及ぼしていないかを確かめられます。
同じ回帰テストを毎回3〜5回以上繰り返すような場合は、手作業よりテスト自動化ツールを導入するほうが、長期的な費用と速度の改善につながります。リリースの方法にも工夫が要ります。
- 段階的な公開：カナリアリリースやA/Bテストで公開し、問題時は切り戻す
- CI/CD：変更を契機に、テストとビルドを自動で実行する仕組み
カナリアリリースは一部のユーザーに限定して公開し、A/Bテストは二つのパターンを比較します。どちらも、不具合が見つかったときの影響範囲を小さく保つための方法です。
CI/CDは、継続的インテグレーションと継続的デリバリーのパイプラインを指します。人の手による確認を減らし、品質の劣化を早く見つけられます。
リリース頻度が上がるほど、手作業による負担とミスのリスクが増えます。保守を続ける期間が長いほど、自動化への投資が効果を発揮します。
回帰テスト、段階的リリース、自動化を標準のフローに組み込むと、安全な小規模リリースを続けやすくなります。その結果、納期が安定し、ユーザーの信頼にもつながります。
属人的な運用から仕組みへ移すと、緊張を強いられずに安全なリリースを続けられます。これが、保守開発のスケジュールを安定させる到達点です。
納期遅延の典型要因と契約形態（準委任・ラボ型）
保守開発で遅延を招きやすい要因は、追加要望の範囲が曖昧なこと、調査や回帰テストが遅れること、進捗が見えず問題の発覚が遅れることです。
遅延を防ぐには、契約形態の選び方も大きく影響します。仕様変更や追加機能が続く保守開発では、請負契約だと変更のたびに追加費用の交渉が発生し、速度が落ちることがあります。
- 準委任契約：SESなど、作業時間や体制に対して対価を支払う方式
- ラボ型開発：チーム単位で、エンジニアを毎月定額で確保する形
ラボ型は月額10万円程度から、最低契約期間1か月といった条件で、開発リソースを継続して確保できます。優先順位の変更にも、柔軟に対応できます。
保守契約に2年縛りなどの最低期間がある場合は、途中で解約できるか、違約金があるかを事前に確認しておきます。
納期を守るには、変化に対応できる開発のリズムを、適切な契約のもとで継続して確保します。
まとめ
保守開発の期間・スケジュール・納期を、新規開発との違いに着目して整理しました。納品で終わらず稼働中の改修が続くため、安定した対応のリズムを設計することが大切です。
期間は既存コードの理解や影響調査に左右されます。ドキュメントを更新して知識の属人化を防げば、見積もり精度を高められます。
緊急障害はトリアージとSLAで速度を区切り、小改修は2〜4週間で回します。計画改修は数か月の中期計画で進めます。それぞれの時間軸を混同しないことが、継続的な保守開発では肝心です。
回帰テストと段階的リリースで安全性を保ち、準委任やラボ型などの契約で、継続的な開発のリズムを確保します。
発注や契約を検討する際は、自社で発生する改修の類型と頻度を整理し、それに合う体制を相談します。
▼全体ガイドの記事
・保守開発の完全ガイド
▼開発を相談する前に読みたい無料ホワイトペーパー
・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を創業。