目次
KPTとは、行ってきた仕事や活動を振り返る際に、以下の3つの視点で整理するフレームワークのことです。
- K：Keep＝今後も続けること
- P：Problem＝問題なので、やめること
- T：Try＝今後、試してみたいこと
アジャイル開発や反復型開発ではイテレーション（繰り返しの単位）ごとに作業の振り返りが推奨されますが、そのためのチーム反省会などでよく用いられるフォーマットであり、「ふりかえり」するための有効なシステムとなります。
Keep (続けたいこと、良いこと)
うまくいって次も続けたいこと。良いことを検討します。
- どんな些細なことでもよい
- 個人的なことを挙げてもよい
- 前回のふりかえりのTryがあれば、それを次も続けるか検討する
Problem (不満点、問題点)
次に、不満に感じていること。工夫の余地がありそうなことを検討します。
- 発生している現象を具体的に書く
- 将来的に発生しそうだと思うことも書く
- 未来の問題（リスク）も挙げる
Try (改善策、工夫してみたいこと）
最後に、問題に対する改善策を検討します。
- より良くなりそうな改善策を検討する
- やってみたらうまくいく予感のすることを挙げる
ここでのポイントは「思いつく限りのアイデアを考えて、多くの選択肢から選ぶ」ことです。また、その改善案は「実現可能な行動（アクション）」になっていること。そうでないと次に活かすことができないためとなります。
新しい問題(Problem)が発生したら、改善策を検討し実行可能なアクション(Try)を設定する。次回、そのアクションを実行します。
そして前回のTryで設定したアクションの結果を分析する。うまく行っていれば今後も継続(Keep)し、問題(Problem)があればより良くする方法を検討し、次回さらに改善した策(Try)を実行します。
もちろん新しい問題が発生することもあるので、そのときは改善策を検討する。やってよかったことを新しく発見した場合も残しておく（今後も忘れずにやれるように）。
KPTチェックリスト
ゲーム開発でKPTを実際に行うときにどのようなことを書くのが良いのかリストにしてみました。
概要
- ゲームタイトル：ゲームタイトル名
- 一言説明：ゲーム内容を端的に表す説明。ゲームジャンル
- 開発期間：開発開始から終了までの期間
- コンセプト：目標とするゲームや実現したいゲーム体験、達成したい技術的目標など
コンセプトは表現したかったものを、細かくカテゴリ分けしても良いかもしれません。
総評
- 自己評価点：100点満点中の80点、など
- 良いところ：うまく作れたところ。うまくいったこと。
- 悪いところ：うまく行かなかったこと。失敗したこと
良いところ・悪いところはKPTでしっかり書くので、簡単にまとめて問題ないです。
KPT
| 分類 | 検討項目 |
|---|---|
| コンセプト | ・実現できたコンセプトは？ ・挑戦してみてうまくいったコンセプトは？ |
| 開発全般・ スケジュール | ・タスク管理ツールをうまく使えたか？ ・スケジュール通りにうまくいったことは？ ・期間内に完成させるためにしたことは？ ・ゲーム内容に見合う開発期間だったか？ |
| 作業分担 | ・他人に任せて良かった点や得られたことは？ ・良い納品物が得られた理由は？ |
| プログラム | ・効率化できたプログラムは？ ・処理を汎用化できた部分は？ ・次回作でも使いまわせそうな部分は？ |
| アート | ・見た目のクオリティを上げるためにしたことは？ ・次回作で流用できそうなアートは？ |
| UI | ・快適なUIを実現できた部分や工夫は？ ・わかりやすいUIにするための工夫はあったか？ |
| シナリオ・ 世界観 | ・魅力ある登場人物を作るためにしたことは？ ・シナリオやキャラで評判の良かったところは？ ・ゲームシステムとシナリオの融合はうまくいったか？ |
| サウンド | ・統一感のあるサウンドを用意できたか？ ・シーンを盛り上げるサウンドとなったか？ |
| 評価・ プロモーション | ・評判の良かった部分はどこか？ ・うまくいったプロモーションは何か？ ・SNSで知名度を上げるためにしたことは？ ・イベント出展、プレスリリース、ストア掲載時にうまくいったことは何か？ |
| 分類 | 検討項目 |
|---|---|
| コンセプト | ・実現できなかった、不十分だったコンセプトは？ ・保守的になっていたところはないか？ ・新規性やオリジナリティが不足していた部分はないか？ |
| 開発全般・ スケジュール | ・スケジュール通りにいかなかった部分は？ ・必要以上に時間を取られた部分はどこか？ ・開発途中で進捗が悪くなった理由は？ |
| 作業分担 | ・作業指示に問題のあったところは？ ・期待した納品物が得られなかった理由はあるか？ |
| プログラム | ・不具合やエンバグが頻発した部分は？ ・バグを取るのに苦労したところはどこか？ ・実装に時間がかかりすぎた部分はどこか？ |
| アート | ・チープだった部分はないか？ ・チープな部分で改善できることはあるか？ |
| UI | ・わかりにくかったUIはないか？ ・違和感のある動作をしていたUIはないか？ |
| シナリオ・ 世界観 | ・魅力がなかった部分はどこか？ ・説明的なセリフはなかったか？ ・ゲームのテンポを阻害する冗長なシーンはなかったか？ |
| サウンド | ・サウンドのクオリティが低い部分はなかったか？ ・入れるべきところに入らなかったサウンドはないか？ |
| 評価・ プロモーション | ・評価が悪かった部分は何か？ ・低評価のレビューで妥当だと思った意見は何か？ ・認知度を上げるためにやるべきだったことは？ ・イベント出展、プレスリリース、ストア掲載時に準備不足だったことはあるか？ |
| 分類 | 検討項目 |
|---|---|
| コンセプト | ・今作で試したコンセプトを継続するか？ それとも別のコンセプトを試すか？ ・挑戦してみたい表現方法や技術はあるか？ |
| 開発全般・ スケジュール | ・試してみたいタスク管理ツールはあるか？ ・作業時間を短縮できそうな部分はあるか？ ・不具合の発生を減らすためにできることはあるか？ |
| 作業分担 | ・他に作業分担できそうな部分はないか？ ・さらに効率を改善できそうな部分は？ ・アセット素材を活用できる部分はあるか？ |
| プログラム | ・使ってみたい技術は？ ・試してみたいアーキテクチャやアルゴリズムはあるか？ ・効率よく実装するためにできることは？ |
| アート | ・今作で挑戦できなかったアートは？ ・次回作でクオリティを上げたい部分はどこか？ ・効率よくデータを作るためにできることは？ |
| UI | ・よりわかりやすいUIにするためのアイデアはあるか？ ・使っていて楽しいUIにするには？ |
| シナリオ・ 世界観 | ・わかりやすいシナリオにするためにできることはあるか？ ・魅力的なシナリオや世界観を作るアイデアはあるか？ ・キャラを魅力的に見せるためにできることはあるか？ |
| サウンド | ・サウンドをよりゲームにマッチさせるためにできることは？ ・サウンドのクオリティを上げるためにできることは？ |
| 評価・ プロモーション | ・新しくできるプロモーションはあるか？ ・話題性のあるコンセプトを作るためのアイデアはあるか？ |
参考になりそうなリンク
実際にKPTを行った方の記事を見てみるのも参考になると思います。
初めてunity1weekで作品を出せたのでKPTで振り返る
こちらの方は unity1week という「Unityを使って1週間でゲームを作る」イベントに参加したときの振り返りをまとめられています。
