継続的なKPTがチームの夢中を生み出す
人間が夢中になるメカニズムと開発チームの成長
私たちが何かに夢中になる瞬間、それはしばしば困難とその克服による小さな成功体験のループが関わっているのではないでしょうか。 特に子供の頃は大小さまざまな新しい挑戦をする際に、このプロセスを経験し、そこから熱中できる・夢中になれるものを見つけているように自分の子供達をみて感じています。 この心理的メカニズムは大人になっても変わらず、小さな成功体験のループを回し続けることが、人が夢中になって打ち込める環境を作り出すと考えています。 一般に言われる「勢いがある」「モメンタムを感じる」チームというのは、一人ひとりが日々の仕事に夢中になっている状態なのではないでしょうか。 この記事では、私たちの開発チームがどのようにしてこのループを活用し取り組んでいるかを紹介します。
開発チームと「夢中になる」ループ
先に述べたように HQ 開発チームでは、小さな成功体験のループがチームのパフォーマンス向上に重要だと考えています。 創業後の開発チーム発足から、このループを形成し維持するために KPT という振り返りのフレームワークを積極的に利用してきました。 KPT は、Keep (継続すべきこと)、Problem (問題点)、Try (改善策) の三つの要素を基に、定常的な PDCA サイクルを回していく手法です。
Scrum 開発と KPT の基本
以下は ChatGPT にまとめてもらった Scrum と KPT の説明です（HQ 開発チームでは LLM を日々フル活用していいます。こういった説明は本当に Web 検索の出番が少なくなってきました） HQ で実施している Scrum と KPT の内容とも一致しています。
Scrum 開発は、アジャイル開発のフレームワークの一つであり、継続的かつ柔軟な製品開発を可能にするために設計されています。Scrum では、プロジェクトを短い期間（通常は 1〜4 週間）のスプリントに分割し、各スプリントの終わりには成果物をレビューし、次のスプリントで取り組むべき改善点を特定します。このプロセスにより、チームは定期的に成果を出し、プロジェクトの方向性を素早く調整することができます。 Scrum の中心には、透明性、検証、適応の 3 つの柱があります。これらはチームが情報を共有し、プロジェクトの状況をリアルタイムで評価し、必要に応じて計画を修正することを促進します。Scrum チームは、プロダクトオーナー、スクラムマスター、そして開発チーム自体から構成されます。プロダクトオーナーは製品のビジョンを持ち、優先順位を設定します。スクラムマスターは Scrum プロセスを促進し、障害を取り除く役割を持ちます。開発チームは、スプリントの目標を達成するために協力して作業します。 KPT は、Scrum のレトロスペクティブフェーズで特に有効なツールであり、Keep (継続すべきこと)、Problem (問題点)、Try (試みるべき新しいこと) の 3 つの観点からチームの活動を振り返ります。Keep では、チームが良いと感じた実践や成果を確認し、継続することを決めます。Problem では、遭遇した問題や改善が必要な点を特定します。Try では、特定した問題を解決するための新しいアプローチや実験を提案します。このプロセスを通じて、チームは継続的な改善を促し、次のスプリントでのパフォーマンス向上に繋がるアイデアを形成します。 このように、Scrum 開発と KPT は相補的な関係にあり、チームが目標に向かって効果的に前進するための枠組みと具体的な実践方法を提供します。この組み合わせにより、開発プロセスの透明性が高まり、チームはより迅速に改善策を実施し、プロジェクトの成功に貢献することができます。
振り返りの方式としては他にも良く似たフレームワークがあるかと思います。 手法自体に特に目新しさはないのですが、ありきたりな方法でも取り組みの際の意識の持ち方とちょっとした工夫で、自転車を漕ぎ始めたらどんどん加速していくように改善のループが回りだすと感じています。
Keep: 継続すべき良い習慣
HQ 開発チームでは、Keep の段階で、小さな成功体験や、チームにとってプラスになったことを積極的に共有しています。 これには、個々の成果はもちろん、チームメンバーの貢献や、生産性向上に繋がった小さな変更など、さまざまなことが含まれます。
数件例をあげると:
- ユーザーサポートチームより報告されたバグ対応が早かった
- コードのリファクタがきっちり決まった
- 要件が複雑で難航していたプロジェクトが前進した
- Visual Studio Code のプラグイン導入で効率が上がった
- ChatGPT でいい感じの変数名をつけられた
など大小さまざまな個々人、チームの成功が上がってきます。
習慣としてとして今後も繰り返していきたい Keep については次回以降の KPT でも残しておき、意識し続けられているか、継続できているかの確認を行います。
習慣化して定着したと皆で合意できるものについては、Keep を殿堂入りさせてチームの文化として残していきます。（開発チームのカルチャー紹介ページにも、これまで殿堂入りした Keep の一部を載せています）
Problem: 課題の特定と共有
日々の開発で直面する問題点や、コードの改善点、読みにくいドキュメント、長期間直せないでいるバグなど、様々な課題を Problem の段階で明らかにし、オープンにチーム内で共有することが重要と感じています。 問題を直視して言語化するのは時に勇気がいる作業ですが、「差し込み作業が多く予定されたタスクの進捗が遅れた」だったり「動作確認の漏れでエラーが発生してしまった」や「xx のコードが負債化している」 など少し踏み込んだ問題点を挙げるように意識しています。 ただ、踏み込んで問題を提起するにしても、Scrum のスプリントの短い間隔（HQ では 2 週間が１スプリント）で毎回行っていると自然と心理的負荷は軽く、驚くような大きな問題が引っ張り出されることなどは起きないのが創業からの経験則です。 また Problem 検討の際には、個人批判ではなく具体的な問題に対する批判をすることを前提条件として望んでいます。
Problem のステップでチーム全体で課題を認識し、解決策を見つけるための土台を作ります。
Try: 改善策の提案と実行、および過去の Try の再評価
Problem で挙げられた課題に対して、Try の段階で具体的な改善策を提案し、実行に移します。 例:
- Problem: 差し込み作業が多く予定されたタスクの進捗が遅れた
- -> Try: 差し込み作業の緊急度を評価する基準を設定して、本当に重要なものだけを差し込むようにする
- -> Try: 依頼されている作業をローコードツールで機能として実装する
- Problem: 動作確認の漏れでエラーが発生してしまった
- -> Try: エラーになった条件をテストケースに追加する
問題・課題のサイズが大きく中長期的な投資が必要なものは別途プロダクトのロードマップで管理し、比較的短期で改善可能で具体的な取り組みが可能な Problem に対して Try を設定するようにしています。 Problem は未解決であればスプリントをまたいで残り続けるので、取り組みへの意識を向ける反面、 ずっと未解決の Problem が残り続けると「オオカミ少年」のように誰も気にしなくなったり、チームの精神衛生上も良くないので、「重要度・取り組み可能性」を考えて Problem を整理するのをチームでは重視しています。
方法もわかっていてやれば解決可能なものについては、「即断・即決・即実行」の行動指針に従い、次のスプリントで積極的に取り組みます。 KPT のミーティング後 １ 時間以内に実行してしまうものもあります。 すぐに終わらないものでも、次のスプリントの計画時にバックログのタスクの重要度と量を考えつつ、計画に組み入れたものはスプリント内に時間を取って実行するのを推奨しています。
良い循環の創出
取り組んだ Try と解決された Problem は、次のスプリントの KPT で Keep に上がってくることが多いので、チームで認識した問題・課題に対して取り組んで乗り越えたという実感が生まれ、新たな Problem に対して向かっていくモチベーションが生まれるというループにつながっています。 チームは日々の小さな負債を解消し、「次はもっとできるかもしれない」という自信を蓄え、少しずつ自分たちの基準を上げていくループが KPT によって生まれています。 継続的な PDCA により各自が実感することで、一人ひとりが自分の仕事により夢中になれる環境を作っていく。蓋を開けてみればごくありきたりなことを言っているだけなのかもしれませんが、それこそが本質なのではないかと創業以来の取り組みを通して思っています。
最後に
今回の投稿では、KPT を利用して小さな PDCA ループを回し続けることで、チームの成功体験を積み重ねて個々人が夢中になれる環境を作り出していく取り組みについて、HQ で実践している具体を通して紹介させてもらいました。 HQ 開発チームでは一緒に日々の成長を共にする人材の募集をしています！ HQ では初期プロダクトとして社員の個別最適なリモートワーク環境の構築を支援する「リモートHQ」を開発、運用していますが、今後更にプロダクトは増えていく予定です。
