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

追加開発とは、すでにリリースされ稼働しているシステムに対して、新しい機能を追加したり、既存の機能を改修・改善したりする開発のことを指します。市場やユーザーのニーズは絶えず変化し、法改正や他システムとの新たな連携、業務フローの見直しなど、システムは一度作って終わりではなく、運用しながら少しずつ育てていくのが当たり前の時代になりました。そのため、新規開発の何倍もの頻度で発生するのが、この追加開発です。しかし、いざ既存システムに手を入れようとすると「この機能追加にどれくらいの期間がかかるのか」「新規開発のときよりも見積もりが読みにくいのはなぜか」「保守の範囲なのか、別途追加開発として発注すべきなのか」といった疑問に直面する企業担当者は少なくありません。追加開発は、ゼロから作る新規開発とも、現状維持を目的とする保守・運用とも性質が異なるため、それぞれの感覚のままスケジュールを引くと、見積もりと実態が大きくずれてしまいます。

本記事では、追加開発の「開発期間・スケジュール・納期」に焦点を当て、なぜ追加開発は作業時間こそ短く済む一方で見積もりが難しいのか、規模別の期間目安とリリースサイクルの考え方、アジャイル的に小さく追加していく進め方、そして納期遅延の典型要因と「既存ベンダー継続」か「他社切替」かで期間がどう変わるのかまでを、具体的な事例とともに体系的に解説します。既存資産があるがゆえに生じる追加開発固有のスケジュール設計の難しさと勘所を理解することで、限られた期間と予算のなかで稼働中のシステムを安全に育てていくための判断軸が身に付くはずです。これから機能追加や改修の発注を検討されている方、あるいは追加開発の納期が読めずに悩まれている方は、ぜひ最後までご覧ください。

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

▼全体ガイドの記事
・追加開発の完全ガイド

追加開発の期間はどう決まるか

追加開発のスケジュールを考えるうえで、まず押さえておきたいのは「追加開発は新規開発よりも作業時間そのものは短く収まりやすいが、その期間は見積もりにくい」という、一見矛盾するような性質です。ゼロからシステムを構築する新規開発が数か月から1年以上を要するのに対し、既存システムへの機能追加や改修は、変更する範囲が部分的であるぶん、純粋な開発工数だけを見れば格段に少なく済みます。ところが実際の現場では「簡単な追加だと思っていたのに、想定の倍の期間がかかった」という事態が頻発します。この差が生まれる理由は、追加開発の期間が「新しく作る部分の量」だけでなく、「既存システムをどれだけ理解し、変更の影響をどこまで確認する必要があるか」によって大きく左右されるからです。ここでは、追加開発の期間がどのような要素で決まるのかを、新規開発との違いに着目しながら掘り下げていきます。

追加開発が新規開発に比べて作業時間を短く抑えられる最大の理由は、すでに稼働している基盤の上に乗せていく開発だからです。新規開発では、システムの土台となるインフラ構成の設計、データベースの設計、認証やログインの仕組み、共通的な画面レイアウトやデザインの方針、開発環境の整備といった、システムを成り立たせるための膨大な「土台づくり」をゼロから行わなければなりません。これらは一つひとつが時間のかかる工程であり、新規開発の期間を押し上げる大きな要因となっています。一方、追加開発では、こうした土台はすでに整っています。データベースのテーブル構造も、ユーザー認証の仕組みも、デザインのルールも既に存在しているため、新しく追加する機能はその上に「乗せるだけ」で済みます。たとえば既存の業務システムに新しい帳票出力機能を一つ追加する場合、認証もデータの保存先も画面の枠組みもすでにあるため、開発者は純粋に帳票を生成するロジックと、その出力画面を作ることに集中できます。これが、もし同等の機能をシステムごと新規に作るとなれば、認証から作り始めなければならず、桁違いの工数がかかります。追加開発は、いわば建て増しのリフォームに近く、基礎や柱がすでにある家に一部屋を加える作業です。更地に家を一軒建てる新規開発とは、必要な手数がまるで違うのです。このように、既存資産を活用できることこそが、追加開発の純粋な開発工数を新規開発よりも小さく抑えられる本質的な理由であり、部分的な機能追加であれば数週間単位で実装が完了することも珍しくありません。

