社内でLTしたネタ。去年からサポートしているチーム作りのお話。
1週間スプリント
最初は短いサイクルで試行錯誤したいから1週間スプリントでやることにした。
スプリントの終了と開始
金曜日にスプリントレビューとレトロスペクティブとプランニング。
プランニングは2部制にして
- 第1部では次のスプリントでやりたいことの認識合わせを全員で
- 第2部では細かいタスクの話をエンジニア中心で
やってる。
ストーリーポイントと理想時間を併用してみてる
これはだいぶあとの方の話。
最初の頃はチケットのサイズを見積もるのにストーリーポイントだけを使ってたんだけど、半年くらいした頃にストーリーポイントに加えて理想時間の見積もりも併用することにした。
最初の頃に理想時間を導入しちゃうと、頭では分かってても「時間」に引っ張られてしまうので、ポイントだけで始めることにした。で、半年くらいしたころには新しいやり方にも慣れて、もう数字に追いかけられないチームになってたので、もう少し自分たちのことを知って改善に役立てるために導入してみようかってことで始めた。
ストーリーポイントは、ちょっと先の話をするため。プランニングよりも前につけておいて、リファインメントで「次のスプリントではここらへんまでかなぁ」「んー、それならこっちが上のほうがいいなぁ」みたいな話をするときに使う。
理想時間は、エンジニアたちが自分たちのことを知るため。スプリントプランニングの第2部でつけて、毎日残り時間を更新して、バーンダウンチャートをこの理想時間でかいてる。
Daily Scrum
朝みんなで Zoom にあつまってデイリースクラム。
まずは運用周りの状況を確認。自社サービスの開発だけじゃなくて運用も担当してるので、問い合わせやアラート、トラブルの対応や緊急依頼などもハンドリングしてて、毎日変化する状況を把握する。
その確認が終わったら、エンジニアからタスクの状況を共有して、今日やることの再計画をする。もし運用で急ぎのタスクが入ってたら、どのタスクを止めるかを話し合う。
それから、PDM（Product Manager）やPJM（Project Manager）から、今自分たちがどんなことをやってるかの共有がある。これは少し先に運用タスクとして入ってきたり、次のスプリントの計画に入ってきたりする。
以前に↓のような記事を書いたけど、最近はみんな慣れてきて短ければ10分、色々あるときでも30分くらいで終わってるな。
bufferings.hatenablog.com
Team
そういえば、チームはこんな感じ。自社サービスの開発と運用の両方を見ている。
エンジニア
エンジニアが6人いて、DVM（Development Manager）がリードしてる。エンジニアの動きについては後で説明する。
PDM
PDM（Product Manager）が2人いて、Chief PDMがリードしてる。PDM と Chief PDM は常に認識を共有している。決断は、混乱がないように Chief PDM がしている。
PDM はビジネスチームやデザインチームととても近い距離にいて、社内外含めてステークホルダーと話をしたりしながら、プロダクトの将来を描いている。
サービス運用も含めてハンドリングをしているため、とても大変なんだけど、いつもエンジニアのことを気遣ってくれててかっこいい。
PJM
PJM（Project Manager）は全体を見てる。スクラムマスター的な動き。
組織のマネージャーが PJM とバディを組んでるので、チームにとって良さそうなことがあれば、組織のやり方も含めて変えていけるようになってる。
この2人が、チームの中で間に落ちそうなものを拾い上げてくれるので、エンジニアもPDMもそこをあまり気にせずに自分のやることに集中できる。
PDM が忙しすぎるときはサービス運用タスクを拾ったり、エンジニアがいっぱいいっぱいのときは簡単な問い合わせなら PJM が手を動かしてくれたりする。2人とも、もともとスキルの高いエンジニアなので、あんまり手を出しすぎないように気を遣ってくれながらなのもかっこいい。
開発スタイル
モブ & ペア
エンジニア6人は、タスクや状況に合わせて色んな組み合わせで開発を進める。例えば
- 2人 x 3
- 3人 x 2
- 4人, 2人
- 6人全員
チームのルールで、タスクを担当する最小単位を2人にしている。シンプルなタスクなら2人で、ちょっと難しいものは3人で、全員が深く理解しておいた方が良いものは6人で担当する。
この組み合わせはマネージャーやリーダーが決めるのではなくエンジニア6人で話し合って決めている。「このタスクは3人でやるほうが良さそう」とか「これはちょっとそちらの2人の意見もほしいので4人でやろう」とか。1日の途中でも1つのペアが「相談したいー！」って声をあげて、みんなが集まってきて、そこでペアを組み替えたりもする。
こういうやり方にたどり着くまでの流れはこんな感じ：最初の頃にペアワークを導入して、しばらくして慣れてきた頃に6人全員のモブワークを実施。しばらくすると、ふりかえりで「全員じゃなくてもいいときがある」という意見が出てペアに戻してみて、次のふりかえりで「認識を揃えるという意味では、ペアよりも結局モブワークの方が良い場合がある」って意見が出て、それ以降も2人や3人などの組み合わせにトライしつつ、今は「最もチームとして良い組み合わせを、常に考える」というところに落ち着いて、動的に組み替えるこのような形になった。
Zoom Breakout Room
ペアワークなどには Zoom のブレイクアウトルームを使っている。メンバーが自分で移動できる設定にしているので、他のペアに確認したいことがあるときなどは「ちょっとRoom 3に行ってくるね」って聞きに行ったりしてる。便利。
ちなみに、基本的にみんなカメラはオフにしてる。1 on 1 とかだとオンにしてるけど、ペアワークのときとかはオフならオフで問題ない。僕は饅頭食べながらペアワークを横で見てたりする。楽でいい。
Daily Pair Rotation
最近新しくトライしてるのは、日次でペアを交代する仕組み。
タスクの区切りで交代、ってなると中々交代するタイミングが合わないのと、そのタスクの細かい部分については担当したペアしか分からなくなるので、ローテーションしてみようって話になった。
アンカー（残る方の人）を決めてペアの組み合わせを考えるんだけど、考えるの大変だねってなったので、Parrit を紹介しておいた。気に入ってくれてるみたい。
https://parrit.io/
Evening Huddle
朝のデイリースクラムとは別で、帰りの会もしてる。最初の頃は全員で集まって Daily Scrum と同じことをやってたんだけど、夕方と朝に同じことしなくてよさそうってのと、どっちかっていうと、エンジニアはエンジニア同士で、プロデューサーはプロデューサー同士で、もうちょっと深い話がしたいねって話がでて、別々にやることにした。
目的は、それぞれのロールの中で深い共有をして認識を揃えること。不安があれば共有すること。
朝の会では再計画に必要十分な情報をさくっと全員で共有するので、エンジニアリングやプロデュースの深い部分までは踏み込まない。一方、この帰りの会では、例えばエンジニアだと技術的な細かい不安や疑問、気になっていること、知っておいたほうがいいことなどを踏み込んで話す。プロデューサーも、プロデューサー内で認識を揃えるために、お互いの状況や意見を交換している。
そうそう。最初の頃は、朝のデイリースクラムでエンジニア全員が一人ずつ話をしていたんだけど、そうすると粒度が細かくなって全体が見えにくくなってしまうから、帰りの会で話をしたことをエンジニアの代表一人が次の日の朝に共有する、ということにした。代表は毎日交代する。
他のペアのタスクにも目を向けることができるようになった、とか、チームとしての全体観を考えるようになった、とかで良い感じ。
Me Time
ふりかえりの中で「ペアやモブで仕事をしていると、一人の時間がないので、一人時間を作ろう」ってなって、帰りの会の後の30分〜1時間ぐらいを me-time にした。その日にやったことの中で気になったことを調べたり、E-Learning をやったり、他にも色々やることがあるので大切な時間。
DVM
ここで DVM（Development Manager）の話をしておこうかな。
DVM はエンジニアのリーダーとして、技術的な意思決定をする。採用する技術や、エンジニアリングの方向性、技術的負債の返済計画をエンジニアに相談しながら決めたりする。
それから、PDM や PJM からの技術的な相談の窓口になっている。直接エンジニアたちに相談をすると、そのつど手がとまっちゃうので、まずは DVM が受け取ってそこで答えられるものには答えて、エンジニアに聞いたほうが良いものは、タイミングを見て DVM からエンジニアに相談をする。
そして、DVM はエンジニアのペアプロの部屋をうろうろする役割をしている。チーム内ではこの役割のことを「リベロ」と呼んでいる。これは、ふりかえりのときに「ちょっとペアで悩むことがあったときに、他のペアに聞きたいなーって思うときがあるんだけど、邪魔するのも悪いなぁって気持ちにもなる」という話があって「じゃ、DVM にうろうろしてもらって『これ聞きたいー』みたいなの相談できるようにしてみよう」ってなって始めた。実際にうろうろしてたら、色んな相談ができるようになったみたいで良い。
Pull Request Review
そうそう。もともとこのチーム「コードレビューに時間がかかる」「リーダーが忙しすぎてボトルネックになってしまう」という課題の相談があったのだけど、ペアワークの導入と帰りの会の深い共有と DVM as リベロで、Pull Request を出す前にエンジニア内で認識は揃ってて、実装の方向性の話も終わってて、出したときには「落ち着いて全体を再確認する」くらいになっているので、どちらの問題も解決した。
Backlog Refinement
次のスプリントでやるバックログアイテムの話って、プランニングのときに話をするだけだと全然時間が足りないね、ってなって、バックログリファインメントをやることにした。
週に一度まとまった時間を取るより、毎日少しずつ話しをしてみようか、ということで、デイリースクラムの後にやってる。
最初は全員でやってたんだけど、これもまたふりかえりで「DVMがエンジニアの代表で話をしてみよう」ってなったので、今は Chief PDM・DVM・PJM の3者でやってる。
全員でやってたときは細かい話がしづらかったんだけど、人数を絞ってからは結構密度の濃い話をすることができるようになって、良い。
次のスプリントのバックログアイテムを相談したり、もう少し長いスパンの話をしたり、お互いに相談したいことを持ち寄ったりしてる。
PDM「ビジネスチームからのこういう相談があって・・・」DVM「あぁ、そういうことなら差し込みになりますけどやりましょうか。その代わりこの最後のチケットはできなくなるけどいい？」PDM「はい、それでお願いします。ありがとう」
とか
DVM「ちょっと技術的に難しい問題があって、次のスプリントにはみ出しそうだから調整できると助かります」PDM「じゃあ、次に予定してたこれを、もう少し後にずらせるように調整してきますね」
とか
エンジニアリファインメント
これも最近始めたトライ。リファインメントに DVM が代表で参加するようになったので、そこで話し合った内容の共有をエンジニアにするのと、あとは、プロダクトバックログアイテムに見積もりとしてストーリーポイントをつける作業をエンジニアで集まってするのと。
火曜と木曜の Me Time をエンジニアリファインメントに充てるようにしてみてる。
2週間スプリントと Non Project Day
半年ぐらいたって、新しい開発スタイルにも慣れてきて実験も落ち着いてきたので、今年から2週間スプリントに変更した。それと同時に、Non Project Day を1週目の金曜日に導入した。
サービスのことを考えると、チームのスキルアップに時間をさくことには価値がある。という話になって、プロジェクトのことを忘れて「サービスのためになる」と思うことにそれぞれが取り組む日にした。
- 気になっている部分のコードを読む
- ドキュメントを整備する
- 自動化について考える
- 今後採用するかもしれない技術に触れてみる
- などなど
単純に楽しいし、プロジェクトの中で取り組むことが難しい部分にふれることができて、とても良い。
Business Status Sharing
Non Project Day の日は、Backlog Refinement はお休みにして、その時間で Business Status Sharing をすることにした。
PDM が今のサービスのビジネス状況を共有してくれて、今後の方向性や、ユーザーの声、ビジネスチームの声などをエンジニアに届けてくれる。
また、リリースしたものに対するユーザーの反応や KPI の状況なども教えてくれる。とてもおもしろい。
Sprint Review は再確認だけ
あ、そうだ。書くの忘れてた。
スプリントのアイテムは、完了したらそのつど PDM にレビューしてもらうので、スプリントレビューのときにレビューしてもらうことは特にない。スプリントレビューでは「今回のスプリントではこれらのチケットがクローズできたね」って認識合わせをして終わり。
スプリントプランニングの第1部も、すでにバックログリファインメントで十分に話し終わっているので、「この順番で上から理想時間見積もりをして、できるところまで取っていくね」という話で終わり。
なので、スプリントレビューとプランニング第1部合わせて30分くらいで最近は終わっている。健全な感じで良い。
仕組みを改善する仕組み
ということで、これが今の開発チームの全体像。
自分が気をつけたのは「一人にしない仕組みを作ること」。エンジニアもそうだけど、特に PJM や PDM や DVM やマネージャーは一人になってしまいがちなので、そうならないような仕組みづくりをしてきた。お互いがお互いを頼れる場を仕組みにしておいた。
そして、今はもう「仕組みを改善する仕組み」がチームの中にできていて、自分たちで回し始めているのでとても良い。
