チームリーダーなりたての3ヶ月について考えたことと振り返りの記録


この記事について

今年の10月からリーダーとしてのロールを受け持つことになりまして、チームがどう動いたら成果を出せそうか・楽しく開発できそうかみたいなことについて考えたり・実行してみたり・振り返ってみたり・反省してみたりした記録です。
まだ進行中であり、日々状況は変わるため何が成功かというのは組織やチームによって違うため、この記事が届いた誰かの何らかの何らかになればと思い筆をとってみます。

私と働く環境について

WEBサービスを提供する会社で開発エンジニアをしています。私達の会社ではECサイトを通して多くの人に自己実現を叶えてもらうため日々改善・開発を行い、よりたくさんの価値を届けるために日々働いています。
さらに多くの人にその価値を届けるため、今年から採用に大きく力を入れるようになりました。昨年とくらべて開発チームは3倍から4倍ほどの大きさのチームとなりました。今まではCTO直下で完全にフラットだったチームを分割して、さらに小さなチームを作ることになりました。
私が所属するチームは、新規機能の開発と改善を担当しています。チームメンバーは5人で業務委託の方にも加わってもらいながら日々開発をしています。

目次

1. 当初考えていたこと
 ・スクラム開発のエッセンスを取り入れてみる
 ・会話数を多くすることを狙ってみる
 ・3ヶ月を通してなにか一つ成長や変化を振り返って感じてもらう
 ・価値を早く届けることにこだわってみる
2. チームで動く中で持った課題感
 ・役割背負いすぎて自分が疎かになった問題
 ・レビュー貯まる問題
 ・見積り難しい問題
3. 振り返り
 ・スクラム
 ・会話数
 ・成長
 ・レビューを早く回す
 ・役割を分担していく
 ・2点見積り
4. その他
5. 今後について

1. 当初考えていたこと

チームを作るにあたっていくつかやってみたいことがありました。

・スクラム開発のエッセンスを取り入れてみる
・会話数を多くすることを狙ってみる
・3ヶ月を通してなにか一つ成長や変化を振り返って感じてもらう
・価値を早く届けることにこだわってみる

それぞれについて補足を書いていきます。
スクラム開発のエッセンスを取り入れてみる
今より以前に自分がいたチームで、自分や仲間の頑張りに対してアウトプットが少ないという課題がありました。頑張ってるんだけどうまく身を結んでない感じです。
いろいろ要因はあると思うんですが、成果物を届けるサイクルの中に一つ課題があるなと考えていました。そんななかちょうどCTOがスクラムマスターの研修に行った話を聞いて、これは試す価値がありそうだとなりました。
https://www.amazon.co.jp/dp/4798129712/ref=cm_sw_r_cp_ep_dp_KC.dCbAXF57S2
とりあえずスクラムの雰囲気を知りたくて読んだのが「SCRUM BOOT CAMP THE BOOK」でした。基本の考え方から、実際の開発現場で起こりがちな事柄をどう解決していくかの解説があり読んで良かった感がありました。チーム開発の様子は漫画っぽく事が進むので、ざくっと読むにはもってこいだと思います。
私が理解したところを雑にまとめると「チームの透明性を保つ」「成果物にこだわっていく」「自分たちは良いチームだし、さらによくなるということを強く信じる」かなと感じました。これは良さそうだなと。とりあえず1週間毎のスプリントでtrelloをつかって管理してみることにしました。
+-+-+-+-+
会話数を多くすることを狙ってみる
さきほどの「チームの透明性を保つ」と近いところなんですが、仕事のことに限らず会話量を多くすることを狙ってみました。
slackであったり、コードレビューであったり、現在のサービス開発を取り巻く環境は他の働き方と比べると画面上の文字でコミュニケーションを行うことがとても多いと思います。文字でのコミュニケーションでは人柄や物言いを知ってる人と知らない人とでは伝わり方に差があったりするのを感じていました。
伝わりやすいに越したことはないのでいくつか実行してみたことがあります。

・デイリースタンドアップミーティング
・16時に小休憩(おやつタイム)を挟む

デイリースタンドアップミーティングはスクラム開発で定番のものなので詳細は割愛しますが、毎日の進捗・課題の確認を15分程度で行うものです。
おやつタイムの方は、前職で3時になるとマーケターの人がなんらかのお茶(紅茶だったりほうじ茶だったりその人の気分で変わる)を入れてくれて楽しいおしゃべりをした時間がいい感じだったのでそれを真似てみました(あと現在の同僚が以前お菓子ボックスを用意してくれていてそれも参考に)。


