運営者情報

運営してるひと: @sters9

       

妻と猫と横浜あたりに住んでいる。最近は Go や Kubernetes や GCP をしています。 PHP や JavaScript もすこし。

プライバシーポリシー

tools.gomiba.co

アーカイブ

2021/03 (8) 2021/02 (12) 2021/01 (8)

2020/05 (2) 2020/04 (2) 2020/02 (2) 2020/01 (1)

2019/12 (3) 2019/11 (2) 2019/10 (5) 2019/09 (3) 2019/07 (6) 2019/06 (4) 2019/04 (3) 2019/01 (2)

2018/12 (6) 2018/10 (4) 2018/09 (6) 2018/08 (7) 2018/07 (16) 2018/06 (7) 2018/05 (7) 2018/04 (5) 2018/03 (3) 2018/02 (10) 2018/01 (6)

2017/12 (8) 2017/11 (6) 2017/10 (10) 2017/09 (12) 2017/08 (12) 2017/07 (3) 2017/06 (1) 2017/01 (4)

2016/12 (5) 2016/10 (3) 2016/09 (1) 2016/07 (2) 2016/06 (1) 2016/04 (1) 2016/02 (1) 2016/01 (2)

2015/12 (1) 2015/10 (1) 2015/09 (3) 2015/06 (1) 2015/01 (1)

2014/08 (2) 2014/07 (3) 2014/05 (1) 2014/01 (7)

2013/12 (2) 2013/11 (4) 2013/10 (1) 2013/09 (1) 2013/08 (3) 2013/07 (4) 2013/06 (5) 2013/05 (2) 2013/04 (7) 2013/03 (1)

いろいろな振り返りを試す、あるいは、振り返りの振り返りを行う

なぜいろいろな振り返り手法を使うのか

よく見る Keep, Problem, Try は何も悪くない。ただこれをずっとやっていると「今回も順調だったな!とりあえず、みんなKeepとProblemをいっこは書いてくれよな!」とか「Tryがたくさんでたな、やっていこう!→前回のTryやったっけ?まいいか」のような、なんとなくこなす、のような格好になりがちだと思っている。

実際にそういう経験もある。

これはやっている人達が問題に気づけていないか、埋もれてしまっているんじゃないだろうか。KPTではもっとProblemに注目して、議論して、Tryを絞ってやっていかないといけないんじゃないかな。なかなか難しそうだけど。

そこで、視点を変えた振り返り手法を使うことによって、KPTでは気づけなかった問題に気づくことができるのではないかと考えている。

いろいろな振り返り手法

他にもいろいろあるのだけれど、やってみたことのある振り返り手法についてだけ書く。

KPT

  • Keep, Problem, Try
  • 続けたいこと、問題なこと、解決案
  • 問題を探し、解決することにフォーカスしている

YWT

Mad, Sad, Glad

Sailboat

  • https://tune.hatenadiary.jp/entry/2020/03/02/100000
  • 絵を書く振り返り。プロダクトやチームのゴールに向かう姿にフォーカスする
  • 以下の要素を描く、船以外はふせん的なテキストも書く
    • 船 = 自分たち
    • 左側に島 = プロダクトやチームのゴール
    • 右側に風 = プロダクトやチームにとっての追い風、チャンス
    • 船の下にイカリ = ゴールに向かうためのいまのブロッカー
    • 島の下に岩 = 将来的にリスクになること
    • (左右は逆でもいいし位置も大体でいいと思う)
  • チームメンバーが5人を超えているとワイワイお絵かきできて面白そう

What Went Well, What Didn’t Go Well

  • うまくいったこと、うまくいかなかったこと
    • KPTを簡略にして、この2つの問いに絞る
  • おそらく書かれる内容は多種多様になるので、きちんとグループ化する必要がありそう

Team Rader

  • https://medium.com/the-liberators/retrospective-do-the-team-radar-1794057653e9
  • レーダーチャートを使ってそれぞれがレーダーを作る
  • 項目は振り返りしたいポイントに合わせて設定する必要がある(難しそう)
  • ポイントの高い低いという乖離がある部分は、特定の人にタスクが偏ったとか、それぞれが感じた違い、何か原因がある
  • 逆にみんなが低いポイントをつけた部分はみんなが共通して問題を感じている可能性がある

その他

Retrium という振り返りツールがあって、ここの紹介ページにいろいろな手法が紹介されている。

https://www.retrium.com/retrospective-techniques

振り返りの進め方

以下のようにすすめるとよいんじゃないかなと。

  1. 個人で書く
    • 他の人からバイアスを受けないようにすることがだいじ
  2. 発表
    • 誰がそれを書いて、どんな問題なのか、どういうことを感じたのか、とか色々言う
    • ここでのフォーカスは、誰が良かった悪かったではなく、何が良かった悪かったのか、不明瞭な点は議論して掘り下げる
  3. グループ化する
    • 個人でそれぞれに書くと内容が似ているものがあるのでそれらはまとめる
    • 無理にグループ化する必要はない、取り扱いたい話の粒度を考えて分けるとよい気がする
      • 例)タスクのアサインができなかった、タスクの中身が不明瞭だった、といったものがでたときに…
      • まとめると: タスクの準備が甘い、のような話で考えることができる
      • まとめないと: それぞれの問題を考えることができる
  4. 投票する
    • 何が一番問題だったのか、解決したいのかを考えるために、投票を行う。1人あたり3-5票くらいもつといいと思う
    • すべての課題にアクションするのは難しいので、投票の多かった上位2つ3つに対してネクストアクションを考える
  5. ネクストアクションを決める
    • ここはみんなでかんがえる
    • ネクストアクションは忘れがちなので、中長期的なものよりは、次のタイミングではこれをやってみよう!くらいのものが出るといいと思う

振り返りの振り返り

最初に書いたけれど、振り返りを淡々とこなすだけ、マンネリ化してくると振り返りの効果、意味がない。その兆候が見られ始めるとか、ある程度の振り返り回数をこなすなどしたら、振り返りの振り返りを行うのがよいだろう。

ここに上げた方法のどれでもいいので、これまでのやってきた振り返りの内容や雰囲気を思い出しつつ、それらを振り返る。例えば、最初にあげたなんとなくKPTやってる、に対してKPTするとこういうことになるのではないだろうか。

  • Keep:
    • 継続してKPTができている
    • 毎回いくつかのTryが出ている
  • Problem:
    • Tryが実施しきれていない
    • KPTがいまいち盛り上がらない
  • Try:
    • Tryを1つに絞る、Tryでやることを振り返り時に明確にする
    • 別の振り返りを使ってみる

リンクとか