Modern business: Brainstorming / kevin dooley
こんにちは、エンジニア/スクラムマスターの中村です。
前回「朝会」についてお話しました。
今回は「ふりかえり」のお話です。
今日は私がふりかえりで気をつけている点などをお話します。
ふりかえりの特徴
「ふりかえり」の特徴として以下が挙げられます。
1：チーム全体が、行動可能な改善策を探し、試す勇気を得ること
2：チーム全体が、これまでの行動を思い返し、新たな気づきを得ること
3：チーム全体が、やってみてうまくいった行動を、チームに定着させること
4：チーム全体が、メンバーの多様性を受け入れ、信頼関係を築くこと
「ふりかえり」では私は「KPT」(Keep/Problem/Try：けぷと)という思考のフレームワークを使うことが多いです。ですので主に「KPT」にフォーカスを当ててお話します。
※参考：プロジェクトファシリテーション実践編：ふりかえりガイド(リンク先はPDFです)
Keepが出なければ、まずはGoodでもOK
チームになって間もなかったり、経験の浅いメンバーが多い場合、(続けていきたい習慣の)”Keep”がなかなか出てこないことがあります。
どうしても出ない場合、シンプルに「良かったこと」という観点で”Good”を挙げてもらうようにします。
例えば「○○機能のプログラムが分からない時にAさんが声をかけてくれた」などです。
“Good”には(例の「Aさんが･･･」のように)「誰か」という要素が入っていることが多くあり、チームメンバーの良い点を(「ふりかえり」を通じて)誉めることができます。
Problemでは「どう困ったのか？」を意識
「タスクを細かく分割できなかった」という”Problem”に対して、もう1段深く「それによって誰がどんな風に困ったか？」という質問をします。
もし答えが「誰も困っていない」だとしたら、”Problem”でないかもしれません。もしかすると「細かく分割する」こと自体がチームにムダな行為かもしれません。
表面的な現象ではなく、本当にそれは困っていることなのか？本当の原因(真因などと呼びます)は何か？を見つけ出し、その真因に対する”Try”を考える必要があります。
Tryは「それでPはなくなるか？」を意識
その”Try”が実現できれば、(対応する)”Problem”は解決するか？という観点で確認します。
こうしてみると、その”Try”は表面上の原因に対するものであり、真因には届いていないことに気づいたり、また、その”Try”以外にも必要なことに気づくこともでできます。
前回との差分を確認すること
「ふりかえり」は一定のペースで継続的にすることでより効果を発揮し、上手く行っていないチームはこの前回との差分を確認していないことが多い気がします。
ふりかえりの最初に前回の”Problem”や”Try”を確認します。
そして、前回の”Problem”がまだ残っているのか？、”Try”が”Keep”になっているか？などを意識して話し合います。
前回の”Problem”が”Try”によって解消され、それが”Keep”として定着するというサイクルはチームの【成功体験】となります。
最後に
「ふりかえり」によって(リリースしている、していないに関わらず)1つの区切りとなり、そのタイミングで、自分達チームを客観視できるメリットがあります。
今回はKPTにフォーカスを当ててお話しましたが、他にも「タイムライン」「ニコニコカレンダー」といったプラクティスも一緒に使ってみるとより効果が出ることもあります(この話はまた機会があれば･･･)
同じような問題が出ている、チームが自分達の成長を実感できていない、停滞感が･･･と悩んでいる方は「ふりかえり」をやってみてはいかがでしょうか？
ソーシャルアカウント
フェンリルのオフィシャル Twitter アカウントでは、フェンリルプロダクトの最新情報などをつぶやいています。よろしければフォローしてください！
関連記事
