メンバーに対してチームリーダー(マネージャー)が気をつけるべき点

はじめに

現在ITエンジニア歴16年目でこれまでなんどかチームリーダー(プロジェクトリーダー)を経験してきましたが、数年前は上手くいっていたけど、ここ1年位のチームではなかなかうまく行かないことが多く、メンバーからのクレームが上長経由で伝えられてくることがあります。

クレームを伝えてくるメンバーの多くが経験が浅いエンジニア(若手、未経験中途入社)であり、まだITエンジニアとしての業務や商流が分かってない部分もあるゆえのエゴのようなクレームもあるのですが、中にはリーダーとして気をつけるべきだなと思ったことがあったので、まとめておきたいと思います。

なお、経験が浅いエンジニアと主語大きめに書きましたが、数年前にリーダーをした際にQAから転身したてのITエンジニアや、20台中盤くらいの方もいましたが特にクレームはなかったので「メンバーによる可能性はある」ということは書き添えておきます。
また、上手くいっていた際も単に報告しなかっただけで不満はあったかもしれません。
(一緒に働いてれば大なり小なり不満はあるでしょうし、報告しない=問題にならないなので結果的には問題ではなかったのかもしれませんが)

チームリーダーと書いていますが、プロジェクトリーダー、プロジェクト・エンジニアリングマネージャーなどメンバーのピープルマネジメントする方には通用する話だと思います。

メンバーを否定しないで肯定する

例え内心(それはないな…)と感じても表に出さず一度肯定してから伝えることが重要です。
当たり前に思えて意外とできてない人も多いと思います。
特に視座が低い、目的意識が低い、無いメンバーに対しては率直な感想が出がちですが、否定された!と感じてクレームになる可能性が高いので気をつけましょう。

例えば年次目標に3冊技術書を読むと言ったメンバーがいるとします。
この1年で3冊は普段から本を読む人からすると正直少ないと私は思います(思いました)
ですが、ここで素直に「少ないですね」と言ってしまうと否定された!とクレームになりかねません。
「まずは今年3冊確実に、来年から量を増やしていきましょう」などのように表現すると良いでしょう。

聞かれない限りアドバイスしない

否定しないに関連して、メンバーが否定された!と思う行動のひとつに勝手なアドバイスがあります。

オススメの本を紹介する、こういう行動を取ると良い、こういう考え方をすると良いと
アドバイスするのも、自分の選んだ本を否定された!自分の考えを否定された!となる可能性があるので、関連した話題が出ても明確に聞かれない限り、質問されない限りアドバイスしない方が賢明です。

ちなみにアドバイスしたら自分の考えを否定された!とクレームしてきたメンバーはリーダーになりたいとキャリアアップを臨んでおり、上長からリーダーについてアドバイスをして欲しい、次のキャリアとして後進育成もやって欲しいと言われた中でアドバイスをした結果のクレームです。
上昇志向がありキャリアアップを望んでいる人に対するアドバイスでもクレームになってしまう可能性があるのです。
そのため、上長からの依頼であっても、良かれと思っても、本人が望んでいても、明確に求められない限りアドバイスはする限りではないでしょう。

こちらに非があれば謝罪する

これも当たり前に思えて、会話の流れで謝罪せずに終わらせてしまうとクレームになることがあります。
また、リーダーが「そんな細かいこと…」と思っていてもメンバーは気にしているかもしれないので、きちんと謝罪する癖をつけておきましょう。

とはいえ、何でもかんでも謝罪しても仕方ないので、ポイントとしては指摘をした際が重要です。
リーダーとはいえ人間ですので勘違いもあれば、ミスもあります。
その際、間違った指摘をしてしまったときはきちんと謝罪をするようにしましょう。

ここで最初に書いた 会話の流れで謝罪せずに終わらせてしまう ケースが発生し得ます。
例えばメンバーの書いたコードを見ながら会話していて「ここ間違ってるよ」と指摘したのに設計書通りで正しかったという場合に「あ、私のミスだった。で、次は～」「ごめんね、で次は～」「すまん、違ってた。で、次は～」のように明確に謝罪しなかったり、しても流れでしているとリーダーが非を認めなかった!謝罪がなかった!とクレームが発生する可能性があります。
ここはきちんと「すいません、私が間違ってました。」と謝罪するようにしましょう。

指摘をする際はエビデンスを用意してから指摘する

一つ前の話の防止策にもなるのですが、メンバーに対して何かしらの指摘をする際はその指摘内容に誤りがあるとクレームの原因になります。
そのため、指摘する前にエビデンスを用意してから指摘しましょう。
もし会話の最中などで気づいた場合は「確認したい点がある」と言って一緒にエビデンスを確認してから指摘するようにしましょう。

無理難題を言われても断らず、かと言って確約もしない

チームメンバーからこうして欲しいという要望があっても、様々な事情でそれを叶えられない場合があります。
そういった場合に詳細に理由を説明し難しい、できないと回答しても、メンバーからするとリーダーが要望を聞いてくれない!というクレームになりかねません。

