みんなで考える開発チームのふりかえり改善活動

今回のブログでは、チームのふりかえりの改善活動について書きます。

業務の中にふりかえりの時間を設けているチームは多いでしょう。

私がこれまでに所属していたチームでも、ほとんどのチームでふりかえりの時間を設けていました。ふりかえりは、すべてのチームで共通した手法を用いるのではなく、チームの携わる業務によって、さまざまな手法を組み合わせていました。

この記事では、Backlog の開発を行っている課題チームのふりかえりの目的を整理したあと、なぜふりかえりを改善する必要があったのか、どのような手法を選んだのかをまとめます。

なぜふりかえりをするのか

そもそも「自分たちはなぜふりかえりをしているのか?」というところに立ち返って考えてみます。

私は「自分たちはなぜふりかえりをしているのか?」の問いに対して、次のような答えを用意していました。

  • チームが役割や状況に応じた適切な手法や業務の進め方を考えるため
  • チームに所属するメンバーが同じ方向を向いて進むため

これだけではイメージがしづらいので、その界隈でささやかれる2つの格言を引用して考えてみます。

ある木こりが、がんばって木を切っている。

通りがかった旅人がその様子を眺めていたが、斧を振るう勢いのわりに、なかなか木が切れていない。

見ると木こりの使っている斧がこぼれしているようなので、旅人は言った。

「斧を研いだほうがいいのでは?」

すると、木こりは言った。

「わかっちゃいるんだけどね、木を切るのに忙しくて、それどころじゃないよ」

「木こりのジレンマ」という寓話|斧を研ぐ時間がなぜ重要なのか?

「早く行きたければ一人で行け、遠くへ行きたければみんなで行け」

(If you want to go fast, go alone. If you want to go far, go together.)

早く行きたければ一人で行け、遠くへ行きたければみんなで行け

1つ目の格言は「木こりのジレンマ」として広く知られています。すばやく変化する状況では、あるときうまくいった・効率的だった手法が、別のときにはそうではなくなることを表す比喩としてとらえています。加えて、常に締切に追われているようなチームが、業務改善をできないことを表しているともとらえています。

2つ目の格言は、大きな成果を出すチームでは多様なメンバーが必要であり、メンバー間のコミュニケーションや合意形成に時間を割く必要があることを表しているととらえています。

ちなみに、この両方で「チーム」や「チームに所属するメンバー」を主語として解釈している点もポイントです。ふりかえりで話す内容の主語を「私」「あなた」という個人ではなく「チーム」のような人のまとまりを主語として会話することが望ましいと考えています。そうして、チームが進むべき方向を導き出すことが、チームで行うふりかえりを行うことの醍醐味ではないでしょうか。

簡単に目的を確認できたので、以前はどのようなふりかえりをしていたのかを紹介しておきます。

ふりかえりのフレームワークはYWT(やったこと・わかったこと・次にやること)を使って Cacoo にふせんを貼り付けます。ミーティングの時間は毎週水曜日の午後に1時間確保し、次のようなタイムラインとテンプレートを使って進めていました。

内容

説明

チェックイン

今の気持ちを良い・普通・悪いの3段階で表わして一言話す

やったこと・わかったことを書く

個々人でCacooに「やったこと」「わかったこと」のふせんを貼る

やったこと・わかったことを発表する

Cacooに書いたことをチームに発表する・話し合いをする

次にやることを書く

個々人でCacooに「次にやること」のふせんを貼る

次にやることを発表する

Cacooに書いたことをチームに発表する・話し合いをする

改善前のYWTのテンプレート。左の青のふせんが Backlog のタスクと対応していて、関連するふせんを線で結んでいます。改善前のYWTのテンプレート。左の青のふせんが Backlog のタスクと対応していて、関連するふせんを線で結んでいます。

なぜふりかえりを改善するのか

私の考えるふりかえりの目的と以前のふりかえりについて書きました。それでは、なぜふりかえりを改善しようとなったのかを説明します。

