フリーランスになるならまず「契約」について固めた方がいいです。
会社員をしているとあまり馴染みがないので逃げたくなるような話ですが、
フリーランスになると当たり前のように誰も守ってくれません。
自分と契約書（取り決め）だけが自分を守ってくれます。
という私も、始めの頃はDiscordやChatworkで話を詰めて、金額を決めて、要件定義書やお見積りを作成し、それを送り合意を取って着手。
それでいいと思っていましたが、そうでもありません。
一見問題なさそうですが、大有りです。
むしろ、何も問題はないでしょと思ったあなたは、絶対読んでください。
拙いですが「3へぇ」くらいは押したくなると思います。
私はフリーランス2年目のエンジニアで、法律や契約の専門家ではありません。あくまでも自分の実体験をもとにした話なので、参考程度に読んでもらえると助かります。実際にトラブルが起きた場合は、自己判断せず専門家に相談してください。（AIもダメもちろんだめだよ）
実際にあったトラブル
仲介構造のトラブルで100万円が未入金になったこと、書面なしで進めた案件で「言った・言わない」が起きたこと、どちらも経験しています。
詳しくはこちらに書いているので、よければ合わせて読んでみてください。
受託・レベニューシェア・コンテンツ販売、全部やってみてわかったこと →
あるクライアントとの金銭まわりのこじれが何度も続いて、そこから少しずつ固めていきました。
防御姿勢というか、隙をなくすために。色々調べたりAIに聞いたりしつつ、着手金を条件にするまでには1年かかりました。
この経験をもとに、今使っているチェックリストをまとめました。
受託・保守の契約書に入れておくべき項目
失敗を踏まえて今使っているチェックリストです。
受託開発
| 項目 | 書いておくべきこと | 自分の場合 |
|---|---|---|
| 業務内容 | 何を作るか、何を含まないか | 別紙仕様書に定める |
| 報酬 | 金額、消費税の扱い、支払期日 | 月末締め翌月末日払い、振込手数料は先方負担 |
| 着手金 | 総額の何%か、着手時に支払われること | 30〜50%（私は30万超は必須条件にしている） |
| 納期 | いつまでに何を納品するか | 別紙仕様書に定める |
| 検収 | 何営業日以内に確認、無応答の場合の扱い | 14日以内、通知なしは承認とみなす |
| 仕様変更 | 変更が発生した場合の追加費用の合意方法 | 別途見積もり・協議で決定 |
| 著作権 | 納品後に誰に帰属するか | 報酬完済をもって先方に移転 |
| 秘密保持 | 開発中に知り得た情報の扱い | 契約終了後3年間 |
| 契約解除 | どちらがどの条件で解除できるか | 1ヶ月前の書面通知で中途解約可 |
補足
何をの納品するかの部分ですが、私はポリシー的にリポジトリの譲渡はしたくないので、プロジェクトをZIP化したものを納品しています。
保守契約
| 項目 | 書いておくべきこと | 自分の場合 |
|---|---|---|
| 対象範囲 | バグ修正の定義、機能追加は対象外と明記 | バグ修正・軽微な調整・問い合わせ対応のみ。新機能・仕様変更は別途 |
| 対応時間 | 平日何時〜何時、レスポンスは何時間以内 | 平日10:00〜17:00 |
| 月額費用 | 固定か、作業量に応じた変動かの明示 | 固定の基本保守料 |
| 更新・解約 | 自動更新か否か、何ヶ月前に告知か | 1ヶ月前の書面通知で中途解約可 |
| 免責 | 対象外のトラブルの扱い | 外部サービス起因の動作不良は免責 |
特に保守は「バグ修正は含むが機能追加は別料金」という線引きを最初から書面に入れておかないと、曖昧なまま何でも対応させられる状態になりがちです。
「ちょっとした修正」が積み重なって、月の半分はその案件に使っている、なんてことになりかねないので。（恐ろしいですが実話です）
着手金
私は30万円を超える案件は、着手金をもらうようにしています。
だいたい総額の30〜50%くらいです。
そもそもの話、個人開発でそれしか収入がないという前提で考えた時に、この案件は100万で受けれますが2ヶ月かかります。と考えた時に、検修期間や相手のレスポンスも考えて2.5〜3.5ヶ月くらい入金がないかもしれないという想定はした方がいいです。（もちろんキャッシュが潤っているなら止めませんが）
また、今のところ副業を合わせて10年近く個人開発をしていますが「着手金ありますか？」と先方から聞いてくることはまだ一度もないので、自分から条件として出す方がいいです。
もちろん、たまに断られることもあります。
でも断られた時点で「支払いに不安がある相手かもしれない」というシグナルとして見ることもできるので、それはそれで情報になります。
実際、初めて着手金を条件として出したとき、契約解除を通告されたことがあるので、相手が悪かったんだと思うし、トラブルが起こる前でよかったとは思いました。MTGや仕様の確認、要件定義の作成などの時間は帰って来ないけどね。
少し乱暴な言い方ですが、まともなクライアントほど「わかりました」とあっさり通ります、
なので関係値がない場合、最初は言いにくいかもですが、お金の切れ目は縁の切れ目でもあるので円滑に話を進める上では初めからお互いに基盤をしっかりしていく方がメリットが多いです。
フリーランス保護法について
ちなみに、2024年11月から、フリーランス保護法（フリーランス・事業者間取引適正化等法）が施行されていて、
一応、業務内容・報酬額・支払期日の書面明示義務、60日以内の支払い義務などが定められています。
とはいえ法律があるからといって何かが自動で解決するわけではないので、「法律を根拠に動ける」と割り切る必要があります。
またトラブル時の相談窓口として、厚労省委託の「フリーランス・トラブル110番」（第二東京弁護士会運営）があります。
弁護士に無料相談できる（らしい）ので、頭の片隅に入れておくといいかもしれません。
私はおかげさまで、まだお世話になっていません。
余談：要件定義はファイルで残す
ある案件で、ホスティングサービスの無料枠の制限でページが一時的に見れなくなってしまう問題を起こしてしまったことがあります。
しかもちょうど納品→検修というすごいタイミングに。
その際に「機能が足りないからこれじゃあOKは出せない」と言いがかりをつけられて、今はもういい経験だったと思えますが、当時はめちゃくちゃ大事になりました
でも要件定義のDBに更新日時が残っていて、クライアントに提出した日時と一致していたことが証明できて、やっと思い違いだったと意見を変えてくれて話は丸く治りましたが、私としては免罪なのに詰められています。
ここで伝えたいことは、これは半分偶然みたいなものだった。ということです。
当時、自分はObsidianやClaude Codeで処理しやすいようにMDファイルで要件をまとめてDBに入れるフローにしていて、WordやExcelでの管理はやめていた。もちろん効率のつもりで。
でも冷静に考えると、会社員時代は契約書や正式な取り決めの書類を作るのは普通のことだった。
フリーランスになって効率を求めすぎて、その当たり前を忘れていた…という自戒です。
そもそもWordもExcelもAIで十分に操作できるしね。
要約すると「形式はなんでもいいので、要件定義は必ずファイルで残すこと」を私はおすすめします。
まとめ
フリーランスになって最初のうちは、「案件がある＝生活がつづく」もっと言えば「案件がないとお金がない」という偏った考え方になりがちなので契約まわりを後回しにしてしまいがちなのはなんとなくわかります。
案件がとれるかどうかが先で、細かい話を詰めることで「めんどくさいやつと思われたら困る」という変な遠慮もあります。
でも、ちゃんと契約することは「めんどくさい」のではなく「自分を守る最低限の手順」だと認識すべきだなと今は感じています。
まずは仕様と金額をメールに書いて残すだけでも十分です。
それだけで「言った・言わない」の大半は防げます。
大事なのは相手は編集できない部分で記録を残すことです。
ちなみに私は静的なWEBページ上で
デベロッパーツールで偽装している！！！エンジニアなんだからそんなこと簡単だろ！！！
なんてことも言われたこともあります
世の中、いろんな人がいます。
— niau