仕様が固まったあとに、思いがけない追加要望が届くことがあります。断れば関係がぎこちなくなりそうで、そのまま受け入れれば納期や工程への影響が読めなくなります。開発の現場ではよく起きる場面ですが、断るか受けるかの二択で判断する必要はありません。手続きに乗せるという選び方が、契約のひな型にはあらかじめ用意されています。

1. 追加要望を「断る／受ける」の二択にしない

断ればぎこちなくなり、受ければ工程が狂う

仕上がったはずの仕様に、あとから要望が重なる場面は珍しくありません。断れば関係が硬くなりそうに感じられ、そのまま受け入れれば、完成の形がどこにあるのか見えにくくなります。

要望を断れば、次の依頼が来にくくなるのではないかという不安がつきまといます。一方で、求められるままに受け入れてしまうと、当初の計画には無かった作業が積み重なり、進捗の見通しが崩れていきます。どちらの心配も、実務ではよく耳にするものです。

断るか受けるかを選ぶよりも、要望をいったん手続きの上に乗せるほうが、双方にとって扱いやすくなります。IPAが公開している契約のひな型は、取引き構造を透明化する目的で提供されており¹、要望の扱い方もその構造のなかに組み込まれています。取引き構造が見えるようになれば、要望をどの段階でどう扱うかも、その都度の感覚ではなく、あらかじめ決まった手順として扱えるようになります。

決まっていない事項をそのまま塩漬けにせず、未確定のまま扱うための枠も、同じひな型のなかに用意されています。

選択肢を知っておくだけでも、返答の余裕が変わる

手続きに乗せるという道があると知っているだけでも、要望を受けた瞬間の反応は変わってきます。即答で断る必要も、即答で受け入れる必要もなく、いったん確認の手順に乗せることを案内できるからです。

この余裕は、経験を積んだかどうかとは関係がありません。契約のひな型にどのような枠が用意されているかを、参画前に知っておくだけで得られるものです。

ここから先は、その枠と手続きが具体的にどこにあるのか、そしてリモートの案件でどう使えるのかを順に見ていきます。

図の作成：Remogu編集部。要望への向き合い方を整理したもので、統計データではありません

3つの向き合い方で、あとに残るものが変わる

同じ要望でも、向き合い方によってあとに残るものが変わります。断れば要望への回答は早く終わりますが、なぜ断ったのかという経緯は残りません。そのまま受け入れれば要望自体は前に進みますが、工程への影響が見えにくくなります。手続きに乗せれば、影響の確認に時間はかかるものの、申し出から合意までの経緯が記録として残ります。どちらを選ぶかではなく、どの経路を通すかという整理で見ると、あとの扱いやすさの違いがはっきりします。

向き合い方	その場で起きること	あとに残るもの
断る	要望への回答が早く終わる	断った経緯は残らない
そのまま受ける	要望が前に進むが影響が見えにくい	変更の経緯が記録されない
手続きに乗せる	影響の確認にいくらか時間がかかる	申し出から合意までの記録が残る

3つの向き合い方を並べてみると、手続きに乗せる進め方だけが、あとになって参照できる形を残すことが分かります。要望が届いた直後にどの経路を通すかを意識するだけで、その先の展開が変わってきます。

2. 決まっていないことは、決まっていないまま扱う枠がある

未確定事項を、無理に確定させない

仕様の一部がまだ固まっていない状態のまま開発に入ることは、珍しくありません。すべてを最初に確定させようとすると、検討そのものが長引き、着手が遅れてしまいます。

ひな型には「未確定事項の取扱い」を定めた条文（第36条）が置かれており²、決まっていない事項を決まっていないまま扱う枠が、最初から用意されています。未確定な事項を無理に確定させるよりも、未確定のまま扱う枠に乗せるほうが、後工程への影響を小さく保てます。

この枠がどのように働くかは、次に見る変更管理手続とセットで理解すると、つながりが見えやすくなります。

図の作成：Remogu編集部。契約のひな型にある枠の位置を整理したもので、統計データではありません

枠があることで、着手を止めずに進められる

