アジャイルコーチの備忘録

3歩歩いたら忘れるニワトリアジャイルコーチの備忘録。書評、活動記録など...

新しいふりかえりのアクティビティ: Requestについて

最近クライアント先で実験しているふりかえりのアクティビティが、チームや全体に良い効果をもたらしつつあると感じるため、アクティビティを「Request」と「KPTR(=Request)」とそれぞれ名づけてシェアしたいと思います。

「Request」のコンセプトです。

チームのカイゼンと同じくらいのエネルギーを、他者へのリクエストに向けることで、チームのみならず「チームを含むシステム全体」のカイゼンと調和をはかるためのアクティビティ

また、Requestが効果的なチームは以下を想定しています。

  • 関係者が多いプロジェクトの大企業等のスクラムチーム
  • 開発チームだけでふりかえりを実施しているチーム

f:id:norihiko-saito-1219:20200703193945p:plain

作成した背景

これまで、様々な企業でのスクラムマスターやアジャイルコーチの経験を通して、チームでカイゼンをするというアジャイルにおけるふりかえりのコンセプトは素晴らしいですが、実際の運用では以下のような問題があると感じてきました。*1

  1. チームだけで解決できるProblemを選ぶ中で、チームがチーム以外のことを考えなくなる
  2. チームだけで解決できるProblemを選ぶ中で、部分最適に陥り改善インパクトが低下していく

そして、上記の結果、以下状態になったチームも少なからず経験してきました。

  • チーム自身に対して無力感を抱くようになる
  • チーム以外に対して批判的感情を抱くようになる

無力感や批判的感情を抱いたチームは、チーム内では楽しく活動できるもの、マネージャーやステークホルダーなど他者との健全な関係性を抱けないまま、その偉大なパワーを次第に弱めていきます。

上記を解決するため、チームのProblemに対してチーム自身で解決策を図ると同時に、チーム以外の他者に対して積極的にリクエスト(=お願い)することを要素として追加したのが「Request」です。

Requestのやり方

  1. チームメンバーで課題の原因分析する
  2. チームのTryと他者へのリクエストを決める

1. チームメンバーで課題の原因分析する

まずは、チームメンバーで話し合いたい課題の原因分析をします。なるべくチーム内で閉じない、組織全体に関連しそうな課題を選択すると効果的です。*2

まずホワイトボード中央に課題のふせんを配置し、あとは「なぜなぜ分析」や「マインドマップ」やシステム思考の「因果ループ図」などで原因分析していきます。

この時、チームだけで解決可能な原因と、他者の力を借りる必要がある原因のふせんを色分けするのがポイントです。

f:id:norihiko-saito-1219:20200703193748p:plain

2. チームのTryと他者へのリクエストを決める

上記分析の結果から、チームのTryと他者へのリクエストを決めます。

上記での「チームだけで解決可能な原因と、他者の力を借りる必要がある原因」の境界線がチームの限界点です。
なので境界線付近の原因について、チームのTryと他者へのリクエストを決めます。

ここでは、自身へのTryのみならず他者へのリクエストを「SMART Goals」の考え方を活かしてなるべく具体的にすることがポイントです。*3具体的なリクエストであればあるほど、リクエストが受け入れられる可能性が高まるからです。*4

(リクエストの例)

  • 悪い例: 開発チームのことを考えてもっと早めに動いて欲しい
  • 良い例: スプリント開始前までに、スプリントで必要なPBIのリソースを用意して欲しい

KPTRのやり方

「KPTR」は「Request」の簡易版です。

KPTや類似するYWTなどのアクティビティでの「何をすべきか決定する」フェーズで、上記を参考に、チーム自身のTryに加えて、具体的に他者にリクエストしたいことを決定します。

想定される疑問

「Request」や「KPTR」はこのブログで公開するのでもちろんまだ具体的なリアクションはありませんが、これらのアクティビティに対する想定される疑問についてお応えします。

どうせリクエストが通らないのでは?

このアクティビティを聞いて「リクエストしても、どうせ上司や顧客は聞いてくれないよ......」という疑問が浮かぶかもしれません。

しかし経験的には、他者が拒絶するのは思いつきのような雑な提案や批判です。
このアクティビティでは以下のような工夫を重ねることで、リクエストが実行される可能性をできる限り高めています。

  1. 課題分析内容や、他者へのリクエスト内容がチームで合意できている
  2. 他者への丸投げではなく「ここまではチームは実施したので、ここから先は手伝ってください」という形のリクエストになっている
  3. リクエストが具体的である

チームの甘えにつながるのでは?

また、このアクティビティを聞いて「チームの甘えにつながるのでは?」という疑問が浮かぶかもしれません。

ですが、このアクティビティはチーム自身をカイゼンさせるよりも、勇気が必要になる場合があると感じます。

個人的な経験からも、それくらい他者へのお願いというのは難しいものです。

お願いは常に、断られたらどうしようという恐怖がつきまといます。なので現実はお願いする代わりに、遠慮や、我慢や、命令や、批判であふれています。「Request」 はチームを甘えさせるものではなく、チームに勇気を持って正々堂々と他者にお願いをすることで、チームの成長と周囲との健全な関係づくりを促すためのアクティビティなのです。

さいごに

今回は顧客先で実験中のふりかえりのアクティビティである「Request」をご紹介しました。
これからはもっともっとふりかえりのアクティビティを作っていきたいと思います!

もしご興味があれば、フィードバックや、自分のチームでも実験していただければ泣いて喜びます!😭

最後までお読みいただき、ありがとうございました!

*1:他のエントリでより詳しく考察しているため、もし良ければお読みください。 norihiko-saito-1219.hatenablog.com

*2:「Request」はLeSS(大規模スクラム)のオーバーオールレトロスペクティブに影響されていますが、1. オーバーオールレトロスペクティブよりも手軽にできること、2. 他者へのリクエストの有無が異なります。 less.works

*3:「SMART Goals」については以下の記事が参考になります。 qiita.com

*4:具体的なリクエスト程実行可能性が高いことについては、NVC(非暴力コミュニケーション)が参考になります。「相手から受け取りたいものがはっきりすればするほど、必要としていることが叶う可能性は高くなる」 www.amazon.co.jp