ユーセンブログ

ゲーム開発に関することをたまに書きます

大学でKPTを試してみた話

 

 初投稿。

 先日、大学のチーム制作の会議でKPT(けぷと)というものをやりました。

 KPTとはKeep、Problem、Tryの略称でアジャイル開発などで使われる振り返りのための会議のやり方です。

 

 このやり方は以前にも何度かやったことがあるのですが、今回ちゃんとやってみてかなり学校でのゲーム制作と相性がいいのでは? と感じたのでそこの所含めて書いていきたいと思います。

 

KPTってどうやるの?

 KPTのやり方は簡単です。

 ↓まずこんな感じでK、P、Tのそれぞれの枠をホワイトボードに書きます。

f:id:k_tachiban:20160410000938p:plain

 後はKeepの枠に良かったこと、Problemの枠に現在の問題点、そしてTryにこれからやっていくことをそれぞれふせんで書き出していきます。これをだいたい1、2週間くらいに一回やります。以上です。

 

 ……とだけ書いてしまうとあまりに雑なのでそれぞれの書くことを説明します。

「Keep」

 ここにはこれからも継続したいこと、良かったことを書いていきます。このKeep、他の2つと比べると割りと軽視されがちですがかなり重要なところ。

 ここでしっかりチームを褒め、雰囲気をよくすることでこの後のProblemで雰囲気が悪くなりにくくなります。これを怠るとただの反省会になってしまって良くない雰囲気になりやすくなります。

 とはいえはじめはそんなポンポン出てくるわけではないので開発の状況だけでなくプライベートであった良かったことなども書き出すようにすると楽しくなります。

「Problem」

 ここがメイン。これまで良くなかった問題点を書き出していきます。この時司会役の人はなるべくぶっちゃけてもらうように指示してください。

 チーム制作でありがちな「みんな何も言わないけど、なんとなくこれはヤバい気がする……」ということを共有します。自分がヤバいと思っていてほんとにヤバいことはだいたいみんなヤバいと思っています。

「Try」

 ここでは、まず、チームの人それぞれに自分が書き出したことについて話してもらってその人の意図を共有します。

 その後、Keep、Problemを踏まえてこれから実行していくことを書き出します。このとき「~を頑張る」などではなく、なるべく具体的にできたかどうかがはっきりわかるように書き出してください。

 あと、すぐに解決方法が出てこないし、時間で解決されそうな問題はスルーしても良いです。ほんとにヤバかったら次回やっても出てくるのでその時対処方法を考えるようにするとスムーズに進みます。

時間配分

時間配分ですが私は

Keep:3分

Problem:3分

Try:10分

くらいを目安にやっています。短く区切ったほうがダラダラしないし楽なので続けやすいです。

 

まとめ

 KPTを開発に使う上で大事な概念として、開発後ではなく、開発中、かつ頻繁にKPTを行うというのがあります。とはいえ朝会のように毎日やるというほどのものでもありません。大体1、2週間に一度位のペースで行います。

 そして、大学の授業でやっているなら週に一度は授業の日があり、サークルでも週に一度ミーティングをやるところは多く、それに合わせてKPTを行うと開発にリズムも生まれるしきちんと情報の共有ができるので、なんとなく発言しにくいといった問題を抱えているチーム開発におすすめの方法です。

 

 で、あってるよね? そうじゃねぇだろっていう意見があればコメント下さい。