保守開発の開発期間・スケジュール・納期について

保守開発とは、すでにリリースされ運用されているシステムを使い続けながら、バグ修正や障害対応、機能の改善、そして業務の変化に合わせた小規模な改修を継続的に積み重ねていく開発のことを指します。新しいシステムをゼロから立ち上げる新規開発が「完成」を目指すのに対し、保守開発には明確な完成というゴールがありません。市場やユーザーの要望、法改正、連携先システムの仕様変更、セキュリティ上の脅威などに対応しながら、稼働中のシステムを止めずに少しずつ育てていくのが保守開発の本質です。だからこそ「この改修はどれくらいの期間で終わるのか」「障害が起きたとき、どこまでのスピードで直してもらえるのか」「保守なのか追加開発なのか、納期の感覚がつかめない」といった疑問に直面する企業担当者が後を絶ちません。新規開発のスケジュール感覚のまま保守開発の納期を引いてしまうと、見積もりと実態が大きくずれ、現場が疲弊する原因になります。

本記事では、保守開発の「開発期間・スケジュール・納期」に焦点を当て、なぜ保守開発は一件あたりの作業が小さくてもスケジュールが読みにくいのか、障害対応・バグ修正・小改修・計画改修という類型ごとの時間軸の違い、既存コード理解と影響範囲調査が期間を左右する理由、そして稼働中のシステムを安全に更新し続けるための継続的な小規模リリースの進め方までを、具体的な目安とともに体系的に解説します。運用しながら直し続けるという保守開発固有の難しさと勘所を理解することで、限られた体制と予算のなかでシステムを長く健全に保つための判断軸が身に付くはずです。これから保守開発の発注や契約見直しを検討されている方、保守の納期やスピードに不満を感じている方は、ぜひ最後までご覧ください。

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

▼全体ガイドの記事
・保守開発の完全ガイド

保守開発のスケジュールは「点」でなく「継続」で考える

保守開発のスケジュールを考えるうえで、まず認識を改めておきたいのは「保守開発には新規開発のような一本のスケジュールラインが存在しない」という点です。新規開発であれば、要件定義から設計、実装、テスト、リリースまでを一直線に並べ、リリース日という終点に向かって全工程を逆算できます。ところが保守開発は、稼働中のシステムに対して大小さまざまな改修が並行的かつ断続的に発生し、それぞれが独立した小さなスケジュールを持ちます。緊急の障害対応が割り込めば計画していた改修は後ろにずれ、ユーザーからの要望が増えればリリースの優先順位が組み替わります。つまり保守開発のスケジュール管理とは「一つの納期を守る」ことではなく、「絶え間なく発生する改修要求を、限られた体制のなかでどう優先順位付けし、安定したリズムで回し続けるか」という継続的な営みの設計に他なりません。この前提を共有しないまま「いつ終わりますか」と問うと、保守ベンダーとの認識齟齬が生まれます。

保守開発の費用感は、一般的に「年間で初期開発費の5〜15%程度」が相場とされています。たとえば初期開発に1,000万円を要したシステムであれば、年間50万〜150万円、月額換算で月数万円から十数万円程度が継続的に発生し続けるイメージです。高度にカスタマイズされたシステムや、外部APIとの連携が多いシステム、古くなったレガシーコードを抱えるシステムでは、この比率が最大で20%程度まで高騰する傾向があります。ここで重要なのは、この費用が「一度きりの納品物への対価」ではなく「システムを使い続けるための継続的なランニング」であるという点です。保守開発のスケジュールも同じ発想で捉える必要があります。一件の改修だけを切り出して「何日で終わるか」を問うのではなく、「月にどれくらいの改修を、どのようなリズムでリリースしていくか」という連続的な計画として考えることで、現実的で破綻しない納期設計が可能になります。納品で終わる新規開発と、終わりのない保守開発とでは、スケジュールの単位そのものが異なるのです。

