PMとコミュニケーション
「コミュニケーション・プロトコルWG 」
〜ITベンチマークSIG〜

　コミュニケーションが成り立たなければ、要求定義は出来ないし、アーキテクチャは伝わらず、問題は伝わってこない。コミュニケーションはプロジェクト管理の原点である。しかし、ひょっとすると、プロジェクト・リーダが、コミュニケーションが成り立っていないことに気がついてないことさえある。
日印中の人々が集まって、「どうすれば、伝わるコミュニケーションができるか」を掲記WGで検討してきた。その成果を昨年「SEのためのヒューマン・コミュニケーション・プロトコル」として纏めた。
　今年の6月に、コミュニケーション・プロトコルと、プロジェクト管理技術のセミナーをPMAJ主催で開催する予定である。興味ある方は、是非受けていただきたい。
ここでは、伝わるコミュニケーションについて、簡単に紹介しよう。

---

1． コミュニケーションとツール
　課題管理表や故障票など、プロジェクトでは様々な報告や纏めがなされる。これらの書式には、状況をどう測定(測定方法)するかと、どう情報を伝えるか(コミュニケーション・ツール)の2つの面を持っている。測定方法の観点で見るとプロジェクト管理技術と言うことができるが、ここではコミュニケーション・ツールの観点で以下述べることにする。
　書式は、言葉・数字、あるいは、これらを図や表にしたもので表されている。言葉で存在する伝えたい情報(言葉)を、伝えるための構造が書式に込められていると考えてよい。
伝えるための構造だけでは不十分で、イントネーション、ジェスチャ、言葉の選択などが、情報を伝えるときに重要な働きをする。これらも、コミュニケーションのツールであり、これらを、総動員して伝わりやすくすることが、伝える側の責務である。

2． 書式と理解
　情報の受け手を考えてみよう。理解出来ると言うことはどういうことだろうか。前項で挙げた書式の中の故障票で考えてみる。故障票は、多くの暗黙の了解の上に成り立っている。まず、「故障」とは何か。また、故障票の中にある「現象」「原因」と言う言葉には、そのプロジェクトや業界でので共通理解の上に成り立っている。「そんなことはない、全ての言葉は定義してある」と言う人がいるかもしれない。その定義は、また、言葉の暗黙の理解の上に書かれている。
上で述べたように、理解出来ると言うことは、情報の渡し手と受け手に共体験があることだ。私の経験では、初めてのお客様とのシステム開発は上手くいかなかった例が多いが、2度目、3度目の開発では、問題を起こしたことがない。これには、いくつか理由があるが、理由の一つは、二度目,三度目の開発では、利用者と開発者の共体験が増え、コミュニケーションが通じる土台が出来上がったためであると考えている。

3．そこでどうするか
上で述べたように、情報の受け手が理解出する程度は、情報の受け手と渡し手の共体験の大きさにかかっている。従って、理解する(させる)には、第一に共体験を大きくすることである。共体験が少ない時は、擬似的に共体験を得る場を設ける。
共体験を補うものとして、第二に、「暗黙の了解である可能性がある部分」を双方が事前に知って、伝達したい情報の誤解を防ぐ方法がある。この一部は、掲記WGでコミュニケーション・プロトコルとして明らかにした。
第三に、伝えたいことを、伝わる様に言える(書ける)ことである。少なくとも、私が受けた学校教育では、どう解釈するは沢山学んだが、どう伝えるかについては、ほとんど習ったことがない。情報を伝える側がいかに伝わるように整理し表現するかが、情報の受け手の解釈する力に加えて必要なのだ。

IT-SIG，内容にご意見ある方、参加申し込みされたい方は こちらまでメールください。歓迎します。

ITベンチマーキングSIGホームページは こちら