本稿の要約を10秒で
- 他者への真摯な思いやりがなければ、効果的なチームマネジメントはできない。
- チームのマネージャーは、チームを代表し、チームの価値観や使命を体現しなければならない。
- コミュニケーションとアカウンタビリティ（自己責任・説明責任）の文化を築けば、タスク管理は自ずと容易になる。
- 「ヒト・ファースト」のチームマネジメントとは、メンバーに対し、個々人の幸せや願いの追求を奨励することである。
あなたは人を大切にしていますか？
人をマネージする仕事は決して複雑なものではない。ただし、例えば、IT技術者として豊富な経験がある、あるいは有能であるからといって、ITチームをリードする立場になれるわけではない。そのため、私のようにITチームをマネージしたいと考えているメンバーたちから、次のような質問をよく受ける。
「マネージャーになるためにどんな経験を積むべきなのでしょうか？」
「マネージャーになってから学んだことは何ですか？」
「優れたチームマネージャーは、各メンバーに何に注力するようアドバイスすべきなのでしょうか？」
私はITチームのマネージャーの職務に就いてから9年になる。その経験から言わせてもらえば、チームマネージャーを目指す人たちが自問すべき最も重要な事柄は、上記3つの質問には含まれていない。その事柄とは以下の問いかけである。
「あなたは人を大切にしていますか？」
かく言う私もITチームのマネージャーになりたいと考え、その当時、自分のチームのマネージャーだったアーチャナ・ラオ（Archana Rao／現アトラシアンCIO）にこう尋ねたことがある。
「私がマネージャーになるには何が必要ですか？」
それは2012年2月のことだったが、ラオの返答をいまでも鮮明に覚えている。それは次のような答えだった。
「私は、あなたの技術スキルや仕事にとても満足しているし、優秀であることは十分に理解しているつもり。でも、あなたは人と接したり、人を扱ったりするのが得意なのかしら？本当に人を大切にしている？その自信がなくて肩書きだけが欲しいのだったら、マネージャーになろうなどとは考えないほうがいいと思う」
こう言われたとき、自分の欠点や浅慮を突かれたようで初めは少々落ち込んだ。だが、彼女の指摘を幾度か反芻しているうちに、それが的を射たアドバイスであったことを理解することができた。そう、人を率いるリーダーになりたかったら、プロジェクトや会社の成功、あるいは自分自身の成功を気にかけるだけでは不十分であり、自分のリーダーシップに依存している人々の成功を第一に気にかけなければならないのである。
チームマネジメントの心得“10カ条”
以上の観点を踏まえ、私がチームをリードする中で大切にしている原則を、マネジメントの10カ条としてまとめて紹介する。
第1条：意思決定者ではなく、意思形成者であれ
これは、私が最も大切にしているマネジメントの原則だ。自分の過去の経験からも「チームがうまく機能するのは、マネージャーが意思決定を下したときではなく、メンバーに意思決定をさせたときである」と言い切れる。
また、私は米国スタンフォード大学に留学していたとき、問題解決における「イケア効果（IKEA effect）」について学んだことがある。これは、多くの人が自分で組み立てたIKEAの家具に親近感や愛着を抱くように、チームのメンバーに問題解決の施策を考えさせることで、その施策を自分たちの“子ども”ように大切に感じる効果を指している。
この効果を、スタンフォード大学のバーバ・シヴ（Baba Shiv）教授は、別の言い方で次のように表現している。
人は、他者が作った洗練されたプロトタイプに対して欠点を探そうする。ただし、ラフなプロトタイプに対しては、自ら可能性を探ろうとする
もちろん、チームの意思決定にマネージャーが一切かかわる必要がないわけではない。大切なことは、意思決定の形成を手助けすることである。そのためには、チームのメンバーに適切な質問をして、それぞれの経験や考え方の共有を促す必要がある。このとき留意すべきことは、マネージャーが答えや結論を与えてはならないという点だ。それによってチームの意思決定に相当の時間がかかる可能性はあるが、一方で、メンバーたちの自律的な判断力と決定事項を守ろうとする意欲は高まっていくのである。
チームの意思形成には、対面式のコミュニケーションや、アトラシアンの「Team Playbook」にある意思決定フレームワーク「DACI」を適用することができる。いずれの手法を使うにせよ、チームメンバーによる意思決定を促すことで、彼らは自分たちだけでなく、関係するチームへの影響についても自ずと考えるようになる。
ちなみに、意思形成のアプローチを採用するチームマネージャーの中には、メンバーが最善の意思決定を下せるよう、分析や提案、あるいは建設的な批判を行う人たちもいる。そのアプローチは決して間違いではないが、私自身は、チームを育成してメンバー各人のモチベーションを高め、より良い意思決定とアクションに結びつけることを大切にしている。自分の好む結論にメンバーたちを誘導するようなことは避けている。
第2条：アカウンタビリティの文化を根づかせる
チームのマネージャーは、あらゆる機会をとらえてチームに「アカウンタビリティ」の文化を根づかせることが大切である。ここで言うアカウンタビリティとは、自分が約束したこと、あるいはコミットしたことには責任を持つという意味だ。その文化をチームに根づかせるには相応の努力が必要とされるが、必ずチームの信頼性とパフォーマンスの向上につながっていく。
私はマネージャーになりたてのころ、メンバーの仕事の遅れにかなりナーバスだった。そのため、チームのステークホルダーたちを失望させないよう、締め切りが遅れそうなメンバーの仕事を自ら引き受けてこなしていた。
そんな私の姿勢を問題視した当時のマネジメントコーチから、次のようにたしなめられたことがある。
「プラナフさん。あなたのやっていることはステークホルダーにとっては有益かもしれませんが、チームのメンバーたちは自分が約束したことの責任を果たすという、とても重要なことを学べていません。チームマネージャーの重要な役割は、メンバーが成長するうえでの障害を取り除くことと、リスクをマネージすることの2点です。チームのメンバーがビジネス上の約束を守れないなら、その根本原因を突き止めて必要なリソースを確保することがあなたの仕事です」
このアドバイスに従うかたちで、私はアカウンタビリティの文化をチームに根づかせる作業にとりかかった。その作業とは、以下のようなルールを定めたうえで、そのルールに対するメンバーたちの同意を得ることである。
- プロジェクトとその日程にコミットする前に、自分の状況と能力について熟考すること
- 一度コミットしたら、その約束を守ること。状況が変わった際には必ず再交渉すること
また、自分が期待するメンバーの態度や行動についても、メンバー全員とオープンに話し合った。こうしたオープンな対話は、アカウンタビリティルールに対するメンバーの抵抗感を小さくし、お互いを尊重する風土の醸成につながったと感じている。
第3条：「タスク」よりも「人」を重視する
タスクよりも人を重視することで、チーム内での人と人とのつながりが強まり、ときには、仕事上の関係を超えた強い友情が生まれることもある。
私はマネージャーとしての経験を積み重ねる中で、チームのメンバーを単なる従業員ではなく、一人の人間として知り、理解することの大切さを学んできた。ゆえに、メンバー全員との1 on 1ミーティングやランチミーティング、コーヒーミーティングを定期的に欠かさず行ってきた。また、新型コロナウイルス感染症の流行前、オフィスにチームの全員が集まって仕事をしているころは、メンバーと散歩に出ることも間々あり、互いにリラックスしてより良いコミュニケーションをとることを心がけてきた。
こうしたコミュニケーションをメンバーと重ねることで、私は話し上手になり、聞き上手にもなった。言い換えれば、人に対して純粋に興味を持つようになり、いまでは、メンバー各人の体験や物事のとらえ方、趣味・嗜好、さらには日常の出来事などに耳を傾けることに喜びを感じるようになっている。一方で、メンバーと仕事の話をする機会は減っていったが、それとは反比例するようにチームのパフォーマンスは上がっていったのである。
第4条：努力が報われなかった理由を明確にする
チームで想起したアイデアが不採用になり、プロジェクトが立ち上げられないことがある。その場合、プロジェクトが立ち上がらない理由をチーム全員が理解しているかどうかを必ず確認しなければならない。
当たり前の話だが、チームにおけるすべての努力が報われるわけではない。チームが必死になって練り上げたプロジェクトアイデアや取り組んできたプロジェクトが「ビジネス戦略の変更」や「アイデアに対する過小評価」「予算の縮小」「重要メンバーの異動・離職」「ROIやビジネスケースの見誤り」など、さまざまな理由によって“お蔵入り”になる、あるいは中止になることは往々にしてある。
ただし、理由はどうあれ、自分たちの努力が報われなければチームのモチベーションは確実に下がる。その負の影響を小さくする一手が、アイデア／プロジェクトが不採用／中止になった理由と意思決定のプロセスをメンバー全員に包み隠さず伝えることである。
私は以前勤めていた会社でITアーキテクトをしていた経験がある。そのころ、50人のチームメイトとともに、あるシステムの開発プロジェクトに携わっていた。それは会社の中核プロジェクトでもあり、すでに1,000万ドル強の資金が投入されていた。
ところが、プロジェクトも終盤にさしかかったある日、私を含むプロジェクトの中心メンバーは、システムのテスト中、システムの心臓部とも言えるような重要な機能がまったくスケールしないことに気づかされた。それに気づいた全員が1,000万ドル強の資金と50人ものチームメイトの努力を無駄にしたことへの恐怖に凍りつき、必死になって問題解決の良策を探した。だが、問題は致命的で、私たちが出さなければならない結論は一つだった。それはプロジェクトの中止である。
この出来事は、自分の携わったプロジェクトが消滅する経験をしたことのなかった私には相当のショックで激しく落ち込んだ。ただしのちの分析によって、プロジェクトをそのまま続けていれば開発されたシステムの維持に年間1,000万ドル以上の費用がかかっていたであろうことが判明した。それを通じて、私は「いまの痛みに耐えることは、のちの大きな痛みを避けることにつながる」ということを学び、同時にプロジェクト中止のショックも和らいでいったのである。