保守開発で発生する作業は、ひとくくりに「保守」と呼ばれていても、その緊急度と時間軸はまったく異なります。大きく分けると、(1)システムが停止したり業務に重大な支障が出ている「緊急障害対応」、(2)動作はしているが不具合がある「バグ修正」、(3)業務の利便性向上や運用上の細かな要望に応える「小改修」、(4)あらかじめ計画して進める機能追加やリファクタリングなどの「計画改修」の4類型に整理できます。緊急障害対応は分単位・時間単位のスピードが求められ、原因切り分けと暫定対応を最優先します。バグ修正は数日から1〜2週間で恒久対応を行うのが一般的です。小改修は2〜4週間のスプリント単位でまとめて消化し、計画改修は数か月の中期スケジュールで腰を据えて取り組みます。この4類型を同じテーブルの上で「どれをいつやるか」と並べて優先順位を付けることが、保守開発のスケジュール設計の出発点になります。すべてを「至急で」と扱うと、かえって全体が滞ってしまうため、緊急度に応じた時間軸の使い分けが欠かせません。

保守開発の期間を読みにくくする要因

保守開発でしばしば起こるのが「画面に項目を一つ追加するだけ」「ボタンの挙動を少し変えるだけ」といった一見ささいな依頼が、想定の何倍もの期間を要してしまうという事態です。新しく作る部分の量だけを見れば確かに小さいのに、なぜ期間が膨らむのか。その答えは、保守開発の工数の大半が「新しく作る作業」ではなく「既存システムを理解し、変更の影響を確認する作業」に費やされるからです。既存システムには長年の運用のなかで積み重ねられた仕様や例外処理が埋め込まれており、表面的には独立して見える機能どうしが、裏側のデータや処理で複雑に絡み合っていることが珍しくありません。この見えない結びつきを解きほぐし、安全に手を入れられる範囲を見極める作業こそが、保守開発の期間を決める最大の変数です。ここでは、保守開発のスケジュールが読みにくくなる構造的な要因を掘り下げます。

保守開発の見積もりが新規開発と決定的に違うのは、「既存コードの解読」「影響範囲の調査」「既存機能が壊れていないかを確認する回帰テスト」という、新規開発には存在しない工数が必ず上乗せされる点です。とくに長年にわたり機能追加を繰り返してきたシステム、仕様書が整備されていないシステム、販売管理や会計など複数の他システムとデータ連携しているシステムでは、一箇所の変更が別画面の表示、帳票出力、夜間バッチ処理といった思わぬ場所に連鎖的に波及する可能性が高くなります。この影響範囲を事前に正確に予測することが難しいため、保守開発の見積もりはどうしても不確実性をはらみます。実際、保守性が極端に低く複雑化したシステムを別の開発会社が引き継いだ場合、既存コードの解読だけで膨大な時間がかかり、「ゼロから読み解くくらいなら最初から作り直した方が安い」という逆転現象すら起こり得ます。だからこそ保守開発では、改修そのものの工数とは別に「調査・影響分析の工数」を明示的に見積もりへ織り込んでもらうことが、納期の精度を高める第一歩になります。

保守開発の期間を不確実にするもう一つの大きな要因が、ドキュメントの不足と知識の属人化です。設計書や仕様書が最新の状態で残っていないシステムでは、開発者はコードそのものを一行ずつ読み解いて挙動を推測するしかなく、影響範囲の調査に余分な時間がかかります。さらに「このシステムは元の担当者にしか分からない」という属人化が進んでいると、その担当者が異動・退職した瞬間に、誰も全体像を把握できないブラックボックスへと変わってしまいます。こうした状態では、軽微に見える修正でも「触ってみないと影響が分からない」ため、安全側に倒して大きめのバッファを積まざるを得ず、結果として納期が長くなります。これを防ぐには、改修のたびに設計書や変更履歴を更新し続ける運用ルールを徹底すること、そして修正前に「どの機能に影響する可能性があるか」をチーム内でレビューする習慣を持つことが有効です。ドキュメントとレビューへの投資は、一見すると遠回りに見えますが、長期的には保守開発のスピードと見積もり精度を大きく押し上げる、最も費用対効果の高い取り組みです。

類型別の期間目安と対応サイクル

