ふりかえりで気をつけていること

Posted on 2021-04-20 , Tags: ふりかえり, Thinking

個人でもチームでも「ふりかえり」をすることは一般的だと思う。今回はその中で個人的に気をつけていることをまとめた。

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

まずはなぜふりかえりをやるのかについて書く。いろいろな意見はあると思うが、個人的にはふりかえりは以下の点で有用だと思っている。

  • 改善のため
    • まずは単純に日毎、スプリント毎に改善していくためである
  • モチベーションをあげるため
    • 自分のやってきたことを見て充足感、達成感を得ることもあるだろう
  • メタ認知のため
    • 他の項目と直交ではないが、そもそも日々すごしている中で自然とメタ認知するのはなかなか難しい。よって明示的に時間をとる必要がある

どうやるのか

ふりかえりは以下のようにして行うことが多い。

  1. できごと(エピソード)をフラットに書き出す
    • ここでは特によかった、悪かったなど評価をせずに列挙する
    • 心に残ったことを全て書き出す
  2. よかったこと、悪かったこと、気になることなど分類を行う
    • KPT、Fun Done Learnなど好きなフレームワークを使ってもよい
    • 「よかったことは他に何があったかな」などと考えることで1.のできごとが増えることも多い
  3. 必要なら各項目を掘り下げる
    • 悪かったことなら原因の分析など、次のアクションが決められるように掘り下げる
  4. 次のアクションを決める
    • 改善のためのアクションを決める
    • 前回のふりかえりで決めたアクションをちゃんとできたかもふりかえる

気をつけていること

以上の手順の中で気をつけていることを挙げる。

「問題」は本当に「問題」なのか？

例えば、「タスクAの開発が予定より時間がかかった」という項目が「問題(悪かったこと)」としてあげられたとする。
しかし、前提によってはこれは「問題」にはならない。例えば、そもそも開発スケジュールが余裕があって、時間がかかっても問題ないようになっているかもしれない。または、実装方法の妙案が思いついて、タスクA終了と同時にタスクBの開発が不要になっているかもしれない。
そもそも問題なのか、問題だとしたら「誰に」「どのような影響を及ぼしている」ことが問題なのか考える必要がある。それによって次のアクションも変わってくる。
例えば、「タスクAの開発が予定より時間がかかった」ことで「サービスのユーザー」に「アナウンスしていたリリース時期に間にあわなくなってしまった」ならまずはユーザーへのアナウンス対応が必要だろう。「チームメンバー」の「士気がなんとなく下がった」という影響のみであればチームメンバーへのケアを考えればよい。

「原因」は本当に「原因」なのか？

これは「なぜなぜ分析」などとも呼ばれる手法に似ているが、ある問題についての「原因」は掘り下げることができる。
例えば「バグAの原因は、担当スタッフXの確認不足だった」という項目があがったとする。ここで確認すべきなのは「担当スタッフXはなぜ確認不足を起こしたのか？」であり、そもそも確認すべきことを知らされていなかった、というコミュニケーションミスなのかもしれないし、いつもなら大丈夫だが、その日は体調が悪かったのかもしれない。
コミュニケーションミスならコミュニケーション設計を見直すべきだし、体調不良ならスタッフXのバックアップができる人を用意する、そもそも休暇をちゃんととってもらう、など次のアクションも変わってくる。「スタッフXが確認不足だった」で止まってしまうと「スタッフXが気をつける」くらいしか改善策が思いつかない。そしてこれは下記にもつながる。

次のアクションが根性論になっていないか？

「気をつける」「心に刻む」「気を引き締める」などの言葉が改善策としてできたら要注意である。
人間というものはよほどの人を除いて、注意力散漫な時が多くある。ある時はプライベートな事情が気にかかっているかもしれないし、またある時は体調が悪いかもしれないし、他の仕事で忙しい時もあるだろう。 その中でずっと「気をつける」のはほぼ不可能であり、改善策として「気をつける」だけしかない場合は近いうちに同じ問題に直面するであろう。
体調が悪かろうが何だろうが、「勝手によくなる」ように仕組みを用意する必要がある。完璧な仕組み作りは手間な時もあるが、せめて「勝手に気をつけやすくなる」ようにすべきだ。指差し確認やダブルチェックなどがこれに当たる。
また、そもそも前項の例のように原因の掘り下げが甘いせいで「気をつける」しかでてこないことがある。次のアクションが「気をつける」以外に思いつかない場合は、一度原因に立ち戻ったほうがいいだろう。

次のアクションを実行できているか？

次のアクションを決めて、決めたことに満足して忘れてしまうことがある。
次のアクションは「いつまでに(期限)」「誰がやるか(担当者)」を決めるとよい。次回のふりかえりでやれたかどうか、やれなかったならなぜやれなかったか確認する。できなくても詰問するのは意味がないのでフラットに原因を聞く。この原因の分析も上記の通り本当の原因を探る努力が必要になる。

次のアクションは持続可能か？ (2021.04.26追記)

何か問題が発生した際、次のアクションで絶対に再発しないようにしようと意気込むあまり、持続可能でないアクションを設定してしまうことがある。
例えば、開発したサービスの品質面に問題があり、次のアクションとして「リリース前に(膨大なテスト項目を含んだ)テスト項目書を元に手作業でテストをする」と設定したとしよう。問題が発生して数ヶ月くらいは問題が起こったときの危機意識からちゃんと続くかもしれない。だが、半年後、1年後はどうだろうか。また、担当者がかわって当時のコンテキストを実体験していない人が入っても続くだろうか。
次のアクションが1回のみではなく、継続的なものである場合、それは持続可能でなければならない。できるだけ自動化することを考え、手動でやる場合は、やる気がでない時や体調が悪い時でも実行可能なものにする必要がある。

まとめ

ふりかえりも効果的にやろうとすると結構大変だと思う。
今回、個人的なふりかえりの目的、やり方、気をつけていることを書いた。
他にも気をつけるとよい点はいろいろありそうなので、ふりかえりに一家言ある方はこっそり教えていただけると幸いだ。