かといって、できもしないことを約束するのは悪手です。
その場は収まっても後で約束が守れないとなった場合に問題が悪化するからです。
また、過去にこの件についてTwitterで聞いてみたところ、リプくださった2名の方はできもしないことを約束されるより、詳細に理由を説明してほしいとのことでした。
このことからも空約束するよりも詳細に理由を説明した方が無難ではあります。

そこでまずは「理由があって難しいですが、実現できるように努力します。その理由としては◯個あって1つ目は～」のようにメンバーの意に沿う用にしつつ、できない理由を説明しましょう。
そして最後に「できれば要望を叶えたいと思っているので努力しますが、どうしても難しい場合はご理解ください」とまで言えばクレームにはなりづらいでしょう。
さらにこの説明は口頭で行った場合は文章にしておく(メールやチャットで送っておく)と安心です。
あとで蒸し返された際に説明を行ったエビデンスとなります。

プラクティスを押し付けない、正当化しない

システム開発には様々なプラクティスがあり、不確実性の高いシステム開発に対応するには日々やり方を工夫しないとうまくいきません。
ですが、チームメンバーはリーダーから振られたタスクをただこなせば良いと思っているケースがあります。
そういったメンバーに、効率がいいから、あなたのため(教育、スキルアップ)になるから、などと言っても響かないですし、プラクティスに割く体力、時間を無駄だと感じることがあります。
それらが我慢の限界を超えるとクレームとなってしまう場合があります。

そのため、リーダーが良いと思ったプラクティスでも、いまのタスクをこなすために効率が良いプラクティスでも、メンバーが嫌がりそうなら多少効率が悪いやり方でも従来のやり方で進めるのが良いでしょう。

実際にクレームがあったプラクティスとしてはペアプロ、モブプロ、アイスブレイクがあります。

ペアプロは疲れるから嫌

これはリーダー側から定期的に休憩を取るようにすべきだったのを作業が進みすぎてしまったがために休憩が取れず、拘束時間が長くなってしまったため、疲れるとクレームになってしまったケースです。

リマインダーやタイマーでもセットして強制的に作業を区切ればよかったですが、そういった工夫をしなかったためメンバーの疲労が溜まってしまう原因となりクレームに繋がりました。

定期的に休憩を取れば解決する話ですが、一度疲れると認識されると二度とペアプロやりたくないと思われてしまいます。

モブプロで汗をかくから同じキーボードを使いたくない、実装中のコードを見られたくない

これはメンバーが手汗をかくため、同じキーボードを使い回したくないということがありました。
それぞれがキーボードを用意してドライバー後退時にキーボードも交換することで解決しますが、本人は手汗を書くことを気にしているので根本的な解決にはなっていません。

またメンバーによっては実装中のコードを見られたくないという人もいました。
レビューはどうするのか?と聞くと我慢していると言っていたので、コードを見られるのが嫌という人もいるようです。
(正直チーム開発に向いてないんじゃないかと思いましたが、まぁそういう人もいるということでしょう)

早く作業したいのにアイスブレイクが長い

毎日の朝回で最初にアイスブレイクとしてハピネスレーダーをやっています。
この時間が長いため、朝回が長くなり、作業時間が削られて嫌というクレームがありました。
こちらはリモート開発で雑談が少ないことへの対策、ルーティンとしして毎朝行うことでモードを仕事モードに切り替えるなどの意味を持ってやっているわけですが、無駄だと思われているようです。

アイスブレイクにかかる時間としては5分以内、長くても10分以内に終わっています。
朝回自体も長くて30分です(チームは二人)
それでも無駄だと感じるのは意図が理解できてないか、業務を終わらせるためのタイムマネジメントが上手くできてないだけだと思います。
ちなみに意図はちゃんと最初に説明しています。
このあたりメンバーの認識が誤っているような気もしますが、クレームなのは違いないので嫌がるなら押し付けないでやめたほうが良いでしょう。
(ちなみにそのメンバーに朝会のふりかえりとして無駄な項目はないか?と聞いたら特に無いと言っていたので、アイスプレイクが無駄というクレームをしておきながら無駄な項目はないという矛盾した言動を取っています)

みんながみんなアジャイルなどが好きな訳では無い

ひとつ前のプラクティスを押し付けないにも関わりますが、ITエンジニアのみんながみんなアジャイルが好きなわけでもないですし、スクラムやXPなどの開発手法に興味があるわけではありません。
たとえアジャイルがどんなに素晴らしい考え方でもそんなことどうでもいい、割り当てられたタスクさえ終わればそれでいいと思っているITエンジニアもいるのです。

私はアジャイルやスクラムの考え方やが大好きなので、メンバーにもそう思って欲しいと考えてしまいますが、それは単なる押しつけにすぎません。
開発を進める上で明らかにアジリティが低い、問題があると思っても、それを理由にいきなり正論でアジャイル棍棒で殴ってもクレームになる可能性が高いです。

まずは他人を変えるのではなく自分で変えましょう、自分が変わりましょう。
開発に問題があれば黙々と手を動かして解決する手段を構築すればよいのです。
そして効果が出て感謝され、信頼貯金が溜まってきたら新しいプラクティスや考え方の提案をしましょう。

