我々の開発チームでは、「バラ・とげ・つぼみ」というふり返りメソッドを使って1週間のふり返りをしています。 ふり返りメソッドには「KPT」や「プラスデルタ」などよく名前が聞くものがいくつかありますが、「バラ・とげ・つぼみ」という手触りを感じる見立てに惹かれて試してみました。 これまでに４回やってみて、仕事の進め方を改善するアイデアが出てきたり、難しいことを難しいと言葉にできていたりと効果を感じています。そこで、この記事で紹介します。何か新しいふり返りメソッドを試したい方や、初めてふり返りをやってみようと思っている方の手助けになれば幸いです。
「バラ・とげ・つぼみ」のふり返りメソッド紹介
このふり返りメソッドは、対象となる期間に起きた出来事を「ポジティブな出来事（バラ）」と「ネガティブな出来事（とげ）」に分けます。そしてそれらを踏まえた上でこれから「未来に向けて期待していること、ワクワクしていること（つぼみ）」を見つけます。
こういうのは成果物を客観的に見てで善し悪しを判断することはできなくて、実際に手を動かし続けることで理解できるものなのですが、何もないとよくわからないので例を作ってみました。
こんな感じで、3つの区画を並べて付箋を貼っていきます。我々のチームでは「バラ」と「とげ」はとにかく軽い気持ちで書くようにしています。そこから行動に繋げようとはせず、「助けてくれてありがとう」とか「想定外の出来事に困ったな」ということを文字にして声に出す場にしています。
そして、ポジティブだからOKとか、ネガティブだから改善案を出すという分け方ではなくて、どちらの出来事とも対等に向き合いつつ、それらを踏まえて、今ワクワクしていることを見つけます。
「つぼみ」ですが、これは難しいです。最初は一個も出ませんでした。私自身「つぼみって何書きましょうね」という感じでした。
ところが繰り返しやっているうちになんとなくわかってきました。それはKPTのTryよりも少し控えめで、チームの半歩先にこんな状況が生まれていたらいいなというある種、無責任な願望でした。一つひとつに即効性はないのですが、そういうのできるといいよね、というものがいくつか出てきました。その状況にとてもワクワクしました。
そこから具体的なアクションに繋げることもあれば、話すだけで終わることもありますが、それらの「つぼみ」は次の週に「バラ」になったり「とげ」になって、また次の「つぼみ」が見つかって、チームの庭が少しずつ賑わっていくように感じています。
導入方法の紹介
ここまで読んでいただいて、「バラ・とげ・つぼみ」の概要や効果はなんとなく伝わっているかなと思います。 ただ、ふり返りをチームで始めるのってちょっとドキドキしますね。特にあまり名前を聞いたことのないふり返りメソッドをやってみようと提案するのは、拒絶されたらどうしようと不安な気持ちになりますよね。私はそうでした。
ここからは、私がどのようにチームに「バラ・とげ・つぼみ」のふり返りを導入したかを紹介します。
ドキュメントを書く
前回のブログ*1で、技術文書に限らず、チームの目標や取り組みについてドキュメントを書くことの重要性を紹介しました。ですので、まずは文章を書きました。
これをプルリクエストにしてチームメンバーにコメントをしてもらい、全員のapproveがもらえた後にふり返りを実施しました。もちろん、レポジトリの中にドキュメントとして存在しているのでいつでも参照できます。
ドキュメントを書くときに気をつけたのは「ふり返りの目標」を明確にすることです。今は、「チームのアウトプットを最大化させる」としています。何でもかんでもふり返ろうすると収集がつかなくなったり、何を書こうか悩んでしまうので、思考の方向性を揃えるために目標を明確にしています。
まとめ
ふり返りメソッドはいろいろありますが、多くのものが独自の概念を使っていました。もうちょっと軽くはじめられるものはないかなと探している時に見つけたのが「バラ・とげ・つぼみ」でした。また、ソフトウェアエンジニアは、何かにつまづいたことを「刺さった」と表現することが時々あり、もしかすると親和性高いかもなと思いやってみました。今のところうまくいっているのでいいなと思った方は導入方法を参考にしながら試してもらい、ぜひ感想を教えてください。
途中、他のふり返りメソッドと比較するような表現をしましたが、もちろん、どちらの方が優れているというものではありません。ふり返りメソッドによってふり返る対象が異なるので、チームの状況に応じて適切なものを選べると良いと思います。我々のチームもそのうち新しいふり返りメソッドを試すかもしれないので、その時はまた紹介します。
読んでいただきありがとうございました。
