発注前チェックリスト（契約・権利・データ・保守）

開発会社との打ち合わせも一通り終え、見積もりも取り、契約書のドラフトも届いた。あとはハンコを押すだけ——そこまで来て、ふと手が止まったことはないでしょうか。「本当にこのまま発注していいのか」「何か見落としているのではないか」という漠然とした不安は、ひとりで情シスや総務のIT担当を兼任している方であれば一度は感じたことがあるはずです。相談できる同僚も、答え合わせをしてくれる先輩情シスもいない中で、最終確認は自分ひとりで完結させなければなりません。

結論から言うと、発注直前に確認すべきことは、契約書の条文をただ読むことではなく、「契約」「権利」「データ」「保守」という4つの領域について、それぞれ何を確認しないと後で困るのかを理解した上でチェックすることです。単に項目を上から順にチェックしていくだけでは、「なぜこの項目が必要なのか」が分からないまま形だけの確認になり、いざ開発会社に質問すべき場面で言葉に詰まってしまいます。

この記事では、当メディアが公開しているチェックリスト「発注前チェックリスト」に挙げている確認項目のうち、特に見落とすと発注後のトラブルに直結しやすい項目を取り上げ、「なぜそのチェックが必要なのか」を1つずつ掘り下げて解説します。チェックリストは印刷して社内で使う一覧表として、この記事はその一覧表の「解説書」として、あわせて活用してください。

この記事で分かること

これまで要件のまとめ方、見積書の読み方、契約形態の選び方、検収の進め方といった各論を個別に学んできた方が、いよいよ発注という意思決定の直前に立ったとき、最後に何を確認すればよいのかを整理します。

• 発注前チェックリストの各項目が、なぜそこに存在するのか
• 契約書で見落とすと後戻りできなくなる条項はどこか
• 「権利」の確認を怠ると、将来どんな場面で困るのか
• データに関する取り決めが、契約書に一言もなかったらどうなるか
• 保守契約を発注時点で確認しておくべき理由
• チェックリストのどの項目を、誰に、どう質問すればよいか

一つずつ、順番に見ていきます。

なぜ「発注直前」にもう一度立ち止まる必要があるのか

要件を整理し、相見積もりを取り、開発会社を選び、契約形態も決めた——ここまでの工程を丁寧にこなしてきた担当者ほど、「あとは契約書にサインするだけ」という段階で気が緩みやすくなります。しかし、発注前の最終チェックが必要なのは、ここまでの工程がそれぞれ「個別の意思決定」であるのに対し、契約書へのサインはそれらすべてを一つの法的拘束力のある合意として固定する行為だからです。

• 要件のまとめ方が甘くても、契約前であれば追加のヒアリングで修正できる
• 見積もりの内訳に疑問があっても、契約前であれば聞き直せる
• しかし契約書にサインした後は、記載されていない内容を「言った・言わない」で争うことになる

つまり発注前の確認は、これまでの工程で詰め切れなかった論点を、契約という後戻りしにくい形にする前の最後の関門です。この関門を「なんとなく大丈夫そうだから」で通過させてしまうと、トラブルが起きたときに「あのとき確認しておけばよかった」と悔やむことになります。

以下、チェックリストの構成に沿って、契約・権利・データ・保守の4領域を順に見ていきます。

契約の確認：何が書かれているかより、何が書かれていないかを見る

契約書を確認するとき、多くの担当者は「書かれている内容」を読むことに注力しますが、実務上トラブルの原因になりやすいのは、むしろ「書かれていないこと」です。

まず前提として、システム開発の契約形態には大きく分けて請負契約と準委任契約の2種類があり、どちらを選ぶかによって「完成義務」の有無が変わります。この違いについては別記事で詳しく解説していますが、発注前チェックの観点で重要なのは、契約書に記載された契約形態が、実際の開発の進め方と一致しているかという点です。

例えば、仕様が固まりきっていない段階から開発を始める、いわゆるアジャイル的な進め方をするにもかかわらず、契約書上は請負契約（完成義務あり）になっているケースがあります。この場合、「何をもって完成とするか」の基準が曖昧なまま契約が進み、検収の段階で発注者と開発会社の認識がずれるリスクが高まります。

契約書を確認する際は、次の観点でチェックしてみてください。

