第1部：全案件共通の10項目
① 目的が1行で言えるか
「業務効率化のため」は目的ではありません。
「月40時間かかっている請求書の突合作業を、月5時間にする」——ここまで書けて、はじめて要件を決める基準ができます。
数字が入らない目的は、後で「これは要件に入っているのか」を判断できません。判断できないものは、必ず揉めます。
② 現状（As-Is）の業務フローが描けているか
誰が、いつ、何をトリガーに、何をするのか。部門をまたぐ流れ、例外処理、そして「担当者が経験で回している暗黙のルール」まで。
JUASの調査では、品質が予定どおりにならなかった要因の39.6%が「想定以上の現行業務・システムの複雑さ」です。業務が複雑だったのではなく、複雑さが見えないまま契約したから起きています。
ここを描けないなら、開発の前に業務整理を独立したフェーズとして置くべきです。
③「やらないこと」が書いてあるか
要件定義書には「やること」が並びます。しかし揉めるのは常に、書かれていないことについてです。
今回のスコープ外を明示的にリスト化してください。「将来的にやりたいこと」も、フェーズを分けて書いておく。これだけで追加要求の交渉が驚くほど楽になります。
④ 既存システムとの連携要件が洗い出されているか
- 連携先はどのシステムか
- 方式（API／CSV／DBダイレクト）とタイミング（リアルタイム／日次バッチ）
- 突合キーになる項目は何か
- 連携が失敗したときにどうするか
ここは発注側しか知りえない情報です。ベンダーは「聞くべきこと」を知りません。言われなかったから聞かなかった、が最も高くつきます。
⑤「決められる人」が1人決まっているか
仕様を凍結すると宣言でき、それを社内に守らせられる権限を持った人。
合議で決めるプロジェクトは、仕様変更が止まりません。名前を1人、書いてください。
⑥ 現場の代表者が要件定義に参加するか
情シスと経営層だけで要件を決め、開発が終わってから現場が「これでは使えない」と言う。これが最悪のパターンです。
文化シヤッターと日本IBMの訴訟（賠償額約20億円が2025年1月に確定）でも、現場の要求が後から噴出したことがカスタム開発の膨張と頓挫につながりました。後から出た要求ほど、断れず、高くつきます。
⑦ 契約形態（請負／準委任）と、その理由を説明できるか
- 請負＝完成責任がベンダーにある。仕様が固まっている前提
- 準委任＝専門家として業務を遂行することに対価を払う。完成責任は負わない
IPAの「情報システム・モデル取引・契約書（アジャイル開発版）」は、アジャイル開発について準委任契約を前提としています。要件を作りながら固めていく手法と、成果物を先に確定させる請負契約は、原理的に噛み合わないためです。
「なんとなく一括請負」で発注していないか。工程ごとに契約を分ける（要件定義＝準委任、実装＝請負）という選択肢も含めて検討してください。
⑧ 検収条件（受入基準）が先に定義されているか
「どうなったら受け入れるのか」を、要件定義と同時に書く。
受入テスト仕様書はどのみち必要になるので、前倒ししても総工数は変わりません。そして先に書くと、要件の曖昧さが強制的に炙り出されます。「この機能、何をもってOKとするんだっけ？」で止まるなら、その要件はまだ決まっていません。
⑨ 非機能要件が数字になっているか
「速く」「安定して」は要件ではありません。
- 同時接続数、想定データ量、5年後の増加見込み
- 画面のレスポンス目標
- 稼働率、メンテナンス許容時間
- バックアップの頻度と保存期間
- 障害時の復旧目標（どれだけで戻すか、どこまで戻せるか）
- セキュリティ要件、アクセス権限の設計
ここが空欄のまま見積りを取ると、各社の見積りが比較不能になります。安い見積りは、たいていここを軽く見ています。
⑩ 保守・運用の体制と費用が見積もられているか
システムは作った後のほうが長く生きます。
- 障害時の連絡先と対応時間帯
- 月額の保守費用と、その範囲（どこからが別途見積りか）
- ソースコード・設計書の帰属と、引き渡しの有無
- ベンダーを変えることになったときに、移管できる状態か
ソースコードとドキュメントを渡さない契約は、実質的なロックインです。契約前に必ず確認してください。
第2部：作るものの種類別・追加チェック
10項目は土台です。ここからは種類別の地雷。
■ 業務効率化システム
[ ] 効率化する業務の工数を実測したか（Before の数字がないと、効果を証明できません）
[ ] 「今のやり方」をそのままシステム化しようとしていないか（業務自体を変えないと効果は出ません。むしろ非効率が固定化されます）
[ ] 現場が入力してくれる設計か（入力負荷が増えて放置される、が最頻の失敗）
[ ] 作らずに済まないか（既存SaaSやノーコードで足りるなら、それが最善です）
■ CRM等の基幹システム
[ ] データ移行の範囲・品質・責任分界を決めたか（最大の地雷。移行だけで別プロジェクト規模になります）
[ ] マスタ（顧客・商品・組織）のコード体系は誰が決めるか
[ ] 現行システムの仕様がわかる人が社内にいるか（JUASの調査では、内製化の阻害要因として「現行システムの仕様がわからない」を挙げた企業が24.6%）
[ ] 「業務をシステムに合わせる」のか「システムを業務に合わせる」のか、方針を先に決めたか
この最後の項目が、基幹システム刷新の分水嶺です。文化シヤッターの案件では、旧システムと同じ画面の見た目にこだわった結果、カスタム開発の割合が95%まで膨張しました。SaaSやパッケージを選んだ意味が消える瞬間です。
[ ] 並行稼働期間と、切り戻し（ロールバック）計画があるか
[ ] 監査・内部統制・電子帳簿保存法などの法定要件を要件に落としたか
■ Webマッチングサイト
[ ] 鶏卵問題をどう解くか決めたか（供給側と需要側、どちらを先に集めるか。技術ではなく事業設計の問題です）
[ ] 決済をどう扱うか（プラットフォーム側が代金を預かる構造にすると、資金決済法上の論点が発生しうるため、設計前に法務確認を）
[ ] 利用規約・特商法表記・個人情報の取扱い（本人確認の要否含む）を整理したか
[ ] 通報・ブロック・トラブル時の対応フローを決めたか（機能ではなく運用の話。後回しにすると炎上時に対応できません）
[ ] MVPの範囲を絞ったか（マッチングサイトは仮説検証型です。最初から作り込むと、検証前に予算が尽きます）
■ Webサイト/ホームページ制作
[ ] 目的が「かっこよくする」になっていないか（何をもって成功とするか。問い合わせ数か、採用応募か、ブランド認知か）
[ ] 原稿と写真は誰が用意するのか（制作が止まる原因の第1位です。 発注側が用意するなら、その工数と期限をスケジュールに入れてください）
[ ] 公開後の更新は誰がやるのか（CMSを入れても、運用する人がいなければ更新されません）
[ ] ドメイン・サーバー・SSL・解析ツールが自社名義になっているか（ベンダー名義のままだと、乗り換え時に詰みます）
[ ] 制作物の著作権と、写真・フォントのライセンス範囲（素材の使用期限が切れていた、は実際にあります）
[ ] 公開後の保守契約があるか（CMSの脆弱性は放置すると改ざんされます）
■ AI技術開発
[ ] 「精度◯%」を成果物の完成条件にしていないか（データ次第で結果が変わるため、達成保証は原理的に困難です。準委任契約が基本になります）
[ ] 学習データは誰が用意し、権利は誰に帰属するか。生成物の権利はどうか
[ ] 誤答・ハルシネーションが起きたときの責任分界と、人間が確認するプロセスを決めたか
[ ] PoCで終わらせないために、本番移行の判断基準を先に決めたか
参考になる公的資料が2つあります。
経済産業省が2025年2月18日に公表した「AIの利用・開発に関する契約チェックリスト」は、AI関連の契約を「汎用的AIサービス利用型」「カスタマイズ型」「新規開発型」の3類型に整理しており、自社の案件がどれに当たるかを最初に見極める助けになります。
もう1つが、総務省・経済産業省の「AI事業者ガイドライン」（第1.1版・2025年3月28日公表、その後改定）。「AI開発者／AI提供者／AI利用者」という3つの立場を整理しており、自社がどの立場に立つのかを理解しておくと、契約交渉の解像度が上がります。
■ モバイルアプリ開発
[ ] ネイティブ／クロスプラットフォーム／Webアプリの選択理由を説明できるか
[ ] ストア審査の期間とリジェクト時の対応責任を、契約とスケジュールに織り込んだか（審査は自社でコントロールできません）
[ ] 開発者アカウントは自社名義か（ベンダー名義で登録されていると、後で移管に苦労します）
[ ] OSのバージョンアップ対応を、保守契約に含めたか（毎年発生します）
[ ] プッシュ通知・位置情報・アプリ内課金の要否（審査要件と個人情報の取扱いに直結します）
[ ] 管理画面とサーバー側の開発費が見積りに入っているか（アプリ単体の見積りだけ見て発注し、後から倍になるパターン）
■ インフラ基盤構築・保守
[ ] SLAを数字で決めたか（稼働率、障害の一次回答時間、連絡体制）
[ ] 復旧目標を決めたか（どれだけの時間で復旧するか／どの時点まで戻せるか）
[ ] 監視の範囲と、夜間・休日の一次対応者を決めたか
[ ] クラウド費用の見積り前提を確認したか（従量課金は「使い方」で金額が変わります。上限アラートの設定を必ず）
[ ] 管理者権限（rootアカウント等）を自社が保持しているか
[ ] 移管・撤退の条件が契約にあるか（インフラは最もロックインが起きやすい領域です）
補足：2026年1月、発注側のルールが変わりました
最後に、発注する側として押さえておくべき法改正を。
2026年1月1日、下請法が「中小受託取引適正化法（取適法）」に改正・施行されました。単なる名称変更ではありません。
用語が「親事業者／下請事業者」から「委託事業者／中小受託事業者」へ
手形払いの禁止（支払期日までに現金で受け取れる状態にする必要）
価格据置取引への対応（協議なく従来どおりの価格に据え置くことが問題となりうる）
従業員数基準の追加、運送委託の対象追加、執行体制の強化
ここで重要なのは、発注内容を書面で明確にする義務の意味が一段重くなったことです。
つまり、この記事のチェックリスト①〜⑩を潰して書面化する作業は、プロジェクトの成功確率を上げるためだけの話ではなく、コンプライアンス上の要請とも重なっているということになります。
（法務の詳細は必ず専門家にご確認ください。本記事は実務上の観点を整理したものです）
おわりに
10項目のうち、いくつ「はい」と答えられたでしょうか。
半分以下だったとしても、それは普通のことです。前回書いたとおり、JUASの調査では発注側企業の38.7%が「現行業務への理解不足」を、30.2%が「ビジネス要件をシステム仕様に落とせない」ことを自ら課題に挙げています。多くの会社が同じ場所でつまずいています。
大事なのは、この10項目を埋める作業を、開発プロジェクトの中でやらないことです。開発が始まってしまえば、時間もお金もその作業には使えません。
発注する前に、ここを埋める。それだけで、失敗確率は大きく変わります。
出典
一般社団法人日本情報システム・ユーザー協会（JUAS）「企業IT動向調査2025」（2024年度調査）
IPA「情報システム・モデル取引・契約書（アジャイル開発版）」（2020年3月31日公開）
経済産業省「AIの利用・開発に関する契約チェックリスト」（2025年2月18日公表）
総務省・経済産業省「AI事業者ガイドライン（第1.1版）」（2025年3月28日公表）
中小受託取引適正化法（取適法）／2026年1月1日施行
文化シヤッター vs 日本IBM 訴訟報道（日経クロステック ほか）