コストを削るなら「契約書のどこ」を削るか

自己資金300万円のうち、開発費を少しでも抑えたい。複業として小さく検証したいフェーズなら、その気持ちは自然です。ただし「安くする」ためにコストを削る先には、安全な削り方と危険な削り方があります。

見積もりの金額そのものを値切る交渉は一時的な効果しかありません。それより効くのは、契約書に並ぶ「項目」を見直して、今のフェーズに不要なものを外すことです。ここで大事なのは、削っていい項目と、削るとあとで高くつく項目がはっきり分かれているという点です。この見分けがつかないまま「とにかく安く」と伝えると、開発会社側もどこを削ればいいか判断できず、結局は当たり障りのない一律値引きか、あとで痛い目を見る条項の削除になりがちです。

削ってよい項目

複業・小予算検証型のフェーズでは、次のような項目は思い切って削る、あるいは範囲を絞る対象になります。

  • 納品後の追加サポート範囲：無制限の質問対応・運用相談を契約に含めると、その分工数が積まれます。検証段階では「初期のバグ修正のみ・期間は1ヶ月」など範囲を絞り、追加相談はスポットで発注する形にする
  • 保守・監視の常時対応：24時間監視や即時対応のSLA（サービス品質保証）は、ユーザー数が少ない検証段階では過剰です。月次の軽い動作確認程度に落とす
  • デザインの作り込み：ロゴやビジュアルの複数案提示、細かなアニメーションなどは、検証に必要な最低限に絞ってよい部分です
  • ドキュメント類の充実度：詳細な運用マニュアルや操作手順書は、利用者が自分一人・少人数のうちは簡易版で十分です
  • 拡張性を見込んだ設計：将来の大規模利用を見込んだ冗長設計や負荷対策は、検証段階ではオーバースペックになりがちです

これらはいずれも「今すぐ困らない」項目です。検証がうまくいって次のフェーズに進むときに、あらためて追加発注すればよい部分だと考えてください。何を削るかを開発会社に丸投げするのではなく、自分から「このフェーズでは何が要らないか」を先に言語化して伝えると、交渉がスムーズに進みます。

削ってはいけない項目

一方で、金額が小さく見えても、削ると後から取り返しがつかなくなる項目があります。

複業検証型が開発費を抑える際、削ってよい契約項目と削ってはいけない契約項目を左右で対比した図。

項目削ってはいけない理由
知的財産権の帰属ソースコードや成果物の著作権が開発会社側に残る契約だと、将来の乗り換え・機能追加・売却が事実上できなくなる
検収条項「何をもって完成とするか」の基準がないと、支払い後に不具合が見つかっても是正を求めにくい
個人情報・決済まわりのセキュリティ対応検証段階でも実データを扱うなら、最低限の対策を削ると情報漏えい時に事業自体が終わる
契約解除・支払い条件途中で止める場合の精算方法が曖昧だと、揉めたときに交渉の土台がない

これらは目先の見積もり金額にはあまり影響しない項目ですが、トラブルが起きたときの被害の大きさが桁違いです。特に知的財産権と検収条項は、契約書で必ず確認したい条項（知的財産権・検収・保守）でも整理されている通り、個人が開発を発注するときに最初につまずきやすいポイントです。ここを削って安くなった金額は、後で何倍にもなって返ってくる可能性があると考えてください。

「あとで足す」を前提にした削り方

削ってよい項目に共通するのは、「今は要らないが、必要になったら追加できる」という性質です。逆に削ってはいけない項目は、「後から追加しようとしても手遅れになりやすい」という性質を持っています。この違いを軸に判断すると、迷ったときの基準がぶれません。

また、削った項目をそのままにせず、「どの条件がそろったら追加するか」を自分の中で決めておくことも重要です。たとえばサポート範囲なら「有料ユーザーが10人を超えたら保守契約を結び直す」のように、あらかじめ線引きしておくと、追加のたびに開発会社と一から交渉し直す手間が省けます。この積み上げ発注が無計画に膨らむと、見積書に載っていない、後から発生しやすい費用の項目で触れられているような「気づいたら予算オーバー」の状態に陥りやすいので注意してください。

詳細はコラムへ

契約項目それぞれの具体的な確認ポイントや、追加発注が増えていく前の防ぎ方については、「これも追加でお願い」が積み重なる前に、決めておくべきことで詳しく扱っています。削ってよい・だめないの判断に迷ったときは、まずこのガイドの基準に立ち返り、個別の論点はコラムで深掘りする、という順番で進めてください。