56.KPTのやり方 その⑤
Problem
Problemになると、Keepの時よりも盛んに意見が出たりする。
カイゼンが進んでいくと減るはずだが……
どんどん新しい問題も出てきて、いつまでたってもProblemが多い状態が続いたりする。
Problemが多いときは「発生頻度」と「影響度」の表を作って分類していみよう。
発生頻度が多く影響度が大きいProblemを選んでカイゼンすると良い。
グルーピング
分析を行い時などもそうなのだが、分類することで「見える」ことが多い。
Problemの共通点を見て分類すると、どんなところをみんなが問題だと思っているかが見えてくるゾ。
グループ同士の関連性なんかも見えてきたり。
抽象的な内容
だいたい出てくるのが「～をちゃんとしてない」という意見。
で、Tryになったときに「～をちゃんとする」となったりする。
もう少し具体的に書いた場合、Tryでとるべき施策も変わってきたりする。
例えばマンガに描いた「時間がなくテスト計画の作りこみが甘い」などだったら、
時間が足りない場合のテスト戦略を考えておき、計画時にその戦略をベースに組み立てる……など考えられるかもしれない。
同様によくあるのが「単語」。
例えば「バグ票！」と書かれて付箋がベタリ！
話しながら貼るのでその時はわかるのですが、Tryに移ったとき、次回KPT時に「……これなんだっけ？」となる。
できるだけ具体的に書いてもらおう。
個人攻撃・悪口
例のアニメに出る黒い人を書いたため「個人攻撃（物理）」になってしまいそうだが、それをやるとお縄になるので気を付けよう。
どうしてもデグレを出す人なんかが攻撃対象に上がったりするが、そこで個人攻撃、悪口を言っても仕方がない。
KPTが愚痴大会になってしまわないように気を付けよう。
作者のところでは
作者のところはプロジェクトが国をまたがっており、規模も全体で数百名となるので、QAチームのみでKPTを行っている。
けど、QAチームだけの意見ではなく、QAからみた他のチーム（開発チームや企画チーム）のこともKeep, Problemを出している。
それらまとめた結果はプロジェクト全員にメールし共有するスタイルである。
ちなみに辛辣な意見が出ることもあるがそれもそのまま共有している。
