はじめに
チームが継続的に改善していくために定期的にふりかえりを行うことは重要です。
ふりかえりの代表的なフレームワークの一つとして「KPT」や「KPTA」があり、私のチームでも活用する場面が多いのですが、最近まで以下のような課題を感じていました。
- Problemをどう深掘ってよいか分からない。
- KeepからはActionが比較的出やすい一方で、Problemに対するActionは具体化しづらい。
- Actionに腹落ち感がなかったり、数スプリント前に出たものと同じものになり根本解決につながっていないと感じる。
そうした課題感を抱える中で、研修で問題解決フレームワークを学ぶ機会がありました。そこで学んだ「問題解決には思考の順序がある」という考え方をふりかえりに当てはめてみると、Problemの扱い方の解像度が上がり、Actionの質も向上しました。
本記事では、その考え方を共有します。
問題解決の順番
腹落ち感のあるActionが生まれない背景の一つとして、問題を十分に整理しないまま解決策を議論してしまうことがあると思います。
Problemが曖昧なままActionを出そうとすると、議論が発散したり、過去と同じ対策に戻ってしまったりします。
問題解決を考えるには、以下の順番で考えることが重要です。
- What：何が問題なのか？
- Where：どこが問題なのか？
- Why：なぜそうなっているのか？
- How：どうするのか？
ActionがHow（解決策）だとすると、いきなりHowに飛ばず、What→Where→Whyを考えます。
What：何が問題なのか？
Problemの議論で最初にやるべきことは、「何を問題として扱うのか」の認識をチームで揃えることです。
私のチームでは、まず各自がKeepとProblemを付箋に書き出し、それを読み上げた後に、集中的に扱うトピックを決めてから深掘りしています。
しかし、付箋に書かれている内容だけでは「何が問題なのか」が曖昧なこともあります。その場合、発言者がどの点を問題だと感じているのか、認識を合わせることが重要です。
また、特に個人の反省系のProblemに多いと感じていますが、話してみると他のメンバーは全く問題と捉えていなかった、というケースもあると思います。
そのような時には深掘りするテーマから外してもよいと思います。
Where：どこが問題なのか？
Whereとは、「問題が発生している箇所を特定すること」です。同じ事象を扱っていても、「どこが問題なのか」は人によって異なります。
例えば、「ログの調査に時間がかかってしまった」というProblemを深掘りしているとします。
- Aさん：「ツールの操作に慣れていないこと」が問題
→ 個人のスキル・習熟度の問題 - Bさん：「ツールが使いにくいこと」が問題
→ ツールの問題 - Cさん：「本番前に十分な練習機会がなかったこと」が問題
→ 事前準備プロセスの問題 - Dさん：「本番対応フローに余裕がないこと」が問題
→ 運用体制・フロー設計の問題
このように、同じ事象でも、問題の所在は「スキル」「プロセス」「設計」「体制」といった、異なる箇所にあります。Whereを揃えないままWhy（原因）に入ると、それぞれが異なるレイヤーの原因を議論することになり、結論がぼやけてしまいます。
また、問題のある箇所を特定することで、「議論しなくてよい箇所」も決まります。ふりかえりの時間は有限なため、議論する箇所を一つか二つに絞るのがよいと考えています。
Why：なぜそうなっているのか？
Whereで「どこに問題があるのか」を特定したら、次に考えるのがWhy、すなわち原因の追究です。
このステップでは、一つの原因に決め打ちせず、まず可能性を広げ、その後に絞り込む考え方が重要です。
例えば、Whereで「ツールが使いにくいことが問題」と特定した場合、
- ツールの手順書がない
- ツールの手順書に書いてある内容がメンテナンスされていない
- ツールの理解が属人化している
- ツール自体のUXが悪い
など、複数の原因が考えられます。
状況に詳しいメンバーの記憶を引き出しながら、事実を元に可能性の高い原因にフォーカスします。
また、仮にツールの手順書がないことが原因だった場合
- なぜ整備されていないのか？→ 導入時に作成されなかった
- なぜ導入時に作成されなかったのか？→ 導入を優先し、ドキュメント作成をタスク化しなかった
- なぜタスク化しなかったのか？
→ Doneの定義やタスク設計の中でドキュメント整備が仕組み化されていなかった
というように問いを繰り返していくと、チームの仕組みや設計に目を向けやすくなります。
How：どうするのか？
Whyで原因の洗い出しができたら、ここで初めてHow、すなわち解決策を検討します。
Howでは、Whyで特定した原因に直接紐づくActionを考えます。
例えば先ほどの例では、「設計書が整備されていなかったこと」が直接的な原因であり、その背景に「Doneの定義に設計書作成が含まれていなかった」ことがあると整理できました。
その場合、Actionの候補としては、
- ツールの手順書を整備する
- Doneの定義に「関連ドキュメント更新」を明示的に追加する
といった選択肢が考えられます。
ここで重要なのは、目の前の現象を改善する短期的なActionと、仕組みそのものを見直す中長期的なActionの両方の視点を持つことだと考えています。
また、Actionには具体性が求められます。
例えば「設計書を作成する」というActionであれば、
- どの粒度・フォーマットで記載するのか
- どこに配置するか
- 緊急時に迅速に参照できる構成になっているか
といった観点まで定義します。
実際に利用する場面を想定しながら成果物の具体像を描くことで、実効性のあるActionになります。
そして、決定したActionはスプリント内のタスクとして管理し、実行後は次回のふりかえりで効果を検証します。
まとめ
What→Where→Why→Howという思考ステップを踏むことで、解決策に飛びつかず、納得感のあるActionにつながります。
もちろん、ふりかえりの場で必ずこの順番通りに進める必要はありません。ただ、誰か一人でもこの視点を持っているだけで、議論の質は大きく変わると感じています。
同じような課題を感じている方のヒントになれば嬉しいです。
Discussion