2019年の施策を振り返る。振り返りフレームワークKPTAの実施例
あららです。この記事はZOZOテクノロジーズ #4 Advent Calendar 2019の25日目の記事です。昨日の記事はalpha_gotoさんの「データサイエンスの新着情報を収集するために使っているサービスたち」でした。こちらの記事も是非ご覧ください。
今回は2019年の振り返りということで、2019年チームで取り組んでいた振り返りフレームワーク「KPTA」の話をしたいと思います。
KPTA
KPTAとは「Keep（続けること）」「Problem（問題点）」「Try（試したいこと）」「Action（行動）」の4つの視点を持つ振り返りフレームワークです。よく耳にするKPT（ケプト）にActionを加えたものとなります。
チームの状況
はじめに実施しているチームの状況を紹介します。
・人数6名のiOS開発チーム
・エンジニアキャリアは豊富なメンバー（一番短くて5年程度）
・全員2019年からプロダクトに配属（買収や新入社員）
・他チーム（BE、デザイナーなど）とのやりとりは頻繁に発生
・他チームの多くは拠点が離れている
たくさん書こうと思いましたが、「全員2019年からプロダクトに配属（買収や新入社員）」で大体雰囲気が伝わると思います。出来たばかりのチームで運営しているのは大規模なサービスです。ドメイン知識も何もない状態でのスタートとなります。もっというと僕がリーダーになったのが5月で、今のチーム体制になったのは夏頃です。まだ4ヶ月程度しか経っていない生まれて間もないチームです。
KPTAで期待している効果
僕はリーダーという役割で「新しく作られたチームでどのようにプロダクト開発を行うか」を考えるわけですが、出来たばかりのチームで問題は山積みです。
・Objective-CとSwiftが入り混じった環境
・整っていない開発手法
・失われたドメイン知識
・よくわからない静的ファイル
・etc
列挙するとたくさんあるのですが、こんな状況でネイティブアプリ開発チーム以外のメンバーが別拠点にいるわけですから、困難なことは目に見えています。短期的に案件をこなす必要があるのはもちろんですが、力任せで目の前の開発をしていると長期的に破綻します。状況を良くしてプロダクト開発に集中できる環境にしなくてはいけません。KPTAは以下のことを期待して実施しました。
・問題を洗い出す
・課題を共有する
・目的と目標を共有する
・行動を明確にする
KPTAを通して、「メンバーそれぞれが課題を把握し主体的に行動する」ことが出来ている状態を目指しました。
なぜKPTでないのか
KPTをやる上で懸念点がありました。現状を考えると「今の状況は問題が先送りになった結果だろう」ということです。KPTでありがちな問題として、Tryとして挙がったことが実行されないということがあるので、同じ結果になる恐れがあります。そこで、Actionを追加してTryを行動まで落とすというKPTAフレームワークを採用しました。
実施の流れ
それではKPTAの実施の流れに触れていきます。KPTAは2時間とし以下の流れで行なっています。
1. グラウンドルールの確認
2. 前回のKPTA確認
3. Keepを付箋に書く（5分）
4. Keepの発表
5. Keepの整理
6. Problemを付箋に書く（5分）
7. Problemの発表
8. Problemの整理
9. Tryを付箋に書く（5分）
10. Tryの発表
11. Tryの整理
12. Tryの選択
13. Actionに合意
すべてを説明すると長くなりすぎるので、ピックアップして紹介します。
グラウンドルール
KPTAを実施する上で、参加者が守るルールを決めています。僕が実施する上で決めたルールは以下の5つです。毎回KPTA実施時に確認しています。
1. 人の話をさえぎらない
2. 一人で話すぎない
3. 積極的に参加する
4. 時間を意識する
5. 原因は追求する、責任は追求しない
参加者全員が当事者意識を持つことが重要です。それには発言しにくい雰囲気を作らないことが重要だと思いルールを定めています。
付箋を使用する
進行の仕方はたくさんあると思いますが、KPTそれぞれ5分間使って付箋に書く手法をとりました。事前にオンラインのドキュメントに記入して持ち寄るなども考えましたが、以下のような懸念点を回避するため付箋にしています。
・忙しくて事前に書かない（書き忘れる）
・1、2個記載して終わりにしてしまう
・周りの意見が見えるため同じ意見は書きづらい
・特定の人しか書かない
付箋に書く時間になると、その場で参加者が一斉に書き始めます。付箋に書くときは無言です。タイマーを使って5分間厳密に計ります。今回は詳しく書きませんが「Problemに行動の否定は書かない」などの書き方も定めています。
書いた付箋の発表
書いた付箋を発表していきますが、「書いた本人が読み上げながらホワイトボードに1枚ずつ貼っていく」というやり方をしています。
一斉に貼って、ファシリテーターが読み上げていく方が早いですが、自分の意見として強く持って欲しいので、本人が読み上げる形式をとっています。
進めていくと必ず同じ意見が出るので、同じ人が一度に発表してしまうと、後になった人は言いにくい雰囲気なってしまいます。全員に同じくらい発言して欲しいので、1枚ずつ順に貼っていくやり方をしています。時間の短縮よりもKPTAを実施する上での目的を達成しやすい方法を選択しています。
内容はボカシますが、イメージはこんな感じです。
Tryの整理・選択
全員が発表し終えたら、どんな意見が出たか全員で整理するのですが、特に Tryでは「Problemに対してTryが出ているか」を念入りに確認します。問題提起だけして、解決策がないと何も改善できません。また、Tryは全て実行することは難しいので、全員で話し合って「効果があり自分たちが具体的に行動出来そうな物」を選択していきます。選択したものがActionになります。
Actionに合意
Tryの選択が完了したら実際のActionを考えます。もしTryの解決方法が明確でなければ、この段階で「どうやるか」は明確にしておきます。
また、ここで担当のアサインを行います。Tryを出した人が担当になるわけではありません。それをやってしまうと「言うとやることが増える」状況になってしまうため意見が出づらくなる可能性があります。
アサインは「知見を持っている人」「役割として適任の人」「やりたいモチベーションがある人」などで決めていますが、ここで重要なのが「同意」ではなくて「合意」ということです。誰か1人の考えではなく、お互いの意思が一致していることを示しています。達成のために当事者意識を持ってフォローしようという意識を持ってもらいます。
ここで決まったActionは、毎週1回の定例で担当になった人が進捗を報告します。
KPTAでの効果
KPTAを実施して実感した効果です。
1. 活発に意見が出るようになった
2. チームが抱えている問題が洗い出せてきた
3. 課題解決のスピードが増した
1回のKPTAでKeep、Problem、Tryそれぞれ30個くらい出てきます。「アーキテクチャの課題」のようなものから「ホワイトボードが足りない」のようなな環境のことまで様々な問題点が洗い出せていると感じます。また、全員でActionを決めて課題解決に取り組むので「問題が先送りになる」という現象に改善効果が見られています。
Actionに人がアサインされるため、目的である「メンバーそれぞれが課題を把握し主体的に行動する」も少しずつ達成に近づいていると感じます。冒頭で出た「山積みの問題」は解決に向かっています。
KPTAの改善
上述のような手順でKPTAを実施していますが、すでにいくつかの改善点があるので紹介します。
1. 開催頻度
2. 付箋からオンラインに移す手間
3. 日本語の記述
開催頻度
最初はアプリのバージョン毎にKPTAを実施していましたが、大規模な機能追加、頻繁なマイナーバージョンアップなどで開催感覚がブレるため、現在は「第４金曜日」など月に1回としました。
付箋の管理コスト
付箋に書く形式でKPTAをしていますが、出来てた案をオンラインに移行するコストがかかります。付箋のメリットを残しつつ、オンラインでリアルタイムでKPTAが実施できないか、Webサービスを試しています。12月から試験運用予定です。
日本語の記述
これも付箋でやる問題ですが、日本語が難しいと言う問題です。現在のチームは母国語が日本語ではないメンバーもいます。特に漢字が難しいという意見が出ました。「何語はなんでも良い」や「英語に統一」「かんじはつかわなくてよい」みたいな案がありますが、変換があれば改善しそうということで、こちらもWebサービス導入で解決しないか試す予定です。
まとめ
今回はKPTAを紹介しました。振り返りフレームワークの導入はチームビルディングとして非常に有効だと思います。今後はKPTA自体の効果測定も行い、もっと定量的なアプローチを続けていきたいです。
課題を中心に話を進めてたのですが、Keepが非常に多く出るチームです。今のチームメンバーは前向きに解決に取り組む実力者が揃っており、他チームも非常に協力的で改善のスピードが早いです。2019年このチームでプロダクト開発が出来て楽しかったです。2020年はより加速して課題解決できると思います。