• 作業範囲（SOW（作業範囲記述書））が、口頭で説明された内容と一致しているか：見積もり時に説明を受けた機能一覧が、契約書または添付の仕様書に具体的に記載されているか
• 納期の起算点と、遅延時の扱いが書かれているか：「〇月〇日納品」だけでなく、発注者側の確認作業の遅れが納期にどう影響するかまで書かれているか
• 追加費用が発生する条件が明記されているか：「仕様変更」「追加開発」の定義が曖昧なまま契約すると、後から「これは追加費用です」と言われても反論しづらくなる
• 契約不適合責任の期間・範囲が記載されているか：民法上のデフォルトルールと異なる独自の定め（期間短縮など）が契約書にないか

特に最後の契約不適合責任については、契約書に何も記載がなければ民法の規定が適用されますが、契約書側で発注者に不利な形で期間を短縮している例も見られます。読み飛ばしがちな条項ですが、納品後に不具合が見つかったときの対応スピードを左右する重要な部分です。

「見積もり時の説明」と「契約書の記載」が食い違っている場合、後で有効になるのは契約書に書かれた内容です。口頭やメールでのやり取りだけで安心せず、重要な合意事項は契約書または正式な仕様書に反映されているかを必ず確認してください。

なぜ「言った・言わない」が起きるのか。作業範囲の書き方の落とし穴

契約トラブルの多くは、悪意のある開発会社によって引き起こされるわけではなく、単に「何を作るか」の解像度が発注者と開発会社の間でずれていたことが原因で起きます。

例えば、「在庫管理システムを作ってほしい」という要望に対して、開発会社側は「入力・一覧表示・検索」までを想定していたが、発注者側は「発注点を下回ったら自動でメール通知が来る」機能も当然含まれていると思い込んでいた、というようなケースです。この機能追加は些細に見えますが、実装には設計・開発・テストの工数が新たに発生するため、開発会社からすれば「契約外の追加要望」になります。

このようなズレを防ぐために確認すべきなのが、契約書に添付される仕様書やSOWの具体性です。

すべての機能を高いレベルまで詰めてから契約する必要はありませんが、少なくとも「今回の契約に何が含まれ、何が含まれないか」の境界線は、契約前に開発会社と言葉にして確認しておくべきです。この境界線があいまいなまま契約すると、開発の途中で「これは追加費用です」「いえ、最初から含まれているはずです」という水掛け論が発生し、スケジュールの遅延にも直結します。

権利の確認：完成後に「誰のものか」で揉めないために

発注前チェックリストで見落とされがちなのが、納品物の権利関係の確認です。多くの担当者は「お金を払って作ってもらうのだから、当然すべて自社のもの」と考えがちですが、これは法律上、必ずしも正しくありません。

ソースコードなどの成果物には著作権が発生し、対価を支払っただけでは著作権そのものが自動的に発注者に移転するわけではありません。契約書に著作権の譲渡について明記されていない場合、原則として著作権は制作者である開発会社側に残ります。この点は別記事「ソースコードの著作権は誰のもの？契約書の確認ポイント」で詳しく解説していますが、発注前チェックの観点で押さえておくべきは次の3点です。

• 著作権の譲渡・利用許諾のどちらの契約になっているか：譲渡であれば自社が著作権者になり、他社への乗り換えや改修の自由度が高い。利用許諾（ライセンス）であれば、開発会社の許可なく他社に改修を依頼できない場合がある
• ソースコード一式が納品物に含まれているか：画面が動いているだけでなく、ソースコード（プログラムの設計図にあたるファイル一式）そのものが納品されるかどうかは、契約書に明記されていないと開発会社の裁量に委ねられる
• 将来、他社に乗り換える可能性を見込んでいるか：将来的な乗り換えを想定していない小規模なツールであれば著作権譲渡にこだわらない選択もあり得ますが、基幹に近いシステムであれば譲渡を求めるか、少なくとも改修の余地を契約書で確保しておくべきです

なぜこの確認が発注前に必要かというと、著作権の帰属や納品物の範囲は、契約書に明記されて初めて確定する事項であり、発注後に「やっぱりソースコードもください」と言っても、開発会社が応じる義務はないためです。契約書の締結前であれば交渉の余地がありますが、締結後に条件を変えることは難しくなります。

