
この記事の要点
- 仕様の変更は、申し出る・影響を見積もる・合意する・記録する、の順で進めると食い違いが減ります
- 変更の申し出は口頭で済ませず、内容と理由を書いた書面で出すのが基本です
- 費用や納期が変わる場合は、変更の内容に合意するだけでなく、契約の変更として残しておきます
開発の途中で仕様を変えたくなったときは、変えたい内容を書面で申し出て、費用と納期への影響を見積もってもらい、合意したうえで記録に残す、という順で進めます。開発の途中で仕様が変わること自体は珍しくありません。大切なのは、変更をその場の口約束で済ませず、決まった手順で扱うことです。
この記事では、はじめてシステム開発を発注する方に向けて、仕様の変更の進め方を説明します。IPA(情報処理推進機構)の「情報システム・モデル取引・契約書」にある、変更管理の手順を参考にしています。
なぜ手順を決めて扱うのか
仕様の変更を手順を決めて扱うのは、変更が費用と納期に影響するからです。小さく見える変更でも、画面・データ・ほかの機能とのつながりを直す必要があり、テストもやり直しになることがあります。
口頭で「ここを少し変えてほしい」と頼み、開発会社も「分かりました」と答えた場合、後になって「その分の費用は含まれているのか」「納期が延びたのはこの変更のせいか」で食い違いが起きやすくなります。仕様変更の手順を決めておくことは、発注者と開発会社の両方を守ることにつながります。
変更の進め方
仕様の変更は、申し出る、影響を見積もる、協議して合意する、記録して契約に反映する、の4つの段階で進めます。変えたい内容と理由を書面で申し出て、開発会社に費用と納期への影響を書面で示してもらい、両方の責任者が承認して変更を確定し、費用や納期が変わる場合は契約の変更として残す、という流れです。
仕様の変更の4つの段階
- 申し出る変えたい内容と理由を、書面で出す
- 影響を見積もる開発会社に、費用と納期への影響を書面で示してもらう
- 協議して合意する両方の責任者が承認して、変更を確定する
- 記録して契約に反映する費用や納期が変わる場合は、契約の変更として残す
1. 変更を申し出る
変えたい内容と、変えたい理由を書面にまとめて、開発会社に申し出ます。IPAのモデル契約書では、仕様書などの内容を変える必要があると考えた側が、変更の内容と理由などを書いた書面(変更提案書)を相手に渡して、変更を提案する形になっています。発注者だけでなく、開発会社から変更を提案することもあります。
書面には、次の点を書いておくと話が進めやすくなります。
- いまの仕様と、変えたい内容
- 変えたい理由(業務の変化、法令の改正、使ってみて分かったことなど)
- いつまでに変えたいか
2. 影響を見積もってもらう
申し出を受けた開発会社に、変更の影響を見積もってもらいます。IPAのモデル契約書では、変更提案書を受け取った側が、決めた日数のうちに、変更の名称、提案の責任者、日付、変更の理由、変更の詳しい内容、費用がかかる場合はその額、変更の作業のスケジュール、契約の条件(納期・費用など)への影響を書いた書面(変更管理書)を相手に渡す、としています。
影響の見積もりで確かめたいのは、次の点です。
- 追加でかかる費用
- 納期への影響
- ほかの機能やテストへの影響
- 変更しない場合や、変更を次の段階に回す場合との比べ方
3. 協議して合意する
見積もりをもとに、変更するかどうかを話し合って決めます。IPAのモデル契約書では、定期的に開く連絡協議会で変更の可否を協議し、変更してよいとなった場合は、両方の責任者が変更管理書の内容を承認して記名押印し、それで変更が確定する、という流れです。
変更するかどうかは、効果と費用を比べて決めます。予算や納期に余裕がない場合は、今回の開発では変更せず、公開した後の改修に回すという判断もあります。
4. 記録して契約に反映する
費用や納期が変わる変更は、変更の内容に合意するだけでなく、契約の変更として残しておきます。IPAのモデル契約書では、契約の条件に影響する変更は、変更管理書に従って変更契約を結んだときに確定する、としています。
合意した変更は、一覧にまとめて管理すると、後から「いつ、何を、なぜ変えたか」を確かめやすくなります。
話し合いがまとまらないとき
変更の話し合いがまとまらない場合の扱いも、契約書で決めておくと安心です。IPAのモデル契約書は、変更の内容が納期や費用などに影響するために発注者が開発を続けるのをやめようとするときは、発注者が残りの部分の契約を解約でき、その場合は、それまでに行った作業の委託料を払い、解約で開発会社に生じた損害を賠償する、という条項例を示しています。
途中でやめることは、それまでの費用が無駄になるおそれもあるため、最後の手段と考えておくのがよいでしょう。
発注者が気をつけたいこと
発注者の側で次の点に気をつけると、変更の手順がなめらかに進みます。
- 窓口を一本にする:社内のいろいろな人が直接、開発会社の担当者に変更を頼むと、どれが正式な依頼か分からなくなります。変更の申し出は、決めた担当者を通して出します
- 作業の指示の出し方に気をつける:準委任などの契約で、発注者が開発会社の技術者に直接、作業の指示を出すと、偽装請負とみなされるおそれがあります。変更の依頼は、開発会社の責任者を通して出します(偽装請負にならないための、発注者の注意点)
- 小さな変更もまとめて記録する:一つひとつは小さくても、積み重なると費用や納期に影響します
また、発注する会社と開発会社の規模によっては、中小受託取引適正化法(取適法)が当てはまります。この法律は、委託する側が、受託した側に責任がないのに給付の内容を変えさせたり、受け取った後にやり直させたりして、受託した側の利益を不当に害することを禁じています(第5条第2項第3号)。変更にかかる費用は、話し合って適切に負担することが大切です。
出典:製造委託等に係る中小受託事業者に対する代金の支払の遅延等の防止に関する法律(e-Gov 法令検索)
変更が多くなりそうなときは
最初から変更が多くなりそうだと分かっている場合は、進め方や契約の形を見直すことも考えられます。たとえば、作りながら決めるアジャイル開発や、専任のチームで期間を決めて進めるラボ型の開発は、変更を前提にした進め方です。進め方の違いはアジャイル開発とウォーターフォール開発の違いで、契約の形はアジャイル開発の契約の結び方で説明しています。
本記事は、仕様の変更の進め方を一般的に整理したものです。個別の契約書の内容や判断については、弁護士などの専門家にご確認ください。
当社のご支援
当社のWebシステム開発では、作るものと納期を決めて進めるプロジェクトのほか、作りながら決めたい開発をラボ開発(専任チーム)でもお受けしています。変更の多さに合わせて、どちらの進め方が合うかをご一緒に考えます。関わり方をご覧のうえ、お問い合わせからご相談ください。
- 仕様変更
- 変更管理
- 発注
- 契約
この記事に出てくる用語
関連する法令・指針(参考情報)
- 法令
中小受託取引適正化法 第5条(委託事業者の遵守事項)
委託事業者には、中小受託事業者に責任がないのに受領を拒むこと、支払を遅らせること、代金を減らすこと、通常より著しく低い代金を不当に定めること、やり直しをさせることなどが禁じられています。
- 指針
独立行政法人情報処理推進機構(IPA)「情報システム・モデル取引・契約書」(第二版(2020年12月22日))
情報システムの受託開発(一部の企画を含む)と保守運用の取引について、モデル契約と解説をまとめた資料です。民法の改正に直接関係する論点と、それ以外の論点の両方を見直しています。
法令は2026年10月21日時点の内容です。要旨は当社がまとめたもので、条文・判決・指針の全文ではありません。個別の事案への当てはめは、弁護士・社会保険労務士などの専門家にご確認ください。表記の決まりは法令・指針の参考情報と凡例をご覧ください。
このコラムは一般的な情報の提供を目的としたもので、個別の状況への助言ではありません。製品・サービスの名前と内容は、記事の更新日の時点のものです。