LIFULLでふりかえりにLDJ（Lightning Decision Jam）を使ったら良いことしかなかった話し。
賃貸・不動産検索の「LIFULL HOME'S iOSアプリ」のプロダクトマネージャーをしている鈴木です。
過去には社内でアジャイル開発の推進を行い、研修や勉強会の運営などをしていました。現在もスクラム開発に関するサークルをやっています。
この記事は、ふりかえり（表） Advent Calendar 2023 の19日目の記事になります。
よいチームはふりかえりによって出来る🤝
チームづくりのタイミングや手法はプロジェクトの中でいくつもありますが、中でも一番効果的だと感じているのは「ふりかえり」です。
あれこれとスタート時のワークショップに時間をかけていた時期もありましたが、とりあえずやってみてふりかえりに時間をかけた方が効率がよいし、深い話ができると感じるようになりました。
ふりかえりの手法としては、KPTを主に使っています。シンプルなので、ファシリもしやすく、参加者も発言しやすい点がよいですね。
ただチームやプロジェクトが成熟してくると、単なる定期的なイベントになって新しい発見がなにもないみたいなケースもあるので、そういった場合は半期などのタイミングでKPT以外のふりかえりを実施したりしています。
チームやプロジェクトの状態によって、使えるふりかえりのフレームワークをいくつか知っておくと強いプロダクトマネージャーになれると思います。
シンプル！だけど、実は難しいKPT
KPTの導入はシンプルですが、実際の運用は案外難しいものです。KPTに関するあるあるな問題を、ChatGPTにリストアップしてもらいました。
1. 問題の把握不足：チームメンバーが実際の問題を見逃してしまうことがあります。問題を見逃すと、それらは改善の機会を失ってしまいます。
2. 問題の具体化の欠如：問題を抽象的に認識し、具体的な要因や原因を特定しないままにすることがあります。これでは問題に対する効果的な対策を講じることが難しくなります。
3. 提案の不十分さ：「Try」のセクションで提案されるアクションが、具体性に欠けたり、実行可能性が低いものになってしまうことがあります。それらが抽象的すぎると、実際の改善には繋がりません。
4. 振り返りの疎かさ： 振り返りが習慣化されていない場合、チームは問題を同じように繰り返す可能性があります。振り返りのプロセスを怠ることで、学びや改善の機会を逃してしまいます。
5. コミュニケーションの不足： チームメンバー間で十分なコミュニケーションが取れていないと、問題点や改善提案が十分に共有されず、解決策の実行が遅れたり、誤解が生じたりすることがあります。
どれも頭を悩ませる問題ですが、今回は「2. 問題の具体化の欠如」と「3. 提案の不十分さ」の解決につながる方法について書いていきたいと思います。ようやく本題です！
安直なKeepや、抽象度が高いProblem、なにかしないとで生み出されたぺらぺらなTryによって、チームに強制的なイベントや儀式が追加されて息苦しくなった方にはおすすめです。
アジャイルすぎるLDJを紹介します💖
紹介するのは「LDJ - Lightning Decision Jam ライトニング・ディシジョン・ジャム」という手法です。
Note & Voteを基本のスタイルにとしたフレームワークで、テーマに対するネガティブとポジティブ、それを解決するアイディア、アイディアの見積もりと優先度をチームで素早く決めることができます。
LDJの詳細については、翻訳記事を書いてくれている方がいたのでそちらを参照してください。
Miroにもテンプレートが用意されているので、そちらもわかりやすいです。
アジャイルすぎで、特に私がよいなと思ったポイントを紹介していきます。
1. Note & Voteでチームの意思決定を見える化する
LDJはまずテーマに対して、ポジティブなこと、ネガティブなことを参加者全員で書き出して共有するところからはじまります。
これはKPTのKeepとProblemを出すところと変わらないので、とっつきやすいと思います。
ネガポジの書き出しと共有が終わったら、なんの問題についてチームで取り組むべきかを投票を行います。
スピードを重視したワークのため、最終的な意思決定はワークのリーダーが行いますが、投票によってメンバーの共通の問題を理解することができるのでチームの意思決定が見える化されます。
2. How might we?でTryすべき課題を定義する
KPTの場合は、ここからTryを考える流れになりますが、LDJではまず問題を「How might we?」「どうすれば我々は◯◯できるようになるか？」で問い直しをします。
この「How might we?」 は、デザイン思考プロセスで問題の再定義や解決策の発見を促すための問いのたて方です。このフレーズを使うことで、問題をより具体的に捉え、解決策を考える際に創造性や多様な視点を取り入れることができます。
例えばProblemの中で「エンジニアのリソース不足」といったような、チームの問題だけれど、チームでどうにもならない思考停止のProblemがあがり続けてしまい苦しいということはありませんか？
そんな問題も「How might we?」で問い直すと、チームで解決できる問題になります。
あとProblemの裏返しになるぺらぺらTryの量産防止にもなります。
3. アイディアの優先度を決めてTryの負債をつくらない
「How might we?」でTryすべき課題を定義したあとは、課題を解決するアイディアを出して投票をします。
投票でよさそうなアイディアが出たら、最後はそのアイディアをインパクト・エフォートのマトリクスでプロットをしていき、チームで取り組むべきアイディアの優先度を決めていきます。
下の図のような形で、まず基準となるアイディアを置くことで、アイディアの効果や工数を相対的に見積もることができます。
工数は1スプリントをセンターに置くとチームで議論がしやすいと思います。
こうすることで、出てきたアイディアの優先度を決めることができます。
Tryで出てきたのはいいけれども、ずっと誰も取り掛からない「Tryの負債」に悩める方にはめちゃくちゃ良い整理方法です。
おしまい
今回はLDJをふりかえりで活用する形で紹介しましたが、一般的にはグロース施策のアイディア出しや優先度決めに利用されています。
なので、このフレームワークを習得するとアイディア出しから、施策の優先度決め、ふりかえりまで応用できてしまうという優れもの💪
慣れれば約60分で、チームの意思決定を素早くができるようになります。よかったらぜひチャレンジしてみてください。
最後にひとつだけ宣伝です。現在LIFULLでは、一緒に働いてくれる仲間を絶賛募集中です！カジュアル面談もやっていますので、興味のある方はぜひご連絡ください。
☛サービス企画採用はこちら （カジュアル面談はこちら）
☛エンジニア採用はこちら
☛デザイナー採用はこちら