「分かった」と言われても伝わってない！？システム開発での認識ズレ対策マニュアル

2025-04-11

URLをコピーしました！

また仕様の説明でズレが出ちゃいました…。こっちは何度も説明してるつもりなんですけど…。

あー、それ、わかります！開発の現場じゃ“伝わらない問題”って避けて通れない問題なんですよね。オフショアだけに限らず日本人同士でも同じことは起こるんです。

やっぱり…。どうしたらうまく伝えられるんでしょうか？

では、“あるあるの原因”と“実践的な対策”を一緒に整理してみましょうか。

Contents

はじめに

システム開発では、エンジニアが仕様や設計、技術的制約を関係者に説明する場面が頻繁にあります。しかし、**「何度説明しても伝わらない」**という問題は、どの現場にも存在します。

これは決して説明不足ではなく、「相手との視点や前提知識の違い」が主な原因です。
この記事では、エンジニアが説明しても相手に伝わらない“あるある”ケースと、それに対する実践的な対処法を紹介します。

よくある「伝わらない」シーン

「なるほど」と言われたのに、まったく違う理解をされていた

これは特に多いケースです。説明のあとに「分かりました！」と返されても、いざできあがったものを見てみると全然意図と違う…。

原因

相手が理解した“つもり”になっている
技術的な前提が共有されていない
同じ専門用語でも、設計方針や文脈によって解釈がズレている

例

「この処理はリトライします」→リトライのトリガーや上限が定義されていない

エンジニアA「失敗時は自動リトライします」
エンジニアB「了解！（HTTP 5xxとかネットワークエラー時に1回くらいでリトライかな）」ラップしてawaitすればOKね）」

実際には

Aは「5回まで指数バックオフでリトライ、特定の業務エラーコードも含む」
→ Bは「無限リトライ？業務エラーはリトライ対象外でしょ？」と想定していた

ズレの本質

リトライ対象の例外種別や回数、バックオフ戦略などが暗黙だった。

システム開発での説明ミスを防ぐ！エンジニアが押さえておきたい5つの対策法

対策1：理解を「言語化」してもらう

一方的な説明で完了せず、「相手に説明内容を自分の言葉で要約してもらう」ことで、認識のズレをチェックできます。

実践ポイント：

「じゃあ、念のためどういう理解か教えてもらえますか？」と聞く
チャットや議事録に要約を書いてもらう
ホワイトボードや図に起こして一緒に確認する

対策2：図・フローで視覚的に説明する

言葉だけでは抽象的になりがちです。図解・ワイヤーフレーム・処理フローなどを使って「見える化」することで、理解度が大きく上がります。

活用例：

Draw.ioやMiroでフロー図を作成
システム構成図、画面遷移図を見せながら説明
Excelやスプレッドシートでデータ構造を視覚化

対策3：段階的に説明する（抽象→具体）

いきなり技術的な詳細を話すのではなく、**「全体像→背景→詳細」**の順で説明することが重要です。

具体的な構成例：

目的（なぜ必要か）
まず最初に、「なぜこの仕様や仕組みが必要なのか」という背景・意図を共有します。

✕「これを実装してください」
○「この画面で●●のエラーが頻発していて、ユーザーからの離脱が多い。だから入力チェックを厳しくしたいんです」

目的がわかると、判断基準や代替案の検討もスムーズになります。
全体の流れ（どういう仕組みか）
次に、「全体の流れや構造」をざっくり共有します。詳細の前に“地図”を渡すイメージです。

例：「今回の処理は、フロント→API→バッチ→DBの4ステップです」
フロー図・時系列・処理ステップ一覧を活用

これで相手は「自分が担当する範囲」や「前後の接続部分」が明確になります。
技術的な仕様（どう実装するか）
ここで初めて実装に関わる具体的な技術仕様を説明します。

・どのAPIを使うか（エンドポイント、メソッド）
・データの構造や型
・想定される異常系・エラーパターン

ここでは「一つの機能や関数レベル」に落とし込むことがポイントです。
例やパターン（どう動作するか）
最後に「具体的な入力例・期待される動作パターン」を出します。

・入力例：このフォームに「abc@example.com」と入力 → 成功
・異常系：未入力ならエラーメッセージ「メールアドレスは必須です」
・成功系：APIが200でレスポンスにユーザーIDが返る

例を出すことで、「それなら理解できた」→「そう動くなら納得」という流れが作れます。