2022年を振り返ってチームリーダーとしてやってみてよかった4つのこと
はじめに
いよいよ2023年がスタートしました。思えば2022年は、開発部の体制が変わりまして、チーム分割に伴いチームリーダーとなり、これまでとは全く違った働き方になった1年でした。プレーヤーとして結果を出すだけではなく、チームの生産性を考えた動き方、他チームや部署との調整やPdMたちと中長期的に何をやっていくのかを決めるなど、幅広くやることが増えました。
そんな1年を振り返ってみて、チーム生産性向上のためやってよかったことを書いてみようと思います。
やってよかったこと
1. １スプリントを2週間から1週間に変更した
以前は2週間を１スプリントとして進めていました。スプリント終わりにスプリントレビューとスプリントプランニングを実施し、その際にKPTや次issueのアサインも行っていました。
しかし１スプリント2週間に課題を感じるようになりました。
- 流動性が高いスプリントが続いており（仕様詰やアサイン待ちなど含め）、事前に2週間分のタスクを埋めれてない
- 1週間で区切った方が気持ち的にもスッキリ週末を迎えれるのではないかという仮説
- スプリントレビューという時間をわざわざ取らなくてもDS[1]の延長線上でできるっちゃできる
「1週目に進捗が出なくても次の週でやればいいや」という雰囲気がどこかしら漂っていたので、この点を改善できるのではないかというのも目的の一つでした。
金曜日だけDSの延長線上でスプリントレビューとスプリントプランニングをするようにしました。もちろんいきなり変更提案すると、懸念もありますので、「生産性や働き方が悪くなるようなら、１スプリント2週間に戻そう」ということを含めて提案しました
そして実際に何週間か続けてみましたが、ネガティブな側面は全くと言って出てきませんでした。当初の狙い通り、多くの良い効果ができたように思います。
- スプリントプランニングでの各メンバーへのタスクアサインがより明確になった
- 曖昧なタスク進捗のまま1週間を終えることがなくなった
- 大きなタスクであってもPRを細かくして進捗を出そうというマインドが生まれてきた
- メリハリのある1週間を感じれるようになった
後々メンバーと1on1で話した際にもこれらの点が出てきたので良かったともいます。PdMとしても１スプリントにメリハリが出たし、エンジニアの進捗がより可視化されて嬉しいという声も出ました。
2. モヤモヤしたことはちゃんと言語化して話す
フルリモートかつテキストベースで会話をしているとより一層ミスコミュニケーションは発生しえます。できるだけ相手側に立った伝え方が望ましいと考えますが、必ずしも全員が全員それが得意なわけではなく、前職からの経験や本人の性格なども影響していることでしょう。
少し気になったコミュニケーションを見つけたとしても、当初はメンバーの顔色を伺って、率直に指摘することはしませんでした。しかしそれではもちろん改善されるわけではもちろんありません。
そこで思いきってスプリントレビュー時のトピックとして、そのスプリントで気になったことを話すようにしました。ただし、ここで大事なのは特定の人を責めたり、攻撃したりしてるような構図にはしないことです。当人は無意識だけだったかもしれません。それなのに責められてると感じて傷ついてしまうこともありえます。あくまでチームにとって良くなるように改善したいだけなので、「特定の人を責めている訳ではないですよ。ただチームとしての生産性やコミュニケーションを改善したいだけなので話しましょう」と前置きをしっかりしました。
そして実際に話してみると、やはり当人はそこまで深く意図して発言した訳ではなかったりなど見えてきました。1回で完璧に改善されるわけではありませんが、繰り返し行うことで確実によくなっていきます。
SlackでのチャットやPRでのコメントだけだと相手の真意をやはりどうしてもわかりかねる時があります。相手にとって嫌だったり、雰囲気が悪くなるかもと不安があったとしても、チームとして必要であればちゃんと話すことの大切さを痛感しました。モヤモヤや悩みは抱え込まず、率直にチームで話しましょう。
どんな背景があって、その行動や発言をしたのかは普段の業務からだけでは読み取ることができません。そのことについて話す機会がちゃんとあれば、「あ、そういうことを考えていたのか」などお互い見えていなかったことを知る機会になります。
3. 全部自分で抱え込まずメンバーにお願いしてみる
リーダーは自分自身のタスク以外にもさまざまなタスクを持っています。カスタマーサポートからの問い合わせ対応や突如発生するバグやエラー対応など意外と多かったりします。
これまではそんな状況でありながら、小さなissueに関しても「自分でやった方が早い」と思って手を出してしまっていたのですが、見事にキャパシティオーバーに陥っていました。どんどん夜まで稼働が増えていき、なんとか稼働時間でカバーしているような状況です。
そこで「どれだけ自分がやった方が早いと思っても、あえてメンバーにお願いする」よう少しずつ試してみました。
すると、自分の稼働時間を減らすことに繋がったのはもちろんですが、自分はより難しい仕様や設計にしっかり時間を割くことができ、より良いプロダクト開発に繋がったように思います。またメンバーとしても、あまりこれまで着手しなかったタスクを通して気づきや学びがあったかと思います。メンバーの負担が増えすぎることには注意しつつも、自分がすべきこと、人にお願いすべきところはしっかりと区別し、チームとしての生産性に何が一番良いか、バランスをとって行ければと思います。
4. 大胆に休んでみる
これは先ほどの「全部自分で抱え込まずメンバーにお願いしてみる」と似ていますが、強制的にその環境を作るということになります。
これまで休みを取ったとしても、「何かあればいつでもSlackで対応する」スタンスをとってしまっていました。しかし、それをやめてみたところチームに良い反応がありました。
- バグやエラー発生時に、メンバーが自主的に動いてくれた
- 新しいメンバーのオンボーディングを、メンバーが分担してサポートしていてくれた
- PRレビューを分担してやってくれた（→普段結構な数のレビューをリーダーがこなしていることに気づいてくれた）
いっそのこと休んでしまえば[2]、メンバーは自分たちでやるしかない環境になり、動いてくれたりします。チームで動いていることの有り難さを改めて感じましたし、このような関係が発展していけば良いなと思いました。優秀なメンバーが揃っていることで成せることかもしれませんが、より一層そういうチームを目指して行きたいと思います。
さいごにおすすめの1冊
何冊か「リーダー」や「マネージャー」と冠した名前の本を読んで、たくさんの学びがありました。どれも気づきや学びがあってよかった本ですが、そんな中でも個人的に一番良かったのがこちらの一冊です。
リーダーの仮面 ー 「いちプレーヤー」から「マネジャー」に頭を切り替える思考法
プレーヤーからリーダー・マネージャーに変わる時は、プレーヤーとしての成功体験は傍に置いておく必要があります。リーダーになったら「個人の成果 < チームとしての成果」を求められるようになりますし、またそうしないとチームとして雰囲気や生産性も悪くなることでしょう。ぜひ新しくリーダーやマネージャーになって悩んでいる方がいらっしゃったらおすすめしたいと思います。
Discussion