はじめに
こんにちは。株式会社COUNTERWORKSでプロダクトマネージャーをしているまったんです。
COUNTERWORKSでは6年半の間ソフトウェアエンジニアをしていたのですが、私の希望で今年の夏からプロダクトマネージャーとなりました。
エンジニアとしてのキャリア終盤の約3年間は、4〜5名程度の開発チームのチームリーダーを務めていました。このチームは、リーダー就任当初と比較して、多くの点で改善が進み、良いチームになったという実感があります。
今回は、そのチームリーダーとしての経験を振り返り、特にチーム運営において実践してよかったことをまとめてみたいと思います。
1. 若手エンジニアの学習方針の変更
私がリードするチームには、新卒や第二新卒といった若いメンバーが配属されるケースが多くありました。
これらの若いメンバーは、多様な技術領域に関心を持ち、浅く広く学習していく傾向が見られたのですが、後述する目的や理由を説明した上で、本人たちがメリットを感じてもらえた場合には領域を絞って学習するように方針を変えてもらいました。
この背景には、COUNTERWORKSのValueである「One Team」があります。
「One Team」とは、メンバーが何かしらの知識や技能をプロフェッショナルと呼べるレベルまで高め、その専門性をチームに還元することでチーム全体をより良いものにしていこう、というものです。
このValueを体現してもらうため、若手には特定の領域に集中してもらうことにしました。
例えば、チームメンバーが持つスキルをABCの3つのステータスで表現するとします。
| メンバー | A領域 | B領域 | C領域 | 総合値 |
|---|---|---|---|---|
| Xさん | 5 | 2 | 2 | 9 |
| Yさん | 2 | 5 | 2 | 9 |
| Zさん | 3 | 3 | 3 | 9 |
チームで協力する際には、Aが5のXさんは他者のA領域を5まで高めるのポテンシャルがあり、Yさんも同様に他者のB領域を5まで高めるポテンシャルがあります。一方、Zさんは他者のC領域を3にするポテンシャルしか持たず、総合値はXさんやYさんと同じなのにチームへ貢献できることが相対的に小さいです。
そのような状態に陥らぬよう何か得意な領域を持ってもらい、早い段階で専門性を通じてチームに貢献できたという成功体験を積み、仕事へのやりがいを感じてほしいと考えました。
この学習方針に変えてもらった結果、チームに貢献する体験を積み上げ、やりがいを感じ、更に学習意欲が湧くという好循環を生み出せている若手メンバーを増やすことができました。
2. 担当領域を広げる取り組み
得意な領域を持っているメンバーに対しては、得意ではない領域の開発をしてもらう機会を定期的に設けました。
私がチームリーダーになる前の開発メンバーは、バックエンドが得意な人はバックエンドだけ、フロントエンドが得意な人はフロントエンドだけを担当するというスタイルがほとんどでした。
この開発スタイルは、得意な領域のスキルを磨き続けられるメリットや、考えることが少なくて済むというメリットはありますが、
工数の大きな機能でバックエンドとフロントエンドで工数の差が大きいものを開発するとなると、工数が小さい方の領域が得意な人のリソースは余っているのにリリース時期を早めることができないといったデメリットがあります。
組織としては早くリリースして早くフィードバックを受けて早く改善したいので、チーム内で協力することでリリース時期を少しでも早められるチームを目指すことにしました。
当時、私はバックエンド領域の方が得意でしたが、まずは私自身から少しずつフロントエンド領域の実装割合を増やしていきました。
その後、他のメンバーにも得意ではない領域へのチャレンジを促し、領域にこだわらず実装するのが当然という空気感をチーム内に作っていきました。
結果として、多くの人が得意ではない領域での実装を毛嫌いすることはなくなり、領域ごとの工数が偏る機能の開発においても、得意ではない領域でも貢献できる柔軟性の高いチームになることができました。
3. 振り返り方の変更
COUNTERWORKSでは2週間を1スプリントとして、スプリントの最終日にレトロスペクティブを行っています。
COUNTERWORKSでは長い間KPT法を用いて振り返りをしていましたが、これがかなりマンネリ化しており、振り返りの場でのコミュニケーションがあまり生まれないという課題を感じていました。
そこで、振り返り方を変えてみたところ、かなりコミュニケーションが活発化し、チームとしての学習が捗るようになりました。
特に、Happiness RadarやCelebration GridといったフレームワークはKPTとの違いが大きく、マンネリが大きく改善されました。
以下の本には振り返りフレームワークがたくさん載っており、振り返りがマンネリ化していると感じる方には是非手にとってみてほしいです。
4. リファインメントの時間を確保する
スクラムガイドのスプリントプランニングの章で書かれている、 スクラムチームは、このプロセスの中でプロダクトバックログアイテムのリファインメントをする場合がある。 という記述を丸呑みしているわけではないですが、COUNTERWORKSではプランニング時にリファインメントをするのが常態化してしまっていました。
大きな機能のリファインメントをプランニング中に行うと、当然ながらスプリントの計画を練る時間が逼迫されてしまいます。その結果、スプリント中の作戦を大して練れずになあなあにスプリントが始まり、以下のような問題が発生していました。
- メンバー間で作業の解像度に差が生まれる。
- 無駄なコミュニケーションが発生する。
- スプリントゴールを達成できずにスプリントが終わる。
そのような問題を解決するために、基本的にはリファインメントはプランニング中には行わず、プランニングの前日には完了させるようにしました。そして、プランニングではスプリントの作戦を練るだけに集中するようにしました。
結果として、メンバー全員が同じ解像度でスプリントを始められるようになり、デイリースクラムでは、スプリントゴールの進捗の検査や、スプリントバックログの適応のためのコミュニケーションのレベルが格段に上がりました。
5. 進捗の検査をきちんとする
デイリースクラムが簡単に形骸化してしまうことに悩んでいました。同じ悩みを抱えている組織は多いと思います。
デイリースクラムでスプリントゴールの進捗の検査が行われず、誰もアラートを上げないままスプリントレビューを迎え、スプリントレビューでようやくスプリントゴールが達成されていないことが明らかとなる、という大きな問題を抱えていました。
そこで、進捗の検査を確実に行うために、以下のことを徹底し続けました。
- デイリースクラムでファイブフィンガーを使ってスプリントゴールの達成に対する自信度を表明する。
- 3本指以下の人がいれば、必ずその場で話し合いをする。
- スプリント最終日に4本指を上げたのにスプリントゴールが未達だった場合、どの時点で進捗に問題を抱えていたのかをきちんと振り返る。
その結果、前述の「リファインメントの時間を確保したこと」も相まって、進捗における自信度への違和感に対するツッコミがメンバー間で起こるようになり、健全な適応が行われるようになりました。
さいごに
いざ書き出してみると至極当然なことしかできていなかったなあと少し恥ずかしく思いますが、チームをこれから成熟させていきたいんだと考えている方にいい影響を与えられるになっていたら嬉しいです。
最後になりますが、株式会社COUNTERWORKSではより良い開発チームを作っていくんだという気持ちのあるエンジニアを大募集しています。
少しでも興味があれば応募お願いします！
ポップアップストアや催事イベント向けの商業スペースを簡単に予約できる「SHOPCOUNTER」と商業施設向けリーシングDXシステム「SHOPCOUNTER Enterprise」を運営しています。エンジニア採用強化中ですので、興味ある方はお気軽にご連絡ください！ counterworks.co.jp/
Discussion