仕様変更の追加費用はどこからか【2026年版】線引き・変更管理・見積もりの根拠と揉めない実務

「開発の途中で少し仕様を変えたいと伝えただけなのに、想定外の追加費用を請求された」——システム開発を外注している方から、こうした相談をよく受けます。入力項目を1つ増やすだけで数十万円。見積書には「仕様変更が生じた場合は別途協議のうえ決定します」としか書かれていない。妥当なのか、言い値なのか、判断する物差しがないまま承認を重ね、気づけば当初予算の1.4倍になっている。

結論から言うと、仕様変更が追加費用になるかどうかは、「契約時に合意した仕様との差分かどうか」で決まります。請負契約は決めた仕様を完成させることに対価を払う契約なので、その外側の変更は追加費用と変更契約の対象になります。そして金額の妥当性は「増える工数×人月単価」で検証できます。検証できないのは、見積書が「一式」でまとめられていて、比べる単位そのものが存在しない場合だけです。

順序を間違えないでください。高いか安いかの議論は、範囲と手続きが決まったあとにしか成立しません。範囲が決まっていない状態で金額だけを交渉しても、根拠のない値引き合戦になり、次の変更でまた同じことが起きます。仕様変更は悪ではなく、管理されていない変更が、費用と納期を静かに膨らませるのです。

本記事では、仕様変更の定義と追加費用になる仕組み、追加になる変更とならない変更の線引き、変更管理(CR)の手順、提示された追加費用の根拠を確かめる方法、揉めないための実務と契約形態の選び方、よくある質問の順に解説します。線引きと手続きは、そのまま自社の発注仕様に貼り付けられる形で表にしました。

私は人材業界の出身で、2018年からホーチミンでベトナムオフショア開発の体制づくりに携わり、約100社の相談に乗ってきました。追加費用で揉めた案件に共通するのは、たった2つです。この記事を読み終えるころには、いま手元にある請求が妥当かを仕分けられ、次の発注で同じことを起こさない手順が組めるはずです。

仕様変更とは何か——「合意した仕様との差分」が追加費用になる仕組み

仕様変更という言葉は現場で広く使われますが、追加費用の話になった途端に定義がぶれます。発注側は「頼んだものの一部」と考え、開発側は「新しい仕事」と考える。この認識のずれが、そのまま請求のずれになります。まずは何を仕様変更と呼ぶのか、そしてなぜそれが費用に変わるのかを、作業の中身から押さえてください。

仕様変更の定義: 要件変更・設計変更・不具合との違い

仕様変更とは、契約時に合意した仕様(何を、どう作るか)との差分のことです。似た言葉と並べると輪郭がはっきりします。

このうち、費用の話でこじれるのは仕様変更と不具合の境界です。ここは後ほど詳しく扱います。先に押さえておきたいのは、仕様変更そのものは悪ではないという点です。使ってみて初めて気づくことは必ずあり、変更をゼロにすることを目標にすると、かえって使えないシステムができあがります。問題になるのは、管理されていない変更が費用と納期を静かに膨らませることです。

追加費用になるのは、変更が5種類の新しい作業を生むから

システム開発は、先に決めた仕様を土台にして設計・実装を積み上げる作業です。土台を動かすと、次の5種類の作業が新しく生まれます。

1. 作り直し: すでに書いたプログラムや作った画面を、新しい仕様に合わせて修正・再作成する
2. 手戻り: 終わったはずの設計やテストの工程まで戻ってやり直す
3. 影響範囲の波及: 1か所の変更が、つながっている別の機能にも波及して修正が必要になる
4. 再テスト: 直した部分と、その影響を受ける部分をもう一度動作確認する
5. スケジュールの調整: 作業が増えた分だけ納期がずれ、体制の維持や再見積もりが発生する

つまり追加費用は、増えた作業量の対価です。開発会社が儲けるための口実ではありません。ここを理解しておくと、請求の妥当性を冷静に判断できます。

感覚のずれが生まれるのは、変更が目に見える部分で完結しないためです。私はベトナムの大手IT企業でERPのプライム案件を上流から下流まで担当し、仕様を決める側と変更に対応する側の両方を見てきましたが、たとえば「入力項目を1つ増やしたい」という一見小さな依頼でも、画面の表示を直すだけでは終わりません。その項目を保存するデータの入れ物を変え、保存と読み出しの処理を直し、すでに登録済みのデータをどう扱うかを決め、最後に一連の動作をテストし直す。発注側から見た「ちょっとした変更」が、開発側では複数の工程にまたがる作業になるのが実情です。

