プロジェクト・コミュニケーションのベーシック 〜 情報のトレーサビリティを確立する

英語のCommunication と、日本語の「コミュニケーション」という言葉には、微妙なニュアンスの違いがある。わたし達が会話で「コミュニケーションが良くなった」などと語る場合、ふつうは双方向の意思疎通を意味している。「前の課長は向こうが一方的に命令してくるだけだったが、今度の課長はちゃんとコミュニケーションができるよな」という風に。もっと柔らかい言い方をすれば、『ふれあい』みたいな、感情面での同調というニュアンスを含む。

ところが英語のCommunicationは、原則として情報の伝達を意味している。それは、たとえ一方向でも成立する。だから、TV局が電波で大勢に向けて一方的に情報を発信する様な仕組みを、英語ではMass Communicationとよぶ。これは日本語でマス・コミュニケーションとなり、いつものように発音しやすい4文字言葉化して「マスコミ」になった（口頭では、コミュニケーションではなく「コミニュケーション」と発音する人がほとんどだ）。

PMBOK Guide(R)が、プロジェクトの10個のマネジメント知識エリアの一つとして、Communication Managementを入れたのはとても卓見だったと思う。だが、これを「コミュニケーション管理」と、ベタな日本語のニュアンスで捉えてしまうと、本質がずれてしまう。じゃあ赤提灯にいって酒でも飲んで、メンバー同士の「コミニュケーションを良くしよう」みたいな発想になりがちだ。だが、それではプロジェクト・コミュニケーションの半分も捉えていないことになる。

PMBOK Guide(R)は元々、大規模なプロジェクトのことを念頭に置いて作られた。だから、全員が顔見知りでない状態で、どのように知識・情報を確実に他者に伝達するか、ということが問題意識のベースにある。そこで「コミュニケーション計画」のような概念が出てくるのだ。そして実行段階は、「インフォメーションの配布」ということになる。英語のCommunicationは、一方向の配布がベースだからだ。どこにも“飲みニュケーション”みたいな話題の入る余地はない。この英語はむしろ、「情報伝達のマネジメント」と訳した方が、日本の読者にはピンときたと思う。

プロジェクトにおいてコミュニケーションが重要なことは、いまさら言うまでもないだろう。ただ、これほど我々にとって分かりにくく、つかみ所のない領域もない。PMBOK Guide(R)があげる10の知識エリアは、（全体を統合するProject Integration Managementを除くと）大きく二つのカテゴリーに分けられる。

A. スコープ、コスト、スケジュール（タイム）、品質

B. 人的資源、調達、リスク、ステークホルダ、コミュニケーション

上記のカテゴリーAは、いわゆる「ハード・スキル」に属する知識エリアである。つまり、定量的・計数的な管理技術として、かなり確立している分野である。そして、WBS、EVMS、CPM（クリティカル・パス法）、SQC（統計的品質管理）などの手法が開発されている。1950年代のクリティカル・パス法の発見が、モダンPMの誕生をうながした、という歴史も頭に入れておきたい。

そして「ハード・スキル」の特徴は、技術的手法論とツールが発達しているために、座学で習得が可能なことだ。むろん本で読んだり講義で聴いたりしただけでは不十分だ。自分で練習し実践してみないと、使いこなすレベルには達しない。しかし、知識を得ることによって、入門者は相当程度にレベルアップできる。なんとなく、自分にもできそうだ、と感じさせてくれる。

ところが上記カテゴリーBの方は、どちらかというと「ソフト・スキル」に近い面が強い。ソフト・スキルとは、日本語で『人間力』みたいな言葉を使いたくなるような、属人性の高い技能である。人を使う、業者を使う、危険を予知する、利害関係者とうまくやりあう、人に何かを伝達する・・。こうした能力にも、もちろん頼るべき原理原則はある。だからPMBOK Guide(R)でも苦心惨憺して、プロセスだのツールだのを説明している。だが、それを読んで、「うん、これなら俺もできそうだ」と感じる読者は希だろう。

プロジェクトにおけるコミュニケーション（情報伝達）の最大の目的とは何か。それは、次の二つに集約できる。

(1) 必要な知識・情報を、必要な人たちに、必要なタイミングで、最新の内容で伝える

(2) 伝えたことを確認し、トレーサブルにしておく

こうしたことは、PMBOK Guide(R)には明記していない（あの本は全体としてプロセス志向で記述しており、あまり目的志向には書かれない）。しかし、たとえばエンジニアリング業界ではもう何十年も前から、欧米を中心に、世界的にこの目的に従うやり方を守ってきた。

