nDiki : 2006年05月05日

2006年5月5日 (金)

■ ビジネスメールガイドライン案

スポンサードリンク

以前メールによる社内コミュニケーションの問題について書いて以来、いろいろと考えてみている。

そんな中、東洋経済新報社の「Think! SPRING 2006 No.17 超ロジカルシンキング」の中に参考になる記事を発見。照屋華子氏の「ロジカル・ライティング - 論理的に考え、伝えるための3つの鍵を身につける」という記事だ。

すべてのビジネス・コミュニケーションは「伝え手」「受け手」「テーマ」「答え」「期待する反応」という5つの基本要素で成り立っている。-- Think! SPRING 2006 No.17 p.43

おお、ちょうどこういう切り口を探していたところだったんだ。電子メールによるコミュニケーションも全く同じ枠組みである。記事の中ではロジカル・シンキングをコミュニケーションで生かすという話題を中心に展開しているが、十分メールの書き方に通じるものがある。

この記事と、さらにちょっと前に買った「SEの実力を磨く究極仕事術」のメール術の章を参考にガイドライン案のスケルトンを作ってみた。

感情論は今回は置いておいて、情報共有・課題共有・リクエストの明確化・処理促進をポイントに列挙。それから署名その他、一般的な話もいまのところ省略。

ポイントを列挙しただけなので、他人にもわかる形にはなっていない。

まずは自分自身に適用して、整理していってみることにする。

@ 1. 考える

【伝え手】伝え手は誰? (自分)
【受け手】受け手は誰?
【テーマ】テーマは何? 問いの形で。メールのテーマは1つに絞られているか?
【答え】テーマに対する答え(テーマに対する説明)は何?
【期待する反応】受け手に期待する反応は何?
- 誰に、いつまでに、何をどうして欲しい?
コミュニケーション手段としてメールは適切?

@ 2. メールを書く

 ○○様へ                     # 受け手

 △△の××(自分)です。       # 伝え手

 テーマ
 ******
 コミュニケーション設定

 ○○の結論                   # 答え (結論)
 ==========
 ...

 (ここまででポイントを言いきる。)

 具体的な内容                 # 答え (詳細)
 ============

 項目1
 -----
 ....

 - リスト項目
 - リスト項目

 項目2
 -----
 ...

 - リスト項目
 - リスト項目

@ サブジェクトを書く

見ただけでわかるようにする
- □ 具体的に書く

@ 導入部を書く

コミュニケーション設定を行う。

□ 冒頭に宛先【受け手】を明記する。(誰に読んで欲しいのか? 他に誰に送られているのか?)
□ 次に発信者【伝え手】を明記する。(From: フィールドに頼らず書く → 印刷・コピー用)
□ 【テーマ】を書く。
□ (オプション)【テーマ】の経緯・背景を書く。(「なぜこのテーマのメールがくるの?」)
□ (オプション)なぜこの【伝え手】からなのかを書く。(←「なぜあなたからリクエストされるの?」)
□ 【期待する反応】を明記する。
- □ 「誰が」「何を」「いつまでに」「どのような品質で」して欲しいのかを書く? (← 「で何をして欲しいの?」)
- □ 反応のメリットを書く (←「なぜこの反応をとらなければならないの?」)
- NG 「ご意見があればお願いします」 → ない場合は?
- NG 「どちらが良いと思いますか?」 → 意見として? 決定として?
- NG 「ご検討ください」→ 検討した後どうして欲しいのか?
□ (オプション)なぜこの【受け手】に読んでもらいたいのかを書く (←「何で自分なの?」)
□ 特記事項があれば書く
- □ 答えの情報源など

@ 答え (結論)

結論を書く。

□ 詳細まで読まなくても済むようにする。
- NG 「以下のように……」 → 要旨を書く
- NG 「添付ファイルの通り」 → 要旨を書く

@ 答え (詳細)

根拠・資料などを書く。

□ 受け手から見て必要十分な情報を書く
- NG 「添付ファイルの通り」 → 要旨を書く
□ 受け手が読みやすいように書く
- □ リスト化する

@ 全般

□ 具体的に
- NG 「来週までに……」 → 「×月×日までに……」
- NG 「先日の……」 → 「×月×日の……」
- NG 「この間の……」 → 「×月×日の……」
- 説明は肯定形で書く (否定形だと具体的に何なのかわからない)
□ 論理的に
- □ 構造化する
- □ リスト化する (箇条書き化する)
□ 受け手が読みやすいように
- □ フォーマットを工夫する (ソフトウェア技術者間なら reStructuredText がお薦め)