こんにちは。
BtoB SaaS Product Teamの中嶋です。
Product Teamでは1週間のイテレーションごとにチームでふりかえりをしています。
コロナ禍に入る前は物理のホワイトボードでやることが多かったと聞いていますが、最近は大体figjamボードを使っています。
オンラインのホワイトボードはスペースを自由に使えたり、付箋以外にも画像とかスタンプを押せたりと楽しいですが、油断せずに片付けないでおくと過去のふりかえりの残骸がどんどん残っていきます。
年明けになったのもあり、それらを片付けようと思ったときに、ふと「過去のふりかえりをふりかえってみるのも良さそうだな」と思いました。
この記事では、いままでのふりかえりで出てた課題やそれに対してのアクション、逆に上手く行かなかったものや、どういうアクションがチームのみんなが実行しやすいのか考えてみたいと思います。
- チームの前提
- 4〜6月：アジャイルのプラクティスの実践に悩むことが多かった
- 7〜9月：コミュニケーションとチームでの意思決定をすることの悩み
- 10〜12月：コミュニケーションとシンプルさへの伸びしろ
- おわりに
チームの前提
先に私のいるチームについて簡単にお話しようと思います。
他のチームとは少し違う試みとして、私自身が主導して去年の4月から新しくチームを立ち上げるということをしています。
Product Teamでは、各プロジェクトチームでペアプロ・TDDを始めとしたアジャイルな開発を実践しています。採用のタイミングによって、新しくメンバーがJoinすることもありますが、その場合でも既にアジャイルの知見に詳しいメンバーと共にやることになります。
そういった状況なので、知見の少ないメンバーのみを集めてイチからアジャイルな開発について伝える機会は少ないです。
私がいまやっている取り組みは、自分自身が他のメンバーにアジャイルの事についてどれだけ伝える能力を伸ばせるか。結果的にアジャイルなチームをつくってスケールさせることができるかといったテーマが背後にあります。
チーム人数は私を含め、以下のとおりです。
- 4〜6月：3人チーム（2人Join）
- 7〜9月：4人チーム（1人Join）
- 10〜12月：5人チーム（2人Join、1人leave）
4〜6月：アジャイルのプラクティスの実践に悩むことが多かった
当時のふりかえりボードを眺めていると、チーム立ち上げ時の4月からの3ヶ月間はとにかくペアプロに関する悩みがずっと続いているように見えました。
チームの前提のところでもお話したとおり、Product Teamの特徴的な文化として、常にペアプロとTDDをやります。
中でもペアプロはTDDのRED→GREEN→REFACTORのリズムで交代するのではなく、お互いがキーボードを自然に取り合う交代にしています。
このチームでもペアプロ・TDDが自然にできるのを目指していきましたが、まずここでいろんなのびしろが見つかるようになりました。
このときよくふりかえりに出ていた話題として、以下のようなものがありました。
- ドライバーとナビゲーターを自然に交代し合うといった事が発生しづらい
- ペアでやってて少しでもわからない、ということがあったらすぐ誰かに訊くということが出来てなくて、長く悩むことが続いてた
ペアプロの実践を助けるアクション
ふりかえりのアクションも、ペアプロを始めとしたアジャイルプラクティスをちゃんと実践、強化する方向のものが多かったです。
ペアプロのことで悩んだときには、弊社のメンバーが作った「よりよきペアプロのためのガイドライン」やペアプロの心得をチーム全員で読み合わせるアクションをして、私たちが目指すペアプロの姿を認識合わせる時間を取りました。
こちらはメンバーJoin時にオンボーディングとして全員が目を通すのですが、いまの状態に疑問を持ったり、実際にやってみて解像度が上がった状態から、またチームで読み合わせてDiffを取るのはとても大事だと感じています。
いまふりかえってみて：チームの形成期はなるべく対面で顔を合わす頻度を高める
いまふりかえってみたときに、チーム発足時はチーム全員の出社頻度をもっと多くしても良いと思いました（当時は週一でした）。
オフラインの方が相手の表情や纏う空気感がわかりやすく、キーボードが取りやすいし、すぐ近くにチームメンバーがいるので声の掛けやすさは違います。
まずはオフラインでのペアプロの空気感を覚えてから、リモートでもそれに近い形で再現できるように努めていくのが今は良いのかなと思っています。
オフラインで出社したときの他のメリットとして、ペアプロ慣れてない人の行動を観察することができる、というのが良かったです。
「なかなかキーボードが奪えない」と話をしていたメンバーのペアプロの姿勢を観察していると、キーボードから手が離れてひざの上に乗っていたり、Slackの通知に気を取られて返信をちょっと書こうとする時もあったので、それだとすぐにキーボードを奪うことができないというフィードバックをすることができました。
ペアプロに慣れていないうちはありがちな行動だと思うので、実際に目にしてフィードバックできるという意味でも、チーム全員オフラインで出社する頻度を増やすのは有効だと思っています。
他やってみて良かったアクション
個人的には「わからなかったらすぐ人に訊くって、どういう感覚か」*1というのを社歴の長いメンバーにインタビューするのは、個人的にはユニークだったし良いアクションだなと思いました。
Product Teamに入ったばかりだったので、他のメンバーと知り合う機会もできましたし、スッと他のチームに聞きに行くということもその場で実践出来ました。
もう一つのアクションは、とにかくプランニングと結果を検証するという回数をとにかく増やすものでした。
イテレーション中に一回もリリースができなかったことがあり、原因を深堀りした結果そもそもカンバンが全く動いていない状況に対して誰も声かけできないという課題感があったので、それにアプローチしたいアクションでした。
これですぐにカイゼンしたかというわけでは無かったですが、試行回数を増やすことでチーム全員のカンバンに対する感度だったり、計画通りに進まなかったらどうするかと、計画を状況に合わせて適応させる動きが意識づいてきたと感じています。
7〜9月：コミュニケーションとチームでの意思決定をすることの悩み
3人チームで3ヶ月間走った後に、新しいメンバーが1人Joinしたタイミングでした。
当時のふりかえりを眺めていると、新メンバーのオンボーディングに関わる課題が多かったように思います。
- 新メンバーがなかなかキーボードを奪えない
- 既存メンバーが新メンバーに一方的に喋って教えることが多かった
先生と生徒の関係を早く脱したい課題
新しく入ってきたメンバーがキーボードを取り合うペアプロに慣れていないのは、4月のときと同じくペアプロガイドラインやペアプロの心得を読み合わせて認識合わせるなどをしていきました。
私以外の既存メンバーと新メンバーがペアを組んだ時の課題として、既存メンバーが新メンバーに一生懸命コードベースやストーリーのやることを教える傾向がありました。*2
片方のパートナーを指導するような、先生と生徒の関係性です。
一時的な先生と生徒の関係性は良いですが、それが長引いてしまうとペアプロの相乗効果があまり期待できなくなってしまいます。
なるべく新メンバーが主体的に関わる経験を早いうちに何度も積める方が良いので、以下のようなアクションに取り組んで、みんなが同じように主体的に動く機会（質問をする）を入れるようにしました。
私個人では、最初はなるべく抽象的なナビゲートや、パートナーの「わからない」に関してどこまでがわかっていて、何がわからないのか、というコーチング寄りなペアプロを取り入れるようには意識しました。*3
いまふりかえってみて：最初の1〜2イテレーションは経験の長いメンバーと多めに組むようにする
当時はあまり考えずに新メンバーとのペアは全員でローテーションしていました。
これは新メンバーが色んな人とペアになり、チームに早く馴染んで欲しい気持ちもあったのですが、いま考えるとやはりペアプロ・プロジェクトの経験の長いメンバーと多く組むようにした方が良かったかもしれないと思います。
私以外の既存メンバーもペアプロにようやく慣れ始めたばかりなので、自身がドライバーを取ったり、パートナーにナビゲートしたり、ということはできます。
ただ相手から質問を促す・ドライバーを奪わせるといったスキルについては慣れていない状況でした。*4
そのため、相手を促す事に多少慣れている人が新メンバーとペアを組む機会を多くするというのが新メンバーにとっても、チームにとっても良いのではないか、といまは思っています。
不確実性の高い中での意思決定をすることへの迷い
この時期はチームメンバーの知見が少ない技術を触る機会があり、何が必要で、何から手を付けなくてはいけないのか。ということがあやふやでチーム全体が迷子になりやすかったです。
それは議論が何度も発生して長引いたり、いろいろ調べすぎて結果的にリリースがイテレーション中にできなかったという形で、ふりかえりに出ていました。
この時は、議論の時間を計測して長引きそうなら誰か詳しそうな人に相談する・自分達がどこで詰まっているのかをホワイトボードで図示するといったアクションを取るようにしてました。
いまふりかえってみて：何を目指していて、そこに向かう際に何がわかっていて、何がわかっていないかを整理する
この頃は議論が空中戦になる事が多かった印象です。
知見の少ない技術に触れる場合、当たり前ですがいろんな「わからない」ことが押し寄せてきます。チームメンバー全員が「わからない」ことだらけで、そもそも何を目指していたのかを見失いがちだったり、その認識がだんだんズレてくる感覚がありました。
本来はユーザーストーリーという目指すべきWhatがあるのですが、長いこと議論が発散していたりすると忘れがちになりますし、ユーザーストーリー自体はユーザーに届ける価値を表しているため抽象的です。
そのため、もっと手近な目標までブレークダウンをして、自分達がまずは何を知らなければいけないのか。現時点では何を知っているのか。というのをホワイトボードなどを使って図示しながら、チームメンバー全員で認識を揃えながら丁寧にやっていくべきだったなと、いまは思っています。
10〜12月：コミュニケーションとシンプルさへの伸びしろ
7月に入ったメンバーが9月で抜けたところに、新しいメンバーが2人Joinして5人チームになった時でした。
7月のときと同じように新メンバーが最初キーボードを取れないという課題はありましたが、以前よりはそこまで長引いてなかったです。
このときはコミュニケーションとシンプルさについて悩むことが多かった印象です。
チーム内のコミュニケーション不足
当時はペアチェンジをする頻度も2時間〜半日ぐらいにしていました。*5
理由としては、1時間のペアチェンジだとコンテキストスイッチのコストが大きくなってしまうので、それを軽減することを優先したからです。
そもそもJoinしたばかりの新メンバーは、同様の理由でストーリーを固定しているので、新メンバー2人が固定だと既存メンバーのペアチェンジする頻度がより高まる傾向になります。
ペアが長時間固定されて同じストーリーに取り組む形になった結果、それ以外のストーリーに対するコンテキストが薄くなってしまい、情報に差が生まれやすくなってきました。
もちろん、チームメンバーが均等に全てのことを知っている必要は無いと思っています。「そういえばそういう事あったな。それは◯◯さんがやってたから聞けばわかる」から「完全理解しています」ぐらいの濃淡があって良いと思っています。
この時期ふりかえりで話題になったのは、そもそも特定の誰かしか知らない、という状況です（あるペアが他のチームから共有を受けたことを、他のペアに共有できていなかったなど）。
ペアチェンジのタイミングや、共有しようと思ったらすぐにちゃんとコミュニケーションを取って共有ができることが理想です。
とはいえ、いますぐそれは難しかったので、まずは共有のタイミングを頻度高くやるというアクションにしました。
それによって一定ふりかえりで上がっていた事象は減ったように見えます。
いまふりかえってみて：ペアチェンジはペアプロに慣れてない時こそ頻繁にやった方がいいのでは
現在はペアチェンジは1時間に戻していますが、Joinしたばかりのメンバー固定をする以外は、やはりペアチェンジの時間を1時間〜1時間半くらいにして、それ以上伸ばさない方が良いのではないかと、いまは思います。
コンテキストスイッチのコストが大きくなるのはわかります。その一方で、それは最初のうちであり、ペアチェンジが頻繁にできていれば、それぞれのペアがどんなユーザーストーリーを進めているのかが、うっすらとわかる状況になって次第にコンテキストスイッチのコストも減っていくと思います。
コンテキストをキャッチするという訓練にもなるので、そういった試行回数を重ねやすくするためにも、頻繁にペアチェンジをした方が矯正ギプス的にも良いのではないかと思っています。
逆に半日でペアチェンジをするというのは、コンテキストのキャッチが上手い・どういう時に情報をすぐ共有するか、というのに慣れたメンバーが多いチームの方に向いているような気がしています。
いくつかのやることを混ぜてしまう課題
ユーザーストーリーを実現できる変更をデプロイしてみて、期待した通りにならなくて完全Doneにならないということはよくあります。
その時、他のユーザーストーリーでついでに対応をする事がありました。
解決したい課題を1つのストーリーに2つ以上混ぜると、何かあったときに調べるのが難しくなってきます（何かあった時に戻すのも大変になります）。
時と場合によっては一緒にやる方が良い場合もありますが、上記のように物事を混ぜて複雑にしないで、シンプルに保つことを意識していった方が良いと思いました。
事象は違えど、解決されていない課題に対して別の課題を一緒に混ぜてしまいそうになることは何回か起きていました。
現状あまり有効的なアクションは出せていないですが、何度か似た課題にチームが遭遇して、そのたびにふりかえってみれば、チームとして良いアクションが出せると思っています。
おわりに
9ヶ月分でも情報量がかなり膨大でした。
ふりかえりでいろんな話題が出ていた感覚ですが、全期間通してみると、ペアプロやコミュニケーションの面で悩んでいる事が多かった事に気づきました。
3ヶ月ごとに新しいメンバーが入っているので当然な気はしていますが、それだけスムーズにペアプロを行えるようになるまで、相当練習が必要になるということだと感じています。
普段はできていてもメンバーが変わったり、知見の少ない技術に触れるなど、状況が変わるとできなくなってしまうということは、まだチームの中で習慣として根付いてないとも言えるので、どんな状況でもアジャイルのプラクティスがちゃんと発揮できるようにしていきたいです。
*1:Product Teamではわからなかったらすぐに人に訊く、というのを推奨しています
*2:新メンバーが内向的な特性だったり、既存メンバーが責任感を持って教えなければ、という気持ちが強かったことによって観測できた事象かなと思っています
*3:具体的な内容については、こちらのスライドをご覧いただけたらと思います。https://speakerdeck.com/jnuank/yorixie-li-de-napeapurowocu-suniha-dousurukawokao-eru-81592987-dff1-44f1-9ae3-630f0d9d33e3?slide=55
*4:そういったスキルが別で必要だ、と私自身認識できたのは結構後だったりはしますが…
*5:Product Teamは大体1時間〜1時間半でペアチェンジすることが多いです
