システム開発の仕様変更への対応｜追加要望の扱い方

システム開発の途中で仕様変更や追加要望が出るのは、珍しいことではありません。問題になるのは変更そのものより、変更の扱い方が決まっていないことです。この記事では、変更を種類ごとに分けて考える方法と、要望が出たときの基本の流れ、発注側で先に決めておきたいことを整理します。

新規事業では、作りながら分かることが多くなります。そのため「変更をなくす」のではなく「変更が出ても判断が止まらない形にしておく」という考え方で書いています。

仕様変更は「起きて当たり前」と考えておく

開発を外注すると、「最初に決めた仕様のとおりに完成する」と考えがちです。しかし実際には、開発が進むにつれて、当初は見えなかった要望や課題が出てきます。変更をゼロにしようとすると、かえって無理が出ます。

なぜ途中で仕様が変わるのか

途中で変更が出る理由は、主に次のようなものです。

• 画面や操作を実際に見て、初めて「これでは使いにくい」と気づいた
• 要件定義の段階では、想定していなかった業務や例外が見つかった
• 事業の前提が変わった（対象の顧客、提供方法、競合の動きなど）
• 関係者が増え、それぞれから新しい意見が出てきた
• 技術的な制約が分かり、元の案をそのまま作れないと判明した

新規事業は、市場や顧客の反応が分からないまま始まることが多い取り組みです。開発の途中で見えてくることが多いのは自然なことで、変更の多さが、そのまま計画の失敗を意味するわけではありません。

ただし、変更が出るたびに「言った、言わない」になったり、納期や品質に影響が出たりすると、事業そのものが前に進まなくなります。変更を前提に、決めごとを整えておくことが大切です。

まず変更の種類を分けて考える

「仕様変更」とひとまとめに呼ばれるものには、性質の違うものが混ざっています。種類によって、誰がどう判断するかが変わります。私たちは、次の4つに分けて考えると整理しやすいと考えています。

1. 不具合（合意した内容と違う動き）

事前に合意した内容と違う動きをしている場合は、仕様変更ではなく不具合です。作る側が修正する対象になるのが一般的です。何を合意していたかを確認できる資料が残っていると、判断しやすくなります。

2. 解釈の違い（合意の範囲内かどうか曖昧なもの）

「当然入っていると思っていた」「そこまでは含まれていないと考えていた」というすれ違いです。仕様書の書き方が曖昧なときに起きやすく、トラブルの原因になりやすい種類です。原因は、言葉だけで要件を決めていることにあります。認識のずれについては、システム開発の認識のズレを防ぐ、実物を見ながらのすり合わせでも整理しています。

3. 追加要望（合意した範囲に入っていない新しい要望）

当初の合意に含まれていなかった機能や画面を足したい、という要望です。作る範囲が増えるため、期間や体制に影響します。受けるかどうか、いつ対応するかを、発注側と開発側で相談して決めます。

4. 方針の変更（事業の前提が変わるもの）

対象の顧客を変える、提供する価値を変える、といった事業の方向に関わる変更です。影響が大きく、すでに作った部分を作り直す必要が出ることもあります。技術的な話というより、事業の判断として決裁者を交えて検討する必要があります。

この4つを混ぜて議論すると、話が噛み合いません。変更の要望が出たら、最初に「どの種類か」を共有するだけでも、その後の話し合いがかなり整理されます。

変更要望が出たときの基本の流れ

種類が分かったら、次の流れで扱います。細かい点は案件によって異なりますが、骨格は共通しています。

手順1：要望を記録して、言葉をそろえる

口頭やチャットで出た要望は、そのままにすると、後から「何を頼んだのか」が分からなくなります。次の内容を、1件ずつ書き出して残します。

• 何を変えたいのか（現状と、変えたい内容）
• なぜ変えたいのか（背景や、解決したい課題）
• 誰が言い出したのか
• いつまでに必要か

特に「なぜ」が大切です。理由が分かれば、開発側が別のより簡単な方法を提案できることもあります。

手順2：影響の範囲を確認する

変更を受けるかどうかを決める前に、開発側に影響を確認します。見たいのは次の点です。

• どの機能・画面・データに影響が出るか
• 作業量はどのくらい増えるか
• 納期や、ほかの機能の完成時期にどう響くか
• 変更によって、すでにできている部分に不具合が出るおそれはないか
• 運用面で、準備や教育が必要なことはあるか

システムの内部は互いにつながっているため、一見小さな変更でも、思わぬ範囲に影響することがあります。発注側が「簡単なことのはず」と考えていても、開発側の見立てを聞いてから判断するほうが安全です。

手順3：優先度を決める

影響が分かったら、今回の開発に入れるか、後回しにするか、見送るかを決めます。基準としては、次のような問いが使えます。

• この変更がないと、事業の検証ができないか
• 利用者が困る度合いは大きいか
• 後からでも対応できるか
• 変更しない場合に、どんなリスクがあるか

すべての要望を取り込もうとすると、完成が遠のきます。何を後に回すかを決めることも、立派な判断です。最初に作るものの絞り方は、MVP開発の機能の絞り方で詳しく扱っています。

手順4：合意して、記録に残す

受ける場合は、内容、対応時期、期間や体制への影響を、発注側と開発側で確認して記録に残します。口頭だけで終わらせず、議事録や変更の一覧に書いておくと、後から経緯をたどれます。

見送る場合も同じです。「今回は見送る」と決めた理由を残しておくと、次の開発や追加の検討で役立ちます。

手順5：反映して、実物で確かめる

