kikukawa's diary

都内で活動するシステムエンジニアが書いてます。 興味を持った技術やハマったポイント、自分用メモをつけてます。 最近はweb中心

振り返りでチームの状態を知る

Makuake Product Team Advent Calendar 2018 の5日目の記事です。 業務委託としてマクアケに参画させてもらってるので書かせてもらいました。 ここに書かれていることはすべて私見です。

振り返りの立ち位置

私は振り返りをチームの状態を確認するということに重きをおいてやっています。
本来の意味合いであるKPT的なことも意味はありますが、あくまでそっちはサブとして考えてます。
チームの状態とプロジェクトのフェーズを合わせて考えながらマネジメントをするためです。

やり方

2週間に一回

うちのチームは2週間を1スプリント(厳密にスクラムをやっているわけではない)としてやっているので、2週間ごとに1回金曜の昼に振り返りをやっています。
ただし、決めれられた日にやることよりも、メンバーが揃っていることのほうが重要なのでよっぽど先にならない限りは延期することもあります。

テーマの設定

テーマを設定しないと、漠然としてしまって、議論が発散する、結論もよく分からないということになりがちです。
なので、うちのチームでは振り返りのたびにメンバーに特に振り返ってほしいと思うテーマを1、2個提示しています。
そのスプリントを過ごしてからでないと、テーマを出しづらいので、大体振り返りの前日にテーマを伝えています。

テーマの例

  • XXXXに向けてやりたいこと
    • 次のフェーズに向けて今のうちに考えておきたいことです。
    • それぞれの考えを先に出してもらって次にやることのスケジューリングをしたかったためです。
  • プロジェクト進捗
    • 進捗が問題あっても問題なくても聞くことがあります。
    • マネージャーとメンバーの進捗に対する対する意識の乖離を防ぐためです。
  • リスケ後の進捗感
    • ちょっと無理そうだったリリース日を遅らせた直後のスプリントで設定しました。
    • まだ心配とか、これなら大丈夫とかを聞きたかったためです。
  • チームの状況が見えているか(他の人の動きが追えているか)
    • 個々でやること(技術的、機能的)がバラバラだった時期に設定しました。
    • お互いのことを知っていると安心感と信頼でチームがまとまります。より分かりやすくチームの状態を知りたかったためです。
  • チームの状態
    • ストレートに聞いてしまったときです
    • タックマンモデルで言う混乱期で何度か設定しました。
  • リモートワーク
    • 元々一部メンバーがリモートワークで、さらにリモートワークするメンバーを増やした直後に設定してました。
    • リモートワークを始めてからまだ少ししか経っていないので、度々出てきます。
  • pull request
    • タックマンモデルで言う統一期に入り始めくらいに設定しました。
    • 仕様が決まり、実装を頑張るフェーズに入る前だったので、レビューが効率良くなるよう事前に問題点を潰したかったためです。
    • 情報共有(必要な情報は探しやすくなっている?)
    • 情報共有(お互いの作業の仕様など伝えられてる?)

GoodとBadのみ

よくあるKeep,Problem,Tryではなく、GoodとBadを使っています。
なるべく感情を出してもらいたいという意味で実際にはもう少し言葉は変えてますが。 それぞれこんなことを書いてもらっています。

  • Good
    • うまくいったと感じたこと
    • 感謝
    • お祝い
    • 他メンバーのいい動き
  • Bad
    • 言いたいこと
    • 直したいところ
    • 心配なところ

メンバーに気をつけてもらうこと

書きたいことを書く

私がマネジメントで大事にしていることの一つに 言いたいことを言う というのがあるんですが、 振り返りでも同じで、ちゃんと書きたいことを書くということを気をつけてもらっています。
それを書いたことで議論が勃発する可能性もありますが、 黙って抱えていることのほうがずっと良くないのでなるべく書いてもらうようにしています。

書くべきことを忘れない

バランスを読み取るためにはある程度の付箋の枚数が必要です。
ただ、枚数を出すこと自体が大事ではなく書くべきことが書かれないのが問題です。
2週間という長い期間だと、前半のことは忘れがちなので、工夫して忘れないようにしましょう。
うちのチームでもこの辺いろいろありましたが、今ではチーム用のtimesチャンネル作ってそこにポストしてもらってます。

無理に枚数を書いてもらう必要もないですし、枚数のノルマを設けているわけでもありません。
あくまで、書こうと思ってたことがあって、それを忘れてたらもったいないよね。という話です。

チームの状態を読み取る

GoodとBadそれぞれの付箋の枚数とバランスからチームの状態を読み取ります。
付箋は事前に書いて貼ってもらっておいてもらいます。
そんなに細かくは分からないですが、ざっくりとチームの状態を知るには十分です。

ここで注意が必要なのは日本人はあまり人を褒める文化がないということです。
なのでどうしてもGoodの数が少なくなります。
そこを考慮にいれた上で考えます。

また、もう1つの注意点としては、小さい声でも耳を傾ける必要のあるものはあるということです。
付箋の枚数とバランスで全体を見ることはできますが、個人の状態までは分かりません。
仮にチーム全体がうまくいっていたとしても、個人単位では問題を抱えていることもあるかもしれません。

Goodの付箋の枚数 >> Badの付箋の枚数

Goodが大幅に上回っているときです。
この状態なら絶好調と言えるでしょう。
ただ、あまりこの状態を見たことはないです。

Goodの付箋の枚数 > Badの付箋の枚数 or Goodの付箋の枚数 = Badの付箋の枚数

Goodが少し多いか、同じくらいのときです。
大抵のメンバーがうまく回っていると思っているはずです。
この状態をキープしたいです。

Goodの付箋の枚数 << Badの付箋の枚数

チームの状態が悪いときです。
本来は、ここまでになる前にマネージャーとして何か手をうつべきです。

メンバーに伝えるかどうか

チームの状態をみることは大事ですが、それをチームメンバーに伝えるかどうかは チームの成熟度によると思ってます。

私はチームができた直後はそもそもそこを見ていることも伝えてませんでした。
今ではもう前述のような読み取りをしていることも伝えています。

最初からやり方を知ってしまうと、意図的にGoodを増やそうという意思が働いて 本当の状態よりも良い状態だと思われるからです。
それを考慮した上で読み取り、伝えてもいいんですがね。

まとめ

  • 振り返りはチームの状態を知るために使える
  • 書きたいことをちゃんと書いてもらう
  • メンバーにどこまでやり方を伝えるかは考える

関連記事

kkkw.hatenablog.jp