新卒未経験学生向け PREP法で伝わる話し方・書き方

F O R N E W G R A D U A T E S PREP 法で 伝わる話し方・書き方 Point → Reason → Example → Point P R E P Point Reason Example Point 新卒・未経験エンジニア向け 1 時間ワークショップ

W H Y P R E P なぜ PREP 法を学ぶのか 🤔 こんな経験ありませんか ? ✨ PREP 法ならこう変わる ・進捗報告で 「結局何が言いたいの ? 」と言われた ・結論を最初に言うので 相手が一発で理解できる ・質問したら「で、何を聞きたいの ? 」 と聞き返された ・なぜそう思うかも添えるので 納得感が生まれる ・メールが長くなって、相手から 返信が来ない ・例を出すので、抽象的にならない ・自分の意見を言うと、 遠回しすぎて伝わらない なぜ学ぶのか ・最後にもう一度結論で締めるので 印象に残る 1 / 14

W H A T I S P R E P PREP 法とは ── 4 文字の頭文字 P R E P Point Reason Example Point 結論 理由 具体例 結論 まず一番伝えたいことを 一言で言う なぜそう言えるのか 根拠を示す 実例・データ・体験で 納得感を作る もう一度結論を言って 印象に残す → → → → の順で組み立てる PREP の 4 文字 2 / 14

M E T A P H O R オニギリで覚える PREP 🍙 オニギリ法で覚える 美味しいオニギリは、 外側に【海苔】 (= 結論 ) 、 中に【ご飯】 (= 理由・具体例 ) 、 中心に【具】 (= もう一度結論 ) 。 話も同じ構造で 組み立てると伝わりやすい。 P ( 海苔 = 結論 ) 💡 覚えるコツ ・外側 = 印象に残る ( 最初と最後 ) ・中身 = 裏付け ( 理由と例 ) R+E ( ご飯 = 理由 + 具体例 ) ・形が崩れたら オニギリじゃない ・順番が大事 P ( 具 = 結論 ) 比喩で覚える 3 / 14

E X A M P L E 1 進捗報告で比べてみる ✗ PREP なし ○ PREP で報告 「あの、昨日からテストコードを書いてて、 昨日は 3 時間くらいかかって、 ユーザー登録機能のテストで、 モックの使い方が難しくて、 ネットで調べたんですけど… その、まだ終わってなくて…」 P: 「ユーザー登録のテスト、 予定より半日遅れます」 → 上司 : 「で、進捗は ? 」 R: 「モックの書き方で詰まっています」 E: 「具体的には AuthService のモックで、 返り値の設定方法が分からない」 P: 「明日の朝、 30 分時間いただけませんか ? 一緒に見ていただきたい」 → 上司 : 「了解、明日 10 時から 30 分」 進捗報告の例 4 / 14

E X A M P L E 2 質問のしかたで比べてみる ✗ PREP なし ○ PREP で質問 「すみません、ちょっといいですか ? あの、ログインの画面なんですけど、 ボタン押しても反応しなくて、 昨日はうまくいったんですけど、 今日になって変なんです、 コードはいじってないつもりで…」 P: 「ログインボタンが反応しない原因の 切り分けを手伝ってほしいです」 → 先輩 : 「で、何を聞きたいの ? 」 R: 「昨日まで動いていたのに、今朝から クリックしても API が呼ばれません」 E: 「 DevTools の Network タブを見ると、 リクエスト自体が出ていない状態です。 コードは main ブランチのままです」 P: 「 15 分でいいので、画面を一緒に 見ていただけますか ? 」 質問のしかたの例 5 / 14

H O W T O B U I L D P の作り方 ── 結論を一文で P Point ── 結論 「最終的に何を言いたいか」を、最初に一文で言う 1. 一文で言える長さ 「○○です」「○○したい」「○○できません」など、 20 字以内で言える形にする 2. 主語と述語を明確に 「○○が」「○○を」を省略しない。誰の何が結論なのかを言う 3. 言いにくいことほど最初に 「実は遅延します」「分かりません」「変更したいです」を後回しにしない P の作り方 6 / 14