保守開発の期間は「何を直すか」によって大きく変わります。先に挙げた4類型——緊急障害対応、バグ修正、小改修、計画改修——には、それぞれに適したスピード感と対応サイクルがあります。これらを混同し、すべてを同じスケジュールの枠で扱おうとすると、緊急対応に追われて計画改修が永遠に進まなかったり、逆に小さな要望を待たせすぎてユーザー満足度が下がったりします。重要なのは、類型ごとに「目標とする対応時間」をあらかじめ取り決め、それに沿って体制とリズムを設計することです。ここでは、緊急性の高い障害対応から、計画的に進める中期の改修まで、それぞれの現実的な期間目安と回し方を整理します。自社のシステムでどの類型がどれくらいの頻度で発生しているかを把握することが、適切な保守体制を選ぶ手がかりになります。

システムが停止したり、業務に重大な支障が出る障害が発生したときは、何よりもまず「影響度の切り分け（トリアージ）」が時間軸を決めます。全ユーザーが業務不能に陥る重大障害なのか、一部の機能だけが使えない軽微な障害なのかによって、求められるスピードはまったく異なります。実務では、保守契約の中で「重大障害は受付から30分以内に一次対応、4時間以内に暫定復旧を目指す」といったSLA（サービスレベル合意）を定め、緊急度に応じた目標対応時間を明文化しておくのが一般的です。障害対応で大切なのは、最初から完璧な恒久対応を目指すのではなく、まず業務を止めないための暫定対応で復旧させ、原因の根本対策はその後に落ち着いて行う、という二段構えで進めることです。暫定対応と恒久対応を切り分けることで、限られた時間の中でも業務影響を最小化できます。逆に、SLAを定めずに「障害が起きたら都度対応」という曖昧な体制のままだと、いざというときに「いつ直るのか分からない」という最悪の状況に陥りかねません。保守開発の納期を語るうえで、緊急時の対応時間の取り決めは欠かせない要素です。

緊急性のない小改修や機能追加は、要望が発生するたびに個別に着手するのではなく、2〜4週間を一区切り（スプリント）として、その期間内に消化できる分をまとめて開発・テスト・リリースするアジャイル的なサイクルが効率的です。一つのスプリントの中でタスクを細分化し、優先順位の高いものから設計・実装し、回帰テストを経てリリースする。この短い反復を繰り返すことで、ユーザーは定期的に改善を実感でき、開発側も無理のないリズムを保てます。一方、システム全体に関わる大規模な機能追加、データ構造の見直し、古い技術基盤の刷新といった「計画改修」は、数か月単位の中期プロジェクトとして、要件定義からテストまでをしっかり積み上げて進めます。ここで陥りやすいのが、計画改修を進めている最中に小改修や障害対応が割り込み、計画改修がずるずると後ろ倒しになるパターンです。これを避けるには、保守体制の中で「日々の保守対応に充てる工数」と「計画改修に充てる工数」を最初から分けて確保しておくことが有効です。両者を同じ財布で管理すると、緊急性の高い日常対応に押されて、本来重要な計画改修が永遠に着手されないという事態を招きます。

継続的な小規模リリースと納期遅延の防ぎ方

保守開発は稼働中のシステムに手を入れるため、リリースそのものが大きなリスクを伴います。新規開発であれば、まだ誰も使っていない段階で多少のトラブルが起きても影響は限定的ですが、保守開発では一つのリリースの失敗が、現在進行形で業務を回している全ユーザーに直撃します。だからこそ保守開発では、変更を一度に大きくまとめてリリースする「ビッグバンリリース」を避け、小さな単位でこまめにリリースしながら、各リリースで既存機能が壊れていないことを確実に確認する進め方が定石になります。ここでは、回帰テストを織り込んだ安全なリリースの考え方と、保守開発で納期遅延が起きる典型的な要因、そしてそれを防ぐための契約形態の選び方を解説します。スピードと安全性を両立させる仕組みづくりが、保守開発を長く続けるための鍵です。

