開発中の「追加要望」とどう付き合うか ― プロジェクトを破綻させないために

開発が進み、実際の画面や機能が動き始めると、

「この項目も追加したい」
「操作方法を変えたい」
「この情報も一覧で確認したい」

といった要望が見えてきます。

それ自体は悪いことではありません。

実際の画面を確認したからこそ、当初は気づかなかった業務上の課題や、本当に必要な機能が明確になったということです。私たちも、開発中にお客様からご意見をいただくことを歓迎しています。

ただし、開発中に出てきた要望を、すべて同じ「追加要望」として扱うことはできません。

合意済みの仕様を実現するための修正なのか。

当初の合意内容を変更する要望なのか。

新しい機能を追加する要望なのか。

さらに、請負契約なのか、準委任契約なのかによっても、対応の考え方は異なります。

本記事では、開発中に生じた要望をどのように整理し、品質・納期・費用を守りながらプロジェクトを進めるかをご紹介します。

まず、「修正」と「追加・変更」を分ける

開発中に出てきた要望について、最初に確認すべきなのは、当初の合意内容に含まれているかどうかです。

例えば、仕様書や画面設計で合意した機能が正しく動いていない場合は、合意済みの内容を実現するための修正です。

一方で、合意後に、

「入力項目を増やしたい」
「承認の段階を追加したい」
「別のシステムとも連携したい」

といった要望が出た場合は、仕様変更や機能追加に当たる可能性があります。

この二つを混同してはいけません。

開発会社の想定より作業量が多かったという理由だけで、本来の合意範囲に含まれる対応を「追加要望」とすることは適切ではありません。

反対に、当初の合意内容を超える変更まで、すべて当初の費用や期間の中で対応できるとは限りません。

要望が出た際には、契約書、仕様書、提案書、議事録、プロトタイプの確認結果などをもとに、まず双方の合意範囲を確認する必要があります。

請負契約の場合

請負契約は、一方が仕事を完成することを約し、相手方がその仕事の結果に対して報酬を支払う契約です。

システム開発における請負契約では、契約書や仕様書などで合意した成果物を完成させることが基本となります。

そのため、合意済みの仕様を満たしていない場合の修正と、合意後に成果物の内容を変更する要望は、分けて扱う必要があります。

例えば、当初から必要と合意していた機能が正しく動かない場合は、原則として新しい機能追加とは異なります。

一方、開発開始後に業務内容が変わり、当初は予定していなかった機能が必要になった場合には、契約範囲の変更として扱うことになります。

変更が必要な場合は、

• どの機能をどのように変更するのか
• 費用はいくら増減するのか
• 納期にどの程度影響するのか
• ほかの機能やテストへの影響はあるか

を整理し、双方で合意してから対応することが重要です。

要望を口頭で受け、そのまま曖昧に開発を進めると、後になって「当初の契約に含まれていた」「含まれていなかった」という認識の相違が起こりやすくなります。

準委任契約の場合

準委任契約では、法律行為ではない事務の処理を相手方へ委託し、受託者は契約の趣旨に従って業務を遂行します。

システム開発では、一定の期間や工数、体制を定め、その中で優先順位を調整しながら業務を進める形が採用されることがあります。

特にアジャイル開発では、開発途中で機能の追加・変更や優先順位の変更が発生することを前提として、準委任契約を採用するモデルがIPAからも示されています。

ただし、準委任契約であれば、要望を無制限に追加できるわけではありません。

契約期間や予定工数、対応できるチームの人数には限りがあります。

新しい要望へ対応する場合には、

「現在予定している作業と入れ替えるのか」

「優先順位を下げて後の期間へ回すのか」

「期間や工数を追加するのか」

を決める必要があります。

例えば、月100時間の支援契約の中で、新たに20時間程度の作業が必要になった場合、何も調整せずに合計120時間を対応できるわけではありません。

既存の作業を20時間分後ろへ回すのか、追加の工数を契約するのかを、双方で協議します。

なお、実際の扱いは、個別の契約書や業務内容によって異なります。

変更が積み重なると、プロジェクトは破綻しうる

新しい要望や仕様変更が一つ発生しただけで、直ちにプロジェクトが破綻するわけではありません。

問題になるのは、影響を確認しないまま、変更が積み重なっていく状態です。

例えば、

• 一度実装した機能を根本から作り直す
• 小さな変更が多数追加される
• 確認のたびに前提条件が変わる
• 変更に伴うテスト範囲が広がる
• ほかの機能との整合性を取り直す

といった状態が続けば、当初の計画どおりに開発を進めることが難しくなります。

画面上では小さな変更に見えても、データベース、権限、ほかの画面、帳票、外部連携などへ影響することがあります。

その影響を確認せず、納期も費用も変えないまま対応を重ねれば、実装やテストに無理が生じます。

短期間で変更を押し込めば、不具合の見落としや品質低下のリスクも高まります。

ただし、これは合意済みの仕様を実現するための修正を拒む、という意味ではありません。

新たな仕様変更や追加機能を受け入れる場合には、その影響を確認し、計画もあわせて見直す必要があるということです。

その負担は、お客様にも返ってくる

変更が増えた際に必要となるのは、開発作業だけではありません。

実装した内容が要望どおりになっているかを確認するのは、お客様です。

変更が増えれば、その分だけ確認する画面やテストケースも増えます。

確認が積み残されると、後続の開発やテストを進められず、スケジュールへ影響することがあります。

また、確認中にさらに新しい要望が発生すると、どの状態を完成とするのかが曖昧になり、確認がいつまでも終わらなくなる場合があります。

その結果、当初予定していた期間を超えて開発体制を維持する必要が生じれば、契約内容や双方の協議結果に応じて、納期や費用を見直すこともあります。

