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

KPT などを利用してふりかえりする場合、プロジェクトチームのなかで

　問題点をあげる → 原因を考える → 改善アイデアを考える → …

というステップを踏むことがあると思います。

まぁ通常のバグを発見した場合と振り返りでProblemを見出した場合、なぜ同じ流れになるか？と言うと、基本的に

　世の中の『問題』に対する取扱い方法はすべて同じ

だからです。

これはトラブルが起きた時の対応でも同じです。

しかし、この「問題点をあげる」というステップにおいて、多くの現場では以下をすっ飛ばして挙げてしまうことがあるなぁと思います。

　「なぜ、それを問題だと思ってるか」
　「それによって、誰に、どのような困ったことが起きた(起きる)か？」
　「そのインパクトってどのくらいの大きさか？」

こうした解析は、実は『問題解決管理』や『変更依頼管理』と言ったプロセスでも、
まったく同じことを明確にするよう求められています。しないのは、現場が我流で「しなくていい」と思っているか、することの目的を理解していないからでしょう。もちろん企業や組織がそうしたことをきちんと徹底させていないということの表れでもあります。

"しなければならない"業界やシチュエーションはごまんとありますが、逆に"しなくてもいい"業界やシチュエーションと言うのは数えるほどしかないもので、知っておけば様々な業界、様々な職種、様々なシーンで利用できます。

たとえば、子供のケンカ仲裁でも使えます。
もちろん大人の仲裁…たとえば夫婦喧嘩などでも使えます。
と言うことは、民事・刑事に限らず裁判などでも同じことになります。
経営上の舵取りでも同じです。

世の中における問題に対した際の画一的な方法論なのです。

「Problem/問題点」を出しましょうと言われると何か１つでも出さなくてはならないと思い込んでしまい、「たぶんこれも問題のうちだろう」と（悪意なく）決めつけてしまって言葉たらずになることがあります。根拠もあいまいだったりするでしょう。

たとえば、一般的なアジャイルで行われるKPTの場合、週１程度の頻度でくだらない進捗報告会の代わりに行われたりしますが、そんな中でなんとなく曖昧な

　「今週やることを絞れていなかった」

というふうにProblemに出すよりは、

（原因）
　今週やることを絞れてなかったせいで、
（結果）
　どの案件も中途半端になってレビューしてもらうタイミングが遅くなって
　リードタイム伸ばしてしまった。
（影響）
　例の重要な後続タスクも遅れると思う。
（インパクト）
　自分のスイッチングコストも高くてストレスが半端なくて憂鬱だった。

少し長くなりますが付箋何枚か分けて書けば問題ありません。

逆にそうした整理ができないまま、属人的に「なんとなくそう思う」なんてものを短い付箋紙に書き記したところで、何の問題解決もできないのは自明の理です。

重要なのは、短文報告で全てを理解した気になるだけの無能なマネジメントをすることよりも、きちんと整理されて未来予測が可能になり、どう対策すればいいかが検討できる状態にすることです。

その意味では必ずしも定量的でなくてもいいでしょうし、感情依存したものでもかまいません。どちらにしても放置しておけばより大きな問題となるからです。

このあたりに対する具体的な情報がないと、次の「原因を考える」「改善アイディアを考える」のステップにおいて、

・問題設定の筋が良いのか？
　実は問題は他の所にあるのでは？
　解決する価値が他の問題と相対的にどうなのか？という議論や判断ができない

・問題に共感してらえない

ということが起きます。本来の目的を忘れ、ただの報告会になって参加した全員の意欲を削ぎ、且つガントチャート上に存在しない時間を消費させ、スケジュールを圧迫させるだけで結局メンバー全員に残業を強制するだけのマネジメントになってしまいます。

そうなってしまったら「冗長的な活動コストがプロジェクト全体の負担を増やす」というマネジメント不良が起きてしまうのは、ウォーターフォールでもアジャイルでも同じです。

もし自分以外がこういった形で問題点をだそうとしていたら、上記の問いをそのまましてみましょう。そのときには人を責めるような雰囲気にならないように「念のため、誤解が無いか確認したいんですけど…」みたいな枕詞をつけると良いと思います。

もちろん、ふりかえりプロセスそのものの中にいれてもかまいません。

　　 問題点をあげる
　→ 原因を考える
　→ 改善アイデアを考える → …

という流れを

　　 問題点をあげる
　→ 問題のインパクトを整理する
　→ インパクトや今後の発生確率、頻度を踏まえて Dot Voting
　→ 原因を考える
　→ 改善アイデアを考える
　→ アイデアを（コスト × 効果マトリクス）に雑マッピング
　→ 取捨選択して ToDo にする

としてもいいでしょう。問題解決管理や変更依頼管理の委員会（CCB）でもあれば、こうしたテンプレートプロセスにしておくと非常にスムーズに進行が可能になるはずです。少なくとも無法状態で属人的なレビューをさせるよりは確実性の高い確認ができるようになるはずです。

ちなみにDot Voting（ドット投票）は、ブレインストーミングなどの結果をすばやく優先順位付けしたり、重み付けをしたい場合などに用いられる方法論です。

リーダー一人の裁量では決められない場合などに迅速にアイデアの優先順位をつけることができます。

また、コスト × 効果マトリクスは正式には「ペイオフマトリクス」と言いますがそういった方法論もありますよね。

縦軸に「成果」、横軸に「難易度」や「コスト(かかる時間等)」をとり、マトリクス上に、複数の案をマッピングして、「効果＝高」×「難易度＝易」の象限にある案を優先的に検討します。「ペイオフ（Payoff）」には様々な意味がありますが、ここでは「対効果」「対結果」、「マトリックス（matrix）は「行列」の意味と捉えてください。

これらのように可視化したうえで判断がブレないようにするのも非常に有効です。