Web制作プロジェクトでよく起こる「言った言わない」問題。実際の失敗事例と、契約書・議事録・メール確認などの具体的な対策方法を、発注側・受注側両方の視点で解説します。
こんな状況、経験ありませんか？
「確かに電話で『ここは後で変更可能』って言ってましたよね？」 「いえ、そんなことは一言も言っていません。追加作業になりますので別途お見積もりが必要です」
Web制作の現場でよく起こる「言った言わない」問題。20年以上Web制作に携わってきた私たちFivenine Designでも、過去に何度もこのような状況に遭遇し、時にはプロジェクトが頓挫しかけたケースもありました。
発注側は「そんな話は聞いていない」と感じ、受注側は「確実に説明した」と主張する。このような認識のズレは、単なる記録不足から始まることがほとんどです。しかし、放置すればプロジェクトの遅延、予算オーバー、最悪の場合は契約解除につながる深刻な問題に発展します。
実際に当社が関わったプロジェクトでは、口頭での合意に依存した結果、追加費用50万円の請求でクライアントとの信頼関係が悪化したケースもありました。このような問題は技術力の問題ではなく、コミュニケーションと記録管理の問題なのです。
なぜ「言った言わない」問題が発生するのか
記憶の不完全性と解釈の違い
人間の記憶は想像以上に曖昧で不完全です。特にWeb制作のような専門性の高い分野では、発注側と受注側で同じ言葉でも理解が異なることがよくあります。
例えば「レスポンシブ対応」という言葉一つとっても、発注側は「スマホで見やすくなる」程度の理解かもしれませんが、受注側は「タブレット・スマホの各ブレイクポイントでの最適化」を想定しているかもしれません。この認識のギャップが後々の「言った言わない」につながります。
口頭コミュニケーションの限界
電話や対面での打ち合わせは、リアルタイムでのやり取りができる反面、記録が残りにくいという致命的な欠点があります。特に以下のような状況で問題が発生しやすくなります：
- 複数の関係者が参加する会議での口約束
- 技術的な詳細を口頭で説明した場合
- 仕様変更や追加要望を電話で伝えた場合
- 納期や費用について「大体この程度で」といった曖昧な合意
プロジェクト進行中の認識変化
Web制作プロジェクトは数ヶ月に渡ることが多く、その間にクライアントの要望や理解度も変化します。プロジェクト開始時は技術的な詳細に興味がなかったクライアントが、進行とともに細かな点を気にするようになることもよくあります。
実践的な「言った言わない」問題の解決手順
1. 包括的な契約書の作成
最初で最も重要なのは、詳細な契約書の作成です。単なる金額と納期だけでなく、以下の項目を必ず明記します：
技術仕様の明確化
- 対応ブラウザ・デバイス
- 使用技術（Laravel 10.x、WordPress 6.x等）
- 機能詳細とその制限事項
- 納品物の範囲（デザインデータ、ソースコード等）
【対応環境】
- PC：Chrome/Firefox/Safari/Edge 最新版
- スマートフォン：iOS Safari、Android Chrome
- タブレット：iPad Safari、Android Chrome
【開発環境】
- フレームワーク：Laravel 10.x
- PHP：8.1以上
- データベース：MySQL 8.0
【納品物】
- 完成したWebサイト
- 管理画面操作マニュアル
- ソースコード一式
- データベース設計書
変更・追加作業のルール 仕様変更や追加要望があった場合の対応方法を事前に定めておくことで、後々のトラブルを防げます。
【変更・追加作業について】
1. 軽微な修正（テキスト変更等）：無償対応
2. 機能追加・大幅な仕様変更：別途見積もり
3. 変更依頼は書面（メール）にて受付
4. 変更による納期・費用への影響を事前通知
2. 構造化された議事録システムの導入
毎回の打ち合わせで統一フォーマットの議事録を作成し、必ず参加者全員で内容を確認します。
議事録テンプレート例
# 議事録 - [プロジェクト名]
**日時**: 2024年XX月XX日 XX:XX-XX:XX
**参加者**:
- クライアント: [名前・役職]
- Fivenine Design: [名前・役職]
## 決定事項
- [ ] 項目1: 具体的な決定内容
- [ ] 項目2: 具体的な決定内容
## 確認・検討事項
- [ ] 項目1: 確認が必要な内容（期限：XX/XX）
- [ ] 項目2: 検討が必要な内容（期限：XX/XX）
## 次回までのアクション
### クライアント様
- [ ] 素材提供（期限：XX/XX）
- [ ] 内容確認・承認（期限：XX/XX）
### Fivenine Design
- [ ] デザイン案作成（期限：XX/XX）
- [ ] 技術検証（期限：XX/XX）
## 次回会議
**日時**: 2024年XX月XX日 XX:XX-
**議題**: デザイン案確認、技術仕様詳細決定
3. メール確認システムの運用
口頭で話した内容は必ずメールで文書化し、相手方の確認を得るシステムを構築します。
メール確認の例
件名: 【要確認】本日の打ち合わせ内容について - [プロジェクト名]
お疲れ様です。Fivenine Designの[担当者名]です。
本日はお忙しい中、貴重なお時間をいただきありがとうございました。
打ち合わせでお話しした内容について、認識に相違がないか確認させてください。
【確認事項】
1. トップページのメインビジュアルは3パターン作成
→ スライダー形式で実装
→ 各画像サイズは1920×800px
2. お問い合わせフォーム項目
→ 会社名、担当者名、メール、電話、お問い合わせ内容
→ 確認画面は不要、送信完了画面のみ
3. 管理画面からの更新範囲
→ ニュース・お知らせの投稿・編集・削除
→ 会社概要ページのテキスト編集
上記の理解で相違ございませんでしょうか。
修正・追加がございましたら、XX月XX日（X）までにご連絡ください。
何かご不明な点がございましたら、お気軽にお声がけください。
4. 進捗管理ツールの活用
プロジェクト管理ツールを使用して、タスクの進捗、変更履歴、コミュニケーション履歴を一元管理します。
推奨ツール
- Backlog: 日本企業が開発、使いやすいUI
- Trello: カンバン方式、視覚的に分かりやすい
- Notion: 文書管理とタスク管理を統合
- Slack: チャットベースでリアルタイム情報共有
これらのツールを使用することで、「いつ、誰が、何を決定したか」が明確に記録され、後から検証可能になります。
よくある失敗パターンと対処法
失敗パターン1: 「とりあえず進めてしまう」症候群
実際にあった事例 あるECサイト制作プロジェクトで、決済システムの詳細仕様が曖昧なまま開発を進めてしまいました。クライアントは「一般的な決済機能」を想定していましたが、制作側は高機能な決済システムを実装。結果として予算が30%オーバーし、大きなトラブルに発展しました。
対処法 仕様が不明確な項目がある場合は、必ず開発を停止し、詳細を確認します。「とりあえず進める」ことは絶対に避けましょう。
【仕様確認チェックポイント】
- 機能の動作パターンを具体例で説明できるか
- 想定外の操作をした場合の動作は定義されているか
- 関連する他機能への影響は検討済みか
- 運用開始後のメンテナンス方法は決まっているか
失敗パターン2: 「軽微な変更」の解釈相違
実際にあった事例 クライアントから「文字を少し大きくして」という依頼を受け、簡単な修正として無償で対応しました。しかし、実際にはレスポンシブ対応も含めた全体のバランス調整が必要で、想定以上の工数がかかってしまいました。
対処法 「軽微」「少し」「簡単に」といった曖昧な表現は避け、必ず具体的な作業内容と工数を見積もります。
変更要求評価フロー
変更依頼受領
↓
作業内容の詳細確認（30分以内で完了するか？）
↓
【YES】無償対応 → 【NO】有償見積もり
↓
クライアント承認後に着手
失敗パターン3: 関係者間の情報共有不備
実際にあった事例 クライアント企業の担当者Aさんと仕様を決めて進めていたところ、途中で上司のBさんから全く異なる要望が出されました。Aさんには決裁権がなく、Bさんは途中からプロジェクトに参加したため経緯を理解していませんでした。
対処法 プロジェクト開始時に関係者全員を明確にし、決裁権のある人を含めた会議体を設置します。
関係者管理表の例
| 役割 | 氏名 | 権限範囲 | 連絡先 | 備考 |
|------|------|----------|--------|---------|
| 最終決裁者 | B部長 | 全体承認 | [email protected] | 重要事項は必ず確認 |
| プロジェクトリーダー | A主任 | 日常的な判断 | [email protected] | 窓口担当 |
| 技術確認者 | C課長 | 技術仕様承認 | [email protected] | システム関連事項 |
失敗パターン4: 完成イメージの認識相違
実際にあった事例 「シンプルで洗練されたデザイン」という要望で制作を進めましたが、納品直前に「もっとインパクトのあるデザインにしてほしい」という要望が出ました。「シンプル」という言葉の解釈が発注側と受注側で大きく異なっていたのです。
対処法 デザインの方向性は必ず参考サイトやモックアップで視覚的に確認し、文書化します。
デザイン方向性確認シート
【デザインコンセプト】
参考サイト1: https://example1.com
→ この部分（ヘッダーのシンプルさ）を参考にする
参考サイト2: https://example2.com
→ この部分（カラーバランス）を参考にする
【避けたいデザイン】
参考サイト3: https://example3.com
→ この部分（装飾過多）は避ける
【色彩イメージ】
メインカラー: #3B82F6 (青系)
アクセントカラー: #10B981 (緑系)
全体トーン: 明るく清潔感のある印象
発注側・受注側それぞれの対策ポイント
発注側（クライアント）の対策
1. 社内体制の整備
- プロジェクト責任者と決裁権者を明確にする
- 社内での情報共有ルールを決める
- 制作会社とのコミュニケーション窓口を一本化する
2. 要望の具体化
- 「なんとなく」「よくあるような」という曖昧な表現を避ける
- 参考サイトや具体例を用意する
- 予算と納期の制約を事前に明確にする
3. 変更管理の徹底
- 途中での変更は必ずメールで依頼する
- 変更による影響（費用・納期）の説明を求める
- 変更承認のプロセスを社内で統一する
受注側（制作会社）の対策
1. 提案力の向上
- クライアントの業界特性を理解する
- 技術的な制約を分かりやすく説明する
- 複数の選択肢とそれぞれのメリット・デメリットを提示する
2. リスク管理の徹底
- 仕様が曖昧な項目は必ず確認する
- 想定される追加作業を事前に説明する
- バッファを含めた現実的な納期設定
3. コミュニケーションの質向上
- 専門用語を使わず、分かりやすい言葉で説明する
- 定期的な進捗報告と確認の機会を設ける
- 問題が発生した場合の早期報告・相談
まとめと次のステップ
「言った言わない」問題は、Web制作プロジェクトの成功を大きく左右する重要な課題です。しかし、適切な記録管理とコミュニケーションルールを確立することで、確実に防ぐことができます。
実際に当社でこれらの対策を導入してから、クライアントとの認識齟齬によるトラブルは90%以上削減され、プロジェクトの満足度も大幅に向上しました。重要なのは、技術力だけでなく、コミュニケーション力と記録管理力を向上させることです。
成功するWeb制作プロジェクトには、優れた技術と同じくらい、確実なコミュニケーション管理が必要です。今回ご紹介した方法を実践することで、より良いプロジェクト運営が可能になります。