この権利関係を軽視した結果として起きるのが、いわゆるベンダーロックインです。著作権が開発会社側に残ったまま、かつソースコードも納品されていない状態だと、その開発会社以外に改修を依頼できなくなり、保守費用の値上げにも応じざるを得なくなります。発注時点でこの確認を怠ると、数年後に選択肢そのものが消えてしまうという点で、権利の確認は契約書の他の条項以上に「後から取り返しがつきにくい」項目だと言えます。

ライセンス（利用許諾）の範囲も忘れずに確認する

著作権とは別に、開発に使われる既製のソフトウェア・部品（オープンソースソフトウェアやクラウドサービスのAPI等）のライセンス条件も、可能な範囲で確認しておきたいポイントです。特に、月額利用料が発生するクラウドサービス上に構築される場合、そのサービスの利用契約が発注者名義になるのか、開発会社名義のまま利用させてもらう形になるのかは、将来の運用コストや乗り換えのしやすさに直結します。開発会社名義のままだと、契約更新やアカウント管理を発注者側でコントロールできない、という状況が起こり得るため、可能であれば発注者自身の名義で契約できないか確認しておくとよいでしょう。

データの確認：契約書に一言もないと、何が起きるか

3つ目の確認領域が、システムが将来蓄積することになるデータの扱いです。発注前の段階では、まだデータが存在しないため見落とされがちですが、運用を始めてから数年後にこそ効いてくる論点です。

具体的に確認すべきなのは、次のような項目です。

• データのエクスポート機能があるか：蓄積したデータをCSVなど汎用的な形式で書き出せる機能が、システムの標準機能として用意されているか。それとも「必要になったら追加費用で対応します」という扱いになっているか
• データそのものの所有権について契約書に記載があるか：業務で入力したデータ（顧客情報・取引履歴など）は、多くの場合データ自体には著作権が発生しませんが、契約書によっては開発会社側の利用範囲やアクセス権について独自の定めがある場合があります
• 保守契約が終了・解約された場合、データはどうなるか：保守契約の終了後もデータへのアクセスが継続できるか、それともシステムの利用自体ができなくなり、データも合わせて失われるのか

これらを契約前に確認しない場合、何が起きるのでしょうか。典型的なのは、数年後にこのシステムから別のシステムへ乗り換えようとした際、「データを書き出す機能がそもそもない」「開発会社に依頼すると高額な追加費用がかかる」という状況に直面するケースです。データポータビリティ（自社のデータを他のサービスでも使える形式で持ち出せる度合い）が低いシステムほど、乗り換えの際のハードルが上がり、結果として本来なら乗り換えたい状況でも、費用を理由に乗り換えを断念せざるを得なくなります。

データのエクスポート機能は、システムが正常に稼働している間は「使う機会のない機能」に見えます。しかし、乗り換えや業者変更を検討する段階になって初めて、その有無が致命的な差になって表れます。発注前の段階でこそ、「将来使わないかもしれない機能」として軽視せず確認しておくべき項目です。

データのバックアップ体制についても、開発時点で確認しておくべきことがあります。開発会社が提供するインフラ上にシステムを構築する場合、バックアップの取得頻度・保存期間・復旧にかかる時間の目安が契約書または仕様書に明記されているかを確認してください。「バックアップは取っています」という口頭説明だけでは、実際に障害が起きたときにどこまで復旧できるかが分かりません。

保守の確認：発注時点で聞いておかないと、あとで交渉力を失う

発注前チェックリストのもう一つの重要領域が、保守契約の内容です。開発契約とは別の契約であることも多いため、「まずは開発を進めて、保守は納品後に考えよう」と後回しにされがちですが、これは避けるべきタイミングの選び方です。

理由は単純で、発注前は開発会社にとって発注者が「選ぶ側」の立場にあるのに対し、発注後は発注者がそのシステムに依存する「選ばれる側」に立場が逆転するためです。契約前であれば、保守費用の相場観を他社と比較しながら交渉できますが、システムが完成し、その会社にしか改修できない状態になってから保守費用を提示されると、多少高くても受け入れざるを得なくなります。

発注前に確認しておきたい保守契約の項目は、次の通りです。

• 対応範囲の境界線：不具合修正は無償、軽微な仕様変更は有償、といった線引きが具体的に決まっているか
• SLA（サービス品質保証）（対応時間の目安）：障害発生時、何時間以内に一次対応が始まるのか。休日・夜間の対応可否も含めて確認する
• 料金体系：月額固定か、都度見積もりか、時間単価制か。おおよその年間コストを試算できる材料があるか
• エスカレーションのルート：現場担当者では対応しきれない障害が起きた際、誰にどう連絡が引き継がれるのか
• 契約期間と解約条件：自動更新の有無、解約の申し出に必要な予告期間