このずれを埋める最も簡単な方法は、変更を伝えるときに「なぜそれが必要か」という目的まで共有することです。目的が分かれば、開発側から「その目的なら、この方法のほうが安く済みます」という代案が出てきます。

同じ変更でも、伝える時期で費用が変わる(工程別の傾向)

同じ「機能を1つ足す」変更でも、言い出すタイミングで費用は大きく変わります。早ければ図面を描き直すだけで済み、遅ければ組み上がった建物を壊してやり直すことになるためです。

この傾向は「変更は早いほど安い」という原則で覚えられます。だからこそ、何を作るかを固める要件定義の工程が効いてきます。ただし、最初にすべてを完璧に決めきるのは現実的ではありません。大切なのは、決めるべきことを決められるうちに決めておくことです。画面の文言や見た目は後から柔軟に直せますが、データの持ち方や機能の骨格といった土台の部分は、後から変えると影響が広い範囲に及びます。土台に関わる判断ほど早い工程で固め、細部の調整は後回しにする。この優先順位づけができるだけで、変更のコストはかなり抑えられます。

では、具体的にどこからが「追加」なのか。次章では、範囲内と範囲外を分ける基準を見ていきます。

追加費用が発生する変更・しない変更——線引きは「仕様書との一致」

追加費用の話がこじれる最大の原因は、「どこまでが最初の約束に含まれるか」の認識が発注側と開発側でずれていることです。基準そのものは単純で、契約時に合意した仕様書(または要件定義書)に含まれるかどうかで判定します。問題は、その仕様書の粒度が粗いと、判定できる範囲が狭くなることにあります。

範囲内と範囲外の一覧(何が追加になり、何がならないか)

一般的な線引きは次のとおりです。会社によって「軽微な調整は無償」の幅が違うため、そのまま鵜呑みにせず、自社の見積書・契約書と照らして確認してください。

この線引きが見積書か契約書に書かれていないまま着手すると、開発側は「それは別料金」、発注側は「聞いていない」となり、感情的な対立に発展します。着手前に「何が範囲内で、何が追加になるか」を文面化しておくことが、最も効く予防策です。とくに効果が大きいのは、含むものではなく含まないもの(対象外)を書かせることです。「テストは対象外」では何も決まりません。工程単位(結合テストは含むが受入テスト支援は含まない)、成果物単位(テスト仕様書は納品するがテストデータは発注側が用意する)、機能単位(管理画面の権限別テストは対象外)のどの粒度で切るのかを指定すると、返ってきた回答がそのまま契約書の除外事項欄になります。

不具合と仕様変更の境界——判定の基準は「発注側の期待」ではない

「動かないのだから不具合であり、無償で直すべきだ」。この主張が通るかどうかは、感情論ではなく判定基準の問題です。

IPA(情報処理推進機構)と経済産業省が公開している「情報システム・モデル取引・契約書(第二版)」(2020年12月22日公表)のひな型は、検収完了後に「納入物についてシステム仕様書との不一致(バグも含む)」が発見された場合に、発注者が履行の追完を請求できると定めています。つまり判定の基準は「システム仕様書との一致・不一致」であって、発注側の期待との一致ではありません。仕様書に書かれていない挙動は、不具合ではなく変更として扱われます。

ここから導かれる実務上の結論は明快です。仕様書の粒度が、そのまま無償修正の範囲を決めます。

仕様書の粒度が、そのまま無償修正の範囲を決める

仕様書が粗いほど、「仕様書との不一致」を主張できる範囲が狭くなり、追加費用になる領域が広がります。逆に、画面・機能・処理の単位まで書き込まれた仕様書があれば、無償で直させられる範囲が広がります。見積書や仕様書の分解単位が細かいことは、発注側にとって単なる透明性の話ではなく、保証範囲の話でもあるのです。

要件定義書が具体的なレベルまで落とし込まれていなければ、開発が進んでから「こうしてほしかった」と言っても、それは新たな仕様変更として扱われます。「要件定義が甘い=追加費用が発生しやすい」という関係は、当社が受ける相談の傾向とも一致します。仕様書の書き方そのものは「仕様書 書き方」の記事で詳しく扱っています。