信頼貯金がない中で提案しても採用されづらいですし、正論でかかっても反感を買うだけで上手く行かない可能性が高いです。
それなら自分で手を動かしてまずは実績を作りましょう。

気づき

問題はリーダーorメンバーだけにある？→そんなことはない

ここまで書いて気づいたことですが(最初に少し書きましたが)、正直メンバーの受け取り方の問題とエゴな気がしています。
もちろん他責にするつもりはありません、リーダーである自分にも非はあったでしょう。
ですが、あまりにリーダーが気を使わなければならな過ぎると思いませんか?
それがリーダーだと言われればそれまでですが、個人的にはチームとはリーダーが作るものではなくチーム全員で作り上げていくべきものだと思っています。
リーダー一人がメンバーの顔色とご機嫌を伺い、クレームを起こさないようにチーム運営していくのはちょっと違うと思います。

チームで開発する理由と背負うべき責任

我々ITエンジニアはお客様(エンドユーザー)に価値を届けるため(そして対価としてお金をもらうため)に作業しているわけです。
そのための方法としてチームで開発することで個人での開発より多くの価値を届けようとしているわけです。
となれば、チームのアウトカムはチーム全員が責任を持つべきでリーダー一人が負うべきものではありません。
もちろんリーダーが負うべき責任のほうが役割上大きいのは事実ですが、だからといってメンバーが何も考えなくて良いということにはなりません。
メンバーもリーダーも人対人ではなく、問題対私達として捉え、日々変わっていく問題に対して用いる手段を最適化しながら立ち向かっていく必要があると思っています。

どうするべきか?

リーダーは最初にチームの運営方針を明確にしましょう。
これはインセプションデッキに近いかもしれません。

• 我々はなぜここにいるのか?
• やらないことリストを作る
• 夜も眠れなくなるような問題は何だろう
• 期間を見極める
• 何を諦めるのかをはっきりさせる
  あたりの項目はそのまま使えそうです(もちろん不要なら除いても大丈夫です)

あとは以下の項目が必要かと思います。

• チーム運営方針の合意を取る
  • 会議体
    • 朝会
    • 1on1
    • 定期的なふりかえり実施の合意など
  • 新しいプラクティス適用の有無
  • コミュニケーションの取り方
  • 教育についてなど
• リーダー、メンバーそれぞれが明確にすること
  • 私が実現したいこと
  • やりたいこと/やりたくないこと
  • 我慢できること/我慢出来ないこと
  • やってほしくないこと
    これは文書化してエビデンスを残し、必要があれば見直して更新しましょう。
    メンバーから要望があった際に対応結果含めてこの文書に記載していくと良いかもしれません。

最初に認識の齟齬を極力なくしておくこと、開発が始まってもなくしていく努力を続けていくことを明確にすることでチーム運営をスムーズに行うことが期待できます。
またチームに対するメンバーの意識を向上させることも期待できます。
少なくともいきなりリーダーのやり方を押し付けるより、メンバーの納得度が上げられ、クレームの可能性が減るでしょう。

ちなみに私はこの記事を通して上記に気づいたので、まだ実績があるわけではありません。
試してみて問題があれば加筆・修正したいと思いますし、もし試した方がいればコメント頂きたいです。

個人的にメンバーにしてほしいこと

チームリーダーの言動が気になったときはその場で本人にフィードバックしてほしい

リーダーが取るべき行動を書いてきましたが、最後にメンバーにやってほしいことを書いておきます。
それは気になることがあったらフィードバックしてほしい、ということです。
このときネガティブでもポジティブでも構いません。
それでチーム開発がよりよくなるならネガティブフィードバック、大歓迎です。

メンバーからしたらリーダーに意見するなんておこがましい、正論で返されると反論できないからメンドイ、逆ギレされたら嫌などあると思いますが、少なくとも私は謙虚に受け止めてますし、これからもそうしていきます。

これが直接ではなく上長経由などの間接フィードバックになると伝言ゲームになるので事実関係の確認が必要になったり、言った言わないの水掛け論になりかねません。
事象が発生したその場であれば伝言ゲームにも水掛け論にもならず、スムーズに解決できることが期待できます。

リーダーも人間ですし、ミスもすれば、上手く行かない事があります。
そういうときに身近なチームメンバーからのフィードバックが非常に大事なのです。
口頭が難しいならメールやDMなどでも大丈夫です。
メンバーとしてチームに対する責任を果たすという意味も込めて、ぜひフィードバックしてあげてください。

さいごに

最近なんだかなぁと思うことはネタにして公開することで消化する試みをしています。
あまり響かない(バズらない)けど、思考を言語化するのは大事だと思うので書き出す元気があるうちは続けていきたいと思っています。
書き出す元気もなくなると限界に近いと思うので。。

追記

Twitterで記事をツイートしたところ、多くの人に意見(リプ、引用RT)をもらえました。
せっかくなので参考に該当ツイへのリンクを張っておきます。
ぜひ参考にしてみてください。