プロジェクトのコミュニケーションにメールが向かない理由

プロジェクトでメール使いますけど、メールは能力不足というか機能不足でプロジェクトには向かないと思うのです。なぜそう思うかとじゃあどんな観点で選べばいいの、みたいな話です。

コミュニケーションのためにメールを使う
メール、電子メールですからね。お手紙です。対面で意思伝達できない状況を代替する機能ですから、書いて、送って、返事をもらって。

メールに書かれるお手紙の内容はメールを書く人の文才に１００％依存します。また、その書かれた内容はメールの受け手の言語解釈の能力に依存してしまいます。

簡便に言えば、書き手と読み手が同一である保証はないので伝えたいことは伝わらる保証はないし、読み手が書き手の伝えようとしていることを理解し反応するとは限らない、という暗黙の前提があるわけです。

現実の世界ではその点は無視されていますが。

メールした人だけにしか届かない
メールを送るタイミングで宛先として指定したプロジェクト関係者に送ることはできますが、その時点の、という制限がつきます。プロジェクトでであれば、将来、具体的には来月参加するメンバがいるとして、そのメンバには送らないという情報の断面が生じるのです。しょうがないというかそういうものだ、なのですが。

メールを使うことはプロジェクトの情報を意思伝達するために道具として使うわけで、そうした道具が情報の伝達に向いているのかどうかを考えている人はどのくらいいるのかなと思ったり。

目の前にPCのクライアントにあるから使っているのでは。

プロジェクトのコミュニケーションは意思決定の情報を残したい
と思うんですよ。そして再読することを可能としたい。この仕様はどういう経緯で決まったのか、なんて結合試験や総合試験になったときに繰り返される質問です。

新規の参画メンバにプロジェクトの説明をするときにはざっくりとしか伝えられる情報しか持ち合わせていなくて、あとはわからなかったら聞いてね、とやっているでしょう。それって途中参加する人にとっては「なんだかなー」と思うんですけどね。

いや、わざわざワタシのためにまとめて欲しいのではなくて、情報が一元管理されていないことの方を憂いれしまうというか。これからのプロジェクトでも整理されていない、一元化されていない散らかった情報を自分で探さないといけないことが予見されますから。

じゃあ、どうすればいいか
コミュニケーションツールとしての要件を挙げるなら、やりとりしたことがそのまま何らかのリポジトリに残るようになっていることです。

単純に目の前にあるメールを使うならプロジェクトのメールアカウントを作ってそれを全部のメールのCCに入れておくとかそれを勝手にやってくれるメールのアドオンツールを使うとか。

でも、プロジェクトの規模や１日のメールの流量で破綻しそうですね。良さそうでダメなのは欠落は救えないところでしょうか。そうするとやっぱり何しかしらアプリケーションサービスの上で、全量そこに記録していくほかなさそうです。

コミュニケーションは何を生むか
元に戻して、プロジェクトでコミュニケーションする理由は意思伝達するためなんですが、その意思伝達で生むものは意思伝達の結果とその結果による成果物のアウトプットがあると思うんですね。

プロジェクトだからこそ、アクティビティには成果物が紐付きますから。逆に言えば、成果物が生じないアクティビティはないのですね。

ということは、コミュニケーションをとるということは意思伝達と成果物の２つのものを生むということも言えます。コミュニケーションツールはその両方を扱えた方がいいということが言えます。

メッセージの記録と成果物を一元的に記録できる機能を有するものであること。

この要件を押さえられたコミュニケーションツールを選ばないと情報が散逸してプロジェクトで得られるノウハウも学びも属人的な振り返りだけでしか得られなくなってしまいます。