プロジェクトのメールを減らすには

担当するプロジェクトによって１日のメールを受信する量が桁違いだったりします。量的な意味でひどいプロジェクトなんて夜だけで１００通も流通していて、朝にメールボックスを開くと「うげぇ」ってなったこともありました…（遠い目）。

一方、全く流通量が少ないとコミュニケーションが取れていないのかな、なんて心配したりするのですが。

夜に何通来ようが昼間に２００通メールが届こうが宮ければならないメールは読むしかないわけで、そうでもないメールはそれなりに処理しなければならないわけです。

ただ、メールを読むことが仕事じゃないことを忘れてはいけないのですが。

メールはプロジェクトチーム外からとチーム内のメールがある
プロジェクトの中で取り交わすメールをプロジェクトチームを中心に見ると、チームの外の人たちと遣り取りするメールとチームの中で遣り取りするメールに分けることができます。プロジェクトのメールの流通量を制御したいならこの観点で段階でやっていくといいです。

メールはコミュニケーションツールであるということ
なぜメールをするかといえば、コミュニケーションをとりたいからです。これはどうすればいいのか、あれはどうなっているのか、などなど日々書いているメールは確認や承認のために取り交わしてるのです。

ということは、その行為の目的がある限りコミュニケーションは減らないということです。

ではメールを削減するなんて出来ないのかといえばそんなことはありません。ただし、代替策があれば。

代替を考えるときに
メールを他のコミュニケーションに代替する場合、メールが持つ機能を押さえることと、代替するコミュニケーションの学習について理解しながら代替策を実行するかを考えるとよりスムーズに移行できます。

・電子データとして残る
・時系列で記録できる
・分類できる
・検索できる
・学習コストが安い

電子データとして残る　は、再利用を前提としているためです。チーム内ならホワイトボードで情報交換をしても良いですが、チーム外や遠隔地がある場合、ホワイトボードに書いたことをいちいち電子データに興し直すようならそれは無駄ですよね。

時系列で記録できる　は、経緯を把握するとか物事を整理するときにタイムスタンプがあれば簡単に参照できるからです。

分類できる　はメールフィルタやフォルダのようにビューで目的に合わせて視認性を得るためです。

検索できる　は、これどうしてこうなったんだっけ、と後になってから思い出すために必要なことです。プロジェクトの後半になってよくおきます。

学習コストが安い　は、代替策を導入するときに利用者が全員習得しなければ代替策は失敗になってしまうので移行しなければなりませんから、そのための代替策自体のコストもあるし、それを習得する人が習得にかける時間などなど全部のコストが安くないと、結果的に高価なおもちゃになりかねません。

プロジェクトチームの中と外で使い分ける
実践した例からいえば、プロジェクトチームの外とはこれまで通りにメールはコミュニケーションツールとして使い続けます。ただ、添付データの遣り取りはセキュリティの確保されたストレージに移行し、本来のコミュニケーションだけに利用を移行する方や良いでしょう。

プロジェクトチームの中では、trracやredmine、gitなどのチケットでタスクを管理するシステムを導入できるなら全部をそうしたシステムに移行する方が良いです。メールは注意喚起などのリマインドに特化した方が良いでしょう。

プロジェクトチームの外も中も同じようにできると良いのですがタスク管理のシステムはチーム外の未経験者にとってはとっつきにくいものですし、ツールを強要することはプロジェクトに対して壁を感じてしまうので無理強いにならないように配慮が必要です。

プロジェクトのメールの流通量を制御したい場合、なんらか代替策が必要になります。