ふりかえりの考え方について

スララムで約半年間プロジェクト運営をしてきて、スクラムというフレームワークの中に『ふりかえり』というイベントがあります。それについて私なりの考え方がはじめとは変わってきました。

ふりかえりがうまくいかなかった頃

• 現在のプロジェクトでは以下のような体制で行っています。

• 5月~5月末

  • 4名 + コーチ1名
    • 全員スクラム未経験

• 6月

  • 4名 + コーチ1名
    • 1名マイナス
    • 1名プラス
      • スクラム経験者

• 7月~

  • 5名 + コーチ(スクラムマスター)1名
    • 1名プラス
    • 1名プラス
      • スクラム未経験者

• 上記を見てもわかるように私も含めてスクラム未経験者が多く、うまくふりかえりができていませんでした。

• ふりかえりがうまくできていないというのはアジェンダが良くないとか改善案が出ていないとかそういうことももちろんあります。

• ですが、そういったことは慣れの問題もあったりKEPTやYWTなどフレームワークで解決することもあります。

• そもそもチームでふりかえりが終わった直後になんか釈然としない、もやもやしているような状態でした。

• 6月が終わったときにコーチから指摘をいただき、なんとなくその原因がわかってきました。

ふりかえりが少し改善してきた頃

• そのように感じていた頃、私がなんとなくふりかえりをしていてもチームが良くなっていっていくイメージがつかないということを6月末のふりかえりで議題に上げました。
• コーチからは以下のような図でアドバイスをいただきました。
• アドバイスとしては主に2つです。
  • 1つ目はチームの方向性を決めること。
    • チームの方向性とはチームがどうなっていたいかです。
    • たとえば「開発のプロフェッショナル集団になる(開発軸)」とか「生産性のあるチームになる（プロセス軸）」とかです。
    • いわゆるチームとしてのKGIを決定します。
    • チームの方向性が決まっていたらふりかえりで出てくる内容も決定する指針も生まれます。
    • たまに〇〇さんがこうしようと言ったからと後から言う人がいますが、チームの方向性が決まっていたらそもそもチームとしてこうしようと決めたよねという一体感も生まれます（そもそも誰かが言ったとかはどうでもよい話ですが、、、）。
  • 2つ目は進捗を図ること
    • 例えばチームの方向性が 「開発のプロフェッショナル集団になる(開発軸)」とします。
    • その際に開発のプロフェッショナル集団とは具体的にどうなっていたらその状態であるのかを定義します。
    • いわゆるKPIを決定します。
    • 例えば「開発のプロフェッショナル集団」=「全員がRailsアプリケーションを1からすべて開発できる」とします。
    • ゴールがそこですので、今はそうでないのでしょう。では現地点で考え得るKPIを策定していきます(例えば全員が助けを得ることでRailsアプリケーションを開発できるなど)。
    • 進捗を図ることができるとふりかえりでチームの状況が把握でき、チームが次のステップに進むための次のアクションへも話を波及することができます。
• 上記2点のアドバイスをいただくことでふりかえりの内容もチームのふりかえりへの集中度もあがったと思います。
• ちなみに私のチームでは1つのKGIに対して、主に2つのKPIを策定し、そのKPIを満たすために進捗度をはかったり、プロセス改善をしています(以下のイメージ)。
  

これから

• 上記でうまくいっているようですが、あくまでチーム内の話です。
• ちなみに今までチームと言っているのは開発チームのことです。
• チーム内での方向性を決める際にPOの意向(=プロジェクトの意向)が全く反映されていません。
• チームはあくまでPOがプロダクトを開発していく上で最適だと考えられて作られています(以下の階層構造のイメージ)。
  
• 私のチームはまだプロセスにしか目に行っていなく、ビジネスとしてこうなりたいからこういった方向性のチームになりたいとかそういった話になっていません。
• コーチからいただいた図を見ていただくと分かりますが、方向性は決めることができますが、間違った方向に行っている場合には逆効果になってしまう可能性もあります。
  

最後に

• ふりかえり、難しいですよね。
• でも正しいふりかえりを正しく実施ことでチームの成功になると信じています。
• 皆さんも良いふりかえりを！