全てのプロジェクトでコミュニケーションに起因するトラブルの芽を抱えている

プロジェクトがトラブルを抱える理由に必ずあげられるのはコミュニケーションです。それについては何度かこのブログでも取り上げていますが、この点についてエンジニアであれば違和感を持つことはないでしょう。ただ、これから述べることについてを除いて。

プロジェクトがトラブルになりその原因を調べると失敗したプロジェクトで必ず出てくる要因は定番ばかりなのです。

・コミュニケーションが不足していた
・チームの壁があった
・情報連携がうまくいかなかった

本当は他にあって、こうしたよく見かける原因を並べておくことで真因を隠しているのではないかと思うくらいです。

これまで、トラブルプロジェクトを経験すると再発防止策を求められ、それに対応するための原因と言ってしまったことと真反対のことを方策として掲げることになるのです。

トラブルの原因がコミュニケーション不足だったのだから、コミュニケーションを増やす場を作るとかコミュニケーションツールを導入することを対策とするわけです。

まあ、そうなんですけどね。

ちょっと発想を変えてみませんか、と言いたいのです。

不幸にもトラブルとなったプロジェクトで誰がコミュニケーションを必要とさせてしまったのでしょうか。

実は、プロジェクトを始めるときには既にエンジニアに対してコミュニケーションを取らせるような制度設計をしていたのではないか。

そう考えると新しい面が見えてきます（と思うのです）。

コミュニケーションは、知らないことを知る必要があるから要求が生まれるのです。同じように、知っていることを知らしめる必要があるからコミュニケーションを取らなければなら義務が生じるのです。

ではなぜこのような状況が生じるのでしょうか。プロジェクトにおいて担当エンジニアに作業がアサインされる流れを簡便に表現すると次のようになります。

工程→作業分解→WBS→作業分担→作業

プロジェクトではチームを編成します。それは1人ではプロジェクトの目的を実現できないためであることもこれまでのエントリで述べていることです。

では1人でだったらどうでしょう。

工程→作業分解→WBS→（作業分担→）作業

1人で作業するので作業分担に当たる括弧書きの作業は不要です。もちろん、誰ともコミュニケーションを取る必要もありません。なぜなら、作業分担をしていないからです。

これとても大事なところなのですけれどピンときましたか。それとも何言っているんだ、でしょうか。当たり前と思ったら固定観念に縛られていると思いますよ。

プロジェクトにおいてコミュニケーションの障害、いや、コミュニケーションそれ自体を必要とさせていたのはプロジェクトで作業分担を前提とした作業プロセス自体にあった、ということです。

さて、どう解決するか。もう、世の中の一部には解決方法があるようですけれどね。それも原因、いや真因がわかれば手立ては取りようがありますから。