マネージャとコミュニケーション

はじめに

Being Geek の 37 章「マネージャとコミュニケーション」の内容が印象に残ったので、内容を抜粋して書き留めておきます。

37章 マネージャとコミュニケーション

誰かがマネージャになる場合、その「なり方」には大きく分けて次の 3 つの種類があると思われる。

• 本人がその道を選ぶ。「自分はエンジニアよりもマネージャに向いているに違いない。だから、マネージャを目指す」
• 自然の成り行き。特に「なろう」と決めていたわけではないが、小さな選択や行動がいくつも積み重なった結果、いつの間にかマネージャになってしまう、というパターン。
• 有無を言わさず命令される。「今すぐマネージャになれ」と言われ、選択の余地は与えられない。

たとえどのパターンであっても、マネージャになるのであればかなっらず理解しておくべきことはあるので、次にそれについて触れることにしよう。

すべてがリスタート

特に自分からそう望んでマネージャになったのではない場合、よく理解していない人が多いのだが、マネージャになると自分を取り巻く環境は大きく変わってしまう。たとえて言えば、相変わらず同じゲームを続けているはずなのだけれど、ゲームボードがまったく違うものに変わってしまっているという感じ。つまり、また「振り出し」からすべてやり直し、ということである。あなたが仮に非常に優秀なエンジニアだったとしても、今までに培ってきたスキルはもはやほとんど役に立たない。今までは違うスキルを獲得し、磨いていかなくてはならないのだ。
そのことを最も実感するのは、1 日の終わりだろう。1 日の終わりに「今日、自分は何を作ったんだろうか」と問い直すことはある。だが、マネージャになると、その問いへの答えは「何も作っていない」になってしまう。「正午までにバグを 10 個潰すぞ」などと考える日々はもう終わったのだ。もう、コードのことを考えながらバスに揺られることもない。考えることと言えば、「あの件をあの人にどう話せばいいだろう」ということばかりだ。本人は聞きたくないだろうが、大事なことなので言わなくてはならない。どうしたらいい。そんなことばかり考えるのだ。言えば騒ぎになるに違いない。そんな騒ぎは誰も望んではいないけれど、避けることはできない・・・・。

ミーティングが増える

すでに分かっている人も多いだろうが、マネージャはミーティングの多い仕事である。私は個人的にミーティングが嫌いで、できるだけ減らそうと努力をしているのだが、それでも多くのミーティングに出なくてはならない。もちろん、非常に役立つミーティングもある。私の知る限り、役立つミーティングは大きく 2 つの種類に分けられる。「調整のためのミーティング」と「創造のためのミーティング」の 2 つだ。

調整のためのミーティング

これは文字通り、皆の意見を調整するためのミーティングである。多くの人が賛成しているけれど、中には反対している人もいる、そういう案件があるときに開くことが多い。なぜ、皆が賛成しているのか、その理由を反対者に詳しく説明して、納得してもらう。

創造のためのミーティング

何か必要なものがあって、それをどうすれば獲得できるかを話し合うミーティングである。知識のある人間に意見を求めることが中心になる。

この　2 種類以外のミーティングもあり得るが、それはたぶん、役立つものとは言えないので、できるだけで開かずに済むよう努力すべきだ。たとえば、私が「セラピーミーティング」と名付けている種類のミーティングはそれにあたる。意思決定をするわけでもないのに、相反する意見をただ、長々と聞くだけ、というミーティングだ。
経験を積めば、どのミーティングに出るべきか、また出るべきでないかはわかってくるだろう。しかし、はじめのうちは何もかもすべて出席してしまう。それではとても時間が足りない。

コミュニケーションのハブ

マネージャにとって何より重要な仕事は、コミュニケーションの「ハブ」になることである。部内の人間のコミュニケーションだけでなく、部署の外とのコミュニケーションにおいてもハブにならなくてはならない。これはつまり、いくつもの会議室に出向き、人の話を聞くことに膨大な時間を費やさなくてはならないということだ。大変なことである。出席者がそれぞれどういう人で、何を求めているのか、何を話しているのかといったこともよくりかいしなくてはならない。そして必要なときにきっぱり「ノー」と言わなくてはならないだろう。そうしないと状況が悪化することがある。
困るのは、マネージャの場合、うなずく以外にすることがないようなミーティングにも、時には出なくてはならないということだ。ただ、いるだけで価値がある、ということもある。キャリア形成ということを考えると、「ただうなずいているだけ」のマネージャになるということは得策とは言えない。それでも、皆の言い分の聞き役になることが何より重要、という場面はあるのだ。他に何をするより、それが役に立つことがある。
だが、いつもただ、話を聞いているだけというわけにもいかない。話されていることの少なくとも一部は、自分が率いるチームに関することである。自分のチームに関することならば、状況に応じて、手短に適格なコメントをすべき時もある。

