はじめに

一年ほど前にチームリーダーになりました。
今日はその経験談について話そうと思います。

順を追って話そう

リーダーになるキッカケ

去年の今頃、評価FBをもらったときのことです。
「リーダーやりませんか？」と言われたんですね。

元々、自チームが口頭でのタスク管理だったのを、「コレは駄目だろ！！」とJIRAでのチケットタスク管理へ移行し、チームのタスク管理を上長のかわりに大体やっていた、というのがキッカケではないかと思います。

ちゃんと聞いてみたことはなかったですが、今思えば
「どうしてリーダーを打診したのですか？」と聞いてみても良かったかもしれません。

タスク管理がてんやわんや

元々、３人ぐらいのタスク管理をしていたのですが、それがチーム全員＋上長の分となって、
７−８人のタスク管理をすることになりました。

色々課題が有りました。

工数をチケットに付けてくれていない
期限が遅れそうなときにアラートをしてくれない
適宜ステータス変更をしてくれない
ステータス状況を記載してくれない

元々、チケットでのタスクに慣れていないため、まずはここの文化とWFの徹底をする必要がありました。
JIRAのワークフロールールや、ドキュメントを起こすところから始まりました。

チケットに色々状況を書いてくれれば良い。あとは私が見ておく。すべて！！という方向性にしました。
コメント時に、Slack通知するようにしています。
これにより、MTGなどは臨時のときや、話がうまく伝わってないときだけに集約することができました。

そして気づいた、やってなかったこと

リーダーになって、１，２ヶ月ぐらい経ちました。
それまでの間にしていたのは、

Kindle Unlimitedでのマネジメント本のチェック
チームビルディングの読書
youtubeを見まくること

でした。そして気づいたのです。

1on1してないし、MBOシート作ってねぇえええええ！！！！

まず、1on1をする

自分の上長のときも、1on1という文化がなかったので、あれそういえば・・・？という認識でいました。
そもそも、1on1をやってもらったことがありません。
最近よく聞くワード・・・。忘れていた・・・！

ということで、
一旦、1on1を上期向けて行うことにしました。
一人30分から1時間とし、面談するお題目を決めました

今までのスキルセットなど
やりたいこと
やりたくないこと
モチベが上がること
モチベが下がること
現在の業務についてはどうか
将来的に何をしたいか（会社に所属すると考えなくても良い、将来的に転職することも含めて考えても良い）

ここらへんを、面談しながら、ぶっ込んで聞いていきました。
要所で、jamboardなどに軽くメモ。

ちなみに、1on1は週1やるところもあれば適宜って人もいると思います。
個人的には、1on1毎週やる必要ないだろう派なのですが、これも派閥あるかもしれないですね。

MBOシートの選定

会社で用意してあるものがないか、聞いてみたのですが「特にない」という回答でした。
ので、何を使うべきか・・といろいろ考えました。
検討した結果、
「評価に必ずしもつながるものではなく、目標としてどうであるかが大切である」
という記事を見たので、今どきといえば今どきですが、
曼荼羅チャートをベースにしたマインドマップを導入することにしました。

マンダラチャートって？

大谷翔平がやってたアレです。アレ。

簡単にいうと、最初に大項目を書き、それをどんどん深掘りしていくのが目的です。
漠然とした目標のイメージだったものを、どんどん深掘りしていくことで、自分が何をできないといけないかということを、自分自身が、文字で書き起こすことで、自意識、主体性を育みます。

これについて、目標シートの具体例は出さずに、自由にメンバーに書いてもらいました。
すると驚いたことに、メンバー其々の意識差が如実に出ました。

今振り返ると、MBOシートは書いてもらって正解でした。その後の育成ルートを決めるのに役立ちました。

さて、チームビルディング

チームは、一応スクラムで回していましたが朝会はやらないようにしていました。敢えてです。
朝会やるのが、常套手段、というが結構お決まりパターンなんですが、

自分が苦手意識がある（以前居た会社で、朝会パワハラにあったトラウマ）
共通部署であるため、他部署の朝会に呼ばれる