これらは保守契約書そのものに記載されるべき内容ですが、開発契約を結ぶ前の打ち合わせの段階で、おおよその方針を確認しておくことが重要です。発注前にこの確認を怠ると、システムが稼働し始めてから初めて保守費用の実額を知り、「思っていたより高い」と感じても、他社への乗り換えコスト（前述の権利・データの問題と直結します）を考えると交渉の余地がほとんど残っていない、という状況に陥りやすくなります。

チェックリストの各項目を、誰にどう質問すればよいか

ここまで解説してきた内容を踏まえて、発注前チェックリストの各項目を実際にどう使えばよいかを整理します。チェックリストは大きく「要件を整理できているか」「開発会社を選ぶ前に」「社内で決めておくこと」の3セクションに分かれていますが、この記事で解説した契約・権利・データ・保守の論点は、主に2番目の「開発会社を選ぶ前に」セクションに対応します。

このセクションの各項目について、実際に開発会社へ投げかけるとよい質問の例を挙げます。

• 「契約形態（請負／準委任）の違いを理解している」→ 開発会社へ：「今回の開発は請負と準委任のどちらの契約になりますか。その理由も教えてください」
• 「納品物（ソースコード等）の権利の所在を確認する予定である」→ 開発会社へ：「納品物の著作権は譲渡いただけますか。難しい場合、改修の際にどのような制約がありますか」
• 「保守・運用費用がいくらかかるか見積もりに含めて確認する予定である」→ 開発会社へ：「保守契約のSLAと料金の目安を、開発契約と合わせて提示していただけますか」

このように、チェックリストの項目を「はい／いいえ」で自己完結させるのではなく、開発会社への具体的な質問に翻訳して使うことで、初めて実効性のある確認作業になります。単に項目にチェックを入れて満足するのではなく、チェックがつかなかった項目について、次の打ち合わせで何を聞くかを準備する、という使い方をおすすめします。

発注前チェックがすべて完璧でなくても、発注してよいのか

ここまで読むと、「これだけ確認することがあると、いつまで経っても発注できないのではないか」と感じるかもしれません。結論として、すべての項目が100点である必要はありません。

重要なのは、次の2点を区別することです。

1. 契約前でなければ実質的に交渉できない項目（著作権の帰属、保守費用の相場感、作業範囲の境界線など）→ ここは可能な限り発注前に詰める
2. 契約後・運用開始後でも調整の余地がある項目（細かい画面デザインの好み、優先度の低い追加機能など）→ ここは走りながら調整してよい

すべてを完璧に詰め切ろうとして発注が半年遅れるよりも、取り返しがつきにくい項目（権利・保守費用・作業範囲の境界）だけは妥協せず確認し、それ以外は開発を進めながら調整するという割り切りも、実務上は現実的な判断です。逆に言えば、権利・データ・保守の3領域は、走りながら調整することが難しい、つまり「発注前にしか確認できない」領域だからこそ、この記事で重点的に取り上げています。

社内の決裁プロセスとチェックリストをどう連動させるか

発注前チェックリストは、開発会社との確認だけでなく、社内の決裁プロセスとも密接に関わります。特にひとりで情シスや総務を兼任している場合、システム導入の稟議を自分で起案し、IT分野に詳しくない決裁者（経営層や他部署の管理職）に説明する立場になることが多いはずです。

このとき、チェックリストの3番目のセクション「社内で決めておくこと」が効いてきます。

• 発注の意思決定者が明確になっているか：最終的に「発注する」と判断するのが誰なのかが曖昧なまま話を進めると、契約直前になって「そもそも聞いていない」という声が上がり、土壇場で差し戻しになるリスクがあります
• 窓口担当者を決めているか：開発会社とのやり取りが複数人に分散すると、「言った・言わない」が社内側でも発生しやすくなります。窓口を一本化し、決定事項は必ずその担当者を経由して記録する運用にしておくと、後からの確認が格段に楽になります
• 検収の基準を決める予定になっているか：これは前述の「契約」の確認と表裏一体です。社内的に「何が完成したら支払ってよいか」の基準を、発注前の段階でうっすらとでも共有しておくと、検収時に一人で抱え込まずに済みます