抽象化とフィルタリング

コミュニケーションのハブになるということは、自分の受け取った情報を他の誰かに伝える、「中継」をしなくてはならないということだ。だが、受け取った情報を何もかも、そのままの形で伝えればいいというわけではない。たん夏中継だけをしているのでは存在の意味がないのだ。話を抽象化したり、いくつかをまとめたり、不要な部分を削ぎ落したり、といった操作も必要になる。たとえば、30 分間のミーティングで聞いた話を、自分のチームのメンバーに伝えるときは、3 分に圧縮するということも時にはしなくてはならない。
「30 分も費やして聞いた話を、どうしてそんなに短くしなくてはならないのか」と思う人もいるだろう。その気持ちはわかるが、その方が結局、自分のストレスは軽減されることになるのだ。ミーティングで 30 分かけて聞く話と、あとで 3 分に圧縮した話は、実は同じ話ではない。詳細な部分をどこまで知っておくべきかが人によって違うからだ。的確に圧縮して伝えることをしなければ、結局、うまく伝わらず、またミーティングを開く羽目になるだろう。

部署によって違う言語の翻訳

同じ会社でも、部署が違えば話す言葉が違う。もともと、はなずべきことが違っているので、必然的に言葉も違ってくる。マネージャは、社内の関係部署の「方言」のすべてをはなせなくてはならない。例えば、開発部と検査部では、言葉が違っているだろう。両社の間の健全な緊張感を維持するには、マネージャが双方の方言を操って情報伝達する必要がある。1 つのバグをめぐって 1 週間も激しいやりとりが続くこともあるだろう。両方の言葉が違うのは、目標がそれぞれに違っているからだ。マネージャは、言葉の違いだけでなく、目標の違いも把握しなくてはならない。各部署の目標を簡単にまとめると次のようになるだろう。

• 営業部：製品を売ること、その製品を作るのにかかる手間にはあまり関知しない。
• マーケティング部：ブランディング。顧客満足の向上。会社および製品の外部での評価を高めること。彼らが熱心に主張することは、エンジニアからは的外れに見えることが多い。
• テクニカルサポート部：日々、直に接する顧客に納得してもらえる説明をする。

監理部の人間は、部署ごとに違う「方言」を自在に操ることができる。彼らの持つ影響力が意外なほど大きいのはそのためである。
誰もがみんな、自分の仕事で重要で、なくてはならないものだと信じている。そして、誰もが皆、他人の仕事は自分の仕事より簡単だと信じている。困るのは、この考え方が必ずしも間違っていないということだ。
どの仕事も理由があって存在する。どの部署にも、他にはない独自の役割がある。他部署で使われる奇異な略語を耳にするとつい笑ってしまうし、からかいたくもなるが、マネージャなら、その言葉を覚えて使わなくてはならない。その部署がどういうところで、何を求めているかを少しでも理解するためには大切なことである。
特にマネージャになったばかりの人間にとって、他部署の言葉を覚えるのは容易なことではないだろう。当初の戸惑いが消えるのに 3 か月くらいはかかるかもしれない。

ドラマを最前列で見る

混沌としたドラマを「最前列」で見るのはマネージャだけである。マネージャは、見たドラマを要約し、部下に分かりやすく説明する訓練をしなくてはならない。

変化球

