15/09/10 Sendai Agile Stories発表資料

1. KPT採集
～けぷとさいしゅう～
2015
Sep.
ねもりん @nemorine
UltimateAgileStories5 発売記念！

2. すくすくスクラム仙台
KPT知ってますか？

3. すくすくスクラム仙台
ふりかえりのフレームワーク
天野勝 http://www.slideshare.net/esmsec/kpt-27942223

4. すくすくスクラム仙台
しかし この世には
様々な”拡張”KPTが
存在します！
KPTにはシンプルであるがゆえの弱点もある･･･

5. すくすくスクラム仙台
UAS5に投稿した11種の
拡張KPT＋１を
紹介します。

6. すくすくスクラム仙台
①EKPT（いーけぷと）
• 採集場所： 自社のチーム
• 由来： KPT + Excellent
• 対象： もっとチームの良いところに焦点を当てたいチーム
• 特徴： Keepの中で特に“すばらしい！”ことを区別できるように
Excellentという項目を追加したフレームワーク。
Excellentにはチームやメンバーへの賞賛も書きやすいため、感謝
の念を表しやすいというメリットがあります。
Excellent Try
Keep
Problem

7. すくすくスクラム仙台
②KPTS（けぷつ）
• 採集場所： 自社のチーム
• 由来：KPT + Stop
• 対象：過去の慣例に従い不要な活動や不要な成果物などが多すぎる
チーム
• 特徴： Tryの中に含まれる“～をやめる”という項目をStopとして明
示的に書き出すフレームワーク。やめる勇気・・・重要です！！
Keep Try
Problem
Stop

8. すくすくスクラム仙台
③KPTA（けぷた）
• 採集場所： 天野さんのSlide （http://sssslide.com/www.slideshare.net/esmsec/kptkpta）
• 由来：KPT + Action
• 対象：実施を合意したTryが実行されないチーム
• 特徴：効果のあるTryを実行可能なActionに落とすことを目的とし
ています。またTryとActionを分離することで、Tryを抽象的なアイ
ディアレベルで出しやすくなるとのことです。
Keep Try Action
Problem

9. すくすくスクラム仙台
④YWT + KPT（わいだぶりゅてぃーぷらすけぷと）
• 採集場所： TEF道お世話役 安達さん（@kitanosirokuma）
• 由来： YWT + KPT
• 対象： ふりかえりで抜け漏れが多いチーム
• 特徴： YWTとKPTを組み合わせ、WをKeepとProblemに分けるフ
レームワーク。Yに「これまでやってきたことやその結果」といっ
た事実をあらかじめ書いておき、それを見ながらKeepやProblemの
導出を行うと「具体的に＆細かく想起しやすい」というのがそもそ
もの意図とのことです。
Y (やったこと) W (わかったこと) T (つぎにやること)
Keep =Try
Problem

10. すくすくスクラム仙台
⑤KPT + T（けぷと）
• 採集場所： 「ここちいい風とともに･･･」
（http://fclear.ti-da.net/e3292268.html）
• 由来： KPT + Thanks
• 対象： チーム内でもっと感謝を表したいチーム
• 特徴： 通常のKPTに日本ファシリテーション沖縄サロンの代表であ
る平井さんが提唱している感謝（Thanks）を加えたフレームワー
ク。Thanksで明示的に感謝を伝えることでチーム運営がスムーズ
にいきそうです。

11. すくすくスクラム仙台
⑥KPT + W（けぷとぷらすだぶりゅ（仮））
• 採集場所： 上司（上司は知り合いの経営コンサルに聞いたらしい）
• 由来： YWT + 5W1H（5W1HをWと省略）
• 対象： 今よりもっと深く精度の高いふりかえりをしたいチーム
• 特徴： Keep、Problem、Tryそれぞれに5W1Hを加えたフレームワ
ーク。KeepやProblemで導出した項目から「いつ？」、「誰が？」
、「どうして？」などの問いかけを使って深堀りし、その項目が出
た理由や状況などを5W1Hに書いておくことで、もう一段精度の高
いふりかえりができるようになるそうです。
Keep 5W1H Try 5W1H
Problem 5W1H

12. すくすくスクラム仙台
⑦KPT2（けぷとつー）
• 採集場所：「これだけ！KPT」 天野勝 著
• 由来： KPT + ToDo （もともとはKPTTだったようです）
• 対象： Tryは沢山出るけど、やりきれなくなってしまうチーム
• 特徴： 出てきたTryの中で何を実施するのか決めたものをToDoに
移動するという運用を想定したフレームワーク。KPTAの親戚。Try
で出たものをチームで絞って、ToDoに掲げておくことで、今回の
イテレーションでやるべき施策をチーム全員がしっかり意識できる
と思います。
Keep ToDo
Problem Try

