要件定義から納品まで！コーディングの認識の相違を防ぐ契約とルール
Web制作やシステム開発の現場において、「完成したものが思っていたものと違う」「納品後に何度も修正を依頼されて終わらない」といったトラブルは後を絶ちません。これらの多くは、開発の初期段階である要件定義の不足や、コーディングに入る前の合意形成が不十分であることに起因しています。
本記事では、クライアントと制作者の双方が安心してプロジェクトを進められるよう、認識の相違を防ぐためのルール作りや契約時のポイント、そして納品や修正期間に関する明確な取り決め方について、具体例を交えながら網羅的に解説します。
目次
1. なぜ要件定義とコーディングで「認識の相違」が起きるのか？
プロジェクトが炎上する最大の原因は、関係者間の「暗黙の了解」に依存してしまうことです。発注者は「プロだから言わなくてもやってくれるだろう」と思い、受注者は「指定がないから標準的な仕様で作ろう」と考えます。このズレが、後戻りできないコーディング段階で表面化します。
専門用語の壁と視覚化の不足
要件定義書がテキストだけで書かれている場合、非エンジニアである発注者には実際のシステムの動きが想像しにくいことがあります。例えば、「画像をスライダーで表示する」という要件に対し、発注者は自動で切り替わるものを想像し、エンジニアは手動でスワイプするものをコーディングしてしまうといった相違です。
「要件」と「要望」の混同
要件定義の段階で、絶対に実装しなければならない「要件」と、できればやりたい「要望」を切り分けていないと、納品時に「あれが入っていない」というトラブルに発展します。コーディングに入る前に、どこまでを今回のスコープ（対応範囲）とするかを明確に合意しておく必要があります。
2. トラブルを防ぐための「契約」と「ルール」の作り方
認識の相違を完全にゼロにすることは難しいため、相違が発覚した際にどう対応するかを契約とルールで事前に定めておくことが重要です。
納品の定義を明確にする
「何をもって納品とするか」を契約書や発注書に明記しましょう。テスト環境での動作確認完了時なのか、本番サーバーへのアップロード時なのか、あるいはソースコードのファイル群を提出した時点なのか。ここが曖昧だと、検収作業がいつまでも始まらず、支払いも遅れることになります。
修正期間と修正回数のルール設定
納品・検収フェーズにおいて最も揉めるのが「修正対応」です。バグ（不具合）の修正と、仕様変更（追加要望）の境界線は曖昧になりがちです。以下のようなルールを設けることを推奨します。
- 修正期間（検収期間）の明記： 成果物提出後、14日以内など、クライアントが確認してフィードバックを返す期限を定めます。期限を過ぎた場合は「検収合格（合意）」とみなす条項を入れます。
- 無償修正の範囲と回数： 要件定義書に記載された機能が動かない場合（瑕疵）は無償で修正しますが、「デザインの好みが変わった」「要件定義になかった機能を追加したい」場合は別途見積もりとするルールを合意しておきます。
3. 具体的な失敗例（落とし穴）と対策
ここでは、よくある失敗例と、それを防ぐための対策を紹介します。
失敗例：納品間近の「仕様追加」による炎上
【状況】
コーディングが完了し、テスト環境で確認を依頼したところ、クライアントから「競合サイトにあるような検索フィルター機能もやっぱり欲しい。修正期間内だから無料で対応して」と言われた。
【原因】
要件定義での「スコープ（実装範囲）」の合意が甘く、修正期間を「何でも無料で追加できる期間」と誤認されている。
【対策】
コーディング着手前に「これ以降の機能追加・仕様変更は、別途お見積りとスケジュールの再調整が必要になります」という同意書（またはメールでの確証）を取っておくこと。変更管理（チェンジリクエスト）のルールを契約に盛り込むことが必須です。
4. 実践：要件定義・契約時の合意チェックリスト
プロジェクト開始時や、コーディングに入る前に双方が確認すべき項目をまとめました。以下のリストをコピペして、キックオフミーティングや契約書作成時に活用してください。
- 対応ブラウザ・デバイス（例：Chrome最新版、iOS Safari最新版。IEは対象外とする等）は明記されているか？
- アニメーションや動きのある要素について、参考URLやプロトタイプで合意しているか？
- テキストや画像の提供者はどちらか？（提供遅延時のスケジュール変更ルールはあるか？）
- 「納品」の完了条件は具体的に定義されているか？
- 成果物提出後の「検収期間（修正期間）」は何日間に設定されているか？
- 検収期間終了後の対応（保守契約の有無や、瑕疵担保責任/契約不適合責任の期間）は明記されているか？
- 要件定義に含まれない「仕様変更」が発生した場合の、追加費用の請求フローは決まっているか？
5. まとめ：相互理解がプロジェクトを成功に導く
要件定義からコーディング、納品に至るまでのプロセスでは、「言った・言わない」の相違を防ぐための仕組みづくりが不可欠です。契約やルールを厳密にすることは、決して相手を縛るためではなく、双方の期待値をすり合わせ、気持ちよく合意に至るための土台作りです。
本記事で紹介した修正期間のルールやチェックリストを活用し、安全で高品質な開発プロジェクトを実現してください。
よくある質問（FAQ）
Q1: 要件定義書を作らずにコーディングを進めても良いでしょうか？
A1: お勧めしません。小規模な案件であっても、必ずメールやチャット、簡単なドキュメントで「実装する機能」「やらないこと」をテキスト化し、着手前にクライアントの合意（承認）を得てください。これが後々のトラブルを防ぐ命綱になります。
Q2: クライアントが検収（確認）をしてくれず、修正期間が延々と続いてしまいます。
A2: 契約書や発注時の条件に「みなし検収」のルールを設けることが有効です。「成果物提出後、〇日以内にご連絡がない場合は、検収に合格し合意したものとみなします」という一文を入れることで、プロジェクトの無期限な引き延ばしを防げます。
Q3: 納品後に「要件定義書にはないが、常識的に考えてついているべき機能だ」と言われた場合はどうすべきですか？
A3: 非常に難しいケースですが、まずは要件定義書と契約書に立ち返ります。システムの根本的な目的に関わる重大な見落としであれば協議が必要ですが、基本的には「要件定義書に記載がない＝スコープ外」となります。このような相違を防ぐためにも、事前にワイヤーフレームやプロトタイプで完成形を視覚的に共有しておくことが最も重要です。