はじめに
こんにちは、ひよこです。
いきなりですが「いや、その言い方……」とか「結局、何を決めればいいの……？」と感じること、ありませんか？
チャットやドキュメントのやり取りで、こういうモヤモヤが生まれる場面に遭遇することはよくあります。
エンジニアリングにおけるコミュニケーションで本当に大事なのは、個人の文章センスや気合いではなく 「再現性」 だと私は思っています。
私が普段、文章を書くときに意識しているのは以下の 3軸です。
- 効率性：読む側、書く側の手間の少なさ
- 明確性：曖昧さがない判断のしやすさ
- 摩擦の低減：人間関係のトラブルの少なさ
さらに、これらを安定させるために「5 つの法則」をチェックリストとして併用する運用にしています。現代には生成 AI という強力な味方もいますから、文章センスに自信がなくても大丈夫です。
この記事では、コミュニケーションのブレをなくすための5つの法則と、それを AI で実践するためのプロンプトを紹介します。
🐣 摩擦の低減以外は生成 AI とのやりとりでもいえることですね
5 つの法則・原則まとめ
まずは全体像です。この 5つを覚えておくだけで、「なんか伝わらない」「なんか刺々しくなる」といった事故をかなり減らせます。
| 法則・原則 | ひとこと | 主に効く場面 |
|---|---|---|
| KISS 原則 | まず削る。盛るのはその後 | 仕様書、報告、長いチャット |
| グライスの協調の原理 | 量、質、関連、様態でセルフレビュー | 依頼、報告、議事録 |
| 知識の呪い | 「相手も知ってるだろう」を疑う | 非エンジニアへの説明、新メンバー対応 |
| グッドハートの法則 | 指標はゲーム化される前提で書く | KPI 付きの依頼、SLA、運用ルール |
| ハンロンの剃刀 | まずミスと誤解を疑う | レビュー、注意、リマインド |
それぞれ詳しく見ていきましょう。
1. KISS 原則
KISS (Keep It Simple, Stupid) は、「必要なことだけ残して、あとは削ろう」という設計や説明の原則です。原語は少し過激ですが、要は「まずシンプルに」ということです。
🐣 ｢余計なことをするなこのバカが！｣ が直訳でしょうか？ 無能な働き者を諫める言葉ですね
どんなときに使うか
- 仕様や背景説明が A4 用紙 3 枚分くらいに膨れてきたとき
- Slack の 1 投稿が、スマホで 3 スクロール以上になってきたとき
- 「話があちこち飛んでる気がする」と自分で感じたとき
チェック観点
KISS のチェックリスト
- 「これ、意思決定に本当に必要？」と自問して削る
- 同じ内容の行を統合する
- 例え話より先に結論を書き、必要な例だけ残す
KISS は、文章の「正しさ」よりも「通る形」を先に作る感覚で適用します。通る形になってから、必要な情報を足すほうが安全です。
2. グライスの協調の原理
グライスの協調の原理は、会話がスムーズに進むための 4 つの公準（ルール）です。
- 量：多すぎず、少なすぎない情報量か
- 質：事実ベースで、誇張や推測に寄りすぎていないか
- 関連：今の文脈と関係している話だけに絞れているか
- 様態：構造化されていて、曖昧な表現が少ないか
どんなときに使うか
- 「結局どうしたいの？」と言われがちな報告
- 読み返したとき自分でも要点が分かりづらいチャット
- 上長へ「判断をもらう」ためのメッセージを送るとき
チェック観点
軽いセルフチェック
- 量：相手が 1 分以内に判断できそうか
- 様態：結論 → 理由 → お願い の順になっているか?
この原理を意識すると、読み手の負荷を下げるだけでなく、書き手である自分自身の「迷子」も減らせます。
3. 知識の呪い
知識の呪い (Curse of knowledge) は、知っている側ほど「これくらいは常識だよね」と無意識に思い込んでしまうバイアスです。専門職であるエンジニアが陥りやすい罠ですね。
🐣 難しい数学を知っている前提で話す方、研究者にもめっちゃいますよね…
どんなときに使うか
- 非エンジニア、別職種向けに技術説明を書くとき
- 新メンバーや他部署に仕様を共有するとき
- コードレビューのコメントに専門用語を連射しているとき
- アルファベット 3 ～ 4 文字からなる略語を量産しているとき
チェック観点
解呪のチェックリスト
- 「この文章、略語を全部展開したらどうなる？」を一度試す
- 「この人が初見だとしたら、最低限必要な前提は何か？」を書き足す
- 重要な部分は「一文で言い換え + 補足」で二段構えにする
「相手が理解してくれない」と嘆く前に、「相手に前提知識を要求しすぎていないか」を疑ってみると、コミュニケーションの不整合はだいたい収まります。
🐣 たまご時代の自分に出すつもりで書くのが一番かもしれません
4. グッドハートの法則
グッドハートの法則 (Goodhart's law) は、「指標が目標になると、その指標は簡単に攻略されて意味をなさなくなる（壊れる）」という法則です。
典型パターン
- 「レスを早くしてほしい」→ とりあえず「了解です」だけ返す中身のない即レスだらけになる
- 「バグ件数を減らしたい」→ そもそもチケットを起票しなくなる
- 「問い合わせを減らしたい」→ ユーザーが諦めて声を上げなくなる
チェック観点
依頼やルールに「数字」を入れるときは、以下の 3 点セットで書くようにします。
- 指標：何を測るか（例：返信までの時間、バグ再発率）
- 意図：なぜその数字が大事か（例：ユーザーの不安を早く下げたい）
- ガードレール：やってほしくない最適化（例：内容のない即レスは不可）
数字は便利ですが、単体で置くと現場の行動とズレが生じます。意図とガードレールを添えることで、ズレが「事故」ではなく「調整」で済むようになります。
🐣 LLM にこの手の手抜き返答をされて頭に来た経験をしている人は多いのでは？
5. ハンロンの剃刀
ハンロンの剃刀 (Hanlon's razor) は、「ミスや不注意で説明できることを、悪意のせいにしないほうがいい」という原則です。
🐣 悪意と決めつけてひとりでイラついてしまう人、いますよね
どんなときに使うか
- レビューコメントがきつく見えるとき
- 返信が遅い、またはそっけないとき
- 仕様が勝手に変えられたように感じるとき
チェック観点
冷静になるためのステップ
- 「悪意がある」と読む前に、状況要因を 3 つくらい仮説として挙げる
- 例：タスクが詰まっている、前提を共有されていない、締切を誤解している
- 事実と感情を分けて書く
- 例：「◯日の◯◯の件、◯◯がまだ共有されていないようなので教えてください」
- 例：「不安なので確認させてください」くらいまでに留める
この原則は、相手のためというより、自分の認知コストを下げて精神衛生を保つ効果が大きいです。
🐣 ちなみにこの言葉は KISS 原理と同じ意味のオッカムの剃刀のオマージュです。反論の剃刀だと意味が真逆になるのはちょっと面白いw
生成 AI に投げるときの汎用プロンプト集
ここからは、紹介した 5 つの法則をプロンプトで使い回すためのテンプレートを紹介します。
{{...}} の中に、自分のテキストをそのまま貼り付けて使ってみてください。
長文 → 意思決定用サマリ（KISS × グライス）
要領を得ない長文を、意思決定者が即判断できる形に整形します。
以下の長文を、意思決定者が 1分以内に判断できる形に整理してください
- 出力は 3行以内の箇条書きにする
- 各行は「結論（承認、否認、相談など） → 最大の根拠 → 私が依頼したいアクション」の順にする
- あいまいな表現は具体的な数値、日付、担当者に置き換える
- グライスの協調の原理（量、質、関連、様態）の観点で、過不足や構造の乱れがあれば修正する
- 最後に、そのままチャットで送れる「決定依頼文」を 1つ作る
本文
{{ここに元の文章を貼る}}
技術説明 → 非エンジニア向けに変換（知識の呪い）
専門用語だらけの説明を、他部署の人にも伝わるように翻訳します。
以下の技術的な説明文を、非エンジニアの意思決定者向けに書き換えてください
- 全体で 30秒以内に読める分量にする
- 専門用語をそのまま使う場合も、すべて1行で平易な言葉に言い換えて補足する
- 「影響範囲（コスト、スケジュール、品質）」「メリット」「リスク」をそれぞれ箇条書きにする
- 知識の呪いを避けるため、相手が前提知識ゼロでも読めるようにする
本文
{{ここに元の技術説明を貼る}}
丸投げ依頼 → 技術的な相談文に変換（グッドハート）
単なる作業依頼を、エンジニアが実力を発揮できる「相談」に昇華させます。
以下の依頼文を、エンジニアが実装方針を選べる「技術的な相談文」に書き換えてください
- 依頼の目的（例：デモ用か本番運用か）を明確に書く
- 進め方の候補を「品質寄り」「速度寄り」の 2案以上として整理する
- グッドハートの法則を踏まえ、「やってほしくない最適化（例：作り込みすぎない、捨ててもよい暫定対応に留める）」を明文化する
- Slack にそのまま投稿できる文体に整える
元の依頼文
{{ここに元の依頼文を貼る}}
圧強めの文 → 摩擦少なめに調整（ハンロン）
感情が乗ってしまいそうな文面を、プロフェッショナルなトーンに直します。
以下の連絡文を、感情的な摩擦を減らすトーンに書き換えてください
- 事実、依頼内容、期限は削らない
- ハンロンの剃刀の観点から、相手の悪意を前提にしているように見える表現を別の言い方に置き換える
- 相手が忙しい、誤解している可能性も考慮した穏やかな書き方にする
- チャットで読みやすいように、適度に改行とひらがなを増やす
本文
{{ここに元の文を貼る}}
注意点
鋭い方はお気づきかもしれませんが、実はこれら 5 つの条件は実は競合しています。例えば KISS 原理と知識の呪いは相反していますし、上のプロンプトに含まれる数値（～秒以内に…）とグッドハートの法則は競合しています。多くの場合、KISS 原理とハンロンの剃刀も矛盾する場合が多いです。
それでもまずは常にこの 5 つの法則を頭に入れておくだけでエンジニア生活は格段にやりやすくなると思います。そして、経験を積んでいくことでこれらのバランスをうまく取れるようになっていくはずです。
🐣 私も 5 つのバランスについてはまだまだ修行中です
おわりに
たくさんの複雑な理論を覚える必要はありません。「KISS」「グライス」「知識の呪い」「グッドハート」「ハンロン」の 5 つをチェックリストとして回すだけでも、コミュニケーションは驚くほど安定します。
私はいつも、「まず KISS で削る → グライスで整える → 相手の前提を疑う → 指標の罠を避ける → 悪意より誤解を疑う」 という順で見直すことが多いです。
生成 AI を使う場合も、プロンプトを作り込むより、これらのキーワードを混ぜて投げるだけで、だいたい実務で使える「良い感じ」の文章になります。ぜひ試してみてください。ではまた次の記事でお会いしましょう。