LESSON 30分

文書コミュニケーション（Slack, メール, PR）

ストーリー

「Slackでのやり取りがうまくいかなくて...... 質問したのに反応がなかったり、 長文を送ったら『要約して』と言われたり」

渡辺マネージャーが答えた。

「テキストコミュニケーションは、対面以上に工夫が必要だ。 表情や声のトーンが伝わらないからね。 Slack、メール、PRの書き方にはそれぞれコツがある」

Slack コミュニケーション

メッセージの書き方

質問のテンプレート

【質問】[タイトル（何についての質問か）]

■ 背景
[なぜこの質問をしているか]

■ 調べたこと
[自分で調べた結果]

■ 質問
[具体的な質問]

■ 期限
[いつまでに回答がほしいか]

実例:

【質問】検索APIのページネーション実装方式について

■ 背景
検索APIのページネーションを実装しています。

■ 調べたこと
- カーソルベース: 大量データに強い、しかし「〇ページ目に飛ぶ」が難しい
- オフセットベース: シンプル、しかしデータ量が多いとパフォーマンス劣化

■ 質問
当プロジェクトではどちらの方式を推奨しますか？
ユーザー数は現在1万人、1年後に10万人の想定です。

■ 期限
明日（水曜）の午前中に方針が決まると助かります。

やってはいけないこと

NG理由改善
「ちょっといいですか？」だけ送る内容がわからず不安にさせる用件を一緒に送る
長文を一気に送る読まれない構造化し、要点を先に
@channel を乱用全員に通知が飛ぶ本当に必要な人だけメンション
スレッドを使わないチャンネルが散らかる関連する話はスレッド内で
既読無視「見てるの？」と不安にさせるリアクションか「後で対応します」

スレッドの活用ルール

メインチャンネル:
  「検索APIのパフォーマンス問題について相談です」
    └─ スレッド:
        ├─ 詳細な状況説明
        ├─ 田中: 「インデックス設計を見直しましょう」
        ├─ あなた: 「調べてみます」
        └─ あなた: 「解決しました。インデックス追加で200ms→50msに改善」

  ※ スレッド内で結論が出たら、メインに結論を投稿する

メール コミュニケーション

メールの基本構成

件名: [プロジェクト名] [用件の種類] - 簡潔な内容

本文:
[宛先]さん

[1行で用件を伝える]

[詳細（必要な場合）]

[次のアクション/依頼事項]

[署名]

件名の書き方

悪い件名良い件名
お疲れ様です[ECサイト] 検索機能リリース日程の確認
質問[ECサイト] 【質問】決済API仕様の確認
確認お願いします[ECサイト] 【要返信/2/15まで】設計書レビュー
(件名なし)[ECサイト] 【報告】Sprint 5 進捗報告

メールの使い分け

Slack を使うメールを使う
チーム内の日常的なやり取り社外・他部門への正式な連絡
即レスが期待される質問記録として残したい内容
カジュアルな相談承認・決裁が必要な内容
短いステータス更新長文の報告書・提案書

PR（Pull Request）コミュニケーション

PR 説明文のテンプレート

markdown
## 概要
[このPRで何をしたか、1〜2文で]

## 変更理由
[なぜこの変更が必要か]
Closes #123

## 変更内容
- [変更点1]
- [変更点2]
- [変更点3]

## テスト
- [ ] ユニットテスト追加/更新
- [ ] 動作確認済み
- [ ] CIパス

## スクリーンショット（UI変更がある場合）
| Before | After |
|--------|-------|
| [画像] | [画像] |

## レビュー観点
[特にレビューしてほしいポイント]
- `src/search/query.ts` のクエリ最適化部分
- ページネーションのエッジケース処理

レビューコメントの書き方

レベルプレフィックス意味
必須修正[Must]マージ前に修正が必要
提案[Suggestion]できれば対応してほしい
質問[Question]理解のための質問
称賛[Nit] or [Nice]良い実装への称賛、軽微な指摘
レビューコメントの例:

[Must] この部分、N+1クエリが発生しそうです。
ループの外でデータを一括取得した方がよいと思います。

[Suggestion] ここは早期リターンにすると
ネストが浅くなり読みやすくなりそうです。

[Question] この例外処理でcatchしてログだけ出していますが、
呼び出し元にエラーを伝えなくて大丈夫ですか？

[Nice] このユーティリティ関数、すごくきれいに書けていますね。

レビューを依頼する時のコツ

Slackでの依頼:

  @tanaka PR #234 のレビューお願いします。

  - 変更規模: +200行（主にテスト）
  - レビュー時間目安: 20分
  - 特に見てほしい点: DBクエリの最適化部分
  - 期限: 明日午前中

テキストコミュニケーションの注意点

トーンに気をつける

テキストは対面より冷たく感じられがちです。

冷たく感じられる:
  「動きません」
  「バグです」
  「これは間違いです」

柔らかくする:
  「こちらの環境で動作しないようです。確認いただけますか？」
  「バグの可能性がありそうです。調べてみましょうか？」
  「ここは〇〇の方が良さそうに思うのですが、いかがでしょうか？」

非同期コミュニケーションの心得

原則説明
相手の時間を尊重即レスを期待しない。緊急時は電話
コンテキストを含める相手がスレッドを追わなくても理解できるように
結論を先に長いやり取りの途中でも、結論が出たら要約する
見やすくフォーマット箇条書き、コードブロック、見出しを活用

まとめ

ポイント内容
Slack構造化した質問、スレッド活用、リアクション
メール件名に用件、結論ファースト、正式な連絡に使用
PRテンプレート活用、レビュー観点の明示、レベル付きコメント
トーンテキストは冷たく感じられやすい。柔らかい表現を心がける
非同期コンテキストを含め、相手の時間を尊重する

チェックリスト

  • Slackでの質問テンプレートを使える
  • メールの件名を適切に書ける
  • PR説明文のテンプレートを活用できる
  • レビューコメントにレベルを付けられる
  • テキストのトーンに配慮できる

次のステップへ

次のセクションでは、「会議を効果的に進める」スキルを学びます。ファシリテーション、議事録、会議の効率化テクニックを身につけましょう。

推定読了時間: 30分