保守開発のリリースで最も神経を使うのが、改修によって既存の正常な機能が壊れていないか（デグレード）を確認する回帰テストです。単体テスト、結合テスト、システムテストの各工程が終わるごとに回帰テストを実施し、リリース前の最終チェックでも改めて行うことで、変更が思わぬ場所に悪影響を及ぼしていないかを確認します。同じ回帰テストを毎回のリリースで3〜5回以上繰り返すようであれば、手作業で続けるよりもテスト自動化ツールを導入した方が、長期的にはコストもスピードも改善します。さらにリリースの方法も工夫の余地があります。完成した機能をいきなり全ユーザーへ一斉公開するのではなく、まず一部のユーザーだけに限定公開する「カナリアリリース」や、二つのパターンを比較する「A/Bテスト」のように段階的に広げていくことで、万一不具合が見つかっても影響を最小限に抑え、すぐに切り戻せます。さらに、コードの変更を契機に自動でテストとビルドが走るCI/CD（継続的インテグレーション・継続的デリバリー）のパイプラインを整備しておくと、毎回のリリースで人手のかかる確認作業を減らしつつ、品質の劣化を早期に検知できます。手作業に頼った確認は、リリース頻度が上がるほど担当者の負担とミスのリスクを増やすため、保守開発を長く続けるほど自動化への投資が効いてきます。稼働中のシステムを扱う保守開発だからこそ、回帰テストと段階的リリース、そして自動化の仕組みを標準のフローに組み込み、「安全に小さく出し続ける」体制を整えることが、結果として納期の安定とユーザーの信頼につながります。リリースのたびに緊張を強いられる属人的な運用から、淡々と安全に出し続けられる仕組みへと移行することが、保守開発のスケジュールを安定させる最終的な到達点だといえます。

保守開発で納期遅延を招く典型的な要因は、スコープの曖昧な追加要望が積み重なること、回帰テストや調査が後ろ倒しになること、そして進捗がブラックボックス化して問題の発覚が遅れることの三つです。これらを防ぐには、契約形態の選択が大きく影響します。保守開発のように運用しながら仕様変更や追加機能が次々に発生する領域で、完成責任を負う「請負契約」を結んでしまうと、変更のたびに追加費用の交渉が発生し、スピードが大きく削がれます。そのため実務では、作業時間や体制に対して対価を支払う「準委任契約（SESなど）」や、チーム単位でエンジニアを毎月定額で確保する「ラボ型開発」が保守開発のセオリーとされています。ラボ型は月額10万円程度から、最低契約期間1か月といった形で、必要な開発リソースを継続的に確保でき、優先順位の組み替えにも柔軟に対応できます。なお、保守契約に「2年縛り」などの最低契約期間が設定されている場合は、途中解約の可否や違約金の有無を事前に確認しておくことが重要です。納期を守る体制とは、結局のところ「変化に柔軟に対応できる継続的な開発リズムを、適切な契約のもとで確保すること」に集約されます。

まとめ

本記事では、保守開発の開発期間・スケジュール・納期について、新規開発との根本的な違いに着目しながら解説しました。保守開発は納品で終わる一本道のプロジェクトではなく、稼働中のシステムに対して大小さまざまな改修が断続的に発生する継続的な営みであり、スケジュールは「一つの納期を守る」のではなく「絶え間ない改修を安定したリズムで回し続ける」発想で設計する必要があります。一件あたりの作業が小さくても期間が読みにくいのは、工数の大半が既存コード理解と影響範囲調査に費やされるためであり、ドキュメント整備と属人化の解消が見積もり精度を大きく左右します。緊急障害対応はトリアージとSLAでスピードを区切り、小改修は2〜4週間のスプリントで、計画改修は数か月の中期計画で進め、それぞれの時間軸を混同しないことが肝心です。さらに、回帰テストと段階的リリースで安全性を確保し、準委任やラボ型といった柔軟な契約で継続的な開発リズムを確保することが、納期遅延を防ぐ最大の対策となります。保守開発の発注や契約を検討されている方は、まずは自社システムでどの類型の改修がどれくらい発生しているかを整理し、それに見合った体制を相談することから始めてみてください。

▼全体ガイドの記事
・保守開発の完全ガイド

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