ITシステム仕様変更対応の開発期間・スケジュール・納期について

システム開発プロジェクトでは、要件定義や外部設計がいったん確定した後であっても、クライアントの事業環境の変化や現場からの追加要望によって、当初の仕様に対する変更依頼が発生することは珍しくありません。むしろ、開発期間が長期化するプロジェクトほど、途中で「やっぱりこの画面にこの項目も追加してほしい」「稼働後に使ってみたら、この帳票の集計方法を変えてほしい」といった声が上がるのはごく自然な流れだといえます。しかし、こうした仕様変更の要望が発生するたびに、開発ベンダー側もクライアント側も、対応の窓口や検討プロセスが曖昧なまま口頭でやり取りを進めてしまうと、「結局この変更にはどれくらいの期間がかかるのか」「もともとの納期にどれほど影響するのか」が誰にも見えない状態に陥ります。仕様変更そのものは避けられないとしても、それをどう受け止め、どう検討し、どう合意形成していくかという「変更管理プロセス」の設計次第で、開発期間・スケジュール・納期への影響は大きく変わってきます。

本記事では、新規機能を追加する「追加開発」や、稼働後の日常的な小改修・バグ対応を指す「保守開発」、あるいはOS・ミドルウェアのバージョンアップを扱う「アップデート対応」とは異なり、いったん確定した仕様に対して変更要望が発生した際に、それをどのような手続きで受け付け、検討し、承認し、契約に反映させていくかという「仕様変更管理プロセス」そのものに焦点を当てます。変更要求の受付一元化から影響分析、変更管理委員会などによる承認、追加見積り・契約変更とドキュメント修正までの各ステップにどれくらいの期間を見込むべきか、また変更管理プロセスを整備していない場合にどのような遅延リスクが生じるのかを、規模別の期間目安とあわせて具体的に解説します。

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

▼全体ガイドの記事
・ITシステム仕様変更対応の完全ガイド

ITシステム仕様変更対応の期間の全体像

ITシステムの仕様変更対応にかかる期間は、変更の内容が「既存仕様の具体化」の範囲にとどまるのか、それとも明確な「仕様変更」にあたるのかによって大きく異なります。たとえば、すでに合意されている入力項目の並び順を変更する程度の軽微な修正であれば、影響範囲も限定的なため数日程度で対応できるケースが多いでしょう。一方、新しい入力項目を追加し、それに伴って画面表示や帳票出力、場合によってはバッチ処理や外部システムとの連携仕様まで見直しが必要になるような通常の仕様変更であれば、受付から影響分析、承認、契約変更に至る一連の変更管理プロセスを経る必要があり、数週間程度の期間を見込んでおくのが現実的です。さらに、業務フローの前提そのものが変わるような根本的な仕様変更の場合は、いったん要件定義の段階まで立ち戻って検討し直す必要が生じることもあり、その場合は数ヶ月単位の期間がかかることも珍しくありません。仕様変更対応の期間を見誤らないためには、まず変更要望がこの3つのどの水準に該当するのかを見極めるところから始める必要があります。

仕様変更対応にかかる期間を規模別に整理すると、見通しが立てやすくなります。第一の水準は、すでに合意した仕様の範囲内での「具体化」にあたる軽微な修正です。たとえば、入力フォームの項目順序を入れ替える、ボタンの文言を変更するといった、他の機能への影響がほぼ生じない変更であれば、影響分析も簡易的なもので済み、数日以内に対応を完了できます。第二の水準は、新しい入力項目や表示条件を追加するなど、他の画面・帳票・バッチ処理への影響が一定範囲で発生する通常の仕様変更です。この水準では、変更要求の受付から影響分析、ユーザーとベンダーによる承認、追加見積りと契約変更、関連ドキュメントの修正までの一連のプロセスをひととおり経る必要があり、規模にもよりますが数週間程度を見込んでおくべきです。第三の水準は、業務フローの前提や画面構成の骨格そのものに関わる根本的な仕様変更です。この場合は、部分的な修正では対応しきれず、いったん要件定義からやり直すことが検討されるため、影響分析だけでも相応の時間がかかり、承認までの合意形成、契約変更の交渉を含めると数ヶ月単位のスケジュールになることが一般的です。自社が直面している変更要望がこの3水準のどこに位置するのかを早期に見極めることが、現実的な納期設定の出発点になります。

