KENTEM TechBlog

建設業のDXを実現するKENTEMの技術ブログです。

KPT を改良してチームの振り返りを活性化した話

この記事は、 KENTEM TechBlog アドベントカレンダー2025 12日目、12月12日の記事です。

こんにちは!バックエンドエンジニア兼、プロジェクトリーダーをしている N.Y. です。  

みなさん KPT はご存じですか?もしくは実践されていますか??
私のプロジェクトでは、より良いプロジェクト運営を目指して、独自に作ったフォーマットで KPT を行っています。
本日はそのフォーマットに至るまでの経緯と、運用してみた所感などをお伝えできればと思います。

KPT (ケーピーティー or けぷと) とは

振り返りのためのフレームワークで、以下3つの切り口で構成されています。

  • Keep(うまくいったので続けたいこと)
  • Problem(問題・課題・うまくいかなかったこと)
  • Try(問題に対する改善アクション)

私のプロジェクトでは、プロジェクト改善活動の一環として、イテレーション(2週間)ごとに KPT を用いた振り返りを実施していました。

プロジェクトの特徴

自分が所属しているプロジェクトの特徴です。

  • 南は福岡、北は北海道までメンバーが各地に散らばっており、基本的に会議はオンライン。
  • ベテラン~中堅~新卒まで、様々なスペックの人が集まっている。
  • 自分は7月からプロジェクトに参入した新規メンバー。

課題感は突然に

7月にプロジェクトに参入し、だんだん慣れてきた頃のことです。いつも通りKPTに沿って振り返りをしていたとき、ふと思いました。
「忙しくなると Keep が出にくくなっているな・・・」
「振り返りに時間がかかってるな・・・」
「喋る人がいつも同じ気がするな・・・」

「「「この振り返りって、もう少し改善できそうな気がするぞ!!!!!」」」

ここで一度、現在の振り返りでの課題点をメンバーにも聞き、洗い出してみました。

・振り返りに毎回2時間くらいかかっている
・Keep があまり出ていない
・思ったことを喋りすぎているかもしれず申し訳ない
・Problem と Try の対応が分かりにくい(箇条書きになっていたため)
etc...

思い立ったら吉日、何か良い振り返りフォーマットがあるのではないかとネットの海を探しに行きました。

見つけた神フォーマット

良さげなフォーマットを公開してくださっている方がおり、「これだ!!!」となりました。(ありがとうございます!!!)

note.com

この記事内で取り上げられている、以下フォーマットが良さそうだとまず考えました。

  • Keep
    「ドヤりたいこと・感謝したいこと・続けたいこと」を共有する
  • Problem & Try
    「聞いてほしいこと・変えたいこと」など議論したほうが良さそうなことを共有する 全部をなめた後にチームで議論したほうが良いことをピックアップして、議論の着地点を決める

まず、Keep の範囲を「ドヤりたいこと・感謝したいこと・続けたいこと」と広げることで、もっとカジュアルな Keep がたくさん出るようになるのではと思い、これは是非導入したい!と考えました。
ポジティブなことが共有されて一緒に喜ぶことで、モチベーションや気分も上がりプラスの要素しかありません。決定。

一方、Problem & Try ですが、こちらはプロジェクトの特性と現状の課題感に合わせて少し調整をしてみました。

自プロジェクトの特徴に合わせて少し調整

「聞いて欲しいこと」をなんでもありにする

私のプロジェクトではほぼメンバー全員の拠点が異なっているため、コミュニケーションがオンラインでしか取れないという特徴があります。
メンバーが今、何か困っていたり悩んでいることはないか。どういうことに興味があるのか。どのような感情なのか。
といったところを他のメンバーに吐き出せるような場があれば、事が大きくなる前にプロジェクト改善できるようになるのではないかと考え「聞いて欲しいこと」は何でもありとしました。
感覚的には「ちょっと聞いてよ~」というくらいの軽さのものでもOKです。
個人の反省なども、ここに含まれてOKです。

また Problem 未満なので具体的な Try までは求められない限り不要 という位置づけとすることで、今まで Problem としては挙げづらかったことについてもカジュアルに挙げられるようになり、より多くの「聞いて欲しいこと」が集まるのではないかと期待しました。

ちなみに、この「聞いて欲しいこと」で上がってきた課題について、具体的な対策が必要となった場合は適宜 Problem に移動させます。

Problem はチームで議論したいことに集中

既に明確にチームの課題だと分かっているものについては、Problem に記述します。
チームに関連する課題と限定することで、個人の反省はここには含まれないようになります。
また、Problem が多い場合は優先度の高いものから話し合いするようにします。

今までは Problem には上がった内容についてすべて Try を出そうとしていた傾向があったので、答えは必須で求めていないものについては「聞いて欲しいこと」に記述し、議論が必要な部分については 「Problem」とすることで有効に時間を使えるのではという狙いもあります。

できあがったフォーマット

前回のTryを振り返る(10分)

まずは前回の Try が達成できたかどうかを振り返る

自分がドヤりたいこと・メンバーに感謝したいこと・チームまたは個人で続けたいこと(10分)

例:△△を1日かからずに実装できた、タスクをフォローしてくれてありがとう、〇〇がいい感じなので続けたい

聞いて欲しいこと(15分)

情報共有(知識・アイディアの共有)/ 困難・懸念(課題の種・感情の共有)など
解決策は求められるまでは不要
例:△△から出た新技術使えるかも、✕✕がめっちゃ大変だった、〇〇することに不安がある

Problem(チームで議論したいこと)& Try(35分)

Problem が多い場合は一度通して確認し、優先的に話し合った方が良いものから話し合いを実施
Try は担当者と期限を明確に記述し、次回の振り返りで状況確認する

使ってみた感覚

良かった点

  • Keep にポジティブなコメントが出るようになった!
  • Keep を通して、メンバーの隠れた功績が分かるようになった!
  • 「聞いて欲しいこと」にカジュアルな意見が出てくるようになった(~したい、~がしんどい)
  • 「聞いて欲しいこと」を設けて会話のハードルを下げたことで、どんどん意見が出るようになった気がする
  • Problem と Try の対応が見やすくなった
  • 振り返りが長時間化することが少なくなった

気になった点

  • 「聞いて欲しいこと」に困っていることが集まる傾向があるため、Problem との境界があいまいかもしれない
    カジュアルに困っていることを相談できる場としては有効なのかも?
  • Keep を書きやすくなったものの、やはり忙しいと数が少なくなりがち
  • みんな控えめなのか全然ドヤってくれない
  • 全体のボリュームが多い場合、やはり2時間くらいかかってしまう

まとめ

今回は、私のプロジェクトで実施している振り返りのフォーマットを公開しました。
私のプロジェクトでは、拠点がバラバラのためもっとコミュニケーションが活発になる打合せの場を設けたいという気持ちがありましたが、多少は貢献できたのではないかなと思います。
例えば全員リモートワークで、打合せで発言する人が偏りがちなチームであったり、顔を合わせているけど打ち解けるのに時間がかかっているチームなど、コミュニケーションで困っている場合の一つの案として、こちらのフォーマットが活用されれば嬉しく思います。
まだまだ伸びしろのあるフォーマットだと思うので、もっとメンバーが楽しめるようなコミュニケーションの場として活用できるように、今後も随時改善をしていきたいです!

おわりに

KENTEMでは、様々な拠点でエンジニアを大募集しています! 建設×ITにご興味頂いた方は、是非下記のリンクからご応募ください。 recruit.kentem.jp career.kentem.jp