背景
KPTとは
keep よかったこと
Problem わるかったこと
Try これからやってみたいこと
という観点の振り返り手法です☆彡
私「ちがう、ちがあああああああああああう！！」
という想いをきちんと説明してみたいと思います
対象
- KPTって反省して今後に活かす感じでしょ？ 小学校でもやるよね、帰りの会とかｗ と思ってる方
- プロジェクトチームを改善できたらなーと思ってる方
- プロジェクトリーダー
- 絶対成功しなきゃならない方
など
目的
すごさを伝える
注意
いろんな考えがあると思います
使うシーンの前提
- イテレーションを何回も回す（仕様会議→リリースというサイクルがある）
- とにかく何回も似たような行動サイクルをぐるぐる回す、開発でなくてもOK
- チームの改善を上手くやるとメリットが有る状況
伝わらないので開発に喩える
エンジニアにお馴染みの開発に喩えましょう
| KPT | 開発 |
|---|---|
| KPT | デバッグ作業 |
| Problem | バグ、修正点、糞コード、糞UI |
| Try | 修正パッチ当てる、再実行してみる、リファクタしてみる |
| Keep | 修正パッチが良さげなので本番に反映 |
| イテレーション | 単体テスト1周 |
| プロジェクトの改善 | プロダクトや、コードの改善 |
KPTは言ってしまえばデバッグ作業です
開発でデバッグする対象はプロダクトとソースコードですが
KPTでのデバッグする対象はプロジェクトとやり方です（プロダクトを入れてもいいですが）
ワークフローを細かく比較する
デバッグも適当にやらず、ちゃんとテストしたりチケット切ったり
いろいろちゃんとやりますよね？
それを思い出して、一つ一つ丁寧にワークフローを比較してみましょう
|
フェーズ |
開発 | KPT |
|---|---|---|
| テスト | バグや、良くないUI、もっさり動作など問題を発見する | イテレーション中に、プロジェクトが上手く進まない問題を発見する |
| 本当に問題なのか確認し、優先度付けする | これまずいですよね、と仕様を知ってる人に確認する | KPT会：Problemを洗い出して何故問題か議論する |
| チケットを切る | チケットを切る | KPT会：Problemのところに書く（確定） |
| 調査（原因） | 誰かが原因を調査 | KPT会：Problemの掘り下げ |
| 調査（対策） | 誰かが対策を調査 | KPT会：Tryのアイディア出し |
| チケット選択 | 優先度付けしてチケットを選択 | KPT会：Tryを優先付けして次のイテレーションでやるかを決める |
| 担当者とウォッチャー | 担当者とウォッチャーを設定 | KPT会：Tryが誰担当で、誰が実施状況を確認するか決める |
| デバッグ実施 | デバッグ実施 | イテレーション中にTryを実施 |
| 再テスト | 再テスト | KPT会：Keepで前回のTryで解決したかチェック |
| 反映 | branchをマージ | KPT会：Keepに入れる |
この通り、KPTはみんなでやるデバッグ作業です
Problem -> Try -> Keepと全てはつながっています
繋がっていないKeepは？
ナレッジ共有と捉えると良いと思います
ただ、その場合もはじめに何かしらの問題があって〜からスタートすることが多いのではないでしょうか
KPTすごい
これで何となく伝わりますかね？
KPTが毎週上手く回っている ＝ 毎週バグを潰している
１年続けると
KPTが回っている → テスト53回、デバッグ53回行って、チケット消化しつづけ改善してる状態
KPTが回っていない → テスト0、デバッグ0、チケット消化数0
KPTを上手く回すには
伝わったとしたら幸いです
それでは次にKPTを上手く回すことを目標にします
そもそも上手く回ってる、良い状態ってどんな感じでしょうか？
良いKPT＝良いデバッグ
エンジニアならもう既にわかるはずです
良いProblem洗い出し＝良いテスト
他の人が気づかなかった致命的なバグ
自分が担当していたコードのバグ
テスターにグッジョブと言いたくなるやつです
そして、事実ベース＋所感の構成で書かれていると非常にありがたいです
まずは何が起きたのか、事実ベースで洗い出しましょう（これが結構難しい）
良いProblem定義＝良いチケット
悪いチケットの例
↓
【タイトル】バグ 【内容】一覧画面でOKボタンを押したら何か落ちたので良くない
これは説教ですね
良いチケットは
- 環境がきちんと書いている
- 条件が洗い出されていて再現性がある
- 仕様や目的に対して何が問題なのか明確で、次の行動に繋がる
つまり良い「Problem定義」は
- いつどういう状況で起きるか明確で
- たびたび起きることで
- 目的に対して何が問題か明確で、次の行動に繋がる
例えば、後にも先にも１回しか起こらない問題は優先度が最低です
「私は見たんです！ あの日確かに、あのバグを！」とかUFO発見したみたいなこと言われても困ります
また、感想だけ言われても困ります
次の行動につながらないのでデバッグをしている意味がないです
良いTry＝少ない工数で簡単に直りそう
その前に、Tryの候補が複数出てくるといい状態です
バグチケットに対しても複数案対策を思い浮かべて、メンバーとどうするか相談しますよね？
その上で順序付けされてるとなお良いです
もちろん「全員でやらなければならない」より「１人がどうにかできる」方が優先度が高いです
良いTry定義＝きちんとチケットにされてる状態
チケット切ったけど担当者振ってないで誰もやってない、みたいなことありますよね
ああならないように、Tryも担当者を振ります
皆でやるものなら、代表で担当者をつけたりしますし
実行者と監督者を分けてもいいと思います
より良いチケットは、期限や方法もきちんと設定されています
良いKeep（Tryの検証）＝良い修正commitと、網羅性のある良いテスト
開発においては
何のための修正か明確なcommitにより修正されていて
きちんと直ったか網羅性のよいテストが行われると、チケットは解決・終了にできると思います
KPTでも同じで
問題に対して明確な行動をして、結果問題が解決されていて
他のシーンにおいても解決が見込めるなら、Keepしてよいと思います
良い「Keepしないで再度Problemに戻す」＝チケットの差し戻し
バグが再現したとか、完全に網羅できていないとか、一部だけ問題が残っている場合は
チケットを差し戻すと思います
それと同じように、Keepできなかったものは再度Problemに戻ります
ここでポイントなのは「デバッグできなかった」という事実もProblemに含めることができます
これは開発で言うところの「時間が足りなかった」「難しくてできなかった」と同じです
その場合は別の方法を考えたり、メンバーでタスクの調整をしますよね？
KPTみたいな状況だと「やらなかったのが悪い」となりがちですが、そこで思考停止にならずに
解決方法を考えられると良いフローになります
良いその他のKeep＝ナレッジ共有
Qiitaに書くようなものです
出す時には頑張って皆に説明しましょう
〜〜できてよかった（小並感）にならないように
意味のない行為
あいつのせいだ！あいつが！あいつがあああ！！＝フレームワークの仕様が悪い！外部APIが悪い！
KPTでは批判はNGと言われています
これも結構理解し難いことだと思いますので、開発に喩えてみましょう
デバッグ担当エンジニアが書いたチケットコメントがこんなだったらどうでしょうか
「外部APIの仕様が悪い。外部APIが何とかするべき」
「このコード書いたのは○○さんです！ git blameで犯人特定できました！ 彼が直すべきです」
これは先輩から説教ですね
せめてどこが、どう悪くて、何が問題なのか書いて欲しいです
（開発）外部APIの どこが どう悪いか
（KPT） 人の どこが どう悪いか
↑ ↑
意味のない情報 議題にすべきこと
このように、KPTにおいても「誰が」はさほど重要な情報じゃありません
おまえが！おまえのせいで！お前さえ！！＝「おたくの外部APIの仕様最悪すぎません？」
開発でバグを出さない人なんて居ないはずで、誰もが何かしらの間違いを作っています
プロジェクトでも同じように誰もが何かしらの間違いをします
それをKPTでもちだしても、批判の応酬になるのは明白ですね
しかし今重要なのはデバッグすることで、誰がやるかではないはずです
批判の応酬を絶対するなとは言いませんが、今の場合情報として無価値なのでノイズでしかありません
責任追及や批判はダメなのか？
より正確に言うと、３つの点で問題です
１点目は、上で書いたようにデバッグに対する情報として無価値すぎるということ
２点目は、責任追及と対処しなければならない問題とを切り分けて考えられる人が少数派であるということ
３点目は、もし人自体が問題の温床だとして、それはデバッガーではなく調整役の役割だということ（つまり人事案件）
なので、KPTのフロー以外にのせるべき問題です
人事権を持った人に相談したらどうなるかも開発で考えてみましょう
デバッガー「外部APIが最悪なんですよ！」
調整役「わかるけどさ、一旦こっち側でどうにかならない？ ある程度全部試した？」
メンバー「○○さんが最悪なんですよ！」
人事管理「わかるけどさ、一旦どうにかならない？ ある程度全部試した？」
同じですよね
ある程度Problem-Tryの洗い出しや試行錯誤は必要になるはずです
KPTが上手く回ってくるとどうなるか
ゴールの明確化に対する議論が起こる
それは本当にProblemなのかを突き詰めるとそもそもゴールは何なのかの議論に遡っていきます
UIの問題は機能の位置づけに
機能の位置づけはプロダクト全体のコンセプトに
プロダクト全体のコンセプトはビジネスモデルに
ビジネスモデルはユーザーニーズに などと限界まで遡ります
誰も「何故」に答えられなくなったら上流フェーズの穴です（論理の飛躍）
これは起こるたびに「うわぁまた”そもそも論”が始まった」とげんなりしますが
これを突き詰めていければ、ほんとうの意味でチームが同じ方向を向けるようになります
ぜひ「え、それってほんとに問題なの？」と嫌われ役を買って出てみてください
常にテストモードになる
何か問題にぶち当たるたび、「今度のKPTで言おう」という気になるので
常にプロジェクトややり方のテスト状態になります
すると常に今の方法より良い方法を探すようになります
これが数ヶ月も続くと非常に頭が冴えてきて
色んなところからアイディアが湧くようになってきたり、他ではどうやってるか気になったりして
モチベーションも上がります
KPTが下手に回っているとどうなるか
開発に喩えましょう
- テスト回すけどバグが出ない
- 重箱の隅のバグに取り組んでしまう
- 下手なテストコード組んでしまった
何でこんなことしてるんだろうと悲しくなっていき作業感が出て最終的に飽きます
KPTをやらない勇気、または工夫
ここまで読んでいただければ
誰でも簡単にKPTができるなんて言えないのは分かっていただけると思います
テストができて、チケット駆動ができて、チケットの相談がチームでできて、デバッグができるような面子じゃないと回りません
もちろんその対象はコードに対してじゃなく、プロジェクトとやり方に対してです
テストが不得意なテスターと、デバッグでバグが減らないデバッガーがテストフェーズを回した時
どの程度悲惨なことになるかは経験あるかと思います
なので本当ならば、経験年数がそこそこの人同士でやってほしいところですし
無理だなーと思ったらいっそやらないほうが良いです
以下は、それでもやった方が良いなという時にできそうな工夫です
役割を分ける作戦
チケット駆動開発を思い出してみれば分かる通り
全体の管理者（PM）と、デバッガーと、テスターは分かれています
KPTで言えばファシリテーターと、Tryを行う人と、Problemを発見する人に別れても良いと思います
（もちろんKPT会は全員参加です）
意外と認知されていませんが、実際のところ
- 問題発見
- 問題定義
- 解決アイディア出し
- 解決計画立案
- 解決実施
- 解決
は上から順に難易度が上昇します
国家レベルの難しい問題も、チャラい兄ちゃんですら問題発見くらいできてますよね？
対案を出すのは批判より難しく、実際に対応するのは更に難しいです
なので経験値によってフェーズは分かれていたほうが自然です
※ちなみにベースの考え方は同じなので、チケット駆動でデバッグができてる人は、素質があるはずです
全員参加の意義
以上の意味では必ず全員で解決しなければならないものというわけではないと思います
しかし開発においても、全員がチケット状態を認識してもらい、全員がバグ洗い出しに参加してもらった方がプロジェクトはスムーズに運ぶはずです
KPTにも同じことが言えると思います
また、行動が全員に及ぶ場合は、Tryの経緯を全員に把握してもらう必要があります
じゃないと改善そのものにがやらされてる感が出ます
Problemが出ない時は？（ファシリテーター向け）
開発の時に「バグはありませんか」などとテスターに聞かないはずです
必ずテスト仕様書があります
プロジェクトの場合はテスト仕様書レベルには落としづらいものの、ゴール（適切な状態）はいくつかに分けられるはずです
それらに対して、ゴールを満たす上で阻害になっていることは何ですか？ と問えばそこそこ出てくるかもしれません
あとその時出なくても、次回はでるかもしれません
（ここらへんは難しいので私もコツがあったら知りたいくらいです）
最後に
KPTとは
keep よかったこと
Problem わるかったこと
Try これからやってみたいこと
という観点の振り返り手法です☆彡
私「ちゃうねん」
という想いは伝わったでしょうか？
最後にKPTのすごいところをもう２つ
KPTはプロジェクトにおける唯一の自己書き換えコードです
KPTのログは、次のプロジェクトでも使えるはずです（組織がレベルアップする）