発注側の指示に起因する不適合は追完を請求できない(民法636条)

もう一つ、発注側が不利になる規定があります。民法第636条は、請負人が契約の内容に適合しない目的物を引き渡した場合でも、注文者が供した材料の性質または注文者が与えた指図によって生じた不適合を理由としては、履行の追完・報酬の減額・損害賠償の請求・契約の解除ができない、と定めています。ただし同条のただし書きにより、請負人がその材料または指図が不適当であることを知りながら告げなかったときは、この制限は適用されません。

意味するところは、発注側が出した指示に起因する不具合は、無償修正ではなく追加費用になりうるということです。だからこそ、発注側からの指示は口頭で終わらせず、記録に残る形で出す必要があります。「言った・言わない」は、この条文が適用されるかどうかを左右します。法令の適用は個別の事情で結論が変わるため、実際に争いになりそうな場面では弁護士に相談してください。

線引きを決めたら、次は変更が出たときの手続きです。

変更管理(CR)の手順——変更提案書から変更契約までの4段

見積書によくある「仕様変更が生じた場合は別途協議のうえ決定します」という一文は、手続きではありません。誰が、何を書いた書面を、いつまでに出し、誰が承認すると変更が確定するのか。これが決まっていないと、変更のたびに交渉が発生し、そのつど金額の根拠が場当たりになります。変更管理(チェンジリクエスト、CR)とは、この流れを型にしたものです。

変更管理の4段(変更提案書→変更管理書→承認→変更契約)

IPA・経済産業省のモデル契約書のひな型は、ここに正規の手順を置いています。実務ではこれを簡略化して運用しますが、4段の骨格は変えないでください。

見落とされやすいのが4段目です。ひな型では、契約の条件に影響を及ぼす変更は、変更管理書の承認だけでは確定せず、変更契約を締結したときに確定するとされています。金額や納期が動く変更に承認印を押す前に、これは変更契約を要する変更なのかを確認してください。要するのであれば、変更契約の文面が出てくるまで作業着手を認めない運用にできます。

変更管理書に書かせる8項目——重いのは⑥金額と⑧他条件への影響

モデル契約書のひな型(第37条第1項「変更管理手続」)は、変更管理書に記載する事項として次の8項目を挙げています。自社の変更依頼書のフォーマットは、これをそのまま写して作れば十分です。

発注側にとって重いのは⑥と⑧です。⑥はその変更単体の金額、⑧はその変更が納期や委託料の全体へ与える波及を指します。実務で取りこぼされやすいのは⑧のほうです。1件ずつ単体の金額だけを見て承認していくと、納期の後ろ倒しと、それに伴う体制維持費の増加が積み上がり、最後にまとめて跳ね返ってきます。当社では日本人PMが設計レビューの場で影響範囲を先に評価し、⑧に相当する波及を承認前に洗い出す運用にしています。

承認前に着手させない、軽微な変更もCRに起票する

運用のルールは2つだけです。1つ目は、承認なしに変更作業を開始させないこと。2つ目は、追加費用が発生しない軽微な変更であっても必ずCRに起票することです。

2つ目は無駄に見えますが、ここを緩めるとスコープクリープが起きます。「これくらいならいいかな」という感覚で口頭やチャットで伝えた小さな変更が積み重なり、気づいたときには「これだけ積み上がっているので請求します」とまとめて出てくる。私が受ける相談でも最も多い失敗パターンです。無償で対応してもらった変更も記録に残っていれば、「あのとき言ったあれはどうなったのか」という曖昧さもなくなります。

優先度を3段階に仕分け、定例で未承認の一覧を可視化する

変更を止める必要はありません。仕分ければよいだけです。出てきた変更を「絶対に必要」「あれば良い」「なくてもよい」の3段階に分け、本当に必要なものだけを通します。そのうえで、週次または隔週の定例で変更依頼の一覧を開き、保留中が何件あるか、どれが承認済みでどれが未承認かを全員が見える状態にします。

運用ルールは3行で言い切れます。変更は必ず書面で出す。費用と納期への影響が回答されるまで着手させない。承認したものだけを作る。この3行を最初にすり合わせておけば、仕様変更は怖いものではなく、管理できるものになります。

提示された追加費用の根拠を確かめる——工数×単価、3つの入口、4状態