変更を反映したら、できあがったものを実際に触って確認します。文書上は合意できていても、動かしてみると期待と違うことがあります。確認の観点は、納品時の検収と共通する部分が多くあります。システム開発の検収とはも参考になります。

発注側で先に決めておきたいこと

流れを知っていても、体制が整っていないと機能しません。開発が始まる前に、発注側で決めておきたいことがあります。

変更を判断する人を決める

要望が出るたびに、関係者の意見が割れて決まらないのは、よくある停滞の原因です。変更の可否を判断する人と、その人がどこまで決められるかを、先に決めておきます。大きな変更だけは決裁者に上げる、といった線引きも有効です。

こうした役割は、発注側のプロダクトオーナーと呼ばれることがあります。役割の考え方は、発注側のプロダクトオーナーとはで整理しています。

窓口を一本化する

要望が、複数の担当者から、別々の経路で開発側に届くと、情報が混ざります。誰が要望をとりまとめて伝えるのかを決めておくと、判断の速度が保てます。

優先度の基準を共有する

「何を大事にするか」の基準が人によって違うと、優先度の議論が終わりません。今回の開発で何を確かめたいのか、何ができれば先に進めるのか、という目的を、あらかじめ関係者でそろえておきます。事業の判断基準を先に作る考え方は、MVP検証の指標を先に決める方法が参考になります。

契約と進め方を確認する

変更の扱いは、契約の形や進め方によって変わります。たとえば、完成した成果物を納める「請負契約」と、作業の遂行を約束する「準委任契約」では、変更が出たときの考え方が異なる場合があります。そのため、契約前に次の点を確認しておくと安心です。

• 変更要望を出したときの、手続きと窓口
• 変更を受けるときの、期間や体制の調整の考え方
• 変更を受けられない場合の、判断のしかた
• 納品後の修正や機能追加が、どの範囲で対応されるか

契約形態の違いは、受託開発とは？依頼の流れ・契約形態・新規事業の選び方で整理しています。ここで挙げた点は一般的な確認事項であり、実際の扱いは契約内容によって異なるため、個別に確認したい部分です。

そもそも仕様変更を減らす進め方

変更はなくせませんが、減らせる部分はあります。多くの変更は、「実際に動くものを見ないまま決めた」ことが原因で起きるからです。

実物を見ながら決める

文章や図だけで要件を決めると、完成してから「思っていたものと違う」と気づきやすくなります。画面や操作を、早い段階で動く形にして確かめておくと、「これじゃない」を、作り込む前に直せます。プロトタイプ（実際に動く試作品）を先に作る進め方は、この考え方にもとづいています。

要件の抜け漏れを早く見つける

業務の例外や、データの扱いなどは、最初に洗い出すのが難しい部分です。要件定義の進め方は、要件定義とは？新規事業で抜け漏れとズレを防ぐ進め方で詳しく書いています。仕様の伝え方に不安がある場合は、AI開発の仕様の伝え方の手順も使えます。

最初から全部を決めきろうとしない

新規事業では、最初の段階で全部を確定させるのは現実的ではありません。まずは小さな範囲で作って確かめ、その結果を見て次を決める進め方のほうが、変更による手戻りは小さくなります。仕様が固まっていない段階の相談については、仕様が決まってないシステム開発の相談は可能かでも触れています。

仕様変更でよく起きる失敗

最後に、変更の扱いで起こりやすい失敗を整理します。

• 変更を口頭だけで伝える：後から記録が残らず、認識の違いがトラブルになる
• 影響を確かめずに「すぐできるはず」と判断する：納期の遅れや、別の不具合につながる
• すべての要望を取り込もうとする：範囲が膨らみ、完成が遠のく
• 判断者が決まっておらず、議論が続く：決まらないまま時間だけが過ぎる
• 変更の理由が残っていない：後から経緯が分からず、同じ議論を繰り返す
• 事業の方針変更を、通常の変更と同じ扱いにする：作り直しの規模が見えないまま進んでしまう

遅延が起きる仕組みと防ぎ方は、システム開発が遅延する原因と、発注時にできる防ぎ方にもまとめています。変更の管理は、遅延を防ぐ取り組みとも重なります。

また、外注全体の流れや失敗の防ぎ方を知りたい場合は、システム開発の外注ガイドも参考になります。

まとめ

システム開発の途中で出る仕様変更や追加要望は、起きて当たり前のものです。大切なのは、出たときに慌てず判断できる形を、あらかじめ整えておくことです。この記事のポイントを整理します。

• 変更は、不具合・解釈の違い・追加要望・方針の変更の4種類に分けて考える
• 要望は記録し、影響の範囲を確認してから、優先度を決める
• 受ける場合も見送る場合も、合意と理由を記録に残す
• 発注側で、判断する人・窓口・優先度の基準を先に決めておく
• 契約や進め方によって変更の扱いが違うため、依頼前に確認する
• 実物を見ながら決めることで、変更そのものを減らせる

変更を完全になくすことはできません。それでも、変更を「受け止められる仕組み」を持っておけば、新規事業の検証を止めずに進められます。

JustFitは、構想をもとに約1ヶ月で動くプロトタイプを先に作り、実物を見ながら認識を合わせていく受託開発サービスです。「先に作って、後から決める」という進め方で、仕様のずれを早い段階で見つけやすくしています。納品後も、毎月ひとつの機能を追加しながら育てていく伴走型の支援です。仕様がまだ固まっていない段階でも相談できるため、関心があれば JustFitのサービス紹介 をご覧ください。