未確定事項の枠が契約書にあることで、着手の時点ですべてを固めなくても、開発を前に進められます。決まっていない部分をどう扱うかがあらかじめ共有されていれば、進めながら詰めていくという前提そのものが、双方の間で成立します。分からないことを分からないまま置いておける枠があるという安心感は、進行中の細かな判断の負担を減らします。

枠が無ければ、決まっていない部分に気づくたびに、その都度話し合いの場を設ける必要が出てきます。枠があらかじめ用意されていれば、未確定であること自体は問題にならず、どの時点までに詰めるかだけを合わせればよくなります。決めることと決めないことを最初から仕分けておく発想は、参画したあとの動き方にも影響します。

3. 変更を手続きに乗せると何が変わるのか

申し出から反映までの記録が残る

要望を口頭のやり取りだけで進めると、いつ、どの内容で、誰が合意したのかを、あとから確かめにくくなります。

ひな型の改定では、変更管理手続の詳細化（第37条）が行われました³。手続きに乗せると、要望の申し出・影響の確認・双方の合意という一連の流れが、記録として残ります。記録の無いまま進めるよりも、手続きの上に乗せて進めるほうが、あとで「言った・言わない」に戻る場面を減らせます。

変更を手続きに乗せることは、要望を断ることとは違います。要望を扱う経路を、その都度の判断から、決まった経路に移すことです。

手続きは、要望を止めるためのものではない

変更管理の手続きは、要望を通しにくくするための仕組みではありません。むしろ、要望をどう扱うかを毎回ゼロから考える手間をなくし、決まった経路に乗せるだけで先に進められるようにする仕組みです。手続きに乗せた要望は記録という形で積み重なっていくため、似た要望が次に届いたときの判断材料にもなります。記録が積み重なるほど、次に似た場面が来たときの対応も落ち着いたものになっていきます。

図の作成：Remogu編集部。変更管理手続きの流れを整理したもので、統計データではありません

4. 仕様凍結の合意と変更の回数は、判断の要素として扱われている

凍結後の大量要望が、頓挫の責任を分けた例

仕様凍結の合意ができていたにもかかわらず、大量の追加開発要望が出され、その対応を強いられたことで開発が遅延した事案が紹介されています。この事案では、頓挫の責任がユーザ側のみに認定されたと紹介されています（札幌高判平成29年8月31日）⁴。合意そのものに意味があったことが、この事案からうかがえます。

外部設計後の変更の重なりも、考慮された例

外部設計を終えたあとに多数の変更を重ねれば、不具合や障害が起きる可能性が増すとして、変更を重ねた側の事情も考慮された裁判例が紹介されています（東京高判平成26年1月15日）⁵。仕様凍結の合意も、変更の回数も、判断の要素として扱われた例があるということです。個別の事案の結論をそのまま自分の案件に当てはめることはできませんが、合意を記録に残すことと、変更の回数を管理することの両方に意味があると分かります。

ユーザ側に求められる協力には、積極的に行うことだけでなく、開発作業を阻害する行為をしないことも含まれると示されています⁶。これは一方だけに課される重荷ではなく、双方が同じ手続きに乗ることで初めて働く仕組みです。手続きに乗せることを持ちかけるのは、要望を出した側を非難する行為ではなく、双方が同じ土台に立つための呼びかけだと考えると、伝え方も変わってきます。

2件の裁判例が示す判断の要素

2件の裁判例は、それぞれ別の場面を扱っていますが、扱われた要素には共通する部分があります。次の表で、事案の概要と、示された判断の要素を並べて確認できます。

裁判例	事案の概要	示された判断の要素
札幌高判平成29年8月31日	仕様凍結の合意があったにもかかわらず大量の追加開発要望が出された事案	頓挫の責任の認定に合意の有無が関わったと紹介されています
東京高判平成26年1月15日	外部設計後に多数の変更を重ねた事案	変更を重ねた側の事情も考慮されたと紹介されています

図の作成：Remogu編集部。紹介されている2件の裁判例の要素を整理したもので、統計データではありません