(こんな感じで16時にbotが来るのでお菓子食べながら少し喋ったりする)
意外とこの時間が侮れないと思っていて、普段は「調子どう?」とか雑談(獣になれない私たち)の話などしているのですが、困ってたりすると相談が自然発生したりとか表情が冴えなかったりすると深掘りしてみたりとか、ちょうど作業の切れ間を作っているのもあり引き出しを引く良きチャンスになっていたりします。
+-+-+-+-+
3ヶ月を通してなにか一つ成長や変化を振り返って感じてもらう
3ヶ月という期間は会社でOKRを3ヶ月おきに設定しているので、ちょうどチームの作業の切れ目でその期間を設定しました。
働くことは端的には時間と労働力を対価に金をもらっているということだと思うんですが、その時間をうまいこと使って自己成長につなげて行きたい(つなげてほしい)という思いがあります。
ベストは「他社からも引く手あまたに成長してもらいつつ、自分の会社で働きたいとおもってもらう」というところなので、自分としては成長につながる機会を渡せるように頑張って、会社に待遇の方を頑張ってもらう。という感じです。
+-+-+-+-+
価値を早く届けることにこだわってみる
前期の課題でアウトプット量が少ないというテーマがあったので、リリースサイクルを早く回すということについても考える必要がありました。具体的に最初に考えていたことは

・レビューを早く回す
・レビュー依頼されたものはその日のうちに打ち返すことを目標にする

というものでした。このときはレビュー消化の目標をたててみただけで、その他の具体的な施策はありませんでした。

2. チームで動く中で持った課題

役割背負いすぎて自分が疎かになった問題
一番最初にヤバっとなったのが、自身で役割を背負いすぎたことでした。具体的には

・チーム内の各種MTGやスクラムイベントでのファシリテート
・開発チーム全体に報告用の週報の作成
・開発チーム全体のMTG
・施策の計測
・案件のステータス管理
・もろもろのチーム管理

の部分が毎週自身で持ってる開発案件やレビューにのってきたため、明らかにパフォーマンスが落ちました。でもよくよく考えてみるとこれらのタスクのいくつかは、誰がやっても問題ないものでむしろチームとしてやっていったほうが良さそうだったので当番制にさせてもらいました。
+-+-+-+-+
レビュー貯まる問題
どうしても自分の担当分が煮詰まってくるとレビューに手がまわらないということがみんなあって、徐々にレビューが溜まっていく問題がありました。チーム内で話し合うなかで

・チーム内のレビュー中のものを日時でslackに投げるようにした
・レビューバックに気づかないことが多かったので、必ずPR上でメンションをつけてslackの通知で気づけるようにした(github上でチームや個人にメンションがつくとslackで通知が来るようになってる)
・スクラムに則ってみんなでタスクの見積りをする時間をMTGとして設けてタスクの知識量の平準化を狙った

以上のことをやってみました。


PRにレビュー中の状態をラベルで管理するのがもともと風習的にあったので、自チームのPRに対してそれで分類したものを毎日投げるようにしました。
+-+-+-+-+
見積り難しい問題
普段スプリントの中で見積りをしてますが、プロダクトオーナーと話す時など「何日頃リリースできそうか」と話すこととかがあります。見積りの中の情報で話せれば良いんですが、時に「何日」でお伝えしなければいけないことがあったりします。
リリースが目標どおりになかなか行かないことが続いた時にプロダクトオーナーが ゲーム開発プロジェクトマネージメント講座 の「2点見積り」について情報をくれました。
いい感じに進むとリリースできるA点もしかしたらここまでずれ込むかもしれないB点の2点を見積もることでエンジニアも幅を持って見積りを出せるという安心とPM側もバッファを持ってリリーススケジュールを組み立てられるというなんかいい感じの見積り方法を試してみることにしました。

3. 振り返り

チーム自体10月から始まったんですが、正式にみんなが自チームのタスクに取り組めたのが10月の終わりでまだ一ヶ月半ほどしか時期的にはたってないんですが、一応取り組んでみたので振り返りを。
スクラム : ○
厳密に言うと正式なスクラムとしてまだ回せていない点がいくつかあるのですが、続けていこうと思ってます。一週間は

・見積りと計画づくり
・デイリースタンドアップミーティング
・振り返り
・KPT

