クライアントの現場と共に、課題を解決し、あるべき姿に向かうために活動している 現場コーチ では、ほぼ必ず自分達チームのやり方を改善していくプロセスとして「 ふりかえり 」を導入しています。
ふりかえりのやり方は(まずは)オーソドックスにKPTを用いることがほとんどです。このブログではいくつかのTipsを書いているので良かったらそちらも読んで読んでくださいね。
そのような「ふりかえり」ですが、何度も行っているうちにやり方に慣れてきて安定してKPTが出てくるようになるのですが、一方でふりかえりのやり方に対して「もっと上手くできるのではないか?」「何かしっくり来ていない」という感覚を持つこともあります。
このような時には「 自分達が行っているふりかえり自体をテーマにふりかえりをする 」ことをオススメしています。
「ふりかえり」をふりかえってみる
特にやり方を変える必要はなく、これまでのふりかえりと同じやり方で「ふりかえりが上手くできているポイント、習慣はなにか?(Keep)」「自己改善の場になりきれていない障害がはなにか?(Problem)」などを参加者で話し合っていきます。
インプットとして、これまでのふりかえりのKPTボードやKPTの内容を並べて眺めてみることもあります。
このように「ふりかえり」をふりかえってみた結果、現場では以下のようなアイデアが出ていました。
- Tryが大きな目になりがちなので、Tryを噛み砕く時間を取るために時間配分を変えてみる。
- トーキングオブジェクトを導入して、それぞれの会話の流れを整理してみる。
- チーム全員ではなく、まずは3、4人のグループで話し合ってみる。
- その場で書くのではなく、事前にKeepやProblemをWikiなどに書き出しておく。
#これらは一例ですし、実際にやってみて定着したものもありますし、うまく行かず続けなかったものもあります。
常にふりかえることができるのが理想
少し話は逸れますが、ふりかえりは「2週間ごとに行う」といったように定期的に実施されることがほとんどです。
ギルドワークスが現場コーチをしているチームでも1週間ごと、2週間ごとが半々です。
しかし、ふりかえりの場がなくても「あれ?このやり方、おかしいかも…」と誰かが思えば、すぐにその違和感の正体や真因をチームで話し合い、改善案を考えて、アクションをしていくというのが理想の現場だと考えています。
ですので、2週間に1回などといった定期的なものではなく、毎日ふりかえりをする…さらに言うと「ふりかえり」というプロセスそのものがなくても、自己改善ができていくと良いチームだと思います。
とは言うものの、そのような場がなくても意見を表明できる人もいれば、そういう「ふりかえり」という安全な場がないとなかなか意見を出せない人もいるのもまた事実です。また日々プロジェクトの目標に向かってタスクと向き合っている中では、なかなかそのような「自分達のこれまでをふりかえってみて、改善する点を話し合う」という視点や思考にスイッチするのが難しい場合があります。
だからこそ、そういう自己改善の機会であるふりかえりをよりうまくやるために「 ふりかえりをふりかえってみる 」というものは、グッとチームの力を上げてくれることもあります。
これまで何度かふりかえりをやっている現場、チームは一度「ふりかえりをふりかえってみる」ことをオススメします。
※注意:この記事は2015年7月16日に GuildWorks Blog で公開したエントリをリライトしたものです。
※アイキャッチの写真: https://www.flickr.com/photos/chaparral/2802886649/
この記事もどうですか?
-
学び、経験して、一人前を目指すハイレベルな場 〜 新人・越にとってのギルドワークス 〜
「普通のプログラマはいないんじゃないの?」「ベテランしか募集してないんじゃ?」「名前は聞くけれどよく分からない」と思われがちなギルドワークス。いったいどんな会社で、どんな人が働いているのか。ギルドワークスの若手社員である越(と先輩社員の前川…
-
GitHub最新人気リポジトリ【2018年版】
これは ギルドワークスイベントカレンダー 13日目の記事となります。 普段、仕事やプライベートで、何か新しい技術を学ぶ時、githubでサンプルコードを探して、手元で動かすということを行っています。 そこで今回は2018年も終わりに近づいて…
-
「正しいものを正しくつくる」ための考え方・道具を整理してみた
ギルドワークスの佐々木です。 私は、2010年度に 産業技術大学院大学の履修証明プログラム「人間中心デザイン」 を履修していました。デザインとはなんぞや?も分からぬまま、デザイナーやディレクターの方々に混じってエンジニアという立場で参加して…