すでに増額の連絡が来ている場合、最初にやるべきは値引き交渉ではありません。金額の議論は、範囲と手続きが決まったあとにしか成立しないからです。順序を逆にすると、根拠のない値引き合戦になり、次の変更でまた同じことが起きます。ここでは、提示された金額を検証する3つの道具を順に示します。

追加費用=増える工数×人月単価。まず算定単位を出させる

仕様変更の追加費用に定価はありません。金額は「増える工数×人月単価」で決まります。1人月は1人が1か月働く作業量で、おおむね20営業日です。人月単価の水準は会社・職種・商流で大きく変わり、変更規模ごとの費用を示した公的統計も業界団体の一次調査も確認できないため、本稿では金額の目安を示しません。単価の考え方そのものは「人月単価」の記事で職種別・国別に整理しています。

作業量は実際の内容で上下します。大事なのは金額そのものより、どう算定したのかを説明させられるかどうかです。「1件いくら」なのか「工数×単価」なのか、無償修正は何回までか。この算定ルールが事前に決まっていれば、請求が来ても納得して判断できます。ルールがなければ、同じ変更でも言い値になるのが実情です。

増額の入口は3つしかない(対象外・変更・未確定)

増額の請求は、理由の書き方こそさまざまですが、契約上の入口は3つに分かれます。どの入口から来たのかを分類すると、確認すべき書類が自動的に決まります。

必要な反論はそれぞれ違います。「対象外」なら範囲の記載を、「変更」なら変更前の仕様書と合意の記録を、「未確定」なら概算である旨の記載と確定の手順を見ます。混ぜて議論すると、どの書類を見ればよいのか誰にも分からなくなります。

「説明済み/要確認/高リスク/判断不能」の4状態で仕分ける

提示された増額を「妥当か不当か」の2択で見ないでください。実務で使えるのは次の4状態です。

「高リスク」と「判断不能」の違いは、条件が抜けているだけなのか、判定の土台そのものが無いのかにあります。

「一式」の見積もりが最も危険な理由と、法的にどこまで請求できるのか

私は2018年からホーチミンで約100社の開発体制の相談に乗ってきましたが、追加費用で揉めた案件に共通するのは2つです。1つ目は、当初の見積書が「システム開発一式」でまとめられていて、増額分が本当に追加なのか、もともと含まれていたはずのものなのかを誰も検証できなかったこと。2つ目は、変更を口頭とチャットで断片的に頼み、承認の記録が残っていなかったことです。「一式」は金額が高いことが問題なのではなく、比べる単位が存在しないことが問題です。この状態で金額交渉をしても、着地点がありません。要注意です。

法的な整理も押さえておきます。民法第521条は「何人も、法令に特別の定めがある場合を除き、契約をするかどうかを自由に決定することができる」「契約の当事者は、法令の制限内において、契約の内容を自由に決定することができる」と定めています(e-Gov法令検索・2026年9月21日確認)。この契約自由の原則から、追加費用を支払う旨の合意がない限り、開発側は追加費用を請求できないのが原則です。ただし例外があります。商法第512条は「商人がその営業の範囲内において他人のために行為をしたときは、相当な報酬を請求することができる」と定めており(同上)、システム開発の追加作業にこの規定が及ぶかどうかが争点になることがあります。契約書に明記がない場合の扱いは事案ごとの判断になるため、金額が大きいときは弁護士に確認してください。

裏返せば、発注側が確認すべきは次の3点です。要件定義書・仕様書に記載済みの内容か。変更を依頼した記録があるか。作業の開始前に発注側が承認していたか。いずれかを満たさないなら、工数と時間単価の内訳を書面で提示させ、費用の根拠を説明させてください。個別の事案では結論が変わりますので、金額が大きい場合は弁護士への相談をおすすめします。

では、そもそも揉めない発注は、どう設計すればよいのでしょうか。

揉めないための実務と、契約形態の選び方——請負かラボ型(準委任)か

ここまでは、変更が起きた後の話でした。最後は、そもそも揉めない発注をどう設計するかです。やることは2つあります。記録を残す実務を回すことと、案件の性質に契約形態を合わせることです。後者のほうが効きます。

3つのエビデンス(仕様書・議事録・変更履歴)をそろえる

追加費用の交渉で最大の武器は記録です。集めるべきものは3つに整理できます。

