Webサービスやスマホアプリの開発を外部へ依頼するときは、契約書の条文だけ読んでも十分ではありません。実際に揉めやすいのは、「どこまでが見積内か」「仕様変更はどう扱うか」「納品後に自社で改修や他社移管ができるか」「個人情報や本番データをどこまで渡してよいか」といった、見積書・仕様書・SOW・保守条件までまたがる論点です。契約書に問題がなく見えても、添付文書が曖昧だと、追加費用や責任分担で認識ずれが起きやすくなります。
この記事では、Webサービス・スマホアプリ開発を外部へ依頼する前に、何をどの順番で確認すべきかを整理します。読後には、契約条件を「そのまま進める」「修正依頼する」「法務・情シス・調達へ確認する」の3段階で判断し、次に回すべき社内担当や、修正依頼に入れるべき論点を具体的に決めやすくなります。
この記事で見るのは、契約書そのものの良し悪しだけではありません。見積書、仕様書・要件定義書、SOW、発注書、保守条件書まで突き合わせて、発注判断に使える状態かを確認します。
この記事で見るのは、契約書そのものの良し悪しだけではありません。見積書、仕様書・要件定義書、SOW、発注書、保守条件書まで突き合わせて、発注判断に使える状態かを確認します。
契約確認は契約書本文だけでなく、見積書・仕様書・SOW・発注書・保守条件書まで並べて見ると、どこに認識ずれがあるかを把握しやすくなります。
01Sectionまず何をそろえて見ればよいか
最初に押さえたいのは、開発委託の確認対象が契約書本文だけではないという点です。IPAの情報システム・モデル取引・契約書や経済産業省のモデル契約概要資料でも、仕様、変更管理、検収、保守運用まで含めて整理する前提が示されています。実務では、文書ごとの役割を分けて読み、互いに矛盾していないかを確認するのが基本です。
この記事は発注前の実務判断を進めるための整理です。個別契約の適否は、案件の規模、扱うデータ、利用規模、社内規程によって変わるため、強い責任制限や情報管理条件がある案件では専門部門確認を前提にしてください。
この記事は発注前の実務判断を進めるための整理です。個別契約の適否は、案件の規模、扱うデータ、利用規模、社内規程によって変わるため、強い責任制限や情報管理条件がある案件では専門部門確認を前提にしてください。
契約書だけで終わらない理由
契約書に「開発一式」と書かれていても、見積書には対象外作業が細かく書かれ、仕様書には受入基準がなく、保守条件書にはリリース後の窓口がない、ということは珍しくありません。この状態では、条文が整っていても実務判断ができません。
特に確認したいのは、次の6種類の文書です。
文書ごとの役割
見積書
対象範囲、対象外作業、前提条件、追加費用が発生しやすい条件、支払条件を見る文書。最初にズレが出やすい。
仕様書・要件定義書
対象機能、画面、API、データ要件、非機能要件、受入基準の土台を確認する文書。
SOW（作業範囲定義書）
誰がどこまで担当するかを整理する文書。発注側作業、委託先作業、工程範囲の境界を確認しやすい。
契約書本文
契約類型、変更管理、責任上限、権利、秘密保持、再委託、解除、終了後対応を定める中心文書。
発注書・個別契約
どの見積書・仕様書・版番号を発注対象にするかを確定させる文書。参照先が曖昧だと後で争点になりやすい。
保守条件書・運用ルール
リリース後の窓口、監視、障害対応、権限管理、返還・削除・移管条件を確認する文書。
発注判断の3分類で一次判定する
詳細に入る前に、案件を「そのまま進める」「修正依頼する」「法務・情シス・調達へ確認する」の3分類で一次判定すると、止めるべき箇所が見えやすくなります。
| 判定 | 典型条件 | 次アクション |
|---|---|---|
| そのまま進める | 契約範囲、変更ルール、権利、検収、情報管理、保守条件が文書間でおおむね一致している | 最新版一式をそろえて発注起案へ進む |
| 修正依頼する | 「一式」表記が多い、対象外作業が不明、追加費用条件や移管物が曖昧 | 質問票を返し、見積書・仕様書・契約書の修正版を再確認する |
| 法務・情シス・調達へ確認する | 本番データ利用、再委託、国外利用、委託先名義アカウント、強い責任制限がある | 専門部門の確認完了まで発注判断を留保する |
先に止めるべき赤信号
見積書や仕様書の段階で次の状態があるなら、契約書の細部を見る前に差し戻したほうが効率的です。
- 「開発一式」「保守一式」で、対象機能や対象外作業が読めない
- 発注側が何を準備するか書かれていない
- 変更時の承認者や証跡が決まっていない
- ソースコードや管理権限の引継ぎ条件が不明
- リリース後の保守開始日や障害窓口が未定
見積書・仕様書・契約書・保守条件書で前提がつながっていない案件は、条文単体でよく見えても進めないほうが安全です。
見積書・仕様書・契約書・保守条件書で前提がつながっていない案件は、条文単体でよく見えても進めないほうが安全です。
02Section契約範囲と契約類型はどこを見ればよいか
最初の主要リスクは、何が契約内で、何が対象外かが曖昧なまま進むことです。範囲が曖昧だと、途中で追加費用が出るだけでなく、納期遅延の責任分担もぼやけます。
対象機能・対象外作業・発注側作業を切り分ける
最低限、次の3点は分けて読める状態にしておきたいところです。
- 対象機能：何を作るのか。画面、API、管理画面、バッチ、通知、連携など。
- 対象外作業：何は含まれないのか。データ移行、追加テスト、外部連携先との調整、ストア審査差戻し対応など。
- 発注側作業：何を自社が用意するのか。素材、文言、マスタデータ、検証端末、外部サービス契約、受入テスト担当者など。
確認しやすいのは、「対象」「対象外」「発注側対応」が別々に記載されている状態です。「必要に応じて協議」「詳細は別途」だけで締結に進むと、後で作業分担の解釈が割れやすくなります。
工程ごとに見るべき契約類型の違い
システム開発では、契約名だけで判断しないことが大切です。民法の整理を前提にすると、請負は完成責任が中心、準委任は業務遂行や役務提供が中心です。ただし、実務では要件定義支援やPMは準委任、実装や納品は請負、保守は準委任寄り、というように工程ごとに混在しやすくなります。
見分けるときは、契約名より本文の記載を見ます。
- 請負寄りなら、「完成」「納品」「検収」「契約不適合」といった語が出やすい
- 準委任寄りなら、「業務遂行」「作業報告」「月額稼働」「善管注意義務」といった語が出やすい
- 実装部分が請負でも、要件整理や保守は別契約で準委任になることがある
ここでいう検収とは、納品物が受入基準を満たすか確認して受け入れることです。完成責任の有無や検収の扱いは、後の変更管理や責任範囲にも直結します。
最低限ここまで書かれていれば確認しやすい
範囲確認で最低限ほしいのは、次の粒度です。
- 対象機能が機能単位で読める
- 対象外作業が具体名で書かれている
- 発注側が出す素材・情報・確認担当が明記されている
- 工程範囲が、要件定義・設計・実装・テスト・保守のどこまでか分かる
- 契約類型を判断できる語句が本文や個別契約に入っている
03Section変更管理と追加費用はどう決めるべきか
変更時に見るべきポイントを流れで整理すると、追加要望なのか、当初範囲の補正なのかを切り分けやすくなります。
開発委託では、変更が起きない前提で進めるより、変更が起きたときにどう扱うかを先に決めておくほうが安全です。経済産業省のモデル契約追補版解説でも、口頭合意ではなく、変更要求から契約反映まで手続化する考え方が示されています。
変更管理の6ステップ
実務では、次の順番で証跡を残せる形が確認しやすいです。
- 変更要求を起票する：誰の依頼か、背景、希望時期、優先度を明確にする
- 影響分析をする：対象機能、工数、納期、品質、セキュリティ、外部連携への影響を見る
- 再見積を出す：追加費用、前提条件、対象外、納期改定案を明文化する
- 承認する：事業部、予算責任者、必要に応じて法務・調達が承認する
- 契約と仕様に反映する：改定見積、改定仕様、注文書改定などで正式化する
- 完了確認をする：変更後のテスト結果と受入記録を残す
最低限の確認基準は、「誰が依頼した変更か」「何に影響するか」「いくら・いつまでに変わるか」「誰が承認したか」が後から追えることです。
未実装・不具合・追加要望の境界
ここを曖昧にすると、無償修正と追加見積の境界が崩れます。契約不適合とは、納品物や業務結果が契約書や仕様書どおりでない状態を指します。実務では、まず次の表で一次判定すると整理しやすくなります。
| 区分 | 当初資料に書いてあったか | 典型例 | 費用の考え方 | 主な確認先 |
|---|---|---|---|---|
| 未実装 | 書いてあったのに存在しない | 仕様書にあるCSV出力画面が納品版にない | 当初範囲内として無償補正の対象になりやすい | 事業部、PM |
| 不具合 | 書いてあり実装もあるが期待どおり動かない | ログイン画面はあるが正しいID・PWでも入れない | 契約不適合や無償修正の対象になりやすい | QA、PM、事業部 |
| 追加要望 | 当初資料にない、または期待水準が後から上がった | 当初はメール認証だけだったが、後から多要素認証を追加したい | 追加見積と納期改定の対象になりやすい | 事業部、予算責任者、調達 |
境界で迷うときは、仕様書、議事録、変更要求票、テスト結果などの証跡を優先します。公開情報だけでは同じ条件で費用比較が難しいため、最終的には「何が当初合意か」を文書で確認する必要があります。
見積外になりやすい作業をどう確認するか
追加費用が出やすいのは、機能追加そのものだけではありません。たとえば次の作業は、見積条件次第で対象外になりやすい部分です。
- ストア申請支援や審査差戻し対応
- 外部API連携先との調整
- 本番反映や夜間休日作業
- 追加テストや脆弱性対応
- 解約時の移管支援や説明会対応
これらは金額よりも、何回まで含むか、どこから有償か、誰の承認で進めるかを確認するほうが実務的です。
04Section成果物・権利・アカウントはどう確保するか
著作権条項だけでなく、実際に受け取る成果物と管理権限までそろっているかを確認すると、保守継続や他社移管で止まりにくくなります。
納品後に自社で改修や他社移管ができるかは、著作権条項だけでは決まりません。重要なのは、権利、実際に受け取る成果物、運用に必要な管理権限がそろっているかです。
他社移管を見据えるなら、先に確認したいのは「ソースコードなどの納品物」「管理権限」「アカウント主体」の3点です。どれか1つ欠けても、実務上は移管しにくくなります。
他社移管を見据えるなら、先に確認したいのは「ソースコードなどの納品物」「管理権限」「アカウント主体」の3点です。どれか1つ欠けても、実務上は移管しにくくなります。
著作権・利用許諾・再利用部品をどう見るか
文化庁の著作権契約マニュアルでは、著作権は当然に発注者へ移るとは限らず、譲渡か利用許諾かを契約で明記する必要があることが整理されています。二次的著作物に関する権利まで含めるなら、27条・28条の扱いを条文上どう書くかも確認ポイントです。
ただし、譲渡や利用許諾の条文があっても、ソースコード、Figmaの元データ、API仕様、DB定義、インフラ構成、テスト結果が渡らなければ、後続ベンダーは実務上かなり困ります。
少なくとも次が文書で一致しているか確認します。
- 何が納品物か
- 何が権利移転の対象か、または利用許諾の対象か
- 委託先の再利用部品と個別開発部分の境界
- 第三者素材やフォント、画像の利用条件
- OSSの利用有無、主要ライセンス、部品一覧やSBOMの有無
OSSはオープンソースソフトウェア、SBOMは利用しているソフト部品とバージョンの一覧です。IPAのOSSガイドブックも確認先になります。
ソースコード、元データ、管理権限を一体で確認する
実務で抜けやすいのは、著作権ではなく管理権限です。次のようなものは、契約条項ではなく納品物一覧や引継条件で具体化したい部分です。
- リポジトリの管理者権限
- クラウド環境の管理者権限やIAM設定
- ドメイン、DNS、証明書の管理権限
- デザイン元データや素材一覧
- 監視設定、バックアップ設定、CI/CD関連設定
「必要に応じて引き渡す」では確認しにくいため、受領有無、形式、引渡時期、管理者変更の方法まで書かれていると実務で迷いません。
スマホアプリで追加確認したいアカウント論点
スマホアプリでは、成果物の受渡しだけでなく、ストアアカウントの主体が重要です。Appleのアプリ移管概要やGoogle Play Consoleのアプリ移管案内を見ると、アプリ移管は単にファイルをもらえば済む話ではなく、アカウント主体や移管条件の整理が必要です。
そのため、アプリ案件では次を先に確認します。
- Apple/Googleのアカウント主体は自社か委託先か
- 管理者権限を誰が持つか
- 署名鍵や配布証明書に関わる情報をどう管理するか
- 移管時に何が引き継がれ、何は別途整理が必要か
委託先名義アカウントのまま進める案件は、更新継続や他社移管で止まりやすいため、事業部だけで判断せず確認したほうが安全です。
05Section検収・不具合修正・責任範囲はどこまで明確にすべきか
品質トラブルを避けるには、検収条項だけを見るのではなく、仕様、テスト計画、既知不具合一覧、責任条項までつなげて確認します。JISAの業務委託契約運用ガイドラインや民法を踏まえても、納品・受入・責任分担は一体で見たほうが判断しやすくなります。
検収基準と検収期間を先に確認する
検収で先に見たいのは、日数そのものより、起算日、確認環境、合否基準、未回答時の扱いです。
- 起算日がいつか
- 営業日か暦日か
- どの環境・端末・接続先で確認するか
- 何を満たせば受入とするか
- 期限までに回答がない場合の扱い
「納品後速やかに確認する」「正常に動作すること」だけでは、合否基準が主観的になりやすくなります。
無償修正・契約不適合・追加対応の境界
ここでも大切なのは、受入基準と分類ルールを先に合わせることです。最低限、次がつながっていれば確認しやすくなります。
- 必須機能と非機能要件の受入基準
- 重大・中・軽微などの不具合分類
- 既知不具合を残して受け入れる条件
- 契約不適合の通知方法と通知期限
- 再検収が必要になる条件
検収期間が短い場合は、すべてを均等に見るより、優先順位を決めて確認します。
- ログイン、決済、会員登録、基幹連携など止まると業務停止する機能
- セキュリティや法令対応に関わる必須要件
- データ欠損や二重処理につながる整合性要件
- 外部APIや通知など障害化しやすい連携部分
- 納品物や権限がそろっているかという書類・引継面
責任上限と事故初動で止めるべき条件
責任上限や免責は固定値だけでは判断しにくく、案件規模、扱うデータ、業務停止時の影響、保険や代替手段の有無で妥当性が変わります。水準だけでなく、何が対象で何が除外されるかまで確認することが重要です。
止めて確認したいのは、たとえば次のような状態です。
- 個人情報、決済、基幹連携を扱うのに責任制限が強すぎる
- 事故時の一次報告先や初動手順が決まっていない
- 未回答で自動検収になるのに、受入基準が曖昧
- 契約不適合の通知期間だけあり、実際の補正方法が読めない
事故初動では、「誰に、どの手段で、どこまでを一次報告するか」まで決めておくと、障害や漏えい時の判断停滞を防ぎやすくなります。
06Section情報管理・再委託はどこで社内エスカレーションするか
情報管理の論点は、契約条件と運用条件を分けて確認し、一定条件に当てはまる場合は早めに専門部門へ回すと判断が進めやすくなります。
情報管理は、NDAがあるだけでは十分ではありません。個人情報保護委員会の通則ガイドラインでは、委託先監督や再委託管理、漏えい等への対応が重要な論点として整理されています。さらに、NISCの外部委託関連資料のように、契約条件と運用条件の両面で確認する考え方が実務では有効です。
まず、社内で誰が何を見るかを整理しておくと、確認漏れを防ぎやすくなります。
社内で誰が何を見るか
事業部・実務担当
どの情報を委託先へ渡す必要があるか、代替データで足りるか、業務上の必要性を見る。
PM・QA
受入環境、運用フロー、証跡管理、権限付与や剥奪の実務を確認する。
法務
秘密保持、個人情報、再委託、責任制限、返還・削除、権利制約を確認する。
情シス・セキュリティ
保存場所、アクセス権、ログ、端末利用、監査、事故初動、委託先名義アカウントの有無を見る。
調達・購買
契約構成、発注書の参照関係、再委託先一覧の取得、監査や報告義務の位置づけを確認する。
契約で最低限見るべき項目
契約条件としては、秘密情報の定義、利用範囲、再委託、事故報告、返還・削除まで一続きで読めるかが最低ラインです。
- 秘密情報・個人情報・本番データの定義
- 利用目的と利用範囲
- 保存場所、持出し制限、端末保存の可否
- 再委託の可否、事前承認や報告の方法
- 事故報告の連絡先と報告タイミング
- 契約終了時の返還・削除・削除証跡
国外利用や国外保管がある場合は、外国にある第三者への提供に関するガイドラインの確認が必要になることがあります。扱うデータや利用クラウドによっては、事業部単独で進めないほうがよい論点です。
運用で抜けやすい項目
契約条項が整っていても、運用ルールが弱いと事故時に機能しません。特に抜けやすいのは次の点です。
- 検証環境で本番データを使う条件
- 共有アカウントの禁止や権限剥奪手順
- ログ保全期間と閲覧権限
- チャットやチケットで機密情報を送るルール
- 事故時の一次連絡手段と連絡網
Webサービス案件では、IPAの安全なウェブサイトの作り方のような公的情報も、要件や運用ルールの確認先として役立ちます。
本番データ利用、再委託、国外利用、委託先名義クラウドやアカウントがある案件は、自分だけで判断しないほうが安全です。契約条件だけでなく、保存場所、権限、ログ、事故初動まで合わせて専門部門へ確認してください。
本番データ利用、再委託、国外利用、委託先名義クラウドやアカウントがある案件は、自分だけで判断しないほうが安全です。契約条件だけでなく、保存場所、権限、ログ、事故初動まで合わせて専門部門へ確認してください。
情報管理の社内確認チェックリスト
情報管理の社内確認チェックリスト
- ✓
個人情報や機密情報を扱うかを整理した
扱う情報の種類が曖昧なら、まず事業部で整理し、個人情報を含むなら法務や個人情報保護担当へ回す。
- ✓
本番データを検証や障害解析で使う条件を確認した
本番データを使う予定があるなら、情シス・セキュリティ確認を前提にする。
- ✓
再委託の有無と再委託先の管理方法を確認した
再委託先一覧、事前承認または報告条件がない場合は差し戻したい。
- ✓
国外利用や国外保管の有無を確認した
海外クラウドや海外拠点が関わるなら、社内規程とガイドラインに照らして確認する。
- ✓
委託先名義のクラウドやアカウントを使うか確認した
使う場合は、保守終了時の移管や権限返還まで含めて情シス確認が必要になりやすい。
- ✓
事故報告の連絡先、報告手段、初動の流れを確認した
「速やかに報告」だけでは運用で止まりやすい。誰にどう報告するかを具体化する。
- ✓
契約終了時の返還・削除・削除証跡を確認した
本番、検証、バックアップのどこまでが対象か分からない場合は、そのまま進めない。
07Section保守契約・終了条件・他社移管はどう備えるか
開発完了後に困る条件は、発注時にしか直しにくいものが多くあります。とくに保守の空白と移管物不足は、リリース後に初めて問題化しやすい論点です。経済産業省のモデル契約概要資料でも、保守運用や終了時の扱いまで含めて整理する考え方が参考になります。
保守契約未締結のままリリースしないほうが安全です。障害窓口、証明書更新、監視アラート、OSやSDK更新対応の担当が宙に浮きやすくなります。
保守契約未締結のままリリースしないほうが安全です。障害窓口、証明書更新、監視アラート、OSやSDK更新対応の担当が宙に浮きやすくなります。
保守開始日の空白を作らない
開発契約と保守契約を分ける場合でも、リリース日と保守開始日を切れ目なくつなげることが重要です。最低限、次が読めるか確認します。
- 保守の開始日と終了日
- 受付時間、一次応答、エスカレーション先
- 障害対応、監視、軽微改修、OS/SDK更新対応の範囲
- 対象外作業と追加費用が発生する条件
- 開発契約から保守契約へ移るときの引継ぎ条件
終了時に返してもらうものを具体化する
終了時は「返還する」で済ませず、何を、いつまでに、どの形式で返すかを分けて確認します。とくに削除は、本番だけでなく検証環境やバックアップの扱いまで見ないと判断しづらくなります。
移管時に不足しやすいものは次のとおりです。
移管時に不足しやすいもの
リポジトリ管理者権限
受け取ったコードがあっても、管理者権限がないとブランチ運用やCI/CD変更が止まりやすい。
クラウドIAM
本番設定変更、監視確認、権限追加ができず、障害調査が進まない原因になる。
ドメイン・証明書管理権限
更新期限切れや切替作業停止を防ぐため、登録主体と更新権限を確認したい。
Apple/Googleの管理者権限
アップデート申請、移管、審査対応を継続するために必要。委託先主体だと切替に時間がかかることがある。
運用手順書と連絡先一覧
障害時の連絡経路や日常運用が属人化しないよう、手順と担当先を残してもらう。
Appleのアプリ移管概要やGoogle Playの移管案内を見ると、アプリ移管では一部の設定や運用上の引継ぎを事前に整理する必要があります。アプリ案件は、成果物の受領よりもアカウント・権限・更新継続の設計が重要になる場面があります。
複数ベンダーを比較するときの見方
比較では価格だけでなく、移管しやすさと運用継続しやすさを横並びで見ます。
| 比較軸 | 赤信号 | 望ましい状態 |
|---|---|---|
| 契約範囲 | 一式表記だけで対象外作業が読めない | 対象・対象外・発注側作業が分かれている |
| 変更ルール | 都度協議のみで承認者や証跡がない | 起票、再見積、承認、文書反映が明文化されている |
| 権利・移管 | ソースコードや権限、アカウント主体が不明 | 納品物、権利、管理権限、アカウント主体が一致している |
| 検収・責任 | 受入基準が曖昧、自動検収だけ定めている | 受入基準、不具合分類、責任範囲がつながっている |
| 情報管理 | 再委託自由、監査や報告条件が弱い | 再委託管理、事故報告、返還・削除まで読める |
| 保守体制 | リリース後の窓口や開始日が不明 | 開始日、窓口、対象範囲、対象外作業が明記されている |
08Section発注前から契約締結前までの実務手順
実務では、発注前、見積受領後、契約締結前の3段階で不足文書と未確定条件をつぶすと進めやすくなります。
発注前から契約締結前までの3ステップ
- Step01
発注前に整理する
集める文書: 現行要件メモ、想定機能一覧、情報区分の整理メモ、社内確認先の一覧。 確認する論点: 対象範囲、対象外にしたい作業、個人情報や本番データの有無、将来の他社移管や内製化の予定。 社内確認先: 事業部、必要に応じて情シス・セキュリティ、法務。 完了条件: 委託先に渡す前に、何を頼み、何を自社で持つかが説明できる状態になっている。
- Step02
見積受領後に突合する
集める文書: 見積書、仕様書・要件定義書、SOW、提案書、保守条件書。 確認する論点: 対象機能、対象外作業、発注側作業、変更管理、追加費用条件、権利、アカウント主体、保守開始日。 社内確認先: 事業部、PM/QA、調達、必要に応じて法務・情シス。 完了条件: 未記載や曖昧な点が質問票として整理され、修正依頼先と期限が決まっている。
- Step03
契約締結前に反映する
集める文書: 契約書本文、個別契約・発注書、改定見積、改定仕様、運用ルール案。 確認する論点: 変更手続、検収基準、責任上限、再委託、返還・削除、移管物、管理権限、保守体制。 社内確認先: 法務、情シス・セキュリティ、調達、決裁者。 完了条件: 修正点が契約本文だけでなく添付資料にも反映され、どの版が正本かが明確になっている。
質問票に入れやすいのは、「対象外作業の具体名」「変更時の承認者」「ソースコードと元データの受領範囲」「再委託先の管理方法」「削除証跡の出し方」「保守開始日と終了時の引継支援」です。契約案受領後でも、この3ステップに沿って不足文書の回収から始められます。
よくある確認漏れQ&A
契約書に書かれていない内容は、どの文書まで正式条件として扱うべきですか？+
見積書、仕様書・要件定義書、SOW、発注書・個別契約、保守条件書まで含めて確認したほうが実務では安全です。特に、発注書がどの見積書や仕様書を参照しているかが曖昧だと、後で「どの条件で発注したか」が争点になりやすくなります。
検収期間が短いとき、何から優先確認すべきですか？+
業務停止につながるコア機能、セキュリティや法令対応の必須要件、データ整合性、外部連携、納品物と権限の受領状況の順で確認すると進めやすいです。期間の長短だけでなく、受入基準と判定者が明確かも重要です。
小規模案件でも省略しないほうがよい確認項目は何ですか？+
契約範囲、対象外作業、変更時の承認手順、成果物と権限の引継ぎ、情報管理、保守開始日の5点は省略しないほうが安全です。案件規模が小さくても、曖昧なまま進むと追加費用や運用停止の原因になります。
法務に先に回すべき論点と、事業部で整理してから回す論点はどう分ければよいですか？+
事業部で先に整理したいのは、対象範囲、対象外作業、発注側作業、変更要求の背景、将来の移管要否です。法務に早めに回したいのは、権利制約、強い責任制限、再委託、個人情報、本番データ利用、委託先名義アカウントがある案件です。
PartnerBase Mag 編集部
デジタル発注の比較・発注準備を専門に扱う編集チーム。
デジタル発注の比較・発注準備を専門に、依頼範囲、費用、選定基準を実務で使える粒度に整理しています。
支援会社を比較する
得意領域、対応サービス、地域、実績を見ながら候補会社を絞り込めます。