13. すくすくスクラム仙台
⑧KPTIRK（けぷたーく）
• 採集場所： 「これだけ！KPT」 天野勝 著
• 由来： KPT + Issue（課題）+ Risk（リスク）+ Knowledge（ナレッジ）
• 対象： 独自の知識体系を作りたいチーム
• 特徴： IssueはProblemから導き出された課題。Riskは将来起こり
そうな問題。これらに対してTryを考えていくというアプローチを
取っていきます。KnowledgeはKeepの中でナレッジとして流通で
きるまで昇華したアイディアとのことです。
Keep/Knolege Try
Problem Issue
Risk

14. すくすくスクラム仙台
⑨KPT + Be + Do法（けぷとぷらすびーぷらすどぅほう）
• 採集場所： 「ナカシマのブログ」 （http://hisa-magazine.net/engineering/kpt/）
• 由来： KPT + Be + Do
• 対象： 個人のふりかえり
• 特徴： Keep、ProblemをBe（ありたい姿）とDo（やること）に分
けて導出するフレームワーク。精神的な土台（Be）とスキル・能力
的な土台（Do）をバランスよく育ていくことが大事であり、ふりか
えりにこのフレームワークを使うことで両方をしっかり認識するこ
とができるとのことです。
Keep Problem Try
Be
Do

15. すくすくスクラム仙台
⑩KPTH（けーぴーてぃーえっち）
• 採集場所： アジャイル札幌 前鼻さん（@sandinist）
• 由来： KPT + Happy
• 対象： ちょっぴり余裕があって、今よりさらにHappyになりたいチーム
• 特徴： 自分達がもっと幸せになる、楽しむ、楽をするためには？と
いうことをHappyという項目として書き出したフレームワーク。
Problemから導出されるTryに書かれにくい長期的な目線で考える
施策やコレできたらもっと幸せなのにな～というようなちょっとし
た施策もHappyとして書き出しているとのことです。
Keep Try
Problem Happy

16. すくすくスクラム仙台
Keep
要求仕様
Problem
Try
Keep
設計仕様
Problem
Try
Keep
コーディング
Problem
Try
⑪フェーズごとのKPT（ふぇーずごとのけぷと）
• 採集場所：自社のチーム
• 由来：フェーズごとに項目を分けてKPTを実施
• 対象： イテレーションが長いチーム / フェーズごとの強み・弱みを知りた
いチーム
• 特徴： 例えば1ヶ月に一回のペースのふりかえりしかできない場合は、直近
の２週間程度のKeep、Problemしか書き出せないことがあります。そのと
きはフェーズごとのKPTフレームワークを使うことで各フェーズに集中する
ことができ、それぞれのKeep、Problemを導出しやすくなります。
またフェーズごとのKeep、
Problemの数をパッと俯瞰する
ことでチームメンバーがどの
フェーズに自信があるのか、
または問題だと考えているのか
が一目で分かります。

17. すくすくスクラム仙台
⑫リアルタイムKPT（特別付録）
• 採集場所： TEF道お世話役 安達さん（@kitanosirokuma）
• 由来： 思ったときにすぐ書くから
• 対象： 機動力のあるチーム
• 特徴： 業務フローの上にKPTをリアルタイムに重ねていく。1ヶ月
もするとどこに問題があるか一目で見えてくる。
要求仕様書
を作成する
[Procecc Flow Diagram]
設計書を
作成する
コーディング
する
テストケース
を作成する
設計書
要求
仕様書
ソース
コード
テストする
テスト
ケース
テスト
結果
依頼書
メール
環境
テスト観
点
Keep
Problem

18. すくすくスクラム仙台
まとめ
• 色々な拡張KPTを紹介しました。
• 自分のチームに合うものを選択、または組み合わせて使
ってみてください。
• ふりかえり自体が楽しくなるといいですね！
• 新種を見つけたときは是非ねもとまで一報ください♪

19. すくすくスクラム仙台
Have a nice KPT!!

20. すくすくスクラム仙台
UltimateAgileStoriesとは？
UltimateAgileStoriesは、同人誌です。
アジャイル日本上陸から10年余り。
日本でのアジャイルの広がりは、コミュニティを中心とした、個々のエンジニアが
大きな役割を担ってきました。
そのような背景もあり、アジャイルに対する思いは、
ビジネス、マネジメント、コミュニケーション、テクニカルなど、
人によって多種多様です。
今回の企画は、そのような
『いろいろな人の、いろいろな思いを集めた1冊を作りたい！』
という思いから生まれました。
http://ultimateagilestories.web.fc2.com/bookcontents5.html