この3つがそろっていれば、「言った・言わない」はほぼ起きません。逆に、口頭とチャットだけで進めた案件は、後から再構成できません。今日からできることとして、口頭で指示した場合は必ずメールで事後確認する習慣を始めてください。

契約前に決めておく8項目(チェックリスト)

契約に進む前に、次の8項目を確認してください。半分以上に「はい」と言えないなら、質問して埋めてから契約に進むのが安全です。

1. 作る機能の範囲が、要件定義書として文書に固められているか
2. 「何が範囲内で、何が追加になるか」の線引きが見積書か契約書に書かれているか
3. 対象外の作業(テスト・データ移行・セキュリティ対応・プロジェクト管理)が明示されているか
4. 無償で対応する修正の回数・条件が明記されているか
5. 追加費用の算定方法(1件いくら/工数×単価)が事前に決まっているか
6. 変更が出たときに、内容・費用・納期への影響を書面化する手順があるか
7. 発注側の承認なしに変更作業を開始しない、という合意があるか
8. 契約形態(請負/準委任)が案件の性質に合っているか

3番目は見落とされがちですが重要です。総額が他社より明らかに低い見積書は、テスト・データ移行・セキュリティ対応・プロジェクト管理のどれかが対象外に落ちていることで説明がつく場合があります。これらは消えたのではなく、発注側の作業か、後日の追加費用に移動しただけです。

請負とラボ型(準委任)で、仕様変更の意味はこう変わる

8番目が、この記事で最も伝えたい点です。契約形態を変えると、仕様変更の意味そのものが変わります。

請負では「契約時に決めた仕様」が基準なので、変更は追加費用と変更契約の対象になります。これは開発会社が意地悪だからではなく、完成責任を負う契約の構造上、そうならざるをえません。一方で準委任(ラボ型)は、一定期間の稼働に対価を払う契約です。作る順番を入れ替えても契約の前提は崩れないため、変更は「追加費用の問題」ではなく「優先順位の問題」になります。

誤解のないように書いておくと、ラボ型にすれば費用が増えないわけではありません。稼働が増えれば費用は増えます。変わるのは、変更のたびに別途見積もりと変更契約を挟む必要がなくなり、金額ではなく順番を議論できるようになる点です。契約形態の違いそのものは「準委任 請負 違い」の記事で詳しく整理しています。

スプリント単位の優先順位会議と、当社の体制。向く案件・向かない案件

ラボ型で変更を吸収する仕組みは、優先順位会議です。スプリントごとに「このスプリントで作るもの」を確定し、途中で出た変更は次のスプリントに持ち越します。変更を禁止するのではなく、次のサイクルで取り込む構造です。発注側は各スプリントの成果を見ながら順番を変えられるため、「やっぱりこちらを先に」という方向転換ができます。

当社が支援している介護記録SaaSのCareViewerは、日本語のブリッジSE1名とフルスタックエンジニア2名の体制で、週次の優先順位判断によって要件が動き続けるプロダクトを継続開発しています。コストは従来の半分以下で、「想像以上にエンジニアのレベルが高い」という声をいただいています。当社は協力会社を挟まず、2,000名以上のIT人財データベースから直接アサインしているため、人財の入れ替えや増員も社内で完結します。体制は日本人PM/ブリッジSEをフロントに置くパターンAを推奨しており、1名から、最短2週間で開始、増員は約1週間、縮小と交代は1か月単位です。最小構成は日本人PMフロント+2〜3人月で月額約80万円からで、実務3年目安のエンジニアは1,500USD(1USD=150円換算目安で約22.5万円)と単価を公開しています。契約と支払いは日本国内法人・日本法準拠で、海外送金は不要です。変更の影響評価は、日本人PMの設計レビューとGitプルリクエストによるコードレビューで承認前に洗い出します。

一方で、ラボ型が向かない案件も正直に書いておきます。要件が確定していて追加開発の予定がない単発のシステム、納期と総額を先に確定させなければ社内の決裁が下りない案件、優先順位を判断する担当者を発注側に置けない案件。この3つは、無理にラボ型を選ばず請負で発注したほうが総額は読めます。当社もそうした案件のご相談では請負をおすすめしています。要件が動くと分かっている案件に一括請負を当てるのが失敗のもとであるのと同じくらい、要件が固まっている案件に月額の体制を当てるのも無駄が出ます。契約形態は、案件の性質で選ぶものです。

仕様変更の追加費用でよくある質問

