実践を通じて得られた、KPTの効果を高める3つのポイントと秘密のエッセンス

SHIFT ASIAでプロジェクトマネージャー/スクラムマスターを務めているSONICです。

振り返りのフレームワークであるKPTを開発プロジェクトなどで活用されている方は多いと思いますが、KPTは非常に軽量かつシンプルであることから、実は実践の場で効果的に扱うことが難しいフレームワークでもあります。

私自身も、実際に開発プロジェクトの運営に携わるなかでKPTを活用してきましたが、うまく機能しないケースもたびたび経験してきました。
しかしながら、プロジェクトの振り返りにおいてKPTを何度も繰り返すなかで、プロジェクトの生産性や品質を向上させるうえで重要となるKPTのコツを見つけることができました。

そこで本記事では、私自身がKPTを実践するなかで得られたKPTの効果を高めるポイントやエッセンスについて、実際の例を交えながらなるべく具体的かつ詳細にご紹介します。

なお、本記事ではスクラムを用いた開発プロジェクトを例にしていますが、スクラム以外でも応用が可能な内容になっていると思います。

これからKPTに取り組もうと考えている方や、既にKPTを実施しているもののうまくいかないといった方にとって、少しでも有益な情報となれば幸いです。

はじめに

プロジェクトを進める過程では、当初想定できていなかったさまざまなことが起こりえます。

顧客側担当者の多忙さによって未決要件が増加した
連携先の対応プロセスや担当者が変更された
タスクチケットに対応する実装コードがステージング環境に溜まってしまい、大きめのリリース対応が必要になった　など

環境の変化によって柔軟な対応が求められる開発プロジェクトにおいては、日々の対応プロセスのアップデートが重要になります。

しかしながら、私が担当していた案件では上記のようなトラブルについて柔軟なプロセスや対応を適用できていなかった時期があり、また、会議を行っても意見が出なかったり、KPTを通じて「Keepする（継続する）」と決めたことが実際にはKeepされなかったりという状況が発生していました。

そうしたなかで、プロジェクトの振り返りの場において、KPTの解説記事を参考とした3つのポイントと、独自に見つけ出した3つのエッセンスを取り入れてKPTを実践したことにより、プロジェクトにおける課題の検出と解決が非常にスムーズに進むようになりました。

その結果として、大規模リリースにおける管理業務の工数が5分の1へと大きく縮小し、また、下記のような品質を向上し続けるための取り組みも導入され、継続的に品質改善が行われる仕組みも構築することができました。

SonarQubeを導入し、スクラムチームの完了の定義へ追加
コードレビュー観点の改善・追加
SHIFT標準のアジャイルテスト(SQF)の試験的導入

このように、KPTを効果的に活用することができれば、プロジェクト運営において大きなメリットを得ることが可能ですが、そのためには重要な抑えるべきポイントがあります。

そこで、まずはKPTにおいて実践すべきと考える3つのポイントについてご紹介します。

KPTで実践すべき3つのポイント

1. 実施するタイミングを定期化し、明確なタイムボックスを設け、参加人数を10名以下にする

レトロスペクティブ（振り返り）を実施するタイミングを定期化することでミーティングの設定についての不要なコミュニケーションや意思決定コストを省き、また、タイムボックスを明確にして時間を制限することで集中力が散漫になることを防ぐことができます。
さらに、参加人数を多くとも10名以下とすることで気軽に意見をだせるようにしています。

また、私がスクラムマスターを務めているスクラムチームでは、レトロスペクティブのMTGを定期化するだけではなく、ある曜日を「スクラムイベントの日」として位置付けることでその日のスクラムイベントへの参加を習慣づける工夫を行っています。

タイムボックスについては、経験的に1時間前後でメンバーの集中力が切れることから、長くても１時間に収まるようになるべく時間を削ぎ落すようにしています。
これは、後述のKPTの効果を高めるエッセンスの2つ目にもつながります。

参加人数としては、大抵の場合スクラムマスターを合わせても4~6人程度にしていますが、この規模感でもマンネリ化させず意見を出させるには工夫が必要になります。
もし参加人数が10人以上になる場合は難易度が大きく上がるため、それ相応の仕組みが必要になるでしょう。

2. レトロスペクティブが行われる日のみ全員がオフィスに出社するようにファシリテートする

レトロスペクティブの目的は、当該スプリントを振り返ることで以降のスプリントの品質や効果を高めることであり、各ロールの観点からProblem（解決すべき課題）を抽出し、それに基づきTry（次に取り組むこと）を検討することがイベントの要です。
したがって、スプリントに参加しているメンバーの観点でProblemや適用したい・したくないTryを可能な限り漏れなく伝え合う状態が理想です。

しかしながら、Covid-19への感染予防のためにリモートやハイブリッドワークを取り入れている会社も多いのではないでしょうか。
弊社でも同様の理由からリモートを基本とするハイブリッドワークを取り入れていますが、リモートワークでは通勤時間や意図しないコミュニケーションを省ける一方で、接触できる情報の少なさによるコミュニケーションの質が減退してしまうというデメリットがあります。

