PM(プロジェクトマネジャー)が情報共有のために、メールにファイルを添付してプロジェクト関係者に一斉に送ることは多い。このとき、メールの本文の内容が「添付ファイルをご覧ください」だけではいけない。

 「添付したファイルで伝えたい要点は何か」「添付ファイルを見て、何を確認すればよいのか」といったことがメールの本文に書かれていないと、受け取り手が、いったん添付ファイルを開いて一読し、その内容からPMが伝えたい要点を自分でつかみ取る必要が出てくる。

 場合によっては、受け取り手は要点さえつかめればわざわざファイルを開いて確認することはなかったということも、プロジェクトでは起こる。そういったムダな手間をかけさせることが繰り返されると、受け取り手が不快感を強く感じ士気も低下しかねない。それを防ぐためにも、「添付ファイルをご覧ください」だけが本文内容であるメールは送ってはいけないのだ。

ユーザーの窓口担当者になったDさんのケース

 SIベンダーに所属するDさんはあるユーザー企業のプロジェクトにPMとして参画。サブシステムの一つについてはユーザーとの窓口担当者も兼務することになった。利用部門の担当者からメールで届く問い合わせに対してプロジェクトの現場に確認してから回答したり、利用部門の担当者からの要望を踏まえてプロジェクトメンバーに指示を出したりする。

 プロジェクトが始まり、要件定義と設計のフェーズに入ってから、Dさんは、「スピード感ある対応」をモットーに窓口担当者としての仕事をこなした。利用部門の担当者から届いた問い合わせメールはできるだけ早く現場メンバーに展開。現場のメンバーから回答がない場合はまめに声をかけて回答を促した。利用部門の担当者からも、その働きに対する評価は高く、Dさんもいきいきと仕事をしていた。

 しかし、フェーズが進んでいくと、メンバーからの回答がない場合が増えてきた。Dさんが声掛けしてもメンバーの反応はつれない。プロジェクトの一体感もなかなか醸成できなかった。

 それでもなんとか設計フェーズは予定通り完了。Dさんは打ち上げをプロジェクトメンバーとやることにした。その打ち上げの場で、Dさんはメンバー同士の以下の会話が気になった。

Yさん:Dさんからのメールが大量に来るけど、自分の仕事に関係あるのだけ来るといいんだけどなぁ。
Sさん:そうそう。添付ファイルを見てくれって書かれてあるだけでしょ。それで見てみると自分の仕事に関係ないことが多いんだよな。添付したファイルをなんで見なきゃいけないのかを、いちいち添付ファイルを開いて確認するのが面倒なんだよ。メールにちゃんと書いておいてほしいよな。

 打ち上げが終わったあとでも、この会話が気になったDさん。翌日、プロジェクトルームで仕事を始める前、過去の自分の送信メールをチェックしてみた。すると「自分のメールはことごとく本文に内容がない」ということに気付いた。例えば以下のようなメールを送っていた。

各位

懸案事項だったモバイル対応の件ですが、添付ファイルのようになりましたのでご連絡します。

D

 このメールでは、受け取り手は添付ファイルを開かなければ用件や要点は分からない。以下のように書いておけば、受け取り手はこの本文だけ読めば事足りたはずだ。

各位

懸案事項だったモバイル対応の件ですが、従来型の携帯電話は対象外とし、iPhoneとAndroid端末のみ対応することになりました。

具体的な機種やバージョンへの対応予定は添付ファイルをご覧ください。

D

 こういったメール本文であれば、機種やバージョンを詳細に確認する必要がある受け取り手だけが添付ファイルを開いて読めばよい。「添付ファイルの要点を本文に書かなかったことで、メンバーは添付ファイルを確認しなければならなかった。それがメンバーにストレスを与えていたので士気は上がらず、私のメールに対する反応もよくなかったのか。自分もまだまだだ」。Dさんはこう反省したのだった。