純粋な作業時間は短いはずの追加開発が、なぜ「見積もりにくい」のか。その答えは、既存資産があるがゆえに発生する、三つの目に見えにくい工程にあります。第一が「影響範囲調査」です。稼働中のシステムは無数の機能が複雑に連動しており、たった一箇所のデータベース項目を変更しただけでも、その項目を参照している別の画面や、夜間に動くバッチ処理、定期的に出力される帳票など、思わぬところまで影響が波及します。追加開発では、この「どこに影響が及ぶか」を着手前に洗い出す調査が不可欠であり、システムが大きく複雑であるほどこの調査に時間を要します。第二が「既存コードの理解」です。追加開発を担当する開発者は、まず既存のシステムが「何と何が連動して、どのように動いているのか」を読み解くところから始めなければなりません。特に、長年にわたって何度も機能追加を重ねてきたシステムや、設計書などのドキュメントが整備されていないシステムでは、コードを一行ずつ追いかけて挙動を特定する作業に膨大な時間がかかります。新しく作る機能そのものは小さくても、この「既存システムを理解する時間」が期間を押し上げるのです。第三が「回帰テスト（リグレッションテスト）」です。追加開発では、新しく作った機能が正しく動くかを確認するだけでなく、その変更によって既存の機能が壊れていないか（デグレードが起きていないか）を確認する作業が必須となります。影響範囲が広ければ広いほど、確認しなければならない既存機能の数も増え、テスト工数は膨れ上がります。この三つの工程は、新規開発にはほとんど存在しない、追加開発に固有の「隠れた工数」です。実装そのものは一週間で終わっても、影響範囲の調査と回帰テストに三週間かかる、といったことが当たり前に起こるからこそ、追加開発の期間は表面的な作業量だけでは測れず、見積もりが難しいのです。正確な見積もりには、既存システムの理解度と影響範囲の広さを冷静に評価することが欠かせません。

規模別の期間目安とリリースサイクル

追加開発の期間は、その規模によって数週間から数か月まで大きく幅があります。だからこそ、自社が依頼しようとしている追加開発がどの規模に当たるのかを把握し、おおよその期間感を持っておくことが、現実的なスケジュール計画の第一歩になります。ここでは、追加開発を「小さな機能追加」と「中規模改修」に大きく分け、それぞれの期間目安を示すとともに、稼働中のシステムを止めずに安全に変更を反映していくためのリリースサイクルの考え方を解説します。追加開発は新規開発と違い、すでにユーザーが使っているシステムへ手を入れる以上、「どう作るか」だけでなく「どう安全にリリースするか」までを含めてスケジュールを設計する必要があります。

追加開発の期間目安は、規模に応じて二つのレンジで捉えると整理しやすくなります。一つ目が、既存システムへの小さな機能追加や改善です。たとえば既存画面に検索条件を一つ足す、新しい集計項目を追加する、ボタン一つで実行できる便利機能を加えるといったレベルの追加であれば、2〜4週間程度を一区切りとして、その期間内に設計・開発・テスト・リリースまでを完結させる進め方が有効です。この「2〜4週間で一つの機能単位を回す」というリズムは、アジャイル開発のスプリント（一定期間で区切って開発を繰り返す単位）の考え方そのものであり、小さな単位で素早く価値を届け、ユーザーの反応を見ながら次の追加へとつなげていくことができます。二つ目が、複数の機能にまたがる中規模の改修や、新しい業務の導入準備を伴うケースです。このレベルになると、影響範囲の調査や既存システムとの整合性の確認に相応の時間がかかり、期間は数か月単位に及びます。実際の事例を見ても、ANAが自社アプリへアジャイル開発を導入するにあたり、その手法を試行・評価するトライアルにおよそ5か月を費やしたケースや、大塚商会が基幹システムの刷新に先立って実施したフィッティングコンサルティング（既存業務とシステムの適合性を検証する工程）に5.5か月、週数にして22週間をかけた事例があります。これらは新しい仕組みを既存の環境へ慎重に適合させていく作業であり、規模が大きくなるほど準備と検証に時間を要することがよく分かります。自社の追加開発がどちらのレンジに当たるのかを見極めることが、期間の目安を持つうえでの出発点となります。