決裁者への説明では、この記事で解説した「権利」「データ」「保守」の論点を、金額の話とセットで伝えると納得を得やすくなります。例えば「初期費用は安いが、著作権が開発会社に残るため、将来他社に切り替える際に追加のコストがかかる可能性がある」というように、目先の金額と将来のリスクを一緒に提示することで、単なる「安いから」「知っている会社だから」という判断を避けやすくなります。

なお、費用面でIT導入補助金の活用を検討している場合、対象となるツールや申請要件が年度ごとに変わる点には注意が必要です。補助金の活用を前提に予算計画を立てる場合は、契約前に最新の公募要領を確認し、対象外の支出がないかを開発会社とも共有しておくことをおすすめします。

発注前チェックで見落としやすい5つの落とし穴

これまで解説してきた内容を踏まえ、実務でつまずきやすい落とし穴を5つにまとめます。チェックリストを埋める際に、次の視点も併せて意識してみてください。

1. 「見積書に書いてあるから大丈夫」という思い込み：見積書はあくまで金額の内訳であり、権利の帰属やデータの扱いまでは記載されていないことがほとんどです。見積書の内訳の読み方は別記事で解説していますが、金額の妥当性と契約条件の妥当性は別々に確認する必要があります
2. 担当者個人の説明を、契約書の記載と同一視してしまう：営業担当や開発担当が口頭で「大丈夫です」と答えた内容が、実際には契約書に反映されていないケースは珍しくありません。重要な合意は必ず書面（メールでも可）に残すよう依頼してください
3. 保守契約の内容を、開発契約が終わってから確認しようとする：前述の通り、発注後は交渉力が大きく低下します。保守の方針は開発契約と同時か、それ以前に確認しておくべきです
4. データのエクスポート機能を「今は不要」と判断してしまう：発注時点でエクスポート機能の必要性を感じにくいのは当然ですが、必要性は数年後の状況変化（他社への乗り換え、M&A、規制対応など）によって突然生じます。将来のコストとして事前に見積もっておく方が安全です
5. チェックリストを「埋めること」自体が目的化してしまう：全項目にチェックが入ったことに安心し、なぜその項目が重要だったのかを理解しないまま発注してしまうと、実際にトラブルが起きたときに何を根拠に交渉すればよいか分からなくなります。この記事で解説した「なぜ」の部分こそ、チェックリストの本体だと捉えてください

これらの落とし穴は、いずれも「発注前にしか対処できない」という共通点を持っています。発注後に気づいても、契約書の条文や開発会社との力関係が変わってしまっているため、同じ交渉はできません。だからこそ、発注直前のこのタイミングで、面倒でも一つずつ確認する価値があります。

まとめ：発注前チェックは「後戻りできない項目」を優先する

発注前チェックリストの各項目は、単なる作業手順の確認ではなく、契約書にサインした後は交渉の余地がなくなる事項を、サインする前に確認しておくための最後の機会です。特に次の3点は、発注後に気づいても取り返しがつきにくいため、優先的に確認してください。

• 納品物の著作権・ソースコードの取り扱いが契約書に明記されているか
• データのエクスポート機能・所有権の扱いが確認できているか
• 保守契約の対応範囲・SLA・料金体系のおおよその方針を、開発契約前に聞けているか

この記事とチェックリストを手元に置きながら、開発会社との最終打ち合わせに臨んでみてください。1社だけの説明を鵜呑みにせず、可能であれば複数社の回答を比較することで、「この業界ではこれが標準的な条件なのか、それともこの会社が特殊なのか」を判断する材料にもなります。相見積もりの取り方や比較の観点については、別記事で詳しく解説しているので、まだ1社だけとしかやり取りしていない場合はあわせて参考にしてください。

最後に、この記事で解説した内容はあくまで一般的な確認の視点であり、契約書の具体的な条項を法的にどう解釈すべきかという判断は、案件の規模や重要度によっては弁護士など専門家への相談も検討してください。特に、契約金額が大きい案件や、基幹業務に関わるシステムの発注では、社内での最終確認に加えて、外部の専門家によるレビューを一度挟むことで、見落としのリスクをさらに減らすことができます。

次の記事では、実際に契約を結んだ後、開発の過程でトラブルを未然に防ぐための契約条項の書き方について、より具体的に掘り下げています。契約書のドラフトを前にして、条項の一つひとつをどう読めばよいか迷っている方は、あわせて確認してみてください。