こんにちは。asatoです。スクラムマスターです。
チームでのふりかえりにおいて、新たな観点の獲得やまんねり解消のためにさまざまなふりかえりフレームワークが提案・実験・実践されています。すごいことです。
ふりかえりでは、トピックの「ブレスト」「選択」「議論」、が主な流れになります。このうち、「ブレスト」に対して、「KPT」「象・死んだ魚・嘔吐」「Fun/Done/Learn」など、さまざまな手法がよく話題にあがります。現在僕が支援しているチームでも、毎週いろいろな手法が試されており、チームの議論を活性化させています。
一方で、僕には気がかりなことがあります。それは「トピックの選択」の手法が妥当なのかどうかです。「選択」には「ドット投票」が設計されていることが多いです。重複投票の有無や票の重さなどのバリエーションを加えることはありますが、いわゆる「多数決」です。
なぜ、「トピックの選択が多数決であること」が気がかりかと言うと、プロダクトチームは属性に偏りがあるからです。プロダクトチームのほとんどはエンジニアが占めています。ただただ「多数決」を選べば、当然エンジニアに関連のあるトピックが選ばれます。チーム全体の改善を促進し、納得感や満足感を生み出すには、この事実を考慮してファシリテーションする必要があります。もしあなたのチームが、プロダクトマネージャーやデザイナーなど、チームの中で少数派の属性のメンバーも含めてふりかえりをしているなら、ぜひ一緒に考えさせてください。
このポストでは、ふりかえりにおけるトピックの選択の手段として、多数決以外の方法を探していきます。
ドット投票（多数決）のメリデメ
まずはドット投票について考えてみます。ふりかえりのトピック選択におけるドット投票とは、参加者がそれぞれ決められた数のドット（票）を持ち、チームで議論したいトピックにドットを貼り（投票し）、得票数の多いトピックから議論していくやり方です。投票は1トピックに1つまでや、1トピックに複数票を投票できるなど、バリエーションを持たせられます。票を色分けして重みをつけることも可能です。例えば赤は3ポイント、青は1ポイントとし、赤と青をそれぞれ1票と3票ずつ投票できるなどです。
メリット
ドット投票（多数決）のメリットは「平等性」です。一人ひとりが同じ重さの票を投票し、その結果から議論するトピックが選ばれるため、平等にトピックを選べます。
また、選ばれなかったとしても、各トピックの得票数がわかるため、視覚的にチームの関心事や傾向を把握できます。
さらに、僕たちは子供の頃から多数決に慣れ親しんでいます。ホームルーム、だいたい多数決でしたよね。そのため、大半の日本人にとって、多数決は受け入れやすいはずです。
デメリット
ドット投票（多数決）のデメリットは、公平ではないことです。一人ひとりの票の重さは変わりませんが、冒頭でも述べたとおり、プロダクトチームの多くはエンジニアのため、エンジニアという属性が多くの票をもっている状態が生まれます。これは良い悪いの話ではなく、そういう傾向があるということです。プロダクトマネージャーやデザイナーが出したトピックよりも、エンジニアが出したトピックの方が選ばれやすいことはないですか？
この不公平性は、ふりかえりの効果を低減する可能性があります。少数派である人たちはふりかえりに参加する意義を感じにくくなります。少数派の意見にももちろん価値はあり、むしろチームの外に目を向ける絶好の機会になるトピックも多いです。そのような機会損失の危険性もあります。
ドット投票（多数決）以外の方法案
このポストでは、以下の代替案を考えてみます。
- トピックをランダムに選ぶ
- 早い者勝ちでトピックを選ぶ
- トピックを選ぶ人を選ぶ
- トピックを属性の範囲でカテゴライズする
- エンジニアだけのふりかえりを開催する
トピックをランダムに選ぶ
多数決をやめて、ランダムに運命を委ねます。これは『 闇鍋 』に代表されるやり方です。物理的なブレストで出された付箋を箱に入れて1つだけ取り出すやり方ができます。Miroを使っているなら『 Totally Random 』などのアプリを使うことで実現できます。
ブレストしたトピック自体はエンジニア寄りのものが多くなりやすいですが、選択はランダムなので多数決よりも議論するトピックの傾向はばらけるはずです。
一方で、満場一致で選ばれるべきトピックが選ばれない可能性もあることを忘れてはいけません。また、すべてのトピックが等しく選ばれる確率を有することで「選ばれても大丈夫なものしかブレストで出せない」という心理的ハードルに繋がる可能性もケアする必要があります。
早い者勝ちでトピックを選ぶ
「この話がしたい！」と言えるくらい話したいことがあるなら、その話をするのがいいんじゃないだろうか、という方法です。「この話は今ここでしておきたいです！」「これが解消されないとすごく困るので話しましょう！」そんなトピックがあるならそうしましょう。自主性を重んじた手法と見ることもできます。
この方法であれば、トピックのブレストをスキップしてしまうのもありです。僕は以前、 このやり方を「焚き火」と名付けてチームで実践していました 。焚き火の動画を見ながら思い思い話をするので「焚き火」。そのときどきに気になったことを話し始められるので、とても面白かったです。
デメリットは、個人の性格や個人間の関係性からトピックを提案しにくいと感じる人もいることです。「これが気になっているのは自分だけかも」のような想いがストッパーになってしまいます。全体のバランスを見てファシリテーションしなければ、いわゆる声の大きい人が満足するだけの会になりかねません。
トピックを選ぶ人を選ぶ
トピックを選ぶ人を選んで、その人にトピックを選んでもらおうという戦略です。
トピックを選ぶ人の選び方はいろいろ考えられます。くじ引きみたいにランダムでもいいですし、順番に回してもいいです。エンジニアから1名、次はエンジニア以外から1名、のようなやり方であれば偏りも解消でき、議論するトピックの幅も広がります。
デメリットは、やはり「これが気になっているのは自分だけかも」問題でしょうか。選ぶときの参考にする程度で、事前にドット投票を行ってみてもよいでしょう。
トピックを属性の範囲でカテゴライズする
ブレストで出てきたトピックを、「エンジニア内」「チーム内」「チーム外」にカテゴライズします。ドット投票を行い、得票数の多いトピックを議論していきますが、次のトピックを洗濯するときは今と違うカテゴリーのトピックから選択します。これにより、特定の領域関連のトピックばかり選択してしまうことを防ぎます。
チーム内でエンジニアが多数派という前提のため、この3つのカテゴリーを作りましたが、そこはチームのコンテキストに合わせてカスタマイズできますね。
このカテゴライズの面白いところは、どのカテゴリー、つまりどことどこの関係性に対するトピックが多く出てきているのかを可視化できるところです。優劣があるわけではありませんが、チームの内側にばかり目が向いているのであれば、チームの外側に目を向けるチャンスも提供できます。
ベースはドット投票（多数決）ですので、そこまでデメリットはありません。
エンジニアだけのふりかえりを開催する
ここまでチーム全体のふりかえりに注目してきましたが、エンジニアが自分たちのエンジニアリングスタイル、プラクティス、プロセスのふりかえりをすることはとても大切です。プロダクト開発にとってエンジニアリングは「アイデアを価値に変える」とても重要な役割を担っています。
ですので、エンジニアだけで集まって、他の職種のメンバーの目を気にせず、自分たちにエンジニアリングを見つめ直す時間を設けることは価値があります。例えばチーム全体で毎週1時間ふりかえりをしているなら、30分はエンジニアだけでエンジニアリングのふりかえりに集中し、残りの30分はチーム全体でエンジニアリング以外のトピックに集中することもできます。または、毎日15分エンジニアだけで集まり、自分たちのプラクティスやプロセスの改善に取り組むこともできます。
エンジニアだけで集まることでチーム感が損なわれることに不安を感じるかもしれませんが、テーマを絞り貢献できるテーマに全力で貢献できる環境を作ることはチームの効果性を高めることに繋がります。「自分はこのテーマには貢献できないけど、いないといけないしなぁ」という心境の方が不健全ですので、思い切ってチームのイベントの参加者を分断するのも一つの手です。
おわりに
チームのふりかえりにおいて、ドット投票（多数決）はエンジニアリング関連のテーマが選ばれやすく、エンジニア以外の満足度や自己効力感を低下させている可能性に触れ、その解決策をいくつかリストアップしました。
どこかで誰かの参考になったら嬉しいです。みなさんはどんな工夫をしていますか？