開発会社は変更対応に追われ、お客様は確認作業に追われる。

この状態では、双方の負担が増え、本来の目的である「業務を良くすること」から遠ざかってしまいます。

「今やる」「リリース後に回す」を一緒に決める

必要なのは、要望を我慢することではありません。

要望を整理し、優先順位を決めることです。

新しい要望が出た際には、次の観点で判断します。

その要望は、当初の合意内容に含まれているか

まず、合意済みの仕様を実現するための修正なのか、新しい変更・追加なのかを確認します。

判断が難しい場合には、契約書や仕様書だけでなく、打ち合わせ記録やプロトタイプの確認内容も含めて双方で整理します。

リリースに必須か

その変更がなければ業務そのものを開始できないのか、それとも操作性を向上させるための改善なのかを確認します。

リリースに必須でない変更であれば、一度運用してから必要性を判断する方法もあります。

実際の運用後に判断できないか

開発中には必要に見えた機能でも、実際に運用すると、ほとんど使われないことがあります。

反対に、当初は重要ではないと思っていた機能が、頻繁に使われることもあります。

判断を急ぐ必要がない要望は、リリース後の利用状況を見てから対応したほうが、無駄な開発を避けられます。

費用・納期・品質への影響は何か

追加や変更によって、開発工数だけでなく、設計、テスト、データ移行、マニュアルなどへ影響することがあります。

影響を明らかにしたうえで、本当に今対応するべきかを判断します。

何と入れ替えるか

予算や期間を変えない場合、新しい機能を追加する代わりに、別の機能を後へ回す必要があります。

「追加するか、追加しないか」だけではなく、「何を優先し、何を後へ回すか」を決めることが重要です。

変更内容は、影響の大きさに応じて記録する

変更対応で避けたいのは、要望の内容や対応方針が曖昧なまま、実装だけが進んでしまうことです。

一方で、小さな要望まですべて個別の変更申請書や契約書に記載すると、管理そのものが煩雑になり、プロジェクトの進行を妨げる場合があります。

想定している工数や契約範囲の中で対応でき、費用や納期、ほかの機能への影響が小さい要望については、打ち合わせの議事録や課題管理表、チケットなどに内容と対応方針を残したうえで対応します。

例えば、表示文言の調整や軽微なレイアウト変更など、既存の設計を大きく変えずに対応できる内容であれば、通常のプロジェクト管理の中で記録し、双方の認識を合わせながら進めます。

一方、次のような要望は、影響を整理したうえで、あらためて双方の合意が必要です。

• 当初の合意範囲を超える機能追加
• 一度実装した機能を根本から変更するもの
• 費用や工数の追加が必要になるもの
• 納期やリリース範囲へ影響するもの
• データベースや権限、外部連携など広い範囲へ影響するもの

この場合は、変更内容、対応範囲、費用、納期への影響を整理し、必要に応じて見積書、変更契約書、注文書などで合意してから対応します。

重要なのは、すべての要望を同じ重さで管理することではありません。

軽微な変更は議事録や課題管理の中で機動的に対応し、プロジェクトの前提を変える変更は正式な手続きを行うなど、影響の大きさに応じて管理方法を分けることです。

最初から100%を目指さない

開発中に多くの要望が出る背景には、

「初回のリリースで、できる限り完璧なものにしたい」

という考えがあります。

しかし、実際に使用する前に、必要な機能をすべて正確に判断することは困難です。

そこで私たちがおすすめしているのが、業務を開始するために必要な機能へ絞ってリリースし、実際の運用を確認しながら改善する方法です。

初回で100%のシステムは作れない ― MVPから始めるという選択 でもご紹介しているとおり、まずは業務が回る状態を作り、運用の中で得られた根拠をもとに機能を追加していくほうが、結果として費用・納期・品質を守りやすくなります。

すべての要望を初回リリースへ入れることが、必ずしもお客様にとって最善とは限りません。

Reservoir Wayによる進め方

レザボア・コンサルティングでは、Reservoir Way により、本物に近いプロトタイプを機能単位で確認していただきながら開発を進めます。

文章だけで仕様を確認するのではなく、実際の画面や操作を早い段階で見ていただくことで、

「想定していた業務と合っているか」

「不足している機能はないか」

「実際には使わない機能が含まれていないか」

を確認できます。

要望が出た場合には、まず、

「当初の合意内容に含まれるもの」

「新たな仕様変更・機能追加に当たるもの」

に整理します。

そのうえで、

「現在のリリースで対応するもの」

「リリース後の改善へ回すもの」

に優先順位をつけます。

必要に応じて、対応範囲、工数、費用、スケジュールへの影響も明確にし、双方で合意しながらプロジェクトを進めます。

Reservoir Way は、開発中の変更をなくすための方法ではありません。

変更が発生することを前提として、その影響を早く発見し、無理のない形で整理するための進め方です。

おわりに

開発中に要望が増えることは、必ずしも悪いことではありません。

実際のシステムを確認することで、お客様自身も業務への理解を深め、本当に必要なものが明確になっていきます。

一方で、要望の扱いは、契約形態や当初の合意範囲によって異なります。

合意済みの仕様を実現するための修正なのか。

新しい仕様変更や機能追加なのか。

今の予算と期間の中で対応するのか。

別の機能と入れ替えるのか。

追加の費用や期間を確保するのか。

こうした点を一つずつ整理し、双方が納得したうえで進めることが、プロジェクトを健全に保つために重要です。

レザボア・コンサルティングでは、契約形態やプロジェクトの状況を踏まえ、要望の整理と優先順位づけからご支援しています。

開発中の要望をどのように扱えばよいかお悩みの場合も、お気軽にご相談ください。