仕様変更対応の期間を左右するもう一つの重要な要素が、そもそも変更管理プロセスというものが組織内・プロジェクト内に整備されているかどうかです。変更管理プロセスが存在しないプロジェクトでは、現場やクライアント担当者からの要望が、打合せの場での口頭のやり取りだけでその都度なし崩し的に受け入れられてしまいがちです。この状態では、個々の変更が積み重なるたびに開発範囲がじわじわと広がっていき、気づいたときにはスケジュール全体が大きく後ろ倒しになっているという事態を招きます。一方、変更要求の受付窓口を一元化し、影響分析と承認のステップを経てから着手するという変更管理プロセスが機能しているプロジェクトでは、個々の変更要望について「対応するとすれば、いつまでに、どれくらいの追加期間が必要か」を都度明確化したうえで意思決定できます。このため、仮に多くの変更要望が発生したとしても、当初の納期に対する影響を可視化しながらコントロールできる状態を保てます。仕様変更そのものをゼロにすることは現実的ではありませんが、変更管理プロセスの有無によって、同じ量の変更要望であってもスケジュールへの影響は大きく異なってくるのです。

変更管理プロセス各ステップの所要期間

確定した仕様に対する変更要望が発生した際、標準的な変更管理プロセスは、大きく(1)変更要求の受付一元化、(2)要求内容の検討・影響分析、(3)仕様変更の承認、(4)追加見積り・契約変更とドキュメント修正という4つのステップで構成されます。仕様変更対応にかかる開発期間・スケジュールを見積もる際は、この4ステップそれぞれにどれくらいの時間がかかるのかを個別に積み上げて考える必要があります。新規開発のように最初から仕様が確定しているプロジェクトとは異なり、仕様変更対応では「検討・合意形成にかかる期間」そのものが工程の中に組み込まれる点が大きな特徴です。以下では、各ステップで具体的にどのような作業が発生し、どれくらいの期間を見込むべきかを順を追って解説します。

変更管理プロセスの最初のステップは、変更要求の受付を一元化することです。誰が、どのような方法（書面やチケット管理システムなど）で変更を求めることができるのかという手続きをあらかじめ明確にしておくことで、窓口があいまいなまま個別に口頭で要望が持ち込まれる事態を防げます。この受付ルールさえ整っていれば、要求そのものの受付自体には数日とかからないのが一般的です。次のステップである影響分析には、より多くの時間がかかります。ベンダーは受け付けた変更要求について、対象の画面だけでなく、他の画面、帳票出力、バッチ処理、外部システムとの連携など、システム全体のどこに影響が及ぶのかを調査しなければなりません。あわせて、スケジュール・コスト・品質のそれぞれにどの程度の影響度があるのかを測定します。この影響分析の工程自体にも相応の工数がかかるため、変更の規模によっては数日から1〜2週間程度を要することも珍しくありません。特に、モジュール間の結合度が高いシステムほど、影響が及ぶ範囲の特定に時間がかかる傾向があります。なお、この影響分析にかかる費用の扱いについては、着手前にユーザーとベンダーの間であらかじめ協議しておくことが望ましく、この協議自体もスケジュールに織り込んでおく必要があります。

影響分析の結果がまとまったら、次はその結果をもとにユーザーとベンダーが協議し、仕様変更を承認するかどうかを決定するステップに移ります。小規模なプロジェクトであれば、担当者間の打合せで数日のうちに結論を出せることもありますが、規模の大きなプロジェクトでは「ステアリング・コミッティ」と呼ばれるような会議体、いわゆる変更管理委員会を設置し、そこで決定事項を正式に記録化するのが一般的です。この会議体は定例で開催されることが多いため、次回の開催まで承認が持ち越しになるケースもあり、その分だけ承認までのリードタイムが延びる可能性があります。承認にあたっては、影響分析で明らかになったスケジュール遅延や追加コストを、ユーザー側が受け入れられるかどうかが最大の論点になります。ここで、変更内容が既存の仕様を部分的に修正すれば済むものなのか、それとも業務フローの前提から見直す必要がある根本的な変更なのかによって、承認までの期間は大きく変わります。もし後者に該当すると判断された場合は、その場で仕様変更を承認するのではなく、いったん要件定義の段階まで立ち戻って検討し直すという判断が下されることもあり、その場合は承認までの期間がさらに長期化します。