追加開発のスケジュールを考えるうえで、開発期間と同じくらい重要なのが「どうリリースするか」という反映方法の設計です。稼働中のシステムに変更を加える以上、リリースの仕方を誤れば、ユーザーが日々使っている機能を巻き込んで障害を起こしかねません。ここで避けたいのが、多くの変更をまとめて一度に反映する「ビッグバンリリース」です。複数の機能追加や改修を溜め込んで一気に公開すると、万が一トラブルが起きたときに、どの変更が原因なのかを特定するのが極めて難しくなり、影響範囲も大きくなります。これを避けるための基本的な考え方が「段階的リリース」です。機能が完成するごとに小さく公開していくことで、一回あたりの変更量を抑え、問題が起きても影響を限定できます。さらに、新機能をまず一部のユーザーにだけ公開して反応を見る「カナリアリリース」や、二つのパターンを比較する「A/Bテスト」といった手法を組み合わせれば、本格展開の前にリスクを見極めながら段階的に広げていくことができます。もう一つの強力なアプローチが、CI/CD（継続的インテグレーション／継続的デリバリー）による「随時リリース」です。これは、開発者がコードを更新するたびに自動でテストが走り、問題がなければ自動的に本番環境へ反映される仕組みです。手作業でのリリースにつきものの人的ミスを排し、テストの自動化によって品質を担保しながら、高頻度かつ安全に変更を届けられます。CI/CDの環境が整っていれば、小さな改善を「できたそばから」リリースしていくことが可能になり、追加開発のスピードと安全性を両立できます。追加開発のスケジュールは、開発を終える日だけでなく、こうしたリリース方式まで含めて設計してはじめて、現実的で安全な計画になるのです。

アジャイル的に小さく追加する進め方

追加開発の納期を守り、かつユーザーにとって本当に価値のある機能を届けるうえで、相性が良いのがアジャイル的な進め方です。稼働中のシステムへの機能追加は、市場やユーザーの要望が次々と変化するなかで行われるため、最初にすべての仕様を固めてから一気に作り切る進め方よりも、小さく作って反応を見ながら軌道修正していく進め方のほうが、変化に強く、納期も読みやすくなります。ここでは、追加開発を小さな単位で着実に進めていくための二つの要点——「スモールスタートと短いスプリントの反復」、そして「スコープ管理と優先順位付け」——について解説します。これらは、追加開発のスケジュールを破綻させないための実践的な規律でもあります。

追加開発をアジャイル的に進める基本は、「まず最小限で始め、反復しながら育てる」という考え方です。新たに追加したい機能が比較的大きなものであっても、いきなり完成形を目指して数か月かけて一気に作り上げるのではなく、まずはその機能の核となる最小限の部分（MVP＝実用最小限の機能）だけを実装してリリースします。たとえば、既存システムに新しいレポート機能を追加したい場合、最初から多彩なグラフや細かな絞り込み条件をすべて盛り込もうとするのではなく、まずは「最も見たい数値が一つの表で確認できる」という核の部分だけを2〜4週間のスプリントで作り、実際にユーザーに使ってもらいます。そのうえで、「この項目も見たい」「ここはこう表示してほしい」といった現場の生の声を踏まえ、次のスプリントで改良や機能の追加を重ねていきます。この短いスプリントを反復するアプローチには、追加開発ならではの大きな利点があります。一つは、各スプリントの終わりに必ず「動くもの」がリリースされるため、ユーザーが早い段階から価値を享受でき、フィードバックを次の開発に活かせる点です。もう一つは、一回あたりの開発単位が小さいため、影響範囲や回帰テストの負担も抑えられ、リスクを小さく保てる点です。最初にすべてを作り込んでから一度にリリースする方式では、もし方向性が間違っていた場合に手戻りが甚大になりますが、小さく刻んで進めれば、早い段階で軌道修正ができます。完璧な大きな一手を狙うのではなく、不完全でも小さな一歩を素早く重ねる——このスモールスタートと反復の姿勢こそが、変化の激しい追加開発において、納期を守りながら確実に価値を積み上げていく最も堅実な進め方なのです。

