■NewKTP
//////////////////////////////////////////////////
クッシーさんのNew KPTの記事についてです。
おもしろい視点だと思います、Whyを取り込むんですね。
当たり前だけど、気づきませんでした。
KPTってTOCの思考のプロセスと似ていると感じます。
思考のプロセスは、 「何を何にどのように変えるか?」
対応づけを以下のように考えています。
K or P・・・何を
T・・・何にかえるか
?・・・どのように
どのように(How)がないんですよね。
Tryなので、Howじゃないと思うかもしれませんが、
勉強会で皆さんのKPT見てると、実際は、「How」じゃない気がしました。
K or PとTを結ぶ導線がすぱっときれているような。
→T・・・にHowを書けばいいのかもしれませんが。
4マスに区切って、Howを入れるのもどうかなと思っています。
//////////////////////////////////////////////////
頂いたご意見の中で、一番興味深かったのは、この一文です。
「勉強会で皆さんのKPT見てると、実際は、「How」じゃない気がしました。 」
私は、「TはHowを書く」と考えていたのですが、この点がKPTを説明する上で欠けている視点なのだと感じました。
勉強会などでKPTを使ってふりかえりをする場合、時間が無いため「Tryには、明日から実行したい事を書いてください」と言いますが、本来の使用方法は「Pを挙げて、Pを改善するためにできることは何だろう?」という発想でTを考えます。思考の流れは次の通りです。
- 問題を挙げる
- 問題をPに書く
- 問題に対する具体的かつ有効な解決策を考える
- 思いついた解決策をTに書く
/////////////////////////////////////////////////////////////
1.問題を挙げる
・障害が多発した
2.問題をPに書く
・「障害が多発した」 をPに書く
3.問題に対する具体的かつ有効な解決策を考える
3-1.参加者全員で、「障害が多発」した原因を考える (Why)
A) 特定パターンに関するテスト項目が不足していた
なぜ1:テスト者が気付かなかった。
なぜ2:テストパターンを知らなかった。
なぜ3:テストパターンが暗黙知になっていた。
B) 初期化していないポインタを使っていた
なぜ1:変数の初期化の重要性を理解していなかった。
なぜ2:言語の文法を理解できていなかった。
3-2.挙がった原因に対し、解決策を考える (How)
C) テストパターン一覧を作成し、全員で認識合わせする
D) 変数の初期化をコーディングルールに追記し、全員で認識合わせする
E) 不足していたテスト項目を増やして、明日から再テストする
F) 静的解析ツールを導入し、自動チェックする
3-3.実現性を判定し、即座に実行できる事を決め、Tに書く (Try)
G) テストパターン一覧を作成し、全員で認識合わせする
H) 変数の初期化をコーディングルールに追記し、全員で認識合わせする
I) (進捗に影響させないため)毎日定時後一時間、不足していたテストを実行する
J) 静的解析ツールの種類/機能/価格を調べる
/////////////////////////////////////////////////////////////
私のイメージでは、 3-1(Why) と 3-2(How) をKPTに書いていません。そもそもKPTに書くスペースがなかったので、不要だと考えていました。
私の場合、3-1(Why)を撲滅するために、暗黙知となっている事象を手順書やwikiなどに書き、失敗しない様対策を行うものだと考えていたのと、そもそもTryはKPT実施時に出席した者が理解できていれば十分であり、Tryを見れば会議の内容を思い出すことができたので、KPTの3項目で十分でした。
しかし、それではKPTがチームの暗黙知になってしまうため、他のチームへ水平展開することを考えると、やはり「Why」は必要だと考えています。
ご意見ありがとうございました。
返信削除KPTは、奥が深いですね。
TryがHowじゃないと言い切り気味は反省しています。
実際は、Howを記入している事も多いです。
今回の記事を見て、2点思いました。
(1) Whyは必要だと思います。
3-1のプロセス、この点を見える化すると、ご指摘の
通り他チームへの水平展開もしやすくなるでしょう。
また、「P」が本当に問題なのか?という事を考える
きっかけになると思います。問題のしっぽをつかんでい
るかどうかは大切だと思います。
(2) TryがHowなら、目的(Object)もある場合がよい事も
あるような。
西さんにコメントを寄せてから、私も前に書いたKPT
を見直しました。上記の例のように、
「障害が多発」→「障害を少なく」のように、Pを見れば
目的が分かります。Pの定義が目的の定義を暗示する。
全てにおいて、本当にそうなのかな??って気がして。
ふりかえりツールにそこまで考えなくてもいいかなと
いう気もします。
私が思った2点のいずれにも、[Why]視点はかかせない
と思います。
Whyを取り込む場合は、現在のKPTのように、一覧
して見える化できるのが理想な気がします。
TO:ふかのっちさん
返信削除素晴らしいコメント、ありがとうございます。
確かに、理由と目的があれば、KPTは更に強力なツールになりそうですよね。
>ふりかえりツールにそこまで考えなくてもいいかなという気もします。
結局、何をどこまで求めるかという問題だと思います。KPTを使うのも手ですし、それ以外の方法を使うのも手だと思います。
正解は、自分で見つけるしかないのではないかと思います。