開発中に出てくる「追加要望」は、どう扱えばいいのか
開発が進んで実際の画面や機能が動き始めると、「この項目も追加したい」「操作方法を変えたい」「この情報も一覧で確認したい」といった要望が出てきます。
それ自体は悪いことではありません。実際の画面を見たからこそ、当初は気づかなかった業務上の課題や、本当に必要な機能がはっきりしてきたということです。私たちも、開発中にお客様からご意見をいただくことを歓迎しています。
ただ、開発中に出てきた要望を、すべて同じ「追加要望」として扱うことはできません。合意済みの仕様を実現するための修正なのか、当初の合意内容を変更する要望なのか、新しい機能を追加する要望なのか。さらに、請負契約か準委任契約かによっても、対応の考え方は変わります。
この記事では、開発中に出てきた要望をどう整理し、品質・納期・費用を守りながらプロジェクトを進めるかをご紹介します。
まず、「修正」と「追加・変更」を分ける
開発中に要望が出たとき、最初に確認したいのは、それが当初の合意内容に含まれているかどうかです。
たとえば、仕様書や画面設計で合意した機能が正しく動いていないなら、合意済みの内容を実現するための修正です。一方、合意後に「入力項目を増やしたい」「承認の段階を追加したい」「別のシステムとも連携したい」といった要望が出た場合は、仕様変更や機能追加に当たる可能性があります。
この二つは混同しないようにしなければなりません。開発会社の想定より作業量が多かったという理由だけで、本来の合意範囲に含まれる対応を「追加要望」とするのは適切ではありません。反対に、当初の合意内容を超える変更まで、すべて当初の費用や期間の中で対応できるとは限りません。
要望が出たら、契約書、仕様書、提案書、議事録、プロトタイプの確認結果などをもとに、まず双方の合意範囲を確認する必要があります。
請負契約の場合
請負契約は、一方が仕事を完成することを約し、相手方がその仕事の結果に対して報酬を支払う契約です。システム開発の請負契約では、契約書や仕様書などで合意した成果物を完成させることが基本になります。
そのため、合意済みの仕様を満たしていない場合の修正と、合意後に成果物の内容を変更する要望は、分けて扱う必要があります。当初から必要と合意していた機能が正しく動かないのであれば、原則として新しい機能追加とは異なります。一方、開発開始後に業務内容が変わり、当初は予定していなかった機能が必要になった場合は、契約範囲の変更として扱うことになります。
変更が必要なときは、次の点を整理し、双方で合意してから対応します。
- どの機能をどのように変更するのか
- 費用はいくら増減するのか
- 納期にどの程度影響するのか
- ほかの機能やテストへの影響はあるか
要望を口頭で受けて、曖昧なまま開発を進めてしまうと、後になって「当初の契約に含まれていた」「含まれていなかった」という認識の食い違いが起こりやすくなります。
準委任契約の場合
準委任契約では、法律行為ではない事務の処理を相手方へ委託し、受託者は契約の趣旨に従って業務を遂行します。システム開発では、一定の期間や工数、体制を定め、その中で優先順位を調整しながら業務を進める形がとられることがあります。
特にアジャイル開発については、開発途中で機能の追加・変更や優先順位の変更が起きることを前提に、準委任契約を採用するモデルがIPAからも示されています。
ただし、準委任契約だからといって、要望を無制限に追加できるわけではありません。契約期間や予定工数、対応できるチームの人数には限りがあります。新しい要望に対応するなら、現在予定している作業と入れ替えるのか、優先順位を下げて後の期間へ回すのか、期間や工数を追加するのかを決める必要があります。
たとえば、月100時間の支援契約で、新たに20時間ほどの作業が必要になったとします。何も調整しないまま、合計120時間分を対応できるわけではありません。既存の作業を20時間分後ろへ回すのか、追加の工数を契約するのかを、双方で協議します。
なお、実際の扱いは個別の契約書や業務内容によって異なります。
変更が積み重なると、プロジェクトは破綻しうる
新しい要望や仕様変更が一つ出ただけで、すぐにプロジェクトが破綻するわけではありません。問題になるのは、影響を確認しないまま変更が積み重なっていく状態です。
- 一度実装した機能を根本から作り直す
- 小さな変更が多数追加される
- 確認のたびに前提条件が変わる
- 変更に伴うテスト範囲が広がる
- ほかの機能との整合性を取り直す
こうした状態が続けば、当初の計画どおりに開発を進めるのは難しくなります。
画面上では小さな変更に見えても、データベース、権限、ほかの画面、帳票、外部連携などに影響することがあります。その影響を確認せず、納期も費用も変えないまま対応を重ねれば、実装やテストに無理が出ます。短期間で変更を押し込めば、不具合の見落としや品質低下のリスクも高まります。
とはいえ、合意済みの仕様を実現するための修正を断るという話ではありません。新たな仕様変更や追加機能を受け入れるなら、その影響を確認し、計画もあわせて見直す必要があるということです。
その負担は、お客様にも返ってくる
変更が増えたときに必要になるのは、開発作業だけではありません。実装した内容が要望どおりになっているかを確認するのは、お客様です。変更が増えれば、そのぶん確認する画面やテストケースも増えます。
確認が積み残されると、後続の開発やテストを進められず、スケジュールに影響することがあります。確認している間にさらに新しい要望が出ると、どの状態を完成とするのかが曖昧になり、確認がいつまでも終わらなくなる場合もあります。その結果、当初の予定を超えて開発体制を維持する必要が出てくれば、契約内容や双方の協議結果に応じて、納期や費用を見直すこともあります。
開発会社は変更対応に追われ、お客様は確認作業に追われる。こうなると双方の負担が増え、本来の目的である「業務を良くすること」から遠ざかってしまいます。
「今やる」「リリース後に回す」を一緒に決める
要望を我慢していただく必要はありません。必要なのは、要望を整理して優先順位を決めることです。新しい要望が出たときは、次の観点で判断します。
その要望は、当初の合意内容に含まれているか
まず、合意済みの仕様を実現するための修正なのか、新しい変更・追加なのかを確認します。判断が難しいときは、契約書や仕様書だけでなく、打ち合わせ記録やプロトタイプの確認内容も含めて双方で整理します。
リリースに必須か
その変更がなければ業務そのものを始められないのか、それとも操作性を良くするための改善なのかを確認します。リリースに必須でない変更なら、一度運用してから必要性を判断する方法もあります。
実際の運用後に判断できないか
開発中は必要に見えた機能が、実際に運用してみるとほとんど使われないことがあります。逆に、当初は重要ではないと思っていた機能が、頻繁に使われることもあります。判断を急がなくてよい要望は、リリース後の利用状況を見てから対応したほうが、無駄な開発を避けられます。
費用・納期・品質への影響は何か
追加や変更の影響は開発工数にとどまらず、設計、テスト、データ移行、マニュアルなどに及ぶことがあります。影響を明らかにしたうえで、本当に今対応すべきかを判断します。
何と入れ替えるか
予算や期間を変えないなら、新しい機能を追加する代わりに、別の機能を後へ回す必要があります。決めるのは「追加するかどうか」だけではありません。「何を優先し、何を後へ回すか」まで決めておきます。
変更内容は、影響の大きさに応じて記録する
変更対応で避けたいのは、要望の内容や対応方針が曖昧なまま、実装だけが進んでしまうことです。かといって、小さな要望まですべて個別の変更申請書や契約書に記載すると、管理そのものが煩雑になり、プロジェクトの進行を妨げる場合があります。
想定している工数や契約範囲の中で対応でき、費用や納期、ほかの機能への影響も小さい要望は、打ち合わせの議事録や課題管理表、チケットなどに内容と対応方針を残してから対応します。表示文言の調整や軽微なレイアウト変更のように、既存の設計を大きく変えずに済むものなら、通常のプロジェクト管理の中で記録し、双方の認識を合わせながら進めます。
一方、次のような要望は、影響を整理したうえで、あらためて双方の合意が必要です。
- 当初の合意範囲を超える機能追加
- 一度実装した機能を根本から変更するもの
- 費用や工数の追加が必要になるもの
- 納期やリリース範囲へ影響するもの
- データベースや権限、外部連携など広い範囲へ影響するもの
この場合は、変更内容、対応範囲、費用、納期への影響を整理し、必要に応じて見積書、変更契約書、注文書などで合意してから対応します。
すべての要望を同じ重さで管理する必要はありません。軽微な変更は議事録や課題管理の中で機動的に対応し、プロジェクトの前提を変える変更は正式な手続きを踏む。このように、影響の大きさに応じて管理のしかたを分けています。
最初から100%を目指さない
開発中に多くの要望が出る背景には、「初回のリリースで、できる限り完璧なものにしたい」という考えがあります。しかし、実際に使う前に、必要な機能をすべて正確に見極めるのは困難です。
そこで私たちがおすすめしているのが、業務を始めるのに必要な機能に絞ってリリースし、実際の運用を見ながら改善していく方法です。MVPから始める進め方についてのコラムでもご紹介しているとおり、まず業務が回る状態を作り、運用の中で得られた根拠をもとに機能を足していくほうが、結果として費用・納期・品質を守りやすくなります。
すべての要望を初回リリースに入れることが、必ずしもお客様にとって最善とは限りません。
Reservoir Wayによる進め方
レザボア・コンサルティングでは、Reservoir Wayという進め方で、本物に近いプロトタイプを機能単位で確認していただきながら開発を進めます。
仕様は文章だけで確認するのではなく、実際の画面や操作で早い段階から見ていただきます。そうすると、想定していた業務と合っているか、不足している機能はないか、実際には使わない機能が含まれていないかを確かめられます。
要望が出たときは、まず「当初の合意内容に含まれるもの」と「新たな仕様変更・機能追加に当たるもの」に分けます。そのうえで、「現在のリリースで対応するもの」と「リリース後の改善へ回すもの」に優先順位をつけます。必要に応じて、対応範囲、工数、費用、スケジュールへの影響も明らかにし、双方で合意しながらプロジェクトを進めます。
Reservoir Wayを使えば開発中の変更がなくなる、というわけではありません。変更が起きることを前提に、その影響を早く見つけ、無理のない形で整理するための進め方です。
おわりに
開発中に要望が増えるのは、必ずしも悪いことではありません。実際のシステムに触れることで、お客様ご自身も業務への理解が深まり、本当に必要なものがはっきりしていきます。
一方で、要望の扱いは契約形態や当初の合意範囲によって変わります。合意済みの仕様を実現するための修正なのか、新しい仕様変更や機能追加なのか。今の予算と期間の中で対応するのか、別の機能と入れ替えるのか、追加の費用や期間を確保するのか。こうした点を一つずつ整理し、双方が納得したうえで進めることが、プロジェクトを健全に保つことにつながります。
レザボア・コンサルティングでは、契約形態やプロジェクトの状況を踏まえ、要望の整理と優先順位づけからご支援しています。開発中の要望をどう扱えばよいか迷われている場合も、お気軽にご相談ください。