2件の事案が示しているのは、合意した内容や変更の回数を記録に残しておくことが、あとになって状況を振り返るための土台になるという点です。個々の結論を自分の案件にそのまま当てはめることはできませんが、記録を残す姿勢そのものは、どの案件にも共通して役立ちます。判断が分かれる場面ほど、何を合意し、何が未確定だったのかという経緯が意味を持ちます。

5. リモート・フリーランス案件でどう関わるか

参画前に、未確定事項の扱いを確かめる

参画前の段階で、契約書に未確定事項の取扱いや変更管理の手続きが書かれているかを確かめておくと、要望が届いたときに戻る場所が分かります。契約を結んだあとに探すよりも、参画前に確かめておくほうが、いざというときの動き方に迷いが出ません。

契約書を細部まで読み込む時間が取れない場合でも、未確定事項の取扱いと変更管理の条文がどこにあるかだけを先に確認しておくと、あとで慌てずに済みます。参画が決まってから読み返すよりも、参画前の段階で位置を把握しておくほうが、実務に入ったあとの動きが速くなります。

多段階契約と多段階の見積りで、変わる前提を組み込む

多段階契約を用いると、検討が進むにつれて徐々に明確になる仕様や、開発の途中で生じる変更の影響を極力抑えることができると示されています⁷。ただし、段階を分けるほど契約に関わる作業の手間は増えます。手間が増える点まで含めて理解しておくと、段階を分ける意味が見えやすくなります。

見積りについても、多段階の見積りを用いれば双方のリスクを低減できると示されています⁸。一度で確定させるよりも、段階を踏んで見直すほうが、変わる前提を最初から組み込んだ進め方になります。

リモートで進める案件では、やり取りが文字で残りやすいという利点があります。要望の申し出も、口頭ではなくテキストで残しておくと、手続きに乗せる際の土台になります。顔を合わせる機会が少ない分、記録に残すことへの抵抗も小さく、手続きに乗せる進め方はリモートの案件のほうがむしろ馴染みやすい面があります。

参画前・参画中に確かめておきたいこと

参画前と参画中とで、確かめておきたいことは変わります。次の表に、タイミングごとの確認ポイントを整理しました。

タイミング	確認すること
参画前	契約書に未確定事項の取扱いや変更管理の手続きが書かれているか
参画前	見積りが多段階になっているか
参画中	要望が来た際に、口頭ではなく記録に残せる経路があるか
参画中	仕様凍結を合意した時点が記録に残っているか

確認する項目そのものは限られていますが、参画前に確かめるか、参画中にその都度確かめるかで、手間のかかり方が変わります。表の順番のとおり、参画前の確認から先に済ませておくと、参画中の確認は状況が動いたときだけで済むようになります。

Remoguが取り扱う案件は、90%以上がフルリモートで進められます⁹。場所にかかわらず、こうした確認ポイントを押さえながら参画先を選べる環境で、手続きに乗せる進め方を実践していけます。積み上げてきた経験を活かせる案件かどうかも、確認ポイントに合わせて見ていくと選びやすくなります。

登録してから、条件を1つずつ確かめていく

参画前の確認事項は、案件が具体的に決まってからでないと分からないものも含まれます。まず登録して、気になる案件の条件を実際に見比べながら、表に挙げた確認ポイントを1つずつ当てはめていく進め方もあります。

6. まとめ

仕様が固まったあとの追加要望は、断るか受けるかの二択で判断する必要はありません。ひな型には、決まっていない事項を未確定のまま扱う枠（第36条）²と、変更を手続きに乗せる仕組み（第37条）³が、それぞれ用意されています。

仕様は最初からすべて決まっているとは限りません。決まっていない部分を無理に埋めようとするよりも、扱うための枠と手続きを使うことが、揉めない進め方につながります。断る側にも受ける側にも回らず、手続きという第三の道を選べることが、この記事全体を通して見えてきた答えです。

仕様凍結の合意も、変更の回数も、判断の要素として扱われた例があります⁴。外部設計後の変更の重なりが考慮された例もあります⁵。合意を記録に残すことと、変更の回数を管理することの両方に、意味があると分かります。