仕様変更が承認されたら、最後のステップとして追加見積りの提示と契約変更、そして関連ドキュメントの修正が必要になります。承認された内容をもとに、スケジュールとコストへの影響を明確にした追加見積書を作成し、本来であれば契約書自体を作り直す契約変更の手続きを行うことが望ましい対応です。あわせて、変更内容を要件定義書や外部設計書といった関連ドキュメントに反映し、修正しておく必要があります。このステップにかかる期間は、追加見積りの作成自体は数日程度で済むことが多いものの、契約変更に関する社内稟議や捺印手続きなどユーザー企業側の事務手続きに時間がかかる場合があり、想定より長引くことも少なくありません。また、ドキュメント修正についても、変更内容が複数の設計書にまたがる場合は、その分だけ修正作業に時間がかかります。ここで重要なのは、承認された内容や合意事項を必ず書面（合意書や変更契約書）に残すことです。口頭の了解だけで開発作業に着手してしまうと、後になって「言った・言わない」のトラブルに発展するリスクが残るため、書面化のステップを省略せずスケジュールに組み込んでおくことが、後工程のトラブル防止につながります。

変更管理を怠った場合に生じる遅延リスク

ここまで見てきた変更管理プロセスの各ステップは、一見すると手間のかかる手続きに思えるかもしれません。しかし、この手続きを省略し、変更要望をその都度なし崩し的に受け入れてしまうと、開発期間・スケジュール・納期の観点でより深刻なリスクを招くことになります。ここでは、変更管理を怠った場合に典型的に発生する3つのリスク、「スコープクリープによるスケジュール膨張」「小さな修正に潜む連鎖的影響とデグレ」「口頭合意のみのトラブル」について解説します。

変更管理プロセスを経ずに、現場やクライアントから寄せられる「あれもこれも」という要望を無制限に受け入れてしまうと、開発範囲が際限なく膨張していく「スコープクリープ」と呼ばれる状態に陥ります。個々の要望自体は小さく見えても、積み重なることで開発工数が増大し、当初のスケジュールは大幅に遅延し、予算も当然のように超過していきます。さらに、限られた期間内に膨れ上がった要望をすべて詰め込もうとすることで、テストや品質確認にかけられる時間が圧迫され、品質面での低下も招きやすくなります。この事態を防ぐための対策は大きく2つあります。一つは、プロジェクトの初期段階で要件に優先順位をつけ、コア機能（MVP）以外の要望については、いったん今回のスコープから外し、別フェーズや将来のバージョンアップで対応するというルールを最初から徹底しておくことです。もう一つは、寄せられた要望が「すでに合意している仕様の具体化」の範囲にとどまるのか、それとも明確な「仕様変更」にあたるのかを厳密に区分して議論することです。この線引きをあいまいにしたまま「ちょっとした変更だから」と安易に受け入れてしまうことが、スコープクリープの入り口になります。

仕様変更対応において注意すべきなのは、見た目には「小さな修正」に見える要望であっても、影響分析を省略してしまうと思わぬ連鎖的影響を及ぼすという点です。たとえば、ある画面に入力項目を1つ追加するだけの変更であっても、その項目のデータは裏側の帳票出力やバッチ処理、外部システムとの連携仕様にまで関わっている場合があります。表面上の画面変更だけを見て「これくらいならすぐできる」と判断し、影響分析を経ずに短納期で対応してしまうと、これまで問題なく動いていた別の機能が意図せず壊れてしまう「デグレ（デグレード）」を引き起こすリスクが高まります。特に、モジュール間の結合度が高いシステムほど、この連鎖的影響の範囲は広くなりがちです。変更管理プロセスにおける影響分析のステップは、まさにこうしたリスクを未然に防ぐための工程であり、「小さな修正だから影響分析は不要」という判断を安易に下さないことが、結果的にスケジュール全体の安定につながります。急ぎの要望であるほど、影響分析を省略したくなる誘惑が働きますが、その省略こそが後工程での手戻りとスケジュール遅延の最大の原因になり得る点を認識しておく必要があります。

変更管理プロセスを整備していないプロジェクトでよく見られるのが、打合せの場で口頭のみで伝えられた追加要望を、そのまま記録に残さず開発を進めてしまうケースです。この状態は、後になって「言った・言わない」のトラブルに発展する大きなリスクをはらんでいます。実際、システム開発をめぐる裁判例においても、仕様書や要件定義書に明記されていない機能については、契約の対象外であると判断される傾向があります。つまり、たとえ打合せの場で先方担当者が「これも入れてほしい」と口頭で伝えていたとしても、それが書面化され双方の承認を得ていなければ、開発側がその機能を実装する契約上の義務を負っていたとは認められにくいのです。この種のトラブルを防ぐためには、どんなに小さな要望であっても、必ず議事録などの書面に残し、内容についてユーザーとベンダーの双方が承認した記録を管理しておくことが欠かせません。この書面化のプロセスは、一見するとスケジュールを遅らせる余計な手間のように感じられるかもしれませんが、実際には後工程での認識齟齬や紛争によって生じる、より大きな手戻りとスケジュール遅延を未然に防ぐための投資だと捉えるべきです。