H O W T O B U I L D R の作り方 ── 理由は 1 〜 3 つに絞る R Reason ── 理由 「なぜそう言えるのか」を、根拠として示す 1. 「なぜなら」「理由は」で始める 接続詞を意識的に使うと、聞き手が「ここから理由だな」と認識できる 2. 1 〜 3 つに絞る 理由を 5 つも 6 つも並べると、印象が薄くなる。最重要のものを 1 〜 3 つに 3. 事実と意見を区別する 「データを見ると…」 ( 事実 ) と「私はこう思います」 ( 意見 ) を混同しない R の作り方 7 / 14

H O W T O B U I L D E の作り方 ── 具体例で納得を作る E Example ── 具体例 「実際にこういう場面 / データがある」と裏付ける 1. 数字・事実・固有名詞を入れる 「 3 時間」「 AuthService 」「 DevTools 」など、具体的なほど信頼感が出る 2. 自分の体験を使う 教科書の例より、自分が触ったコード・経験した出来事の方が説得力がある 3. 1 つで十分 ( 必要なら 2 つ ) 例を並べすぎると論点がぼやける。一番強い例を 1 つ選ぶ E の作り方 8 / 14

H O W T O B U I L D 最後の P の作り方 ── 締めて、相手の動きを引き出す P Point ── 締めの結論 最初の P を繰り返す + 相手にしてほしい行動を添える 1. 最初の P を言い換えで繰り返す コピペではなく、別の言葉で同じ結論を再提示すると印象に残る 2. 相手にしてほしいアクションを添える 「 30 分時間ください」「レビューお願いします」など、次のステップを明示する 3. 短く締める ダラダラ続けない。最後の P は一文〜二文で。聞き手が「ここで終わり」と分かるように 最後の P の作り方 9 / 14

E X E R C I S E 練習 ── 自分で PREP を組み立ててみる 📝 課題 「あなたが今、興味がある技術 1 つを、 5 分以内で PREP で紹介する文章を書いてください」 ( ヒント ) ○○ を学んでいて、特に○○の点が良いと思いま ( ヒント ) なぜなら○○だから / 理由は 2 つあります す P Point R Reason ( ヒント ) 例えば、先週やった○○では○○でした E Example 練習問題 ( ヒント ) なので、○○を学ぶ価値があると思います P Point 10 / 14

P I T F A L L S PREP でよくある失敗 3 つ P が長すぎる 1 ✗ 「最近進めている XX 機能のテストコードのカバレッジについて、現状の状況をご報告したいのですが…」 ○ 「テストカバレッジが目標の 80% に到達しました」 E が抽象的 2 ✗ 「いろいろ調べた結果、たぶんうまくいくと思います」 ○ 「公式ドキュメントの該当節と、 Stack Overflow の 3 件の回答を確認した結果、この方法で動きます」 最後の P がない 3 ✗ 「…という状況です」 ( で終わる ) ○ 「…という状況です。なので明日、 30 分時間をいただけますか ? 」 よくある失敗 11 / 14

W H E R E T O U S E PREP を使う場面 ── 毎日のチャンス 💬 朝会・夕会 📝 日報 進捗報告、詰まり点の共有 今日の振り返り 💪 使う場面 ❓ 質問するとき 🎤 面談・ 1on1 Slack ・口頭での質問 上司に相談・提案 📧 メール・チャット 📊 ドキュメント 依頼・報告・相談 技術記事・社内資料 PREP は 1 日に何回も使うチャンスがあります。意識的に練習することで、 1 ヶ月で習慣になります。 12 / 14

C O N C L U S I O N PREP は、 伝える型 ではなく 相手を尊重する型。 結論を先に言うのは、 相手の時間を大切にする姿勢の表れ。 📌 今日から、まず「結論を一文で言う」ことから始めよう。 13 / 14