多段階契約を用いれば、変わる前提を最初から組み込むことができます⁷。見積りも段階を踏むことで、双方のリスクを抑えられます⁸。断る・受けるの二択で悩む前に、こうした枠や手続き、契約の組み方があることを知っておくだけでも、追加要望への向き合い方は変わってきます。参画を検討する際は、契約書に未確定事項の扱いや変更管理の手続きが書かれているかを確かめる視点を持っておくと、案件を選ぶ判断がしやすくなります。

Remoguの案件は90%以上がフルリモートで進められます⁹。まず登録して、自分の経験に合う条件を確かめてみることから始められます。

7. よくある質問

追加要望は断ってもよいのでしょうか

断ることも選べますが、断るか受けるかの二択で判断する前に、手続きに乗せるという道を確かめる余地があります。ひな型には未確定事項や変更を扱う条文が用意されているため²、要望が届いた時点で、その枠に乗せられるかを確認する進め方があります。断ることを目的にするのではなく、要望をどの経路に乗せるかを先に決めておくと、返答そのものが落ち着いたものになります。

口頭で伝えられた依頼は、どう扱えばよいのでしょうか

口頭のやり取りは、あとから内容を確かめにくくなります。手続きに乗せる考え方では、要望の申し出を記録に残す段階を経て、変更管理に進みます³。口頭で受けた依頼も、いったん記録に落としてから扱うと、あとの確認がしやすくなります。チャットやメールに要点を書き留めるだけでも、記録として扱える形になります。打ち合わせの場で口頭で伝えられた場合も、その場の会話を終えたあとに要点をまとめて送っておくと、記録としての役割を果たします。

仕様が未確定のまま進めてもよいのでしょうか

未確定の事項をそのまま塩漬けにする必要はありません。ひな型には、決まっていない事項を未確定のまま扱う枠（第36条）が用意されています²。無理に確定させるよりも、この枠に乗せて進めるほうが、工程への影響を抑えやすくなります。決まっていないことを認めた上で進める、という順番そのものに意味があります。

仕様凍結の合意は、どう残しておけばよいのでしょうか

合意そのものを記録に残しておくことが、あとの判断の要素になります。仕様凍結の合意があったにもかかわらず大量の要望が出された事案では、頓挫の責任の認定に合意の有無が関わったと紹介されています⁴。合意した時点と内容を記録に残しておくと、あとから振り返る材料になります。日付と合意した範囲をメールやチャットの形で残しておくだけでも、十分な記録になります。

リモートで進める案件でも、同じ考え方は当てはまるのでしょうか

当てはまります。手続きに乗せるという考え方そのものは、対面かリモートかで変わるものではありません。リモートで進める案件は、やり取りが文字で残りやすいという利点があり、記録に残すという点では相性がよいといえます。Remoguが扱う案件も90%以上がフルリモートで進められるため⁹、場所にかかわらず条件を確かめながら参画先を選べます。まずは登録して、自分の経験に合う案件の条件を確かめてみましょう。

※公開中の案件数は時期によって変わります。記事中の案件の傾向は執筆時点のものです。

出典・参考情報

＊1 情報処理推進機構「システム開発の健全化に向けて」情報システム・モデル取引・契約書から読み解く（講演資料）（2025年4月24日）
＊2 情報処理推進機構「システム開発の健全化に向けて」契約書ひな型の目次 第4章 契約内容等の変更（2025年4月24日）
＊3 情報処理推進機構「システム開発の健全化に向けて」個別契約書に関する改定点（2025年4月24日）
＊4 情報処理推進機構「システム開発の健全化に向けて」札幌高判平成29年8月31日（プロジェクトマネジメント：ユーザの義務）（2025年4月24日）
＊5 情報処理推進機構「システム開発の健全化に向けて」東京高判平成26年1月15日（プロジェクトマネジメント：ユーザの義務）（2025年4月24日）
＊6 情報処理推進機構「システム開発の健全化に向けて」プロジェクトマネジメント：ユーザの義務（2025年4月24日）
＊7 情報処理推進機構「システム開発の健全化に向けて」多段階契約（2025年4月24日）
＊8 情報処理推進機構「システム開発の健全化に向けて」多段階契約（見積り時期とリスク）（2025年4月24日）
＊9 Remoguサイト公開情報（フルリモート可能案件の割合）