そのため、私が参加するスクラムチームでは、レトロスペクティブ（振り返り）の日を共通の出社日と決めて、関係者が全員オフィスに出社するようにしています。
Face To Faceのコミュニケーションでは、リモートに比べて相手の反応をよりダイレクトに感じられることから、思いついたことをより発言しやすくなる効果が見られています。
結果として、リモート環境でのミーティングよりも意見が出やすくなり、Tryの検討も行いやすくなりました。

もしリモート環境におけるレトロスペクティブで意見が出づらいときは、レトロスペクティブの日のみ全員が出社するという施策をKPTのTryの項目に加えてみてはいかがでしょうか。

3. スプリントレトロスペクティブはスクラムマスターがファシリテートを行う

レトロスペクティブで用いるKPTは、スプリントの品質と効果を高めるための1つの手段です。レトロスペクティブはスプリントの品質と効果を継続的に改善していくためのスクラムイベントの一種ですので、その確立と定着はスクラムマスターの責務と言えるでしょう。

私はスクラムマスターとして、レトロスペクティブの実施やKPTの導入を行うことがありますが、私が苦労したことは集約すると以下の3点であり、すべてKPT導入後の課題です。

Keepが溜まってしまい、Keepの見直しだけにレトロスペクティブの時間をつかってしまう
Problemの抽出とTryの検討を重ねることで、ルールが溢れてしまい実践されなくなった
スプリントレトロスペクティブのKPT更新がマンネリ化してしまい、課題はまだ存在するはずなのに意見が出てこない

これらの課題は、多くの方がレトロスペクティブを繰り返すなかで頻出する典型的な課題とも言えるでしょう。

具体的な解決方法は、この後にご紹介する「KPTの効果を高める3つの秘密のエッセンス」にて詳しく述べますが、スクラムマスターが率先してファシリテートすることがレトロスペクティブとKPTを効果的に行う上でのポイントとなります。

KPTの効果を高める3つの秘密のエッセンス

続いて、KPTの効果を高める3つの秘密のエッセンスについてご紹介します。

1. Keepの見直しは1カ月に1回とし、それ以外のレトロスペクティブではスクラムマスターがレトロスペクティブの前にKeepを確認するに留める

Keepの項目が20~30と増えてくると、改善事項の維持確認のためにレトロスペクティブのタイムボックスをまるまる使い果たしてしまいます。

しかしながら、レトロスペクティブの目的は当該スプリントを振り返りスプリントの品質や効果を高めることであり、KPTのProblemとTryの見直しも重要です。

そこで私のチームでは、チーム全体でのKeepの見直しは月1回だけとし、通常はスクラムマスターだけがレトロスペクティブが始まる前に確認する程度に留め、Problemの洗い出しとTryの検討にフォーカスできるようにしています。

2. そぎ落とす

Problemの洗い出しとTryの実践、Keepでの保持というKPTサイクルを繰り返すと、ルールだらけになってしまった経験はありますか？
私のチームではルールが増えてしまい、結局実践されないという悲しい経験を何度も経験しました笑

人間は同時にはいくつかの変数しか認識できないようでして、私達が実践していることはKPTのKeepを意識せずともそれが実行される仕掛けをKPTのTryの項目で検討することです。

例えば、アプリセキュリティの順守事項をKeepに記載するのではなく、アプリセキュリティ向けの静的解析ツールを導入し検査項目の設定を調整することで、静的解析を実行するだけでKeepすることができています。また、当該静的解析ツールの実行と所定の指摘項目の修正を完了の定義(品質基準)に含めることでスプリントごとの成果物は上記Keepを満たすものになります。

つまり、Keepのままだと10件、20件とあったルール（Keep事項）が、「スプリントバックログ内のタスクはスプリント終了時までに完了の定義を満たすように実装する」というルール1つに凝縮されたとも言えます。

これは一例ですが、ProblemとTryを繰り返したことにより、あなたのチームのルールが増えてしまったときは、ルールをそぎ落とすためのレトロスペクティブを開催してみることをおすすめします。

レトロスペクティブの開催曜日を固定しているチームでは、レトロスペクティブの開催日について奇数日は削ぎ落しの日、偶数日は改善項目追加の日と設定すると1:1の丁度良いバランスとなるでしょう。

3. 点数をつけさせることでメンバーの意見を吐き出す

何度かレトロスペクティブを実践すると、Keepの確認が形骸化していってしまう経験がある方も多いのではないでしょうか？私はスクラムチームのメンバーに「Problemはありますか？」「他に意見がある人はいますか？」と質問しても意見がなかなか出ないことを経験しました。

そこで、私が実践していることは、Keepの確認を行うときは100点満点で点数をつけさせることです。メンバーは100点満点とは言いづらく、そこそこの点数と課題事項が出てくるようになりました。

また、断定するテクニックも非常に有効です。

スクラムチームのメンバーが悩みや不満を抱えていそうであれば、そのメンバーのロール上、どのような状況なら、どのような苦痛を抱えるかを事前にシミュレーションしメモにまとめておき、レトロスペクティブのタイミングで「このような状況であなたはこのロールだから、○○を待つことに困っているんでしょ」などと断定してあげることで感じ方やストレスを確認することができます。またこちらの断定が外れていたときは、具体的に何に困っているかを発言してくれるようになります。

このように、Keepが形骸化してしまっているときは点数をつけさせることと、相手の状況とProblemを断定するテクニックが非常に有効です。是非お試し下さい。