ふりかえりの手法がチームに合わなくなった

1つ目の理由としては、前節で引用した「木こりのジレンマ」のように、かつてうまくいった手法が今のチームの役割や状況に合わなくなったことです。

一般的に、チームの役割や取り扱う業務が変化したときに、以前のふりかえり手法が十分に機能しなくなる場合があります。

Backlog の課題チームには、主に軽微な不具合修正を行う Operation ロールとユーザーに価値を提供する機能を開発する Development ロールが存在し、それを交互に切り替える運用をしています。

Operation ロールで扱う不具合の場合は、ほとんどが1〜2日程度で片付くので、個々のタスクを書き出すだけでも「やったこと」がいっぱいになる状況でした。一方で、Development ロールでは1つのタスクに数週間・数ヶ月を要するので、同じような方法だと「やったこと」に1つしか書けないという状況に陥りました。

考える時間が減った

2つ目の理由は、考える時間を減らしてしまうことです。

長い間、同じふりかえり手法を使っていると、やったことリストが今週自分の対応した課題の羅列になってしまい、ふりかえりが進捗共有になってしまうことはありませんか?私はあります。

今思えば、その兆候として、「Backlog の履歴情報をAPIで取得して一覧化する」とか「CacooのAPIを使えないか」といった自動化したい意欲が生まれていました。

前にも少し書きましたがふりかえりの目的は、チームで適切な手法や業務の進め方を考えることや同じ方向を向いて進むことでした。

そう考えると改善の方向性は、進捗共有を自動化することではなく、課題を通して考えたことを共有し一緒に考える時間を作ることとすべきだったと感じています。

実際「ひとつひとつ転記する」行為を通してその業務に思いを巡らしながら、ほかの人の書いている内容をみて「そうだそうだ」と相槌を打つ時間にこそ深いふりかえりがなされているのではないかと私は考えています。

毎週のふりかえりに飽きてきた

3つ目の理由は、現状のふりかえり手法に慣れてしまうことで、ふりかえりに飽きてきて参加することを億劫に感じてしまうことがありました。

具体的な内容はここでは紹介しきれませんが、ふりかえりの改善を提案しようと思った当初は「毎週同じようなふりかえりをやっていて楽しくなくなってきた」というような漠然とした気持ちが根底にあったように思います。

以上3つの理由を検討するうちに、話し合うこと・考えることにフォーカスできるようにして毎週のふりかえりを楽しくするというのが最終的な目的ではないかと思い至りました。

どのように改善したのか

ふりかえりを改善するための理由は「話し合うこと・考えることにフォーカスできるようにする」ことだったと述べました。

ここでは、その目的を達成するために、具体的にどのような手法を取り入れたのかについていくつか紹介します。

色のついたふせんを使う

これまでのふりかえりでは単色のふせんを使っていました。これは過去のふりかえりの履歴を辿ることでわかったのですが、以前は色のついたふせんを使う運用をしていたようです。ただ、当時はこの手法がうまく機能しなくなったったために単色のふせんを使うようになったようでした。

ただ、今回は「自分の書きたいのはどれにあてはまるのだろうか?」と考えることや「自分はこの色だと思っていたけど、○○さんが別の色にした理由が知りたい」という会話のきっかけになるのではないか、というねらいがあったのでこの方法を提案しました。

4つの色のついてふせんを使います。赤は人やチームに関すること、黄色はプロセス・プラクティス、紫はスコープ・スケジュール、オレンジは技術・ツールに関することを書いています。4つの色のついてふせんを使います。赤は人やチームに関すること、黄色はプロセス・プラクティス、紫はスコープ・スケジュール、オレンジは技術・ツールに関することを書いています。

なお、この手法は過去のブログに紹介されているものを参考にし、項目をアレンジしたものです。