納期に影響する要因

仕様変更対応の納期は、変更管理プロセスの各ステップにかかる期間の積み上げだけでなく、いくつかの外部要因によっても左右されます。ここでは、特に納期に大きな影響を与える2つの要因、「仕様変更が発生するタイミング」と「根本的な変更による要件定義のやり直し判断」について掘り下げます。

同じ内容の仕様変更であっても、それがプロジェクトのどの段階で発生するかによって、納期への影響度は大きく変わります。要件定義や外部設計が確定した直後の段階であれば、実装や詳細設計にまだ着手していない部分も多く残っているため、変更管理プロセスを経たとしても、比較的短い期間で計画に組み込み直すことができます。しかし、開発がある程度進行し、実装やテストの工程まで進んだ段階で仕様変更の要望が発生すると、すでに作り込んだプログラムやテストケースの手戻りが発生するため、影響分析にも修正作業にも、要件定義直後の変更と比べてより多くの時間がかかります。さらに、システムがすでに稼働した後の段階で仕様変更が発生する場合は、本番環境への影響を最小限に抑えるための移行計画やリリースタイミングの調整も必要になり、納期に対する影響はいっそう大きくなります。仕様変更対応の納期を見積もる際には、単に変更内容の規模だけでなく、それがプロジェクトのどの局面で発生したものかという時間軸の要素もあわせて考慮する必要があります。

変更管理プロセスにおける影響分析や承認のステップを経る中で、当初想定していたよりも変更内容が根本的なものであると判明することがあります。たとえば、業務フローの前提そのものが変わる、あるいは複数の主要機能にまたがる構造的な見直しが必要になるといったケースです。このような場合、部分的な仕様修正として対応しようとすると、かえって既存の設計との整合性が取れなくなり、後工程で予期しない不具合を招くリスクが高まります。そのため、変更管理委員会などの場で「いったん要件定義の段階まで立ち戻って検討し直すべきだ」という判断が下されることがあります。この判断は、短期的には納期を大きく後ろ倒しにする決定に見えるかもしれませんが、中途半端な部分修正を積み重ねた結果、後工程でより大規模な手戻りが発生するリスクを回避するための、長期的には合理的な選択であることが少なくありません。納期への影響を正しく見積もるためには、こうした「要件定義からのやり直し」が発生し得るという前提をあらかじめ関係者間で共有し、根本的な変更が判明した時点で速やかにスケジュールの見直しに着手できる体制を整えておくことが重要です。

まとめ

ITシステム仕様変更対応の期間は、変更内容が既存仕様の具体化にとどまるのか、通常の仕様変更にあたるのか、あるいは要件定義からのやり直しが必要な根本的な変更なのかによって、数日から数ヶ月まで大きく幅があります。変更管理プロセスは、(1)変更要求の受付一元化、(2)要求内容の検討・影響分析、(3)仕様変更の承認（変更管理委員会・ステアリングコミッティ）、(4)追加見積り・契約変更とドキュメント修正という4つのステップで構成され、それぞれの所要期間を積み上げて全体のスケジュールを見積もる必要があります。このプロセスを省略し、要望を無制限に受け入れてしまうと、スコープクリープによるスケジュール膨張、小さな修正がもたらす連鎖的影響とデグレ、口頭合意のみによる「言った・言わない」トラブルといった深刻なリスクを招きます。納期に影響する要因としては、仕様変更が発生するタイミング（要件定義後か稼働後か）と、根本的な変更に対して要件定義からのやり直しを判断するかどうかが特に重要です。仕様変更そのものをなくすことはできませんが、受付から契約変更に至るまでの手続きをあらかじめ明確にし、どんな小さな要望であっても書面に残して双方で承認する運用を徹底することが、仕様変更対応のスケジュールを安定させ、後工程でのトラブルを防ぐための確実な一歩となります。

▼全体ガイドの記事
・ITシステム仕様変更対応の完全ガイド

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