小さく刻んで反復する進め方を成立させるうえで欠かせないのが、徹底したスコープ管理と優先順位付けです。追加開発の現場では、運用が続くほどに「あの機能も欲しい」「ここも直したい」という要望が次々と積み上がっていきます。これらをすべて無制限に受け入れてしまえば、どんなに開発を効率化しても期間は際限なく延び、納期は守れません。そこで重要になるのが、溜まった要望に優先順位をつけ、「今回のスプリントで何を作り、何を作らないか」を明確に線引きする規律です。優先順位を決める際には、その機能がもたらすビジネス上の価値の大きさと、実装にかかる工数や影響範囲を天秤にかけ、「効果が高く、かつ着手しやすいもの」から取り組むのが定石です。価値の低い要望や、影響範囲が広く慎重な検討を要する要望は、無理に今回へ詰め込まず、次のスプリントや将来のバージョンへと回します。この「今はやらないことを決める」判断こそが、納期を守るうえで最も効果的な防波堤になります。要望を断ることに後ろめたさを感じる必要はありません。限られた期間のなかで本当に価値の高い機能を確実に届けるためには、何に集中し、何を見送るかを意識的に選び取ることが不可欠だからです。また、優先順位は一度決めて終わりではなく、スプリントごとに見直すことが大切です。市場の変化やユーザーの反応によって、昨日まで優先度が低かった機能が、今日は最優先になることもあります。要望の一覧を常に整理し、その時々で最も価値の高いものから着手していく——この継続的なスコープ管理と優先順位付けの規律が、変化に追随しながらも納期を守り抜く追加開発を支えるのです。

納期遅延の要因と、既存ベンダー継続・他社切替の期間差

追加開発の納期は、計画段階での備えと、誰に開発を任せるかという発注先の選択によって大きく変わります。追加開発は新規開発に比べて期間が短いぶん、わずかな見込み違いや遅延が納期全体に与えるインパクトが相対的に大きく、油断していると簡単にスケジュールが崩れます。ここでは、追加開発で納期遅延を引き起こす典型的な三つの要因とその対策を整理したうえで、稼働中のシステムを「これまで開発してきた既存ベンダーに引き続き任せる」場合と、「別の会社に切り替える」場合とで、期間にどれほどの差が生まれるのかを解説します。発注先の選択は、追加開発の納期を左右する見落とされがちな、しかし決定的な要素です。

追加開発の納期が崩れる要因は、その多くが計画段階での備えによって防げるものです。代表的な三つを順に見ていきましょう。第一が「スコープ外要望の無制限な受け入れ」です。開発が始まってから「ついでにこれも」「やはりこうしたい」という要望が次々と差し込まれ、それらを断れずに受け入れ続けた結果、当初のスコープが膨れ上がって納期を超過するパターンです。対策は、前章でも触れた優先順位付けの徹底にあります。新たな要望が出てきたら、その都度スコープに入れるかどうかを評価し、緊急性や価値が高くなければ「次のバージョンで対応する」と切り分ける規律を持つことです。何でも引き受ける姿勢が、結果として納期破綻を招くことを認識しておく必要があります。第二が「テスト工程の終盤へのしわ寄せ」です。開発を優先するあまりテストを後回しにし、リリース直前にまとめてテストしようとすると、そこで重大な不具合や既存機能のデグレードが見つかったときに、手戻りの時間が確保できず納期が破綻します。追加開発では既存機能への影響確認、すなわち回帰テストが特に重要であるため、テストを終盤に固めるリスクは新規開発以上に深刻です。対策は、開発と並行してテストを早期から進めること、そして回帰テストを自動化しておくことです。テストの自動化が整っていれば、変更のたびに既存機能への影響を素早く確認でき、終盤での発覚を防げます。第三が「進捗のブラックボックス化」です。開発の進み具合が発注側から見えず、「順調です」という報告を信じていたら、納期直前になって大幅な遅れが発覚する、というケースです。対策は、ガントチャートやカンバンボードといったツールを使って進捗を可視化し、誰が見ても今どこまで進んでいるかが分かる状態を保つことです。あわせて、不測の事態に備えてスケジュールにあらかじめバッファ（余裕）を持たせること、そして定例ミーティングで進捗と課題を継続的に共有することも有効です。これら三つの要因は、いずれも追加開発の現場で頻発するものですが、優先順位付け・テストの早期化と自動化・進捗の可視化という対策を講じておけば、その多くは未然に防げるのです。