仕様変更と追加費用について、相談の場で繰り返し聞かれる質問を5つにまとめました。社内での説明や、開発会社への確認にそのままお使いください。

Q1. 追加費用の請求を拒否できますか?

要件定義書に記載済みの内容か、変更を依頼した記録があるか、作業前に発注側が承認していたか。この3点のいずれかを満たさない場合は、工数と時間単価の内訳を書面で提示させ、根拠を説明させる権利があります。ただし、契約書に記載がなくても商法第512条の適用が問題になる場合があるため、一律に拒否できるわけではありません。金額が大きい場合は弁護士にご相談ください。

Q2. 口頭やチャットで頼んだ変更も追加費用の対象になりますか?

なります。依頼の形式ではなく、合意した仕様との差分かどうかで判定されるためです。ただし、開発側があらかじめ「別途費用が発生する」と文書で示していない場合や、事前に取り決めた変更のルールを守らずに着手した場合は、請求しにくくなります。発注側も開発側も、記録を残すことが自分を守ります。

Q3. これは不具合ですか、それとも仕様変更ですか?

判定の基準は仕様書との一致・不一致です。仕様書に書かれたとおりに動いていなければ不具合(契約不適合)で、原則として無償の修正対象になります。仕様書に書かれていない挙動は、期待と違っていても不具合ではなく変更として扱われます。判断に迷う場合は、該当する記述が仕様書のどこにあるかを双方で指し示すところから始めてください。

Q4. 追加費用は当初契約の何%が相場ですか?

信頼できる一次統計は確認できていません。増加率は、対象外の書き方・変更の頻度・契約類型・要件の確定度で大きく変わるため、条件のそろっていない平均値と自社を比べても判断の材料になりません。相場を探すより、「増える工数×人月単価」で1件ずつ検証するほうが確実です。

Q5. 仕様変更が多い案件は、請負と準委任のどちらが得ですか?

要件が動き続けるなら準委任(ラボ型)です。変更のたびに追加見積もりと変更契約を挟む手間がなくなり、同じ月額の中で優先順位を組み替えられます。要件が確定していて追加開発の予定がないなら請負です。なお当社のラボ型は1名から、最短2週間で開始でき、縮小と交代は1か月単位で調整できます。判断の軸は、どちらが安いかではなく、要件が動く案件かどうか。

まとめ: 線引きを先に文書化し、変更は記録して承認してから着手させる——要件が動くなら契約形態を変える

仕様変更が追加費用になるかどうかは、契約時に合意した仕様書との差分かどうかで決まります。判定の基準は発注側の期待ではなく仕様書との一致・不一致であり、だからこそ仕様書の粒度が、そのまま無償修正の範囲を決めます。追加費用そのものは、作り直し・手戻り・影響範囲の波及・再テスト・スケジュール調整という新しく生まれた作業の対価であって、開発会社が儲けるための口実ではありません。ただし、金額の算定単位を説明させる権利は発注側にあります。

すでに増額の連絡が来ているなら、値引き交渉より先に検証してください。増額の入口を「対象外」「変更」「未確定」の3つに分類し、確認する書類を決める。そのうえで「説明済み」「要確認」「高リスク」「判断不能」の4状態に仕分ける。「一式」の見積もりが最も危険なのは金額が高いからではなく、比べる単位が存在しないからです。次の案件では、変更提案書から変更管理書、承認、変更契約までの4段を最初に合意し、承認前に着手させない、軽微な変更もすべて起票する、という2つのルールを守ってください。仕様書・議事録・変更履歴の3つがそろっていれば、「言った・言わない」はほぼ起きません。

そして、要件が動き続ける案件なら、契約形態そのものを見直す価値があります。請負では変更が追加費用と変更契約になりますが、準委任(ラボ型)なら同じ月額の中で優先順位を組み替えられます。当社は日本人PMをフロントに置き、2,000名以上の人財データベースから直接アサインする体制で、1名から・最短2週間・月額約80万円から提供しています。一方で、要件が確定した単発の開発や、総額を先に確定させたい案件には請負のほうが向きます。契約形態の違いは準委任と請負の違い、ラボ型の全体像はラボ型開発とはもあわせてご覧ください。現在の体制と要件をお聞かせいただければ、仕様変更の起きやすさに合う契約形態の判断と概算見積もりでお答えします。合わない案件にはその旨も率直にお伝えします。