PG、SE、PM に求められるコミュニケーションスキルの違い

　この記事のまとめ。長文エントリごめん。

1. 「コミュニケーションスキル」と一言でくくられるが、中身は多岐に渡る
   
2. プログラマ（PG）は、「確認するスキル」が最重要
   
3. システムエンジニア（SE）は、「絵にするスキル」が最重要
   
4. プロジェクトマネージャ（PM）は、「言うことを聞かせるスキル」が最重要
   
5. コミュニケーションは全人格的なスキルで、その真髄は「人を動かす」こと

　ン十年前、入社したての頃はCプログラマだった。その後、SEとして仕様折衝、設計に携わった。時折、炎の海に放り込まれ、コードを書いたりテストをしたり、リアルバトルを止めに入ったりと火消し屋のキャリアを積む。

　その後、PM見習いでチームリーダーをしているうちに、要件定義のさらに上流に引き寄せられ、今では開発現場を離れてコンサルタント（非IT）の丁稚をしている。

　システム開発の工程を河上へ遡及するにつれ、スキル不足を痛感した。わたしに最も足りないのはコミュニケーションスキルなのだが、どのコミュニケーションスキルが足りないのかは、その仕事にどっぷり浸かって初めて気付くのが常だった。

「コミュニケーションスキル」は多岐にわたる

　一般に、「コミュニケーションスキル」とひと括りにしがちだが、それは間違い。コミュニケーションスキルは多種多様にあり、一語にまとめるのは誤解を招く。

　例えばこうだ。

　コミュニケーションの「目的」からすると、「聞く」「伝える」だけでなく、「（相手の思いを）想像して汲み取るスキル」、「（汲み取った思いを）絵にするスキル」、「説得するスキル」、「自分の意思に従わせるスキル」が挙げられる。「言いたいことは分かったがダメ」では、ガキの使いやあらへんで。

　もっと掘り下げると、「自分の思いをしぐさや態度で伝えるスキル」と「情報は伝えるが思いを伝えないスキル（ポーカーフェイス）」が出てくる。必ずしも言葉を要しないところがポイントやね。

　コミュニケーションの「方法」から見てもスキルが沢山あるぞ。(1)会って話す→verbal/non-verbal 。verbal でも oral/literal 。oral でも1対1 、1対多、1対すげー多…　(2)メールで伝える…　(3)電話で伝える…と、それぞれのシチュエーションによって求められるものは全然別もの（適当な訳語が思いつかないので英語でカンベン）。

　てっとり早くいってしまえば、同じ writing でもホワイトボードを前にしたときとメーラーに打ち込む場合と別でしょ、ということ。理路整然とメールで言ってくるのに、ホワイトボードだとちっちゃな字で読めねぇ人、いるでしょ?

　さらに、同じ「コミュニケーション」でも、その間柄により変わってくる。例えば、「初めて会った人とうちとけられるスキル」、「慣れた間柄でも軋轢を生まないように厳しいことを伝えられるスキル」、「知っている人、知らない人大勢を前に伝えるスキル（プレゼンテーションスキル）」、「上下関係」、「請負元先」が挙げられる。

　もっと具体的に言うなら、こうだ。派遣社員のお姉さまとは楽しくおしゃべりできて、キツめの仕事もソツなく伝えられるのに、常駐先の部長には「全部優先じゃ分からないにょ」と言いたいのをガマンする（でも顔に出る）。

　これ全部「コミュニケーションスキル」の一言で片付けられる。コミュニケーションは全人格的な行動だけれど、くくり過ぎ。コミュニケーションスキルの重要性は誰も異論がないにもかかわらず、各論に入ると拡散したりテクニカルに走ったりして本質を見失うのは、これが原因。

　あらあら、前フリが長すぎた（あらあら禁止！）。以降、PG、SE、PMのステージ毎に必要なコミュニケーションスキルを考察してみる。

プログラマ（PM）の場合

　日経○○で「できるプログラマのコミュニケーションテクニック」という枕詞がよく使われる、本質は「確認するスキル、というかクセ」だろう。なんのこっちゃという前に、仕事ができるプログラマの口癖を思い出してみてみよう。

　デキるプログラマは、話をじっと聞いた後に必ずこう言い出すはず。「結局この件は、…にしたい、ということなんですね?」。つまり、「つまり」で始まるまとめを自分の言葉で返している。その結果、「そこは違うよ」「それでオッケー」がその場で得られる。

　一般に、プログラマは言葉を字義通り解釈しがち。いや、それはそれで正しいんだが、厳密に文字通り解釈しようとして、言葉と言葉の間にある「伝えたい意味」を取りこぼしてしまう場合がある。

　例えば、帳票仕様で「注文発注指示書」と「注文書」が出てきたとする。言葉が違っているので別物だと解釈し、がんばって両者の違いを見出そうとする。紆余曲折の末、訊いてみたら同じもので、後者が略称だったというオチはよくある（逆もまた然り）。

　だから、「それって…なんですよね」という確認は重要。よくある言い分「書いてある通りに作りました」「言われた通りにしてあります」は確かに正しいのだが、ホントにそれで良い? と自問してみるべし。

システムエンジニア（SE）の場合

　SEと言っても守備範囲は幅広い。顧客やPGとの相対距離で分類分けしたくなるが、ここでは共通して重要なコミュニケーションスキルを一つ挙げる。それは「絵にするスキル」。相手が言っていること、自分が言いたいことを簡潔な絵にして、見せるスキル。