スプリントレトロスペクティブ(ふりかえり)(30分〜1時間) – Backlogを上手に使ってらくらくスプリント開発

また、あえて細かなルールや分類の基準を用意しないことで、ある程度自由に解釈ができるので、自分とは異なる視点や考えがよく見えるようになりました。

興味があるものに投票する

これまでは投票は行わずに、個々人が興味のあるものに対する「次にやること」をふせんに書く手法をとっていました。

この方法では、次のアクションが自明のものになってしまったり、課題の深掘りが十分でなく無難なアクションになってしまったりしてるのではないかと考えました。

そこで、個々人で「やったこと」「わかったこと」を書いたあとに、ファシリテーターがリードしつつ全体を眺めて、自分がより深く話し合いたい内容に☆を付けるという手法を取り入れました。

今のところ☆を置ける上限を明確に定めていないので、チームメンバーが関心をもっている内容を一覧にすることができていて、興味のある内容にフォーカスした話し合いにつなげることができていると感じています。

みんなで「次やること」を話し合う

前節にも書きましたが、これまでは個々人が「次にやること」をふせんに書いて発表する手法をとっていました。この手法でうまくゆくこともありましたが、チームメンバーが関心をもっている課題を絞った方が効率的に話し合いができるのではないかと考えました。

そこで、ファシリテーターが基本的に☆の多いものから順に取り上げて、みんなで話し合いをするという手法を選びました。

基本的には、☆をつけた人やふせんを書いた人に自由に話してもらいます。そのあとに投票していない人も含めたみんなで課題の深掘りを行います。

これにより、チームメンバーが関心をもっている課題を選んで話し合えるようになりました。想定しなかった効果として、同じふせんに投票していても興味のある点がまったく異なるようなこともあり、より多様な視点で課題について考えられるようになったと感じています。

ふりかえりのふりかえりを行う

ふりかえりの最後に「今日のふりかえりはどうでした?」と質問する時間を設けています。

新しい手法を取り入れたり、アレンジしてみたりしたあとにその効果がでているか確認することは大切です。手っ取り早く確認する方法として、ふりかえりの参加者の感想を聞いて次回の参考とするという方法があります。

実はこの手法は、ほかのメンバーが最近ふりかえりの最後にやっていた方法で、私も積極的に取り入れてゆきたいと感じているのでここで紹介しました。

まとめ

ふりかえりの改善活動はふりかえりのファシリテーターが新しい手法を取り入れたりアレンジを加えることで現在も継続しています。本記事執筆時点では、次のようなタイムラインとテンプレートになっています。

内容

説明

チェックイン

今の気持ちを良い・普通・悪いの3段階で表わして一言話す

やったこと・わかったことを書く

個々人でCacooに「やったこと」「わかったこと」のふせんを貼る

やったこと・わかったことを発表する

ファシリテーターが全体を読み上げてまとまりごとに話し合いをする

興味のあることに投票する

もっと深く話し合いたいことに☆を置く

次にやることを話し合う

☆が多くついたものから話し合いをして Cacoo に「次にやること」のふせんを貼る

ふりかえりのふりかえり

「今日のふりかえりはどうでした?」の質問をする

改善後のYWTのテンプレート。ふせんの色が4つになっています。次にやることは「すぐやること」「次の機会にやること」に分けています。改善後のYWTのテンプレート。ふせんの色が4つになっています。次にやることは「すぐやること」「次の機会にやること」に分けています。

この活動を通して、ふりかえりは「チームで考える時間・話し合う場を作ること」を目的とすべきなのではないかと考えるようになりました。

今回紹介した個々の実例はチームによって合う・合わないがあると思います。ただ、目的については大きくはずしてはないだろうとは思ってます。

最後に、業務が忙しい中ふりかえりの改善提案を快く受け入れ、一緒に考えてくれているチームに感謝します。

開発メンバー募集中

より良いチームワークを生み出す

チームの創造力を高めるコラボレーションツール

製品をみる