チームの改善を支える振り返りのポイント #KPT #振り返り

目次

まえがき

ここで言う振り返りは「KPT」や「レトロスペクティブ」など、チームで起きたことを振り返り、改善につなげるためのセレモニーのことを指しま（施策の効果測定、KPIモニタリングを指す振り返りではない）

GW明けから自分がいるチームで振り返りをやろうと思うので振り返りのTipsをメモしておきます ここに書くことはプラクティスの一つではありますが、ベストプラクティスではないかもしれません というのも振り返り一つとってもチームの状態によって取るべき方法論が変わるからです

ここでは - 1週間、2週間程度の定間隔で行う - 対象はチームにまつわるトピック という前提のもとで、自分が普段気をつけているポイントを記載します

振り返りの目的

端的に言うとチームでお仕事する上での諸々（プロセス、ルール、環境 etc...）の振り返りを定間隔行うことで、継続的な改善の種とすることだと考えています したがって振り返りをすれば課題が解消されるもののではなく、課題を可視化するまでの役割が主と捉えています

一方でKPTのKeepにあるように課題だけではなく、良いことも洗い出します これは前述の改善の成果/成功体験を皆で認識して継続及び横展開していくほか、その取り組みに閉じない文化を可視化する側面もあると思っています

これまで６プロダクト（チーム）で振り返りの装着/運用を行って来ましたが、Keepに出てくる内容はチームの特色が出ることが多く興味深いです

振り返りの方法

このような形式で行うことが多いです 一般的なKPTと若干差分があったりしますが、そこは後述していきます

気をつけていること

気軽に挙げられるようにする

振り返りの場では課題を漏れなく洗い出すために、モヤったことは気軽に挙げてもらいたいと考えています 人は時間が経つとモヤったことを忘れていく生き物なので、思いたったときにProblemを起票をするのがベストだと思いますが、ちゃんと書こうとすると「面倒だなぁ...」とか「これはまだ騒ぐほどじゃないから言わなくていいや」等々、何らかの障壁で起票をせずに忘れ去ってゆき、機を逃してしまうことも考えられます

この障壁を取り払うために、Keep/Problemの前段に「思ったこと」を設けて気軽にバシバシ起票してもらうことで、課題の種を漏れなく洗い出し、「これは課題だろうか？」というところから議論をチームで行っています

また、各論にはなりますが、Slackでkpt用のチャンネルを設けてそこに書いてもらったり、TrelloとSlackを連携してSlackから起票できるようにしたり、いつでも起票できる環境が望ましいかなと思います

チームの状態に応じてテーマ策定する

チームが発足した当初は多くの課題が眠っていて、Problemも大量に出てくると思います。 しかし、しばらくすると誰もProblemを起票をしなくなり形骸化...なんてことはないでしょうか？（僕はありました） 課題が全く無い完璧なチームであれば当然Problemも出てこないわけですが、そんなチームは存在しないと思います。きっと見えていないとこに課題が眠っているはずです この見えていない課題を、「皆が認識していない」「皆が暗黙的に認識しているが振り返りの場で出てこない」の２つに分割したときに、後者へのアプローチとして、振り返りのテーマを策定することが有効と考えます テーマを絞って具体度を上げることで、「思ったこと」を挙げやすくするためです

Tryは軽くする

Tryを設定したまではいいけどなかなか着手できず、どんどん溜まっていった結果全然捌かれない...といったことがかつてありました クリティカルな課題を解消したいときに、根本的な解消を望む場合にはどうしてもその動きは大きくなってしまうためです そんな大きい課題を取り扱う場合には、改善の一歩目を踏み出すためにTryを軽く設定しています

例えば... - 暫定対応と恒久対応に分け、前者はTryで実施、後者はチームのしかるべきタスクキューに詰む(ex. バックログ - 「【暫定対応】を実施」 - 「【恒久対応】をバックログに起票」 - ディスカッションが必要なTryであれば会議設定まで - 「〇〇の会議を設定し、それを受けてアクションリストが明確になっていること」と設定する - そのあとアクションをどう捌くかは次回の振り返りで議論

一方でTryを軽くするあまり、あまり効果のない対応を敷いてしまわないように注意は必要です その課題のissueを見極めて、段階的に解消を行うSTEPを意識することが大事だと考えています

やらないやつはやらない

KPTのフレームで振り返りをやっていると、Problemに対してなにかしらのTryを設定しなければならない力学が働きがちです しかし、タイミングによっては今はアプローチできないものであったり、構造上解消ができなかったり（しづらい）、そもそもこれは課題なんだっけ？というものもあります

主目的は課題を可視化すること、次に改善の一歩目を踏み出すことと捉えており、Tryを機械的に設定して捌くことではありません。やるべきことと、やらないことを分けて考える必要があります

このようなProblemに対しては「また困るならば再度Problemに上がってくる」と割り切って、「今はやらない（今じゃない）」「これはProblemではない」「課題認識までに留める」等々Tryを設定しません 後のために、起票されたProblemは「やらないこと」レーンに移動し、やらない理由と共に記録しておきます

あとがき

これまで振り返りを装着していく中で実践したTipsを記載しました 今後ももちろん継続して振り返りは実施していくので、今後新たに気づきがあればここに追記していこうかなと思います

また、今回記載したのはあくまでも振り返りという1セレモニーに閉じた内容ですが、このような改善の取り組みにはチームの文化形成やゆとりの創出、ステークホルダーとの信頼醸成も欠かせないと思っています。 継続的に改善ができるチームをこれから作っていきたいぞ！と思った際には是非そこらへんも意識しながらトライしてみると良いかと思います（偉そうに言っていますが、自分もまだまだ試行錯誤です）