という都合があり、朝会を省いていました。まあ、共通部署だから、サービス側の朝会にでる人も多かったりという別の都合もありましたが。
そのため、私が誰にどのタスクをお願いするか、を適宜検討して積み、調整していたという感じです。

振り返りには、JIRAのバーンダウンチャートを用いました。
タスクがどのぐらい消化できているか、割り込みがどのぐらい発生しているか、まずSlackにて、月初に共有するところから始めています。

チームビルディングとして、まず難しかったのは
共通部署であるため、お互いが他の人の仕事をあまり知らない
という問題が有りました。
ビルディングする上では、お互いに興味を持ってもらう必要があります。

色々試行錯誤

MRの文化がなかったので、MRを始めて、コードレビューに参加してもらう
とあるツール開発のとあるバージョンのタスクに、２〜３人突っ込んで同じリポジトリを触ってもらう

あたりです。

MRの試行

MRの文化がなかったのは、他の会社の人からすると、まじか！？って思うかもしれないのですが、共通部署で社内向けにしか開発をせず・・・という感じでズルズル行っていたからでしょう。
色々問題があったので、是正することにしました。
色々ツッコミしやすいように環境回りの整備は私の方で行いました。

MRは承認しない場合はセルフマージできない
Gitフローの策定
- 会社にコレがなかったので、チームとして定義しました
MRを作ったときは、自動でSlackに通知される
自動的にJIRAを紐づけ
MRテンプレートを作成し、レビューアサインが自動で適用されるようにした

これにより、ある程度ルール化されたので、「見なくてはならないもの」 にすることができました。
ただし、メンバーによっては、よく参加してくれる人、全然見てくれない人、色々あるので、今後の課題だと思っています。

同じリポジトリの作業に複数人割り当てる

これをすることの目的は同じ作業をすることで

質問を他者にしやすくする
MR時にツッコミしやすくする
お互いに興味を持ってもらう

のが目的でした。MR時のときと同様、うまくいきました。

評価に向けてレーダーチャートを作成する

メンバーは若い子が多かったのですが、自分が認識している課題が一つ有りました。
「どうしたらメンバーの年収をあげることができるか」です。

上層が最終的に、社員の年収を決めるわけなので、上に伝わるように２次評価へ申し送りする必要があります。
そこで、私はレーダーチャートを作成しました。
項目としては以下を定義しました。

報連相
自主性
発展性
ベーススキル
将来性
これについて、1~5の点数性にしました。それを平均し、いくつ以上であればupかdownか、と定義しました。

各々、どうしてこの点数であるか、を記述し、これをレーダーチャートにしました。
長々と、肌感評価しても、あまり印象に残らないため、説得資料として用意した形です。

上層が今どう思っているかはわかりませんが、新たな試みとしては良かったと思います。

振り返り

色々とイベントが多かったです。
主にチームやメンバー系のイベント事がだいぶ多かったですね。
おかげで労務関連に詳しくなりました・・。
メンバープライベートで詳しくは書けませんが、濃ゆい一年でした。

一年を通して、チームリーダーやるうえで、一番大事なのはチームビルディングだなと思っています。
メンバーがどういう思考を持っているのか、将来的にどうなりたいと思っているのか、それを踏まえて育成・年収をあげていくぞ！！という心構えや。

ただ、うまく動いてくれない・・うまくいかないなあ・・ってこと、やっぱりあるんですよね。
でも、ダメなのは「動いてくれない」という考え方そのものが間違っていること。

「その人のために、どうあるべきか」って視点も大事かなと思います。
冷静にいないといけないですね。

あと難しいのは主体性の育みかたでしょうか。
元々主体性がある人は問題有りませんが、そうではない人はどうしていくか。
「できるだけ口を出さない、任せる、見守る、考えてもらう」これができるようにと、意識しました。
結果、ジュニアメンバーの主体性は育ちましたが、シニアミドル層の場合は結構難しいです。
今後の課題ですが、色々勉強していきたいと思います。

チームリーダー１年目、やったこと。