開発会社との上手なコミュニケーション術
システム開発プロジェクトの成否は、コミュニケーションの質で決まると言っても過言ではありません。実際、プロジェクト失敗の68%がコミュニケーション不足に起因しているというデータがあります。
本記事では、開発会社との認識のズレを防ぎ、スムーズにプロジェクトを進めるコミュニケーション術を解説します。
なぜコミュニケーションでトラブルが起きるのか
発注側の認識
「このシステムで業務が劇的に改善される。使いやすくて当たり前」
- • ビジネス視点で考える
- • 「常識」が違う
- • 技術用語が分からない
開発側の認識
「仕様通りに作れば完成。細かい使い勝手はクライアント次第」
- • 技術視点で考える
- • 「常識」が違う
- • 業界知識が浅い
結果
お互いに「常識」だと思っていることが違い、認識のズレが蓄積。最終的に「こんなはずじゃなかった」となります。
コミュニケーション術❶：伝え方の工夫
1-1. 曖昧な表現を避ける
❌ NG例
- • 「使いやすくしてください」
- • 「いい感じにお願いします」
- • 「なるべく早く」
- • 「できるだけシンプルに」
✅ OK例
- • 「3クリック以内で検索できる」
- • 「スマホでも見やすいデザイン」
- • 「6月末までに完成」
- • 「入力項目は5つ以内」
ポイント：数値や具体例で表現すると、認識のズレが防げます
1-2. 「なぜ」を伝える
「何をしてほしいか」だけでなく、「なぜそれが必要か」を伝えると、開発会社がより良い提案をしてくれます。
❌ 指示だけ
「検索機能に絞り込みを追加してください」
✅ 理由も伝える
「顧客データが5,000件あり、営業が『地域×業種』で絞り込めないと検索に時間がかかっています。絞り込み機能を追加したいです」
→ 開発会社が「それなら地域・業種だけでなく、売上規模でも絞れると便利ですね」と提案してくれる可能性が高まります
1-3. 画面イメージを共有する
言葉だけでは伝わりにくい場合、手書きやExcel、PowerPointで画面イメージを作りましょう。
✅ 効果的な共有方法
- • 手書きの画面スケッチを写真で送る
- • Excelで画面レイアウトを作る
- • 参考サイトのURLを送る（「こういう感じで」）
- • 動画で操作イメージを説明（Loomなど）
データ：画面イメージを共有したプロジェクトは、手戻りが47%減少します
コミュニケーション術❷：質問の仕方
2-1. 分からないことは遠慮なく質問
「こんなこと聞いたら恥ずかしい」と思って質問を我慢すると、後で大きなトラブルになります。
実際にあった失敗例
「API連携」という言葉が分からなかったが質問できず、後で「え、そういう意味だったの？」となり、追加費用200万円が発生
✅ 良い質問の仕方
- • 「○○という用語の意味を教えてください」
- • 「△△と▢▢の違いは何ですか？」
- • 「今の説明を、別の言い方でもう一度お願いできますか？」
2-2. 理解したことを自分の言葉で確認
開発会社の説明を聞いたら、「つまり〜ということですね？」と自分の言葉で確認しましょう。
確認の例
開発会社：「レスポンシブ対応します」
お客様：「つまり、スマホでもパソコンと同じように使えるということですね？」
開発会社：「はい、その通りです！」
効果：認識のズレがその場で解消されます
コミュニケーション術❸：進捗管理
3-1. 定例ミーティングを必ず実施
週1回30分の定例ミーティングを設定し、進捗と課題を確認しましょう。
定例ミーティングのアジェンダ例
- 1. 前回からの進捗報告（10分）
- 2. 今週の予定（5分）
- 3. 課題・懸念事項の共有（10分）
- 4. 質疑応答（5分）
⚠️ やってはいけないこと
「必要な時だけ連絡します」というスタイルは、問題が表面化した時には手遅れになっていることが多いです
3-2. 遅延の兆候を早期に察知
以下のような兆候があれば、納期遅延のサインです。すぐに確認してください。
🚨 危険信号
- • 進捗報告が曖昧になってきた
- • 「もう少しです」が続く
- • デモの日程が何度も延期される
- • 返信が遅くなってきた
- • 急に技術的な問題の話が増えた
✅ 対処法
- • 「現在の進捗率は？」と数値で聞く
- • 「予定通りに進んでいますか？」とストレートに確認
- • 「懸念事項はありますか？」と課題を引き出す
- • 必要なら緊急ミーティングを設定
コミュニケーション術❹：変更要望の伝え方
4-1. 変更が必要な理由を明確に
❌ NG例
「やっぱりボタンの色を青から赤に変えてください」
→ 理由が不明で、開発会社が対応の優先度を判断できない
✅ OK例
「社内でテストしたところ、青いボタンが背景と同化して見づらいという意見が多数ありました。赤に変更できますか？」
→ 理由が明確で、開発会社も納得して対応できる
4-2. 影響範囲と追加費用を確認
変更要望を出す前に、「これを変えると、どこに影響しますか？」と必ず確認しましょう。
✅ 確認すべきこと
- • 他の機能に影響はありますか？
- • 追加費用はいくらですか？
- • 納期への影響はありますか？
- • 代替案はありますか？
重要：「無料で変更できるだろう」という思い込みは禁物。変更には必ずコストが発生します
コミュニケーション術❺：トラブル時の対応
5-1. 感情的にならず、事実を伝える
❌ NG例
「全然使えないシステムを作って！どうしてくれるんですか！」
→ 感情的な言葉は、解決を遅らせるだけ
✅ OK例
「○○の画面で△△を入力すると、エラーが出て先に進めません。至急確認をお願いします」
→ 事実を冷静に伝え、迅速な対応を促す
5-2. エビデンスを残す
トラブル発生時は、証拠を記録しておくことが重要です。
✅ 記録すべき情報
- • スクリーンショット（エラー画面）
- • 操作手順を動画で撮影
- • 発生日時
- • エラーメッセージの全文
- • 使用していたブラウザ・OS
ポイント：証拠があると、開発会社が原因を特定しやすく、解決が3倍速くなります
コミュニケーションチェックリスト
【伝え方】
- □ 曖昧な表現を避け、数値で伝えている
- □ 「なぜ」を必ず説明している
- □ 画面イメージを共有している
【質問】
- □ 分からないことを遠慮なく質問している
- □ 理解したことを自分の言葉で確認している
【進捗管理】
- □ 週1回の定例ミーティングを実施している
- □ 遅延の兆候を早期に察知している
【変更要望】
- □ 変更が必要な理由を明確に伝えている
- □ 影響範囲と追加費用を確認している
【トラブル時】
- □ 感情的にならず、事実を伝えている
- □ エビデンス（証拠）を記録している
まとめ：良いコミュニケーションが良いシステムを作る
システム開発は「人と人」のコミュニケーションで成り立っています。技術的に優れたシステムでも、認識のズレがあれば失敗します。
曖昧な表現を避け、数値で伝える。理由を説明する。分からないことは質問する。この3つを意識するだけで、プロジェクト成功率は大きく向上します。
弊社では、お客様とのコミュニケーションを最も重視しています。専門用語を使わず、分かりやすく説明することをお約束します。