マネージャをしていると、絶えず、いろいろな方向からそれぞれにスピードが違う「変化球」が飛んでくる。たとえどんな「クセ球」であっても、うまくさばくのが仕事だが、時には身をかわし、すぐに次の球（もっとひどいクセ球かもしれない）に備えることも必要になる。
マネージャに次々とそういう変化球が飛んでくるのには理由がある。「直球」であれば、どれも部下たちが対処してしまう。また、そうでなくては困る。ほんの些細なことで部下がいちいち相談に来るようなチームをつくってはならないだろう。つまり、良いチームを作れば作るほど、「マネージャのところに来る「球」は、どうしようもない変化球ばかりになるということだ。
変化球が飛んできた場合、まずは 3 つのことについて判断を下さなくてはならない。1 つは、この件のもともとの担当者がどの程度、冷静かを確認することも大切だ。変化球が鼻先をかすめたところで、冷静さを失っている可能性はある。果たして適切な対処ができるだろうか。それとも、おびえて逃げ出してしまうだろうか。
リーダーの役割は、仕事を着実にかんりょうさせることだけではない。何か予測不能な事態が起こったときに、冷静に振る舞い、部下を落ち着かせるのも大切な仕事だ。

「ノー」と言う

「ノー」と言うこと、それはマネージャにとって強力な武器である。読者の中にはマネージャもいれば、これからマネージャになろうという人もいるだろう。マネージャになど絶対にならないと思っている人もいるに違いにない。だが、ともかく創造してみてほしい。仮に自分がマネージャで、何か大変な案件を任されそうになっているとする。そのおかげで、朝 4 時に目が覚めてしまう。そういうときこそ、マネージャは「ノー」と言うべきなのだ。
きっと、それはとても対処のできない案件なのだ。期日どおりに要求されたものは作れないだろう。QA はテストができないだろう。取り組めば、きっと失敗する。そういう時は、はっきり「ノー」と言わねばならない。
マネージャでなくても、「ノー」という権利はある。だが、一般の社員が「ノー」と言う場合は、マネージャに「なぜノーと言うのが正しいのか」を説明する必要があるだろう。そして、その説明を聞いて納得したら、マネージャが「ノー」と言うのだ。
マネージャは、部下の代わりに「ノー」という代理人と言うことだ。部下の話を聞き、何かを止める方がいい、しない方がいいということが明らかになれば、即、「ノー」と言う。そうして、組織が勝機を失っているときに、自分のチームを守る。
「ノー」と言えば、当然、それによって何かしらの影響はあるので、それにも対処しなくてはならない。言いっぱなしというわけにはいかない。あくまでもこれは最後の手段である。自分の力を誇示するためにやたらに「ノー」と言うようになってもいけない。だが、うまく使えば有効な武器であることは確かだろう。

「イエス」と言う

「イエス」は始まりの言葉である。単に肯定を意味するだけの言葉ではない。物事を前に進めるきっかけとなる言葉だ。何か新しいことを始めるときも、重要な人が辞めてしまうなど、困ったことがあったときも、困難な問題に立ち向かう時も、前進するには、まず自分たちの置かれた状況をありのまま受け入れることが必要である。
また、時には、現実離れした「イエス」が必要なこともある。普通に考えるとできそうもないことが、ひとまず「イエス」と言って取り組むことで、思いがけ内発送が浮かぶこともあるからだ。根拠がなくても、まずは「イエス」と言うべき場合もある。

スケーリング

エンジニアからマネージャになったばかりの人は、何か予想外の困った事態に直面すると、エンジニアに戻ってしまうことが多い。エンジニアだった頃になじんでいた方法に戻ってしまうのだ。何もかもを自分ひとりで解決しようとする。その方が安心できるからだ。だが、マネージャとなったからには他人を、部下を信頼して任せなくてはならない。
マネージャにとって大切なことはいくつもあるが、その 1 つは「スケーリング」である。マネージャになったら、もともと自分の持っているスキルをスケーリングしなくてはならない。エンジニアだったときにバグ修正に超人的な能力を発揮していたのだとしたら、マネージャとしては、チームが全体としてその超人的な能力を発揮できるようにしなくてはならないのだ。
自分のまなんできたことを、部下に分かるように翻訳して教えていく必要がある。そして、学ばせるには、信頼して任せるということが必要だ。以前なら、自分でしていたことを任せてしなうのである。
信頼することで、良いフィードバックグループが生まれ、徐々に生産性は上がり、満足のいく仕事ができるようになっていく。部下を信頼することでスケーリングができ、自分と同じクオリティの仕事を、自分ひとりのときよりはるかに多くこなせるようになる。多くの仕事をこなすほど、多くの経験ができ、多くの学ぶことになる。そうしてたくさんのことを学び、理解すれば、それだけ、教える材料も増え、さらにスケーリングを進められるだろう。