自己資金300万円を開発に投じると決めたとき、多くの人が見落としがちなのが「いつ、いくら払うか」という支払いのタイミングです。見積もりの総額ばかりに気を取られ、支払い条件は開発会社の提示をそのまま受け入れてしまう、という人は少なくありません。しかし、支払いのタイミングを工夫することは、金額そのものと同じくらい、資金計画とリスク管理の両面で重要です。
この記事で分かること
結論を先に示すと、個人が開発費を分割で払う際に押さえておきたいポイントは次の3つです。
- 着手金・中間金・完成払いという3段階の分割が一般的な型であること
- 一括前払いには金銭的なリスクがあり、段階的な支払いで回避できること
- 自己資金300万円というキャッシュフローの制約に、支払いタイミングをどう合わせるか
ただし、段階的な支払いにも1つ注意点があり、それは「支払いのタイミングを細かく分けすぎると、かえって開発会社との調整コストが増える」という点です。この点については後半で詳しく説明します。
見積もりの合計金額を見て「この金額なら払える」と判断しても、実際には契約時にまとまった金額を求められ、手元の自己資金が想定より早く目減りしてしまう、という事態が起こり得ます。支払い条件を事前に理解し、自分から交渉できる状態を作っておくことが、資金計画を崩さないための土台になります。
そもそも、なぜ開発費は分割で支払うのか
システム開発の請負契約では、開発会社が先に作業を行い、発注者が後から対価を支払う、という関係が基本になります。しかし、数百万円規模のプロジェクトを開発会社側が完全に「先に作業、後でまとめて回収」という形で進めるのは、開発会社にとっても資金繰りの負担が大きくなります。人件費は毎月発生する一方、入金は納品時の1回だけ、という状態では、開発会社側のキャッシュフローが厳しくなるためです。
そのため、実務では工程の節目ごとに支払いを区切る「分割払い」が一般的です。発注者側にとっても、分割払いには次のようなメリットがあります。
- 一度に用意する金額が小さくなり、資金繰りの見通しが立てやすくなる
- 工程の節目で成果物を確認しながら支払えるため、進行中の軌道修正がしやすくなる
- 万が一、途中でプロジェクトを止める判断をした場合、まだ支払っていない金額の損失を防げる
逆に言えば、分割払いという仕組みそのものが、発注者・開発会社の双方にとってリスクを分散する合理的な方法として定着している、ということです。
分割払いの基本の型：着手金・中間金・完成払い
分割払いにはいくつかのパターンがありますが、個人が小〜中規模のシステム開発を発注する場合によく使われるのが、次の3段階の型です。
1. 着手金（契約時に支払う金額）
契約が成立したタイミングで支払う金額です。開発会社が要件定義・設計といった初期工程に着手するための費用に充てられます。一般的な相場観として、開発費用全体のおおむね30%前後を着手金とするケースが多く見られます（ただし案件の規模・開発会社の方針によって幅があります）。
2. 中間金（工程の節目で支払う金額）
要件定義や基本設計が完了した時点、あるいは開発が一定まで進んだ時点など、工程の節目で支払う金額です。プロジェクトの規模によって、中間金を1回にするか複数回に分けるかが変わります。小規模なMVP開発であれば中間金は1回、機能数が多い開発であれば中間金を2〜3回に分けるケースもあります。
3. 完成払い（納品・検収完了後に支払う金額）
成果物の納品と検収(発注者側が動作確認を行い、問題がないことを確認する工程)が完了した時点で支払う、最後の金額です。この完成払いを厚めに設定しておくことが、発注者側のリスク管理の観点では重要になります。
なぜ「完成払いを厚めに」が推奨されるのか
もし着手金の比率を大きくしすぎると、開発の途中で「思っていたものと違う」「進捗が明らかに遅れている」といった問題が発覚しても、発注者側が既に多くの金額を支払ってしまっているため、交渉力を失いやすくなります。逆に、完成払いの比率を厚めに残しておけば、検収の段階まで発注者側の交渉力を保つことができます。
もちろん、開発会社側にも人件費の先出しという負担があるため、「完成払いだけを極端に厚くしてほしい」という要望が常に通るわけではありません。バランスを取った現実的な配分としては、着手金30%・中間金35%・完成払い35%、あるいは着手金30%・完成払い70%(中間金なし)といった型が実務でよく使われます。
案件規模別に見る、分割回数の目安
分割払いの型は、案件の規模によって最適なパターンが変わります。「必ず3段階に分ける」と決め打ちにするのではなく、自分のプロジェクト規模に合った分割数を選ぶことが、無用な調整コストを避けるコツです。
小規模案件（開発費50万〜150万円程度、開発期間1〜2ヶ月）
専門知識を活かした簡易ツールや、機能を絞ったMVPなど、開発期間が短い案件では、着手金と完成払いの2段階で十分なケースが多くなっています。工程の節目自体が少ないため、中間金を無理に設ける必要はありません。目安としては「着手金40%・完成払い60%」のような、やや着手金の比率を高めにした2段階です。
中規模案件（開発費150万〜400万円程度、開発期間2〜4ヶ月）
自己資金300万円前後で立ち上げるサービスの多くが、この規模帯に該当します。要件定義・設計・実装・テストという工程がそれぞれ意味を持つ規模になるため、着手金・中間金・完成払いの3段階が最も扱いやすくなります。「着手金30%・中間金35%・完成払い35%」を基本形にしつつ、機能追加のタイミングで中間金をもう1回挟む「4段階」に調整する開発会社もあります。
大規模案件（開発費400万円超、開発期間4ヶ月以上）
自己資金300万円の枠を超える案件では、外部からの追加資金調達や、機能を段階的にリリースする「フェーズ分割」の発想と組み合わせることが多くなります。この規模になると、中間金を工程ごとに2〜3回設定し、各フェーズの完了を明確な成果物(動作するプロトタイプ、ユーザーテストの結果など)で確認しながら進める設計が一般的です。ただし、自己資金300万円という前提から外れる規模の話であるため、この記事の主な対象読者にとっては「将来、事業が伸びた場合の参考情報」という位置づけになります。
| 案件規模 | 開発費の目安 | 分割回数の目安 | 典型的な配分 |
|---|---|---|---|
| 小規模 | 50万〜150万円 | 2段階 | 着手金40%・完成払い60% |
| 中規模 | 150万〜400万円 | 3段階（〜4段階） | 着手金30%・中間金35%・完成払い35% |
| 大規模 | 400万円超 | 3〜5段階（フェーズ分割併用） | フェーズごとに個別設計 |
サブペルソナ別に見る、支払い交渉の実際の場面
同じ「分割払い」というテーマでも、置かれた状況によって具体的に気になるポイントは変わります。ここでは、実際によくある2つの状況を例に、支払い条件の考え方を具体的に落とし込みます。
ケース1：専門知識をツール化する場合の支払い交渉
税理士や社労士など、特定の専門知識を持つ人が「自分の業務ノウハウをツール化して同業者に提供する」というサービスを立ち上げる場合、想定読者数や利用頻度がまだ不確かな段階で契約を結ぶことになりがちです。このケースでは、「需要が本当にあるかどうか分からない段階で、まとまった着手金を払うことに抵抗がある」という悩みが典型的です。
このような場合は、開発会社に対して「まず小さい範囲(核となる1機能)だけを契約し、着手金・完成払いの2段階で一区切りつける。反応が良ければ、追加機能の開発契約を別途結ぶ」という進め方を提案するのも一つの方法です。最初から大きな契約でまとめて分割するより、小さい契約を複数回に分けたほうが、需要が読めない段階でのリスクを抑えられます。
ケース2：店舗の自作ツールを他店にも展開する場合の支払い交渉
自分の店の業務改善のために作ったツールを、同業の他店にも展開しようと考えている場合、「個人の店舗経営者として、まとまった金額の支払いに慣れていない」という状況で交渉することになりがちです。店舗運営でのキャッシュフロー管理の感覚(仕入れや家賃の支払いサイクル)をそのまま開発費の支払いに当てはめようとすると、開発の工程と支払いのタイミングがかみ合わず、戸惑う場面が出てきます。
この場合、開発会社との打ち合わせで「自分の店の資金繰りサイクル(月次の売上・仕入れのタイミング)を伝えたうえで、支払いタイミングをそれに寄せてもらえないか相談する」という進め方が有効です。開発会社側も、発注者の資金繰りの実情を把握したうえで支払いスケジュールを組んだほうが、後々の遅延リスクを避けられるため、多くの場合は前向きに相談に応じてくれます。
自己資金300万円という制約に、支払いタイミングをどう合わせるか
自己資金300万円を投じてサービスを立ち上げる場合、支払いタイミングは「単なる契約条件」ではなく、「自分の生活資金・運転資金がいつ、どれだけ減るか」という切実な問題に直結します。
資金の減り方をシミュレーションしてみる
たとえば、開発費用200万円のプロジェクトを、着手金30%・中間金35%・完成払い35%で分割した場合、支払いのタイミングは次のようになります。
| タイミング | 支払い金額 | 自己資金300万円からの残額 |
|---|---|---|
| 契約時（着手金30%） | 60万円 | 240万円 |
| 工程の節目（中間金35%） | 70万円 | 170万円 |
| 検収完了（完成払い35%） | 70万円 | 100万円 |
開発費以外にも、サーバー・ドメイン等の運用インフラ費、決済サービスの初期費用、法務関連の準備費用などが並行して発生するため、実際の手元資金の減り方は開発費の支払いだけでは決まりません。この点は、公開後の運用費の実態や、見積書に載っていない費用の項目と合わせて確認しておくと、資金計画の全体像がつかみやすくなります。
支払いタイミングと開発期間のズレに注意する
もう1つ見落としやすいのが、「支払いのタイミング」と「実際に開発が進むペース」のズレです。たとえば、要件定義が想定より長引いた場合、中間金の支払いタイミングも後ろにずれます。逆に、検収が長引けば、完成払いの支払いも遅れます。
このズレ自体は悪いことではなく、むしろ「支払いは工程の完了と連動している」という証拠でもあります。問題になるのは、発注者側が「契約時にスケジュール表で決めた日付」を支払いタイミングだと誤解してしまい、実際の進捗を確認せずに支払いを済ませてしまうケースです。支払いは必ず「日付」ではなく「工程の完了」に紐づけて実行することを、契約時に明記しておくことが重要です。
一括前払いのリスクと、避けるべき理由
個人開発者やフリーランスへの発注では、資金繰りの事情から「一括前払い」を求められることがあります。開発会社(法人)であっても、規模が小さい場合には同様の要望を受けることがあります。しかし、一括前払いには発注者側にとって明確なリスクがあります。
リスク1：開発が途中で止まった場合、支払った金額を取り戻せない可能性がある
受注者側の事情（体調不良、他案件との兼ね合い、廃業など）で開発が途中で止まってしまった場合、既に支払った金額を返金してもらうのは、契約上・実務上ともに簡単ではありません。分割払いであれば、支払っていない残額の分だけ、発注者側の損失を抑えることができます。
リスク2：成果物の品質に問題があっても、交渉力を失っている
前払いした後に「思っていたものと違う」「品質が低い」といった問題が発覚しても、既に金額を支払い終えている状態では、開発会社側に改善を求める際の交渉材料が乏しくなります。
リスク3：消費者保護の観点でも、高額な前払いには注意喚起がある
消費者庁は、高額な料金を一括前払いする取引について、「前受金保全措置」の有無を確認するよう注意喚起しています（参考: 消費者庁「前受金保全措置」の有無を確認するなど、高額料金の一括前払いを行う際は、契約内容や支払い方法等を十分にご検討ください）。これは特定商取引法上の「特定継続的役務提供」等を主な対象にした注意喚起ですが、「前払いした金額が、相手の倒産・廃業時にどう扱われるか」という論点自体は、個人がシステム開発を発注する場面でも参考になる視点です。前払い金の保全措置(金融機関の保証等)が用意されている取引は限定的なので、システム開発の発注では基本的に「前払い額を必要最小限に抑える」ことが、発注者側にとって現実的な自衛策になります。
エスクローサービスという選択肢
個人開発者・フリーランスへの発注で、双方が初対面に近く信頼関係がまだ薄い場合、代金を第三者が一時的に預かり、検収完了後に支払う「エスクローサービス」を利用する方法もあります。この仕組みについては、個人開発者への発注を検討する際の見積もり比較でも触れていますが、金額規模が大きい場合や、面識のない相手に発注する場合の選択肢として検討する価値があります。
支払いが遅れそうなとき、どう対応すればよいか？
どちら側の事情であっても、気づいた時点ですぐに連絡することが最も有効な対処です。
分割払いを組んでいても、開発の途中で「検収の基準を満たさない」「発注者側の資金繰りが厳しくなった」といった理由で、支払いが計画通りに進まないことがあります。ここでは、発注者側・開発会社側それぞれの視点で、遅延が起きたときの現実的な対応を整理します。
発注者側の資金繰りが厳しくなった場合
自己資金300万円という限られた原資の中で開発を進めていると、想定外の出費(前述の運用インフラ費や外部サービス利用料など)が重なり、次の支払いタイミングで資金が足りなくなる、という事態が起こり得ます。この場合、最も避けるべきなのは「何も連絡せずに支払い期日を過ぎてしまう」ことです。
資金繰りが厳しいと分かった時点で、早めに開発会社に相談すれば、支払い時期を後ろ倒しにする、金額を再分割する、といった調整に応じてもらえることが多くあります。逆に、連絡なく支払いが遅れると、開発会社側は「発注者の資金力に問題があるのでは」と不安を持ち、以後の工程を止めてしまうリスクがあります。早期の連絡は、開発を止めないための最も現実的な自衛策です。
開発側の進捗が遅れ、検収の基準を満たさない場合
逆に、開発側の事情で工程が遅れ、中間金・完成払いのタイミングで「まだ検収の基準を満たしていない」という状況になることもあります。この場合、発注者側が焦って「とりあえず支払ってしまう」という判断をすると、前述したように交渉力を失う結果になりかねません。
検収の基準を満たしていないと感じたら、その理由を具体的に伝え、「基準を満たした時点で支払う」という契約上の原則を維持することが重要です。ただし、些細な不具合の指摘に固執して支払いを不当に引き延ばすと、今度は開発会社側との関係が悪化します。契約時に定めた「検収の基準」に照らして、客観的に判断することを心がけます。
遅延損害金・催促の実務
契約書に「支払いが遅延した場合の扱い」を明記していれば、遅延損害金の請求や、正式な催促の手順に沿って対応できます。個人間・個人対フリーランスの取引では、遅延損害金の条項自体を設けないケースも多く見られますが、その場合でも「支払い期日から◯日を過ぎたら書面で催促する」といった簡易なルールだけは決めておくと、感情的な対立を避けやすくなります。
支払いと税務・経理の関係を押さえておく
開発費の分割払いは、経理・税務の処理にも関わってきます。個人事業として立ち上げる場合、支払った開発費は経費として計上できますが、支払いのタイミングによって計上する年度が変わることがあるため、あらかじめ把握しておくと確定申告の際に慌てずに済みます。
- 着手金・中間金・完成払いのそれぞれで、開発会社から請求書・領収書を必ず受け取る（経費計上の証憑として必須）
- 年をまたぐ分割払いの場合、どの支払いをどの年度の経費として計上するか、税理士や会計ソフトの案内を確認する
- 源泉徴収の要否は、支払い先が法人か個人事業主(フリーランス)かで扱いが変わることがあるため、契約前に確認しておく
こうした税務・経理の具体的な処理は、案件ごとの個別事情によって扱いが変わるため、この記事では入口の整理に留めます。具体的な仕訳や源泉徴収の要否については、税理士など専門家に確認することをおすすめします。副業でサービスを立ち上げる場合の最低限の税務知識は、別記事でも整理しています。
支払い条件は、どこまで契約書に明記すべきか？
金額・タイミング・検収基準・遅延時の扱い・中断時の既払い金の扱いの5点を、必ず書面に残します。
支払いのタイミング・金額・条件は、口頭やメールのやり取りだけで済ませず、必ず契約書(または発注書)に明記します。契約書に書いておくべき最低限の項目は次の通りです。
- 各支払いの金額（または開発費全体に対する割合）
- 各支払いのタイミング（「契約締結時」「要件定義完了時」など、日付ではなく工程で指定する）
- 検収の基準（何をもって「検収完了」とするか）
- 支払いが遅延した場合の扱い（催促の手順、遅延損害金の有無など）
- 開発が中断した場合の、既払い金の扱い
契約書に必要な条項の詳細（知的財産権・検収・保守）については、別記事でも整理しています。支払い条件は、この契約書のチェックリストの一部として、必ず個別に確認する項目に加えてください。
開発会社が提示した支払い条件、どう読み解けばよいか？
着手金の比率・提示の有無・工程との紐づけの3点を見れば、開発会社の姿勢がある程度分かります。
見積書と一緒に提示される支払いスケジュールには、開発会社側の考え方が反映されています。金額の割合だけでなく、次のような観点で読み解くと、その開発会社の姿勢や信頼度をある程度推し量ることができます。
着手金の比率が極端に高い場合
着手金が50%を超えるような提示があった場合、その理由を確認することをおすすめします。理由には、外部の専門人材を先に確保する必要がある、過去に着手金を抑えた案件でキャンセルが多発した経験がある、といった正当な事情がある場合もあれば、単に資金繰りを優先した一方的な提示である場合もあります。理由を尋ねて納得できる説明が得られない場合は、契約前に交渉するか、他の開発会社との比較材料にすることを検討してください。
支払いスケジュールが一切提示されない場合
見積書に総額だけが書かれ、支払いのタイミングについて何も触れられていない状態は、要注意のサインです。開発会社が意図的に隠しているというより、単に発注者側から確認しないと詳細を出さない、という運用になっているケースもあります。いずれにせよ、支払いスケジュールの提示を自分から求めることを契約前の必須確認事項にしてください。
支払いスケジュールの提示が、工程表と一致していない場合
支払いのタイミングが「契約から◯日後」のように日付だけで示され、対応する工程(要件定義完了、基本設計完了など)との紐づけが説明されていない場合も注意が必要です。前述の通り、支払いは工程の完了と連動させるべきものなので、日付だけで管理しようとしている提示には、こちらから「◯◯の工程が完了した時点、という条件を明記してほしい」と依頼することをおすすめします。
支払い条件の交渉で、実際にどう伝えればよいか
支払い条件について「交渉してよいものだ」と分かっていても、実際にどう切り出せばいいか分からない、という人は多いはずです。ここでは、具体的な伝え方の例をいくつか紹介します。
- 着手金の比率を下げたい場合：「初めての発注で、資金計画への影響を慎重に見ておきたいので、着手金を◯%程度に抑えていただくことは可能でしょうか。その分、中間金や完成払いの比率を調整いただければと思います」
- 支払いを工程の完了に紐づけたい場合：「支払いのタイミングを、契約からの経過日数ではなく、要件定義完了・基本設計完了といった工程の区切りに合わせていただくことは可能でしょうか」
- 分割回数を調整したい場合：「今回はMVPとして機能を絞った開発なので、中間金は設けず、着手金と完成払いの2段階にまとめていただくことは可能でしょうか」
これらの提案は、開発会社にとって特別に無理な要求ではなく、実務上よく交わされるやり取りです。臆せず相談してみることをおすすめします。多くの開発会社は、初めて発注する個人に対して丁寧に説明してくれますが、もし高圧的な対応をされたり、質問自体を嫌がる態度を示された場合は、その対応自体が開発会社選びの重要な判断材料になります。
失敗パターン：支払いタイミングでよくあるつまずき
実際に個人が開発を発注する場面で起きやすい失敗パターンを、いくつか紹介します。
失敗パターン1：着手金の比率を確認せずに契約してしまう
見積もりの合計金額だけを見て契約を進め、いざ請求書が届いてから「着手金がこんなに高いのか」と驚くケースです。契約前に、支払いスケジュールの提示を必ず求め、金額と時期を書面で確認してから契約することをおすすめします。
失敗パターン2：中間金の支払いタイミングを「日付」だと思い込んでしまう
前述の通り、中間金は「工程の完了」に紐づくものですが、契約時に提示されたスケジュール表の日付をそのまま支払い日だと誤解し、進捗が遅れているにもかかわらず予定通りに支払ってしまうケースがあります。支払い前には、必ず該当工程の完了を示す成果物(設計書、動作するプロトタイプなど)を確認する習慣を持つことが重要です。
失敗パターン3：分割回数を増やしすぎて、かえって調整コストが膨らむ
「リスクを減らしたいから」と、支払いを5回、6回と細かく分けすぎると、その都度、開発会社側との確認・請求書のやり取りが発生し、双方の事務負担が増えてしまいます。冒頭で触れた「分割を細かくしすぎるとかえって調整コストが増える」という注意点は、まさにこの点です。小規模なMVP開発であれば、着手金・完成払いの2段階、または着手金・中間金・完成払いの3段階程度に留めるのが、現実的なバランスです。
失敗パターン4：口頭の約束だけで支払いを進めてしまう
「じゃあ、進んだ分だけ都度払いますね」という口頭の約束だけで進めてしまい、後になって「言った・言わない」のトラブルになるケースです。金額が小さくても、支払い条件は必ず書面(メールでの合意でも可)に残しておくことをおすすめします。
この記事で持ち帰れること
この記事を読んで、次の2点が判断できるようになったはずです。まず、開発費の支払いを「着手金・中間金・完成払い」という工程単位の分割で考える視点です。もう一つは、自己資金300万円というキャッシュフローの制約の中で、支払いタイミングを工程の完了と紐づけて交渉する具体的な姿勢です。
支払い条件は、開発会社から提示された内容をそのまま受け入れるものではなく、発注者側から「工程の完了に紐づけて分割にしたい」と提案してよいものです。多くの開発会社は、こうした提案に柔軟に対応してくれます。
まずは、今検討している(あるいは既に見積もりを受け取っている)プロジェクトについて、支払いスケジュールが着手金・中間金・完成払いのどの型に近いか、一度書き出してみることをおすすめします。それだけで、契約前に確認すべき論点が具体的に見えてきます。
書き出す際は、金額の割合だけでなく、「その支払いがどの工程の完了と紐づいているか」も一緒にメモしておくと、後から見返したときに交渉すべきポイントが一目で分かります。難しく考える必要はなく、ノートやスプレッドシートに3〜5行の表を作るだけで十分です。この小さな整理作業が、契約書を読む前の準備運動になります。
この記事の次に読みたい記事
支払い条件の整理ができたら、契約書全体で確認すべき他の項目も見ておくと安心です。
見積書に載っていない費用まで含めた資金計画を立てたい場合は、見積書に載っていない、後から発生しやすい費用の項目も参考になります。