追加開発の期間を語るうえで見落とせないのが、「誰に任せるか」によって期間が大きく変わるという事実です。稼働中のシステムを、これまで開発・保守してきた既存ベンダーに引き続き依頼する場合と、別の会社に切り替える場合とでは、たとえ追加する機能の内容がまったく同じであっても、必要な期間に大きな差が生まれます。既存ベンダーに継続して依頼する最大の利点は、そのベンダーがシステムの内部構造やドキュメント、過去の経緯をすでに把握している点にあります。前章で述べた追加開発に固有の隠れた工数——影響範囲の調査、既存コードの理解、回帰テスト——のうち、特に「既存コードの理解」にかかる時間が、既存ベンダーであればほぼ不要になります。どこにどんな処理があり、何を変えると何に影響するかを知り尽くしているため、影響範囲の調査もテストもスムーズに進み、結果として工数も期間も短く抑えられます。一方、他社に切り替える場合には、この理解の時間がまるごと上乗せされます。新しいベンダーは、まず引き継いだシステムのコードをゼロから読み解き、仕様を把握するところから始めなければなりません。もしそのシステムの保守性が低く、ドキュメントが整備されていなかったり、コードが複雑に絡み合っていたりすれば、この解読作業に膨大な時間がかかります。極端なケースでは「既存コードを一行ずつ読み解いて理解するくらいなら、いっそ作り直したほうが早い」という判断に至ることすらあり、それほどまでに他社切替の解読オーバーヘッドは大きくなり得ます。引き継ぎや仕様把握だけで数か月単位の期間が追加で必要になることも珍しくなく、これは追加する機能そのものの工数とは無関係に発生する、純粋な切替コストです。もちろん、既存ベンダーの品質や価格に問題がある場合には切り替えを検討すべきですが、その際は目先の機能の見積もりだけでなく、この解読オーバーヘッドを含めた総期間で判断することが重要です。なお、リリース後の流動的な追加開発では、成果物の完成を約束する請負契約よりも、作業時間や開発体制に対して支払う準委任契約（ラボ型開発）のほうが適しているとされます。請負契約では仕様変更のたびに追加費用の交渉が発生しやすいのに対し、準委任契約であれば、変化し続ける要望に柔軟に対応しながら、安定した体制で継続的に機能を追加していけるからです。発注先と契約形態の選択は、追加開発の期間と進めやすさを左右する重要な意思決定なのです。

まとめ

本記事では、追加開発の開発期間・スケジュール・納期について、新規開発や保守との違いを踏まえながら解説しました。追加開発は、すでに整った土台の上に機能を乗せていくため純粋な作業時間は新規開発より短く済む一方で、影響範囲調査・既存コード理解・回帰テストという隠れた工数があるために見積もりが難しい、という二面性を持ちます。規模で見れば、小さな機能追加は2〜4週間のスプリントで、中規模改修は数か月単位で進めるのが目安であり、稼働中のシステムを止めないためには段階的リリースやCI/CDによる随時リリースの設計が欠かせません。進め方としては、MVPから始めて短いスプリントを反復し、スコープ管理と優先順位付けで「今やらないこと」を決める規律が、変化に追随しながら納期を守る鍵となります。そして、スコープ外要望・テストの後ろ倒し・進捗のブラックボックス化という三つの遅延要因を計画段階で塞ぐこと、さらに既存ベンダー継続なら解読の時間が不要で期間が短く済み、他社切替では解読オーバーヘッドで延びるという発注先による差を見据えることが、現実的なスケジュールを描くうえで重要です。追加開発を検討されている方は、まず「その機能はどの規模に当たり、既存システムへの影響はどこまで及ぶのか」を冷静に見極めることから始めてみてください。具体的な進め方や見積もりに迷われた際は、稼働中のシステムを安全に育てる知見を持つ開発パートナーに相談することをお勧めします。

▼全体ガイドの記事
・追加開発の完全ガイド

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