(1)についてはあまり説明の要はないだろう。上の表現はあえて、ジャスト・イン・タイムの「必要なものを、必要な量だけ、必要なタイミングで供給する」という言い方を真似て書いている。必要な情報のみを伝達し、余計なことで膨らまさない。必要な（そして正当なアクセス権限のある）人たちだけに、それを伝える。そして遅滞なく必要なタイミングで伝える。いずれも、当たり前のことだ。ちなみに、文書や図面情報の内容が最新であることがすぐ分かるように、リビジョン番号を明記することなどは、今時どこの業界でもやっているはずだ。

(2)の方は、しかし、業界によってはあまり常識化していないと思う。とくに「伝えたことを確認する」というのは、いささか欧米流に感じられるだろう。かの国々では『発信者責任の原則』でビジネス文化が動いており、相手に伝わるよう、ちゃんと伝えるのは、発信者側の責任だからだ。だからこそ、相手が分かったかどうか、自分から確認する。

ところが、わたし達の社会は『受信者責任の原則』で暗黙のうちに動いている。伝わらない・分からないのは、メッセージを受け取った側の、理解する努力が足りないからだ、ということになっている。分からないのは恥だから、質問も返さない。逆に「一度しか言わないからな！」と偉い人が怒鳴ったりする。こういう土壌を持った社会に、「コミュニケーション・マネジメント計画を立てましょう」などといっても、何のことやら、である。

トレーサブルという言葉には、多少注釈が必要かもしれない。「トレーサビリティ」という用語は、誰にも分かりやすいように選んだもので、わたしの勤務先では、「トラッキング可能」という方が通じるだろう。いずれも、後からさかのぼって、どういう経緯で今どこまでたどり着いているかを、明らかにできるという意味だ。ちょうど牛肉トレーサビリティと同じように、である。

このためには、すべての情報の伝達に、ユニークなIDをふることが必要になる。それは、わたし達の業界では、何十年も前の紙の時代から、実践してきたことだ。たとえば顧客に公式なレターを発信する。あるいはベンダーに仕様書を送付する。ベンダーから逆に承認図が上がってくる。これを協力会社の関係部署に送付する。こうした伝達行為はすべて、IDをふって、リストに記録する。たとえば、

T-YOC-ABC-0012

といった具合だ。最初の一文字は伝達の種類を表す（TならTransmittalで、書類の送付状である）。次に、発信者-受信者、を表すコードが来る。関連するステークホルダはすべて3文字の略号をつけるのがわれわれの慣例だ。最後は連番である。だから上記のIDは、

「YOCからABC社への書類送付状の12番目のもの」

という意味になる（YOCというのはYokohama Operation Centerの略で、わたしの勤務先の本社のことである。建設現場もあるためこういう表記をするのだ。どうでもいいけど）。これを連綿とリストに記帳していく。その書類送付状には、添付された一連の仕様書や図面の番号とリビジョンが記載されているはずだ。紙の時代だったら、この送付状は複数枚つづりになっていて、受け取った側は受領サインを記入して、返送する。こうして、受領確認が行われる。現代ではもちろん、こうした手続きはすべて電子化されているが、エッセンスは同じである。

だから仮に、後になってABC社と追加交渉でもめたときにも、「T-YOC-ABC-0012でこの図面はあなたに何月何日に送っていて、そちらも受信確認を返しているではないか」という風に証拠立てられる。言った・言わないの無駄な議論を省けるだけではない。情報を受け取った側も、お互いがそれを注意深く取り扱うようになる。

書類送付状ではなく、単純な文章による伝達（昔ならレター、今ならeメール）も、同様である。IDをふっておき、発信した内容、受信した内容は、プロジェクト・チームとしてセンター・ファイルしておく（これも昔なら紙、今ならデータベース）。チーム員はいつでも、それを探せるようにする。こうしたセンター・ファイルをきちんと持っているならば、少なくともそのプロジェクト・コミュニケーションは及第点であるといえよう。

そしてこういう手続きに従って、すべてのやりとりをトレーサブルにしておくよう、新入社員の時から習慣づける訳だ。これがわたしのいう、組織の「OS」の一部を形成していく。こうしたベーシックな行動習慣をチーム員みなが持って、はじめて、プロジェクト・マネージャーの能力が本来の仕事に生かせるようになるのである。