hamburger

主に日記

チームリーダーをしていて気をつけていること

ここ3ヶ月位チームリーダー1をするようになった。求められている役割としては、

  • 技術的な問題に対して意思決定をする
  • リリーススケジュールを調整する
  • メンバーに対してチケットのアサインをする
  • チーム運営

など。手探りではあるが、少し落ち着いてきて考えがまとまってきたので、まとめておく。

仕事を依頼する際の伝え方

ルールを決めるときや案件をアサインする時、なるべくなぜそうするのか?を丁寧に伝えて理解してもらうようにしている。言い方としては以下のような感じ。

OK -> 「〇〇をしたいという要望があり、✗✗機能を実装すれば実現できそうだと考えています。△△に必要らしいので□□日までにMR出せるようなスケジュール感でお願いします」

NG -> 「□□日までに✗✗機能を実装してください」

おそらく、結論から伝えるというビジネス報連相を踏襲するとNGパターンのような言い方になりがちだと思う。でもこれだとなんのために?が抜けているので細かい部分で適切な考慮がされていないことが多く、レビューで細かく確認する必要が出てくる。作業者側も情報が不足しているため判断しづらい。なるべくユースケースを中心に伝え、それを実現するために仕事をしてもらうという風にすると担当者の自走がしやすくなる。

はじめは担当領域のプログラムを書くことに意識が向いていた人たちが、徐々になんのためにやっているのかを考えてアウトプットを出してくれるようになってきていて2、この方針は一定の成果を上げているのだと思う。

意思決定の納得感

上と重複する部分もあるが、何をするにも周囲が納得感を持ってくれるように気をつけている。大事にするのはあくまで納得感であり合意ではない。
合意を一番にすると意思決定が遅くなるような気がしていて、その一歩前の段階の納得感を感じられたタイミングで自分の判断を決定している。ただ、これは自分の意見を押し通すためではないため、反対意見で僕が納得できれば別の意見を採用することも多い。

これをないがしろにするとチーム内の信頼関係が薄れたり、主体性の低下につながると思っているので(自分がそう)、誰がリーダーやマネージャーになるのかといった組織に関することを決定する際も、エンジニアリングスキルと同じくらい重視すべきと考えている。

コミュニケーションのチャネルを増やす

今のチームでのコミュニケーションは、オフライン・slack・PRレビュー・MTGが主な手段である。それぞれプロコンがあり、どれかに偏るのは避けるべきだと考えている

オフライン

pros

  • 表情や声のトーンで文字以外の情報のフィードバックがある
  • 伝える際のハードルが低い

cons

  • 話し相手以外に情報が伝わらない

slack

pros

  • 情報が残る
  • 推敲できるので適切な内容を伝えやすい

cons

  • 発言する側のリテラシーが必要(適切な関係者に伝わるようにメンション・チャンネルを設定する必要がある)
  • 流れやすく印象に残りにくい

PRレビュー

pros

  • チケットのコンテキストがあるので、事前説明無くプログラムに関する議論ができる
  • 技術共有しやすい

cons

  • チケット以外の話題は伝えにくい
  • 汎用的な技術情報はPRレビューよりslackのほうがチームのメリットになる

MTG

pros

  • 会議室予約が面倒
  • 発言が個人向けではなく、暗黙的に出席者全員向けと解釈される

cons

  • 良くも悪くも、MTGの成果が進行役のスキルに左右されやすい
  • 全員向け以外の議論をしてしまうと途端にコスパが悪くなる

今の僕の方針

slackのprivateチャンネルは避ける

よほどのことがない限り、個人チャットやprivateチャンネルはさけ、情報をpublicにしている。仮に皆が見ていなくても、アクセスできるようにしていくことが意思決定フローの納得感につながる

1日2回はオフラインで話す

完全に守りきれているわけではないが、午前と午後に何かしら話題でオフラインコミュニケーションを取るようにしている。
いつでも話しかけて良いとは言っているものの、デフォルトでイヤホンをしている(良くないなぁと思いつつ、自分が作業できる時間帯は極力集中したい)ため話しかけづらいだろうなぁというのが一つ。あと、それをきっかけに色々話すことが多いので。本当はそういうことをしなくても話せる空気を作りたいが、話しかけても良い・毎日必ず会話するという意思表示をすることで、心理的安全性向上に一役買ってそう

定例MTG

いわゆる進捗共有的なものだとチームの課題が把握しづらく、発言者以外の当事者意識が低下しがち。そのため自身の進捗共有のような内容は各メンバーのタイミングで行うようにし(開始・終了・遅延)、定例ではやりたい仕事や困っていることの吸い上げを第一にしている。 この場ではサーヴァント型リーダーとして振る舞い、言われた内容のうちすぐできそうなもの(例えば〇〇の手続きがわからない的なもの)はすぐ対応する。また、忘れずにslack上でフィードバックする。伝えたことが改善されるという実感が持てると、次回MTGも積極的に参加してくれる。

自分が嫌いなパターン

なぜそう考えるに至ったかというと、非常に嫌なコミュニケーションをする人が世の中には一定数いて、それに対するストレスが自分のパフォーマンスに影響ありそうだったから。反面教師にすることで、少なくとも自分の同じ考えの人のパフォーマンスは下げないようにしたかった。自戒も込めていくつか書いておく

slackオンリーマン

距離感・重要性関係なくslackで会話したがる人。一見合理的なんだけど、文章量を減らした結果最初のNGパターンのような文章ばっかりだったり、そもそも情報共有が下手で読む側に理解するコストがかかってた

オフラインマン

ずっと口頭ベース。表情や声のトーンに情報を付加してくるため、物事を雰囲気で伝えようとしてくる人だった。チーム内で情報格差が出てくるので、それをカバーするために定例MTG増やしがち

仲の良い人にだけオフライン

個人的には一番ストレスの元凶だった人。仲の良い人にだけ口頭で詳細まで伝えるくせに、それ以外の関係者には簡素なチケットとリンクのみ送りつけてた。 情報格差が発生している自覚が無く、結果的に仲の良い人のみ仕事の成果を出しやすい環境になる

まとめ

  • いろんな方法でコミュニケーションをとる
  • チーム内の納得感を大事にする
  • 自分が嫌だった振る舞いはしない

  1. 正確には、サービス内のスマホアプリエンジニアリーダーでサービス開発チームのチームリーダーポジションではない

  2. レビュー指摘でも何度かユースケース実現を意識してほしい旨は伝えた