情報成果物作成委託の「プログラム」と「デザイン」— 境界メモ

1. 境界が曖昧になりやすい場面

1-1. Figmaから実装まで一式

デザインカンプ納品と、それを再現するフロント実装は成果物の性質が異なります。
一式発注でも、台帳上はデザイン成果物行とプログラム成果物行に分けると検収トラブルが減ります。

1-2. ノーコード／ローコード

画面構築が設定作業中心でも、業務ロジックや連携スクリプトが含まれるならプログラム要素が混在します。
「見た目の調整」と「動作する仕組み」を発注書の給付内容で分けて書いてください。

1-3. イラスト・キャラデザとゲームロジック

ビジュアル資産とプログラムは権利処理も別であることが多いです。
関連記事としてイラスト・キャラデザ委託とゲーム開発委託があります。

2. 境界メモ表

モバイル開発はモバイルアプリ開発委託、著作権の整理は著作権・IPと委託を参照してください。

3. 発注書に書く境界ルール

3-1. 納品物リストを2系統にする

デザイン納品物（Figma・SVG・PNG等）とプログラム納品物（リポジトリ・ビルド成果物・ドキュメント）を別箇条で列挙します。
「ソース一式」だけではデザイン原盤が含まれるか不明です。

3-2. 修正回数とバグ修正を分ける

デザインのテイスト修正と、プログラムの不具合修正はコスト構造が違います。
修正回数の上限は修正回数の限度の考え方を流用できます。

3-3. アジャイルでもマイルストーン明示

スプリント単位でも、各スプリントの給付内容と代金額（または算定方式）を明示する運用が必要です。
PoCと本番の契約分割はPoCと本番の契約分割を参照してください。

4. 検収と支払期日

デザインは「最終カンプ承認」、プログラムは「受入テスト合格」など、完了定義を分けます。
段階納品がある場合は部分検収のルールを先に決め、60日計算の起算を行ごとに持たせます。
段階納品は段階納品と部分検収、期日は支払60日ルールを確認してください。

5. セキュリティ診断・運用の混在

開発委託にペンテストや運用監視が付く場合、情報成果物の作成と役務提供がさらに混在します。
診断はセキュリティ診断委託、運用SLAはシステム運用SLA委託で別記事化しています。

6. 境界チェックリスト

• 納品物リストがデザイン／プログラムで分かれているか
• 検収定義が成果物ごとに書かれているか
• 著作権・利用許諾の対象範囲が明確か
• 修正回数とバグ修正の扱いが分かれているか
• 明示事項テンプレで抜けがないか

明示事項は記載事項テンプレートで突合してください。

7. 境界が争点になる会話例

7-1. 「デザイン修正」か「実装バグ」か

受託側が「カンプどおりに実装した」、発注側が「見た目が違うので無償修正」と主張する争いは典型です。
事前にデザイン承認の版と実装受入のチェックリストを分けておけば、どちら側の費用かが決まりやすくなります。
会話ログだけに頼らず、発注書の修正回数条項を根拠にできます。

7-2. デザインシステムのコード化

トークン定義やコンポーネントライブラリは、見た目の成果物であると同時に再利用可能なプログラム資産です。
納品物リストに「Figma」「Storybook」「パッケージ名」を併記し、権利帰属をどちらに置くかを明示します。
社内他案件への転用可否も、デザインとプログラムで条件が違うことが多いです。

7-3. AI生成素材の混在

生成AIで作った画像と、手書きコードの実装が同じ納品物に入る場合、利用許諾の確認範囲が広がります。
デザイン側のライセンス条項と、プログラム側のOSSライセンスを別紙で管理してください。

8. 検収チェックの二系統化

デザイン検収は解像度・カラー・余白・ブランドガイド適合を見ます。
プログラム検収は機能要件・非機能・セキュリティ・回帰テストを見ます。
同じ担当者が両方を見る場合でも、チェックリストは2枚に分け、合格印を別に押します。
片方だけ合格のまま支払うと、もう片方の未完了が埋もれます。

9. 契約書の権利条項テンプレ要点

著作権譲渡・利用許諾・二次利用・クレジット表記を、デザイン成果物とプログラム成果物で分けて書きます。
「本件成果物一切」一語だと、原盤データや社内ツールまで含まれる解釈争いが起きます。
除外物（受託側の汎用ライブラリ、第三者が権利を持つ素材）を明示すると紛争が減ります。
変更管理の手順も、デザイン変更と仕様変更で承認者を分けると現場が動きやすいです。

10. キックオフで決める境界アジェンダ

キックオフの最初30分で、納品物リスト・検収責任者・修正回数・権利帰属・コミュニケーションツールをデザイン／プログラムの2列で確認します。
曖昧なままスプリントに入ると、境界争いは必ず後半に増幅します。
議事録には合意した境界と未決事項を分けて書き、未決には決定期限を付けます。
未決のまま着手した作業は、費用負担の暫定ルール（どちらが持つ仮置きか）も決めておきます。
外部のデザイン会社と実装会社が別なら、二者間の受渡し定義を発注側が仲介して文書化します。
仲介を省略すると、発注側が両方の解釈違いの尻拭いをすることになります。

11. 定着のための追加メモ

境界メモは契約時だけでなく、中間レビューでも見直します。スコープが増えるたびにデザイン行とプログラム行のどちらへ載せるかを決め、曖昧な追加は差戻します。特にデザインQAと実装QAが同じチャットに流れると責任分界が溶けるため、スレッドまたはラベルを分けてください。

よくある質問

Q. CSSだけの実装はデザインですか

見た目の再現でも、再現可能なコードとして納品するならプログラム要素が強いです。
発注書では「デザインデータ」と「実装コード」を分けて記載するのが無難です。

Q. ECサイト構築はどちらに寄せるか

テーマ調整中心ならデザイン寄り、カート・決済・在庫連携ならプログラム寄りです。
EC構築はECサイト構築委託も参照してください。

Q. 写真・動画制作との違いは

撮影・編集は情報成果物でもプログラムではないことが多いです。
納品・検収は写真・動画の納品検収を参照してください。

Q. QAテストだけ外注する場合は

テスト役務として切る方が明確です。
ソフトウェアテスト・QA委託の整理を使ってください。

Q. トリカク（torikaku） での推奨タグは

案件に「デザイン」「プログラム」のタグを併記し、完了日と支払期日を行分割で持つ運用が扱いやすいです。

まとめ

• 一式見積でも納品物と検収をデザイン／プログラムで分ける
• 修正とバグ、権利帰属の書き方も境界に沿って整理する
• 段階納品では起算を行ごとに持つ
• 診断・運用が付くならさらに役務行を分離する

注意

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