SaaS・アジャイル開発委託— 段階納品と60日起算

1. 段階納品の設計

1-1. スプリント成果物の定義

各スプリントで納品する成果物（画面・API・ドキュメント）を一覧化し、完了の定義を添付します。
「リリース可能な単位」か「内部確認用」かで、検収の扱いが変わります。
支払60日ルールの起算点で発注前の確認も行います。

1-2. バックログ変更と書面

優先順位の変更自体は開発の通常運用ですが、スコープの大幅増加は追加合意が必要です。
変更履歴をチケットと発注記録の両方に残し、報酬への影響を明示します。

1-3. デモと検収の切り分け

スプリントレビューのデモは確認の場であり、必ずしも検収完了ではありません。
検収承認の意思表示（メール・システム上の承認）をもって受領日を記録する運用が明確です。

2. 60日起算とアジャイル

2-1. 受領日の記録タイミング

スプリントごとに給付を受領するたびに、台帳の受領日を更新します。
暦日での期日計算は記載事項のテンプレートの整理を参照してください。
最終リリース日だけを受領日にすると、中間スプリント分の期日が遅れて見える誤りが起きます。

2-2. 月次まとめ払いの場合

複数スプリントを月末に一括請求する場合でも、給付ごとの受領日は分けて記録します。
一括支払いと一括受領を混同しないことが、期日管理の要点です。

2-3. 検収保留と起算

検収争いがある間は、受領日の扱いが論点になります。
契約上の検収期間・自動検収条項を事前に定め、起算の基準を共有します。

3. 契約形態と役務の区分

3-1. 準委任と請負の混在

SaaS 開発では準委任（工数ベース）と請負（成果ベース）が混ざる契約もあります。
形態ごとに検収・支払条件が異なるため、契約書で区別して記載します。

3-2. 継続的業務委託の該当性

長期の開発支援は継続的業務委託として、記載事項・支払期日・中途解除等のルールが適用される場面があります。
書面の型は検収基準の決め方を活用します。

3-3. 保守フェーズへの移行

リリース後の保守・改修は別契約に分けると、開発フェーズの検収と混線しません。
移行時に新たな発注書面を交付し、業務範囲を切り替えます。

4. 台帳と社内フロー

4-1. チケットと台帳の連携

Jira 等のチケット完了と、法務・経理向け台帳の受領日は別レイヤーです。
スプリント終了時に台帳更新を必須ステップにすると漏れが減ります。

4-2. プロダクトオーナーの権限

優先順位を変える PO の判断が、実質的な発注変更になっていないか点検します。
金額に影響する変更は、発注権限者の承認フローを通します。

4-3. リリース後のインシデント対応

本番障害対応が当初の保守範囲に含まれるかを契約で明確にします。
緊急対応のたびに口頭発注が増えると、記載・支払の抜けが発生しやすくなります。

5. 実務シナリオとチェックリスト

5-1. バックログの優先順位が週次で変わる案件

プロダクトの優先順位変更自体は開発の通常運用ですが、スコープが当初見積もりの150%を超える場合は変更管理に乗せます。
PO が口頭で「次のスプリントはこれ」と指示した場合でも、報酬に影響する変更は発注権限者の承認を得ます。
チケットの優先度ラベルと、台帳の「変更承認済」フラグを対応づけると、後から説明しやすくなります。

5-2. リリース後に保守契約へ移行

本番リリースをもって開発フェーズの最終検収とし、翌月から保守契約の新台帳を開きます。
移行月にインシデント対応が発生した場合、どちらの契約範囲かを契約書で明確にしておきます。
書面の型は検収基準の決め方を流用し、業務内容を監視・障害対応に差し替えます。

5-3. 内製チームと外注のハイブリッド

内製がフロント、外注が API という分担では、外注分だけ受領日・支払期日を台帳で管理します。
結合テストの完了を誰の検収とするかは、結合テスト計画書に検収責任者を明記します。

よくある質問

Q. アジャイルでも発注書面は必要ですか

取引の性質上、書面での記載事項が求められる場面があります。
スプリントごとの追加合意も、記録可能な形で残します。

Q. ユーザーストーリーだけでは不十分ですか

開発の入力としては有効ですが、報酬・納期・検収の明示事項は別途書面で整えます。
チケットは台帳の補助資料として紐づけます。

Q. NoSQL だけの納品で検収できますか

完了定義にドキュメント・テスト結果が含まれるかで判断します。
検収基準を事前に合意しておくことが重要です。

Q. 内製チームと外注のハイブリッドは

外注分だけを台帳で管理し、受領日・支払期日を分離します。
内製作業と外注の境界を契約で明確にします。

Q. クラウド費用は開発委託料に含めますか

契約の定め次第です。実費精算する場合は、精算のタイミングと支払期日の関係も整理します。

まとめ

• スプリント成果ごとに受領日を記録し、60日起算を遅らせない
• スコープ変更は追加合意し、デモと検収を切り分ける
• 開発・保守・準委任/請負を契約上区別する
• チケット完了と台帳更新を別ステップで運用する

6. アジャイル開発委託の発注前チェックリスト

• スプリント成果物の完了定義を別紙に書いたか
• デモと検収承認を切り分ける運用になっているか
• スコープ拡大時の変更管理フローがあるか
• 準委任と請負のどちらで契約しているか明確か
• リリース後の保守契約へ移行するタイミングを決めたか

バックログの優先順位変更は開発の通常運用ですが、見積もりの150%超は変更承認に乗せます。
月次まとめ払いでも、給付ごとの受領日は分けて記録してください。
内製と外注が混在する場合、外注分だけ台帳で受領日・支払期日を追います。

7. 現場で起きやすい落とし穴

7-1. スプリントレビュー＝検収と誤認

デモで動いたから検収完了、とすると修正ラウンドが残っているのに受領日が確定してしまいます。
検収は承認メールやシステム上の承認ボタンなど、意思表示をもって記録します。
PO と経理で「いつ受領日を入れるか」を事前に合意しておくと、月末の混乱が減ります。

7-2. プロダクトロードマップと契約スコープのズレ

ロードマップに載った機能がすべて今期の委託範囲に含まれるわけではありません。
四半期ごとにスコープを書面で更新し、台帳の契約版番号を上げます。
含まれない機能は次期の見積もり対象として切り分け、口頭の期待値を抑えます。

7-3. 技術的負債対応の位置づけ

リファクタリングを「見えない作業」として無償化しないよう、工数の何%を負債解消に充てるか契約に書きます。
無償範囲を広げすぎると、実質的な報酬減額と受託者側に受け取られ、関係悪化の原因になります。

8. 台帳と経理の連携

スプリントごとの請求書が届いたら、台帳の受領日と請求書の対象期間が一致しているか突合します。

不一致がある場合は、受領日を先に修正してから支払期日を再計算します。

四半期の終わりに、検収保留の案件が残っていないか一覧で洗い出します。

注意

本記事は取適法・フリーランス新法に関する一般的な情報の整理であり、トリカク（torikaku） の機能説明を含みますが、法的助言ではありません。
個別の契約内容・取引実態については専門家にご確認ください。