2009年12月31日木曜日

NewKPTに関するご意見を頂きました。

友人より、「NewKPT」について、ご意見を頂きました。

■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を考えます。思考の流れは次の通りです。
  1. 問題を挙げる
  2. 問題をPに書く
  3. 問題に対する具体的かつ有効な解決策を考える
  4. 思いついた解決策をTに書く
 上記思考プロセスの中で最も重要なのが「具体的かつ有効な解決策」の検討です。ここが一番難しく、時間がかかる所です。実際にKPTする際、私はTryを考えるため「なぜなぜ分析」による原因分析を行っています。下記に例を示します。

/////////////////////////////////////////////////////////////

  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」は必要だと考えています。

2 件のコメント:

  1. ご意見ありがとうございました。
    KPTは、奥が深いですね。

    TryがHowじゃないと言い切り気味は反省しています。
    実際は、Howを記入している事も多いです。
    今回の記事を見て、2点思いました。

    (1) Whyは必要だと思います。
    3-1のプロセス、この点を見える化すると、ご指摘の
    通り他チームへの水平展開もしやすくなるでしょう。
    また、「P」が本当に問題なのか?という事を考える
    きっかけになると思います。問題のしっぽをつかんでい
    るかどうかは大切だと思います。


    (2) TryがHowなら、目的(Object)もある場合がよい事も
    あるような。

    西さんにコメントを寄せてから、私も前に書いたKPT
    を見直しました。上記の例のように、
    「障害が多発」→「障害を少なく」のように、Pを見れば
    目的が分かります。Pの定義が目的の定義を暗示する。
    全てにおいて、本当にそうなのかな??って気がして。

    ふりかえりツールにそこまで考えなくてもいいかなと
    いう気もします。

    私が思った2点のいずれにも、[Why]視点はかかせない
    と思います。
    Whyを取り込む場合は、現在のKPTのように、一覧
    して見える化できるのが理想な気がします。

    返信削除
  2. TO:ふかのっちさん

    素晴らしいコメント、ありがとうございます。
    確かに、理由と目的があれば、KPTは更に強力なツールになりそうですよね。

    >ふりかえりツールにそこまで考えなくてもいいかなという気もします。

    結局、何をどこまで求めるかという問題だと思います。KPTを使うのも手ですし、それ以外の方法を使うのも手だと思います。

    正解は、自分で見つけるしかないのではないかと思います。

    返信削除