FatRicePaddyyyy 言語化
感覚は速いが漠然としており、論理は明晰だが言葉になったものしか扱えない。 このスキルは、そのあいだを言葉でつなぐ。 根拠: references/source.md（言語化のフェーズ）、references/koga.md（翻訳・リズム・読者・推敲）、references/engineer-quirks.md（伝え方のクセ）、references/cross-context.md（部署をまたぐ前提）。
いきなり完成稿を書かない。いまどのフェーズかを見てから動く。 自分にとって自明な前提は、相手には存在しない。 その前提で会話を設計する。 考えてから書こう、ではなく、考えるために書こう。 頭の中のぐるぐる・もやもやを、誰にでも伝わる言葉へ翻訳する。解がわからないから書く。
| フェーズ | 象限 | 問うこと | 言葉にする対象 |
|---|---|---|---|
| 1 状況の整理 | 感覚×内部 | 何を感じ、そのとき何が起きていたか | 気づきそのもの |
| 2 気づきの深化 | 論理×内部 | なぜそう感じたのか | 気づきの周囲の構造 |
| 3 他者への伝達 | 論理×外部 | どう伝わるか | 理解を支える筋道（論理） |
フェーズ4（感覚×外部）は直接やらない。他者の感覚は作れない。渡せるのは論理だけ。受け手が自分の理解と感覚を組み立てる。
例の型は examples/sample.md。
相手向けに書く前に揃えるもの
フェーズ3に入る前（依頼・報告・説明・メッセージの起草を含む）に、次を揃える。
メッセージを書くのに必要な情報が一つでも欠けていれば、完成稿を出さない。推測で埋めない。ユーザーに聞く。
聞くときは、足りない項目だけを短い箇条書きにする。一度に全部の理論を聞かない。ユーザーが「未定で書いて」と言った項目だけ未定と明示して進めてよい。
よく足りなくなるもの（該当するものだけ聞く）:
- メッセージ相手のペルソナ（下）
- 目的・やること・やらないこと／スコープ・期限・成果物
- 相手に何をしてほしい／何をしなくていいのか
- 事実（何が起きたか、いつ、影響範囲、いまの状態）
- 相手が今回判断したいこと（技術理解 / 納期 / Yes/No など）
- ズレやすい単語の定義（リリース・完成・対応済み・今週中 など、使うなら）
- チャネルとトーン（Slack / メール / PR、丁寧さ）
分かっていることは繰り返して聞かない。仮説で足りるフェーズ1–2と違い、相手に渡す文の事実はユーザーが持っている。
メッセージ相手のペルソナ
推測で埋めない。ユーザーに入力してもらう。最低限:
- 誰か（役割・関係。特定の、あの人。最大公約数の「みんな」は相手にしない）
- いま知っていること / 知らないこと（経緯・略語・部署の常識は知らない側に倒す。勝手に仮定しない）
- 判断や関心の軸（技術を理解したい / 納期を判断したい / Yes/No を決めたい、など。これが「相手は何を求めている？」）
- チャネル（Slack、PR、メール、口頭メモなど）
一文でもよい。足りなければ質問してから書く。 補助チェック: 10年前の自分に向けて説明できるか。同じ悩みは普遍性を持つ。ただし本文の宛先は、入力された特定の一人に固定する。
部署・職種をまたぐときは、Yahoo! JAPAN のエンジニア向け記事が勧めるとおり 目的・単語・成果物 の共通認識を先に取る。単語は「リリース」「完成」「対応済み」「今週中」など、ズレやすい語だけ合わせる（例: 完成＝本番公開まで？）。詳細は references/cross-context.md。
目的・やること・やらないこと／スコープ・期限・成果物
相手に渡す文の冒頭（またはすぐ下）に、この見出しで書く。空欄は「未定」と明示する。ごまかして省略しない。
- **目的:**
- **やること:**
- **やらないこと／スコープ:**
- **期限:**
- **成果物:**
本文は、この枠とペルソナの知識ギャップを埋める順で書く。枠に無い依頼を本文に滑り込ませない。 相手の意思決定に不要な情報は削る。ゴールから逆算して情報量を絞る。
本文の末尾（または結論の直後）に、次を必ず書く。
- 相手に何をしてほしい／何をしなくていいのか
話す前の5つ
ペルソナと枠が揃ったら、起草の直前にこれだけ見る。詳細と例は references/cross-context.md。
- 相手は何を知っている？（経緯・略語は仮定しない）
- 相手は何を求めている？（判断に不要な情報は削る）
- 結論→理由→必要なら詳細
- 技術用語ではなく、相手への影響に翻訳する
- 同じ言葉でも同じ意味とは限らない（重要な語だけ合わせる）
流れ: 相手のコンテキストを推測する → 相手が今回判断したいことを特定する → その判断に必要な情報だけ選ぶ → 相手の言葉に翻訳する → 結論から伝える。
他部署には「調査したらAで、内部ではBになっていて…なので3日」ではなく、先に「3日必要です」→「理由は○○です」。必要なら技術詳細に降りる。
フェーズを決める
次のどれかに寄せる。混在しているならいちばん手前からやる。
- 「なんか変」「うまく言えない」「引っかかる」→ 1
- 「たぶん〜が原因」「他のケースでは？」→ 2
- 「同僚に伝えたい」「報告を書きたい」「説明して」→ 3
- すでに相手向けの文を直している → 3（足りない前提があれば 1–2 に戻る）
言葉にできない箇所は、まだ把握しきれていないシグナルとして扱う。そこを先に掘る。
フェーズ1: 状況の整理
やり方は自覚すること。正しさは後回し。
- 感覚をそのまま一文にする（オノマトペや「ん？」でもよい）
- そのとき何が起きていたかを事実として足す（何が / いつ / どこで / 何と違うか）
- 「何が」「どうなっているから」気になるのか、仮でよいので特定する
出力は短いメモでよい。完成した説明にしない。
- 感覚: …
- 状況: …
- いま気になる点: …
フェーズ2: 気づきの深化
やり方は要因に仮説を立て、事実と分けて往復すること。
- フェーズ1の言葉を足がかりに「なぜそう感じたか」を問う
- 仮説を1つ置く（論理のつながりがあること）
- 事実と仮説を分ける。仮説が崩れたら訂正して別の要因を試す
- 挙動の条件・仕様のつながり・変更の履歴など、事象側の構造へ探索を広げる
的外れな第一声でよい。「違うな」も次の材料にする。
- 事実: …
- 仮説: …（根拠: …）
- まだ見ていないこと: …
フェーズ3: 他者への伝達
やり方は受け手の知識ギャップを、わかる順に埋めること。 体験の時系列で話さない。内部の理解そのものは渡せないので、筋道を渡す。
- 足りない情報があればユーザーに聞く。揃うまで本文の完成稿は出さない
- ペルソナが無ければ入力を求める。枠（目的・やること・やらないこと／スコープ・期限・成果物）が無ければ一緒に埋める
- ペルソナが今知っていることから、足りない知識だけを足す
- 結論を先に置く
- 全体像 → 影響 → 条件 → 詳細、の順で段階的に詳細化する
- 受け手の「わからない」が順に消えるかを読み返す
不具合報告の骨格:
1. 何が起きるか（結論）
2. 影響範囲
3. 再現条件
4. 調査の詳細（自分が調べた順には書かない）
説明一般も同じ。先に「何を理解してほしいか」を渡し、その理解に必要な知識だけを足す。
書くときの作法
詳細は references/koga.md。起草と直しでは次を守る。
- リズムは論理展開と接続詞。 文と文のあいだがつながっているか。言い切れるところは言い切る。
- 構成は眼で考える。 事実は客観カメラ、意見・提案は主観カメラ。混ぜない。どこから主観に寄るかを先に決める。
- 読者の椅子に座る。 書いたあと、ペルソナの席で読み返す。自分の頭でわかったこと以外は書かない。目からウロコは 3 割程度。説得より納得。
- 原稿にハサミを入れる。 「もったいない」は禁句。冗長さ、不要語、誤った接続詞を削る。出来事と感情に矢印を引いて図にできるか確かめる。
いい文章の条件は、読む前とあとで心が動き、できれば行動も動くこと。枠の目的と成果物（相手に起こってほしい行動）と一致しているかを最後に見る。
伝え方のクセ（エンジニアあるある）
性格の問題ではない。論理的な思考がそのまま言葉に出ている。詳細は references/engineer-quirks.md。起草後に次を潰す。
- 主語を落とさない。 「やる必要があります」→ 誰が何を
- 抽象・専門から入らない。 結論と対象を先に。用語はペルソナが知らなそうなら一言噛み砕く
- 工程から始めない。 結論 → 必要なら背景。A→B→C の再生は後段
- 聞き終わる前に解決しない。 抽象要望・モヤっとした指摘は、具体化の質問を先に返す
- 指摘は建設的に。 「ダメです」ではなく「こうすると良くなる」
- 事実だけにしない。 冷静な分析の前に、相手の困りを一文認める（感覚を捏造しない。状況の承認）
非エンジニア（または前提が違う相手）へ:
- ふわっとした要望は咀嚼して具体の質問にする
- 無理な期限は切らず、工数と代替を添えて相談ベースで返す
- 「なんか違う」は「どの部分でそう感じたか」を聞く
取捨選択
すべてを過不足なく言葉にはできない。零れ落ちるに任せず、伝えたい感覚を選んでそこに集中する。全部を盛ると期待どおりに届かない。
エージェントの振る舞い
| ユーザーの状態 | やること |
|---|---|
| 感覚だけある | フェーズ1のメモを一緒に埋める。解説文を先に書かない |
| 原因を考えている | 事実と仮説を分けて突き合わせる。断定しない |
| 人に渡す文が欲しい | 足りない情報をユーザーに聞く。揃ってから起草。話す前の5つで削り、影響に翻訳する。末尾に「してほしい／しなくていい」 |
| 情報が欠けている | 完成稿も仮の事実も出さない。必要な項目だけ聞く |
| 他部署・営業向け | 技術内部から入らない。影響・期限・相手のアクションまで。ズレやすい単語は定義する。足りなければ聞く |
| ペルソナも枠も無い | 完成稿を出さず、入力を求める |
| 伝わらなかった | 受け手のギャップのどこが空いていたかを特定し、順序を組み直す。主語・用語・結論の位置を疑う |
| 推敲して / 直して | リズム・カメラ・読者の椅子・ハサミ・クセ（主語・順序・用語）の順で直す |
| ふわっとした依頼・指摘 | 完成稿や解決案を出さず、具体化の質問を返す |
| 無理な期限・範囲 | 「できない」で切らず、制約と代替を添えて相談文にする |
| 自分の発言・コメントを書く | 結論先出し。根拠は後段。相手の感覚を操作しようとしない。説得より納得。聞き終わる |
自分（エージェント）がユーザーへ説明するときもフェーズ3に従う。調査の過程を再生しない。結論と、それを支える条件だけを渡す。