こんにちは、おゆかよです。
業務改善の思考フレームワークとしてKPTを利用している企業は多いと思います。わたしの所属するチームでは、以前はふりかえりミーティングが行われていませんでした。業務で気になる点があっても今までのやり方を変えるタイミングがなく、「刀をとがずに切り続けている」ような状況があり、ずっと課題を感じていました。
あるときKPTというフレームワークを知り、それをきっかけにふりかえりミーティングを始めました。やり方がわからないながらも枠を付箋で埋めてもらうと、たくさんの意見が出ました。普段話さない人からも思わぬ意見が出て、各自が思ってることを吐き出せ議論ができて、有益なミーティングに思えました。しかし、細かいところでやり方がわからずに、もやもやした部分もありました。
問題点としては、とにかく時間が足りませんでした。ひとつひとつの付箋について話し合うと1時間では到底終わりません。また、いい案が出てもなかなか実施に至らず、毎回同じProblemが上がってくるだけで前に進んでいないように感じました。
その後、KPTをよく知る方に教えていただき、また書籍も参考にしながら少しずつミーティングの進め方を改善してきました。
時間をかけた結果、今では以前と比べて随分ミーティングがスムーズに進むようになりました。まだ「完全にうまく回っている」と胸を張れる段階には達していませんが、KPTを開始した当初に比べると多くの工夫を加え、改善できていると感じています。
今回は、KPTを実践しているものの効果を実感できていない方に向けて、わたしのチームが工夫してきたポイントをお伝えします。この記事を通して、KPTの本当の目的やうまくいかない原因を理解し、組織の改善を進めるきっかけとなればうれしいです！^^
KPTの簡単な説明
KPT(けぷと、けーぴーてぃー)とは、前述のとおり仕事の「ふりかえり」に適したフレームワークで、「Keep（続けること）」「Problem（問題）」「Try（試してみたいこと）」の3つの要素で構成されています。
わたしのチームでは案件が終了するごと(2～3か月のスパン)にこのフレームワークを用いてふりかえりミーティングを実施します。もっと頻度を上げたいところですが、今はこのペースで安定しています。
ミーティングではホワイトボード上に枠を用意し、K→P→T の順で付箋を貼っていきます。ツールやレイアウトに制約はありませんが、わたしたちはオンライン上でミーティングを行っているのでホワイトボードツールを使用しています。
KPTの目的は「次回もっとうまくやること」
KPTの最大の目的は「次回もっとうまくやること」です。
「反省会」という名のガス抜きに終わらせるのではなく、全員が目的を意識して取り組むことが大事です。
わたしがファシリテーターを務める際には、ミーティングの冒頭でこの会の目的とルールをリマインドしてから開始するようにしています。^^
KPTの進め方
以下は、わたしのチームで実際に行っているKPTの手順です：
- KeepとProblemは事前記入
ミーティング時間はディスカッションに集中したいので、KeepとProblemは事前に記載をお願いしています。 - ミーティングの目的とルールの共有
ミーティングの目的、ルール、タイムスケジュールを全員で共有します。 - Keep、Problemの読み上げと分類
全員のKeep、Problemを順に読み上げ、類似の項目をまとめて分類します。分類後、各グループに「名前」をつけるとその後の進行がスムーズです。 - 深掘りする項目の選定
どのKeepまたはProblemを深掘りするか全員で投票して決めます。
各自、3項目ずつ「イイネ」をつけ、得票数の多いものから選定します。いくつ選定するかはミーティング時間によって判断しています。 - Keep、Problemの深掘り
選定されたKeepやProblemについて議論し、課題の本質を明らかにします。 - Tryの記入
次回試すべき改善案（Try）を全員で記入します。 - Tryの読み上げと分類
全員のTryを読み上げ、類似項目をまとめて分類します。 - 実施するTryの選定
投票で優先順位を決め、どのTryを実施するかを決定します。 - 改善リストへの転記
決定したTryは、ファシリテーターがミーティング後に改善リストへ転記し、チームで共有します。
Keepには「良い結果につながった具体的な行動」を書く
「行動」を書くようにする
たとえば「納期が間に合ってよかった」「テストフェーズでテストNGがほとんど出なかった」などの結果だけを記載するのでは、具体的な行動が見えないためどうやってKeepすれば良いかが分かりません。Keepを書く際はなるべく具体的な行動を記載するようにします。
具体的な行動が書いていない場合は「どのような行動がこの結果をもたらしたのか？」をミーティング内で話し合い、行動まで落とし込みます。
※ Keepにチームの成果やほかのメンバーへの感謝を書くことは、場の雰囲気作りに役立つため禁止する必要はないと思います。ただし、ふりかえりの目的は忘れないようにしましょう。
「新たに気づいた良い点」を書くようにする
すでにルール化されている行動や、次回も確実に実施されると見込まれる行動は、新たに記載する必要はありません。「新たに気づいた良い点」を記録することで、継続すべき行動を明確にします。
Problemには「困ったこと」を書く
「対策」を書かないようにする
Problemに対策(Try)まで記載してしまうのはよくあることです。たとえば「テストチームからの問い合わせが多いので対応者を決めておきたい」といった内容です。
Problemに対策を含めてしまうと、メンバーの考えがその対策にひっぱられてしまいます。Problemを書いているときにTryを思いついてしまう気持ちはわかります！が、ここではあくまで問題点だけを記載します。
「実際に困ったこと」を書くようにする
一般的に「良くないであろうこと」を書くのではなく、実際に困ったことを記載します。たとえば「要件定義と設計が同時並行だった」と書いた場合、それ自体は事実ですが、必ずしも困りごととは限りません。要件定義と設計が同時並行だった結果、どのような不利益が生じたのか？まで記載します。もし特に困らなかったのであれば、Problemとして記載しないようにしています。
Tryには「具体的なアクション」まで書く
アクションに落とし込む
このミーティングの目的を達成するには、KeepとProblemについて次回もっと良くなるための具体的な計画を立てる必要があります。「頑張る」「意識する」などの心構えは抽象的で、実行や評価が難しいため、行動に移せる具体的な内容を記載するようにします。
他の人が書いたKeep、ProblemについてもTryを提案する
出された付箋はすべて個人のものではなくチームのものです。Tryを記載する際には、他の人が書いたKeepやProblemについてもTryを考えて書くようにします。
幅広く応用できるように抽象化する
また、Tryは個別のケースに限定されるものではなく、他の場面でも応用できるように抽象化することを検討します。たとえば「〇〇機能を修正するときには××というテスト観点でテストする」というTryを採用すると、機能ごとに細分化されたルールが増え続ける恐れがあります。汎用的なルールに置き換えることで、さまざまな状況に対応可能な改善案を生み出すことができます。
優先順位を決める
時間やリソースには限りがあるため、すべてのTryを実施するのは現実的ではありません。優先順位を決める習慣をつけ、効率的に改善を進めます。たとえば、投票を活用することで合理的にTryを選定することができます。
いつ、何を、どのように実施するかを明確にする
たとえば「〇月〇日までに、単体テストルールのチェック表に『C0カバレッジ90％』と追記する」といった形で、何をいつまでにどのように行うのかを明確にします。
とはいえ、わたしのチームでは時間がないことが多いので、選定したTryをチームの改善活動リストに転記し、別の会議体で期日やアクションを決めるようにしています。^^;
ファシリテーターはミーティングの「運営者」に徹する
リーダーがファシリテーターをするときの注意点
リーダーがファシリテーターを務める際は、「役割を切り替える意識」が重要です。以下に、リーダーがファシリテーターを務めた際に陥りがちな状況を挙げます。
リーダーとメンバーとの 1 on 1 状態になってしまう
リーダーがメンバーそれぞれの付箋にコメントをしてしまい、メンバー同士の対話が無い状態になりがちです。この場はディスカッションの場とするため、ファシリテーターは記載や発言の不明確な点について明らかにするにとどめ、全員が意見を出し合える雰囲気作りに徹します。
リーダーの意見が強く反映される
リーダーの意見は重く見られがちです。このミーティングの方向性がリーダーの意図に引っ張られないよう、ファシリテーターの役割に徹し、議論を公平に進めるように努めます。
全員に議論に参加してもらう
もしミーティングに5人のメンバーがいて、そのうち3人が積極的に議論を交わしていた場合、会議の雰囲気は「活性化されているように見える」かもしれません。しかし全員が口を開いていないのであれば、それは理想的な状態とは言えません。
発言していないメンバーにも意見を促し、議論に参加してもらうようにします。例えば、「〇〇さんはどう思いますか？」と具体的に名前を挙げて質問したり、全員に順番で意見を求める時間を設けるなどの方法があります。全員が議論に参加することで、多様な視点が生まれ、より良い結果に繋がります。
その他のポイント
大きな問題や、改善効果が高そうな問題にフォーカスする
限られた時間の中で、すべての付箋について議論するのは難しいため、特に影響の大きな問題や改善効果の高い項目にフォーカスします。
KeepとProblemはミーティング前に記載するのがおすすめ
ミーティング時間を効率的に使うために、KeepとProblemは事前に記載してもらうのがおすすめです。ただし、Tryはその場の議論を反映させるべきなので、事前記載は避けます。
ペース配分を意識する
議論が白熱するとミーティング時間が超過してしまいがちです。
Keepは〇分、Problemは〇分、などあらかじめ時間を決めておき、誰かがタイムキーパーをするか、アプリなどを活用して時間がすぎないように細心の注意を払います。
ミーティングの冒頭でタイムスケジュールを共有し、メンバー全員で意識すると良いです。どうしても終わらない場合は定刻前に議論を続行するか別のミーティングを設定するかを決めましょう。
わたしも以前は好き放題時間を超過していました。タイムキーピングの練習を始めると本当に難しく、何度も失敗しました。^^;; 練習あるのみです。
実は一番大事！全員が「次はもっとうまくやりたい」と思ってのぞむ
多くの場合、メンバーは「ただ集まるように指示された」という意識になりがちです。この状態では実りある議論にはなりません。
最初は難しいかもしれませんが、ふりかえりミーティングは「全員が目的をもって集まる場」になることが何よりも大事です。これが達成できたら、少しくらい方針がずれていても実は問題ないとさえ思っています。
改善は評価しながら繰り返す
一度で最高の解決になることはありませんし、ミーティング後に状況が変わることもあります。改善はふりかえりをしながら繰り返すことが重要です。
事実と推測を区別する
KeepやProblemを記載する際に、「事実」と「推測」がはっきりしないことがあります。
「〇〇という仕様を知らなかったからテストケースから漏れ、市場不具合につながった」という文章があったとします。「テストケースから漏れ、市場不具合につながった」は事実だとして、「〇〇という仕様を知らなかったから」は事実でしょうか。仕様を知らなかったとしても標準的なテスト観点を抑えていれば不具合は見つかったかもしれません。
議論はまず事実を出発点とするべきなので、自分あるいはメンバーが言及していることが事実なのか推測なのかは意識して切り分けるようにします。
わたしのチームでふりかえりを行うときは、付箋のテンプレートをあらかじめ「■事実」「■推測」というセクションに分けることで参加者が意識できるようにしています。
おすすめ書籍
参考にしたのはこの書籍です。
書籍の内容をそのまま実行しているわけではありませんが、KPTの流れやファシリテーターのふるまいなど、かなり参考になりました。
まとめ
KPTは「次回もっとうまくやること」を目的にしたシンプルで効果的なふりかえりのフレームワークです。
具体的な行動や問題点、実現可能なアクションを記載することで、改善活動を継続的に進められます。
全員が議論に参加し、目的意識を共有することが成功の鍵です。改善は評価を重ねながら繰り返し行い、チームの成長につなげていきましょう。
コメント