を行っています。
スクラムの枠組みで自分が良いなと思っていた「チームの透明性を保つ」「自分たちは良いチームだし、さらによくなるということを強く信じる」というところがよく働いていると感じました。最初のうちに積極的に意見を吸い上げるようにしてましたが、今はKPTのときに自然発生的にもっとよく開発していくにはの意見がでてくるようになってます。この雰囲気は維持していきたい。
唯一、ベロシティの管理が難しく共通のIssueみたいなものがないためちーむとしての見積りの基準になるptづくりに苦労している。タスクの取り組み方にテコ入れが必要なんだと思ってる。
+-+-+-+-+
会話数 : ○
これはチームとして向き不向きがあるきがしますが、自分たちのチームにはあっていた気がします。↑のスクラムと相まって、またチームメンバーがみんな心が清いので、気軽な感じで相談できる空気が作れてる気がします。
チームが気軽に話せる間柄が、いい意味で無遠慮に良い指摘をしあえる中につながると思っているので保っていきたい。最終的な目的はここで、高め合える雰囲気を作っていきたい。
+-+-+-+-+
成長できる環境の提供 : –
まだ3ヶ月終わってないので判断を保留。一番最初の1ヶ月で1 on 1をして期待するところをお伝えさせてもらってるので、それを振り返りながらはなしてみたい。
+-+-+-+-+
レビューを早く回す : ○ と △
日々自分たちがこなさないといけないレビューが確認できるようになったのと、チームの人の実装をレビューすることがチームとしての役割としてみんなが意識してくれているのでそこはすごく良い。
レビューを早く回して、リリースを早くするのを意識しているため見逃しや他要因もあって腰を据えてレビューできないという課題がまた生まれてるのでここは新しくトライしていきたいところ。
+-+-+-+-+
役割を分担していく : –
これはちょっと判断が難しいので評価はしないけれど、ペパボで働いているjune29 さんから聞いたお話で「自分のロールから1段上の仕事をする」という話を聞いたことがあってとても良い話だと思ったことを覚えてる。このことがその一助になると嬉しいなという思いがある。
+-+-+-+-+
2点見積り: –
まだ1週間前に取り組み始めたため判定できず。でもこれはなんかすごく良さそうだと思う(KPTのときにこの話題がでて良さそうすぎてチームのみんなが湧いた 笑 ありがとうプロダクトオーナー)
その他、チームとしての施策ではないけれどチームの人と自分がしたい勉強のもくもく会をやってみようということでやってみたりしてます。なんか良さそうだったらとりあえずやってみよう、ダメそうならやめればいいのお気持ちで気軽にいろいろな施策のお試しをしています(この他にも小さいことのちらほら)

4. その他

重ねてになりますが、チームメンバーにとても恵まれていて積極的にレビューをしてくれたり、スクラムの改善に積極的に意見出ししてくれたり、お菓子を気づいたら補充してくれたり、数えればきりがない。
当初考えてやってみたいことももちろんありますが、チームが始まってからはむしろチームで考えたことがほとんどなのでそういう意味ではこのnoteはチームの3ヶ月(まだたってないけど)の記録が近い表現かもしれないです。
リーダーとしては頼れないところが多分にあり自身にヤキモキする毎日ではあるんですが、良いチーム感が引き続きあるのでいろいろトライアンドエラーで頑張っていきたいところ。メンバーのちからですね。

5. 今後について

チームの課題としてはレビューが心理的に大きな比重を追っている気がするので、そのへんがどうにかしたいのとチームの外側の外部要因もある気がするのでそのへんもどうにかなると良いんだろうと思っています。
個人的には、まだ全然実装スキルが足りていないので時間をみつけてこの辺を高めていく努力を引き続きしていかないといけないなという危機感を持ってます。それと、自分の実装とチームのこととその事柄で仕組み化できることを仕組みに落としてくとかやっていくことのバランスの良い比重を早いところ見つけないとというのも。
この3ヶ月、今までと違うロールをしてみて実装をしながらチームが良くなることについて考えていく時間の使い方に課題とある種の限界みたいなものも感じていて、同じ課題感を抱えている人がもしかしたらいるんじゃないかなと思ったりしました。
なので今とても他社の開発チームの話や新米リーダーの人々とお話したい気持ちが高まっているので、勉強会などでお会いしましたらぜひお話させてほしいなという気持ちでいます。
えらく長文になってしまいましたが、ここまで読んでいただきありがとうございます。もし同じ課題感を抱えているかたがいたら、その方の一助になれば幸いです。
みなさん、やっていきましょう