設計説明で、こんな経験はありませんか。
- 実装理由は説明した
- 工数の妥当性も示した
- 技術的に間違っていない
それでも、
「納得できない」 と言われる。
結論から言います。
これは技術力の問題ではありません。
話している論点のレイヤーがズレているだけです。
※本記事は、PM向け記事と対になっています。
👉 「説明は理解できるのに納得できない」の正体（PM向け）
Contents
よくある設計シーン
あるチェック処理の実装で、次の2案がありました。
- ① 画面（フロント）でチェック
- ② 登録確定時（バックエンド）でチェック
エンジニア側の説明は、こうなりがちです。
- 将来廃止予定の処理である
- 重複実装のメリットが薄い
- 工数的に後者が現実的
- バックエンドのほうが実装しやすい
技術的には、すべて正しい説明です。
でも、相手はそこを聞いていない
業務側・お客さんが知りたいのは、次の点です。
- どの操作を信じればいいのか
- 画面でエラーが出ないのは仕様なのか
- 権限によって挙動が違うのは想定内なのか
つまり、
業務として、どこで保証されているのか。
起きているズレ
- エンジニア → なぜこの実装が合理的か
- 相手 → この設計で、業務的に何が守られるか
同じ話をしているようで、
見ているレイヤーが違います。
エンジニアが最初に言うべき一文
技術説明の前に、まずこれを伝える必要があります。
「業務上は◯◯のタイミングでチェックされる前提です。
それ以前に画面でエラーが出ない挙動は仕様です。」
この一文がないまま実装理由を説明すると、
相手はずっと 不安を抱えたまま 話を聞くことになります。
具体例（現場でよくあるケース）
- 管理者権限では画面入力が通る
- 一般ユーザーでは確定時にエラーになる
この挙動を知らない業務側は、
「不具合では？」と感じます。
先に
- チェックされる業務上のタイミング
- 画面挙動が仕様である理由
を示していれば、
その後の技術説明は自然に通ります。
まとめ（エンジニア向け）
- 技術的正しさ ≠ 説明としての正しさ
- 最初に答えるべきは 「この設計で、業務はどこで保証されるか」
- 実装理由の説明は、その後でよい
安心を定義してから、技術を語る。
業務側・PMがなぜそこを気にするのかは、
次の記事で逆側から整理しています。
👉 PM向け記事はこちら
「説明は理解できるのに、なぜか納得できない」の正体
チェックリスト（エンジニア向け）
設計説明前チェック
- ☐ 業務上のチェックタイミングを一文で言える
- ☐ 画面でエラーが出ない挙動が仕様か明示できる
- ☐ 権限差による挙動を説明できる
- ☐ 最初に「業務保証」を説明する構成になっている
- ☐ 工数・実装理由を先に話そうとしていない
関連記事
割り込みが多くて集中できない人へ：原因は意志じゃなく「仕組み」だった
締切前に燃えるエンジニアへ：バッファを入れるのがエッセンシャル思考
筋トレアプリがサービス終了。回数を数えるだけのiOSアプリを自作した話