　これはホワイトボードの前に立つ誰かを思い浮かべてみるといいかも。ミーティングが沸騰してくると、ツイと席を立ち、マーカーを手に、飛び交う論点を箇条書き＋簡単な絵にまとめる。絵はシステム構成だったりUMLやDFDだったり、それらをごちゃ混ぜにしてあったり。

　いるでしょ、そんな奴。

　たいていかろうじて読める下手な字なのだが、不思議とすんなりと理解できる。ポイントは次の3点。

　　1. 全員の意見がモレ・ダブリなく載っている
　　2. 合意できているところ、議論すべきところが、きっちり描かれている
　　3. 絵にした瞬間、全員に「分かる」形になっている

　1. と2. ができるということは、MECEができていること。そんな奴はえてして「MECEて何?」とくるが、用語を知らなくて体得できている好例。また、3. ができるということは、1 : n のコミュニケーションができている。

　PGなら極端な話、1 : 1 のコミュニケートだけで仕事になる。プログラマに仕様を伝えられる翻訳者を1人用意すればよいからだ。しかし、SEだとそんなわけにいかない。複数を同時に納得させる必要が出てくる。1 : n のコミュニケート。上手に言葉を尽くすのも一法だが、素早く的確に分かってもらうには絵が一番。

　また、絵には問題点をあぶりだす効用がある。「人 対 人」で議論がヒートアップしたときに有効なのが、ホワイトボード。

わたし　→→→【問題】←←←　あなた

　フツーの議論ならこれでいいんだが、白熱してくると、

【問題】　わたし　→→→←←←　あなた　【問題】

　となり、問題ではなく相手の言動に視線が行くようになる。テーブルをはさんであなたを熱く見るようになる。"you to me" の構図やね。このとき、ホワイトボードに絵を描くと上手くいく。

わたし　と　あなた　→→→　ホワイトボード【問題】

　アラ不思議、"problem to us"の構図になる。文字のヘタクソを罵りながらホワイトボードの絵を理解しようとし、取り組むべきは【問題】であることに気付くというわけだ。育ってきた新人を「外」に出してもいいかな? と判断するとき、ホワイトボードの前の姿で決めている。

プロジェクトマネージャ（PM）の場合

　ここから自信たっぷりに書けなくなる。なぜなら見習いだから。だいたいわたしの周りのPMって、キャラとハートがおおまかカバーしてる人ばかり。オレについてこい！というやつやね。人情味あふれる親分肌で、仕事場よりも酒場で学ぶことが多いね。

　テクニカルなスキルはアレな人が多く、ほとんどの人は最新の技術なんて「知ったこっちゃない」と言い切る（をい！）。結果、「プロジェクトマネジメントって何?」「失敗プロジェクトの数だけ、成長できる」てな感じで、もはや時代遅れなのかもしれないが、巨大プロジェクトには必ず登板する。

　その人をアサインする監督の気持ちは痛いほど分かる。もはや経験則だけでマネジメントできないのに、その人をアサインせずにはいられないのは、

　・成功した場合→やっぱりアノひとだったから
　・失敗した場合→アノ人を投入してもダメ（だから誰を入れてもダメなはず）

つまり、どちらに転んでもアサインした自分の責任を追及されずにすむから。

　時代を感じさせる（かもしれない）PMの最重要コミュニケーションスキルはコレ→「言うことを聞かせるスキル」。情報を正確に伝えるのがコミュニケーションの基本かもしれないが、そもそもコミュニケーションの目的は、伝えた後に相手の行動を促すこと。それも、自分の望んだ方向へ動いてもらうことこそが、コミュニケーションの真髄なり。

　「言葉のキャッチボール」や「相手の気持ちを汲み取る」など、柔らかめに表現されるため、この真実が見えなくなっている。まといつく全ての修飾子を取り除くと、コミュニケーションの本質は「自分の意思を伝えて、相手に行動を呼び起こす」ことに尽きる。的確に伝える、過不足なく伝える、タイムリーに伝える、相手のコトバで伝える　…等など、全ては「伝えた結果、相手に動いてもらう（自分の動かしたい方向へ）」のためなり。

　これに気付かないまま、自分ではキチンとコミュニケートしたつもりでいると、「ちゃんと言ったんですけどねー」「分かろうとしないアイツが悪い！」というグチになる。つまり、「意思を伝える」のが目的ではなく、「伝わった意思どおりに動いてもらっていない」からだ。

　スゴいPMは、人を動かす。ご自身の経験を思い出して欲しい。スゴいPMに重たい話を持ちかけたり、逆に持ってこられたとき、その会話の最後の言葉はこんな感じになってるはずだ。

キミの話はよく分かった。とても大変なことも分かる。だが、この仕事はキミにしかできない。それは私が保証する。だから、頼む、やってくれ。

　んで、スゴければスゴい人にけしかけられるほど、話の終わりごろにはヤル気、ソノ気、気合充分になっているはず。その具体的なやり方は、D.カーネギーの「人を動かす」に書いてあるが、これを読んでいる／読んでいないにかかわらず、彼らは体得している。

　やり方は分かる。人を動かすだ。しかし、それを身につける良い方法が分からん。まぁ、practice あるのみなのだが。 practice ついでに小話で締める。確か「達人のサイエンス」だったはず。

　ニューヨークを訪れた観光客が道に迷った。街角の老人に「カーネギーホールにはどうすれば行けますか?」とたずねると、老人はこう言ったそうな。

　" Practice ! "