本日も乙

ただの自己満足な備忘録。

「Team Geek」を読んでチームづくりについて学ぶ

最近、チームリーダーになったことでチームマネジメントに関してアンテナを張って学んでいます。今まで1、2人でプロジェクトやタスクをこなすことが多く、チームとして動くという意識が薄かったため、チームマネジメントに関して必要性や興味をあまり持っていませんでした。そんな自分がチームリーダーになってしまったのでチームを動かすことについて一から学んでいる状態です。

そんな折に、とある社外のエンジニアと会って相談したところ、「Team Geek」をおすすめされました。ページ数が少なく、今の自分に置かれている状況に合っている内容だったのでサクサク読めました。本書から多くの気づきを得ることができましたが、今回は特に良かった内容を紹介します。

Team Geek ―Googleのギークたちはいかにしてチームを作るのか
Brian W. Fitzpatrick(著), Ben Collins-Sussman(著), 及川 卓也(解説), 角 征典(翻訳)
オライリージャパン (2013-07-20T00:00:01Z)
5つ星のうち4.5
¥2,420

HRT(謙虚・尊敬・信頼)

巻末にHRTだけは覚えておいてほしいと書かれているぐらい、HRT(謙虚・尊敬・信頼)が本書で最も重要です。HRTは「ハート」と読み、謙虚(Humility)・尊敬(Respect)・信頼(Trust)の頭文字を取ったものです。「あらゆる人間関係の衝突は、HRTの欠如によるもの」と書かれているぐらい重要です。

HRTの実践

HRTが大事なのはわかったけど、どうすれば身につくのでしょうか。本書ではいくつかの方法が紹介されていました。

エゴをなくす

自分が何でも知っていたり、重要であるという態度を相手に取ったり、自分の利益だけを優先するような言動を取っていると、その人と働きたくないと思いますよね。エゴをなくすことが謙虚を大事にすることに繋がります。間違いやすいのが、エゴをなくす≠自信を持ってはいけないということではありません。自信は持ったほうがいいのですが、相手にそういう印象を与えないようにしましょう。言い方や態度を改めることで、エゴがなく自信をもって意見を主張することはできます。

エゴをなくすのは「個人」であり、チーム全体のエゴやアイデンティティは育むべきであると書かれています。チーム全体のエゴはこだわりやアイデンティティの成長に繋がり、チームカラーとして出てくるのだと思います。

間違いや能力不足を素直に認める

自分の弱さや間違いを認め、示すことは勇気がいりますが、結果として周りから信頼を得ることにつながります。さきほどのエゴにも関連しますが、自分を大きく見せようとかよく思ってもらおうとすると、間違いや指摘に対して認めづらくなります。そして最終的に大きな失敗という結果になってしまいます。

本書では一人で抱えてしまうリスクについて取り上げています。プロダクトやコードをできてから見せよう、完成していないから馬鹿にされてしまうと一人で抱え込んでしまうと、周囲からフィードバックを得ることができず、失敗する危険性が高くなります。失敗を恐れず、アイディアを具現化することが大切です。

正直になることも必要です。マイナスのフィードバックをする際に、ついつい「褒め言葉のサンドイッチ」をしてしまいがちですが避けるべきです。ただし率直に伝えるのではなく、言い方を変え、批判はしないようにしましょう。

まずは自分から適用する

HRTはあらゆる影響範囲に提供可能です。まずは、自分自身から適用するところから始めましょう。自分が変われば周囲も変わってくるはずです。次にチーム、そしてチームをリードする方法に適用します。チームに適用するということは心理的安全性を高めることにつながってきます。 *1

ミッションステートメント

人によってはミッションステートメントを定めたからといって何の意味や効果を持たないと思うかもしれません。本書でミッションステートメントを定める目的として「やること・やらないことを明確にする」とあります。個人的に「やらないことを明確にする」点において納得感がありました。頼まれたことを何でもやってしまうとやりたくないこと・やらなくてもいいことまで引き受けてしまい、チーム全体のモチベーションやパフォーマンスが上がらないと思っています。チームとしての方向性や、やりたいことについてよく考えたり議論することがあるのですが、「やらないこと」を明確にしたほうが方向性が定めやすいと思うようになりました。

ミッションステートメントを定めるときに抽象的だと何も言っていないのと同義になってしまい、言葉遊びに終わってしまうので、定めるなら具体的にわかりやすいものにしなければなりません。また、置かれている状況が変化の激しい場合は定期的に見直すべきです。

個人的には(自身の置かれている状況によりますが)チームよりも、プロダクトやプロジェクト単位でミッションステートメントを定めたほうが良いと考えます。チームとして「やらないこと」を決めたとしても社内事情でどうしてもやらざるを得ない場合もあり、ミッションステートメントを破ってしまうことで逆にダメージを受ける可能性があると思います。プロダクトやプロジェクトも同様の可能性はありますが、プロジェクト発足してから作るもの・スコープがある程度定まっているため、大きくブレる可能性は低いと思います。また、プロジェクトやプロダクトとして「やること・やらないこと」を決めることで、余計な機能を開発したり、外部からの過剰な期待を抱かせてしまう危険性を減らす効果を持ってくれるはずです。

サーバントリーダー

新人マネージャが陥りがちなのがマイクロマネジメントをしたがる病。その病を治すのが「サーバントリーダーシップ」です。サーバント(Servant)は「奉仕者、召使い」という意味です。チームに奉仕すること、HRTの雰囲気をつくるのがリーダーの役割と書かれています。そのためには社内の障害物を取り除いたり、チームの合意形成を支援したり、チームが順調に進めるように穴を埋めるといった役割を担います。技術的側面とチームの人間関係の両方を管理していきます。

チームに奉仕といってもなんでも言いなりになるのではなく、メンバーが働きやすい状況をつくり、サポートするのがサーバントリーダーだと思います。

最後に

チームマネジメントの本なので今まで敬遠していましたが、リーダーでない人もおすすめできる内容でした。HRTを実践することでチーム内の雰囲気が良くなり、働きやすい環境にしていけると思うので、もっと早く読んでおけばよかったです。

*1:次に心理的安全性に関する書籍を読む予定です。