こんにちは、kintoneチームの小林です。
みなさんは、日々行なっている業務を改善するために、どんな活動をしていますか?わたしが所属するkintoneチームでは「ふりかえり」という活動をとても重視しています。ふりかえりとは、今まで行なってきた業務を思い出して、今後取り組む活動を考えることです。
この記事では、kintoneチームのふりかえり活動と、その効果について紹介したいと思います。
ふりかえりとKPT
kintoneチームでは、KPTという手法を用いてふりかえりを行なっています。
- K(Keep)は、よかったこと
- P(Problem)は、問題だと感じたこと
- T(Try)は、KやPを踏まえてこれから取り組みたいこと
を意味しています。
kintoneチームは、自分たちで作ったサービスを自分たちの業務で使っており、ふりかえりもkintone上に作成した「KPTアプリ」を使って行なっています。
以下の画像は、実際にKPTアプリに登録された、Problemの内容です。KeepやProblemの内容、各自が考えたTryの案、チームで決定したTryが書かれています。
ふりかえりの進め方
kintoneチームでは、以下の3つのステップでふりかえりを進めています:
1. 各自がKPTアプリに内容を登録する
ふりかえりが始まる前に、各メンバーがK(Keep)やP(Problem)と、それに紐づくT(Try)の案を「KPTアプリ」に登録します。
2. 登録した内容をサブチーム内で議論する
3つのサブチームをつくり、各自が登録したKPTの内容について議論して、Tryを決定します。kintoneチームには現在12人のメンバーがいます。いきなりチーム全体で議論してしまうと、長い時間が必要になってしまいますし、大人数の前では意見が出にくい傾向があります。このため、まずは小規模な単位で議論することにしています。
3. 議論した内容をチーム全体で共有する
サブチーム内で議論した内容をチーム全体で共有します。もちろんこのタイミングでも、意見があれば全員で議論することができます。また、前回のふりかえりで設定されたTryの進捗も、この場で確認します。
ふりかえりは2週間ごとに行なっています。あまりに期間を空けすぎると、その期間にあったことを思い出しにくくなったり、T(Try)が抽象的になってしまったりすることがあるので、頻度を調整しています。
ふりかえりの効果
kintoneチームでは、ふりかえりによってチーム内の様々なプロセスを改善してきました。今まで、800個以上のKeep, 1000個以上のProblemが提示され、500個以上のTryを実行してきました。大小さまざまな内容がありますが、代表的な例を挙げてみます:
開発環境の改善
開発効率に影響する問題は頻繁にProblemに挙がります。その度に、IDEの設定の見直しや、ビルドスクリプトの改善、CI環境のメンテナンスなど、様々なTryが実行されています。
勉強会の開催
挙げられたProblemについて、kintoneチーム全体で知見を高める必要がある場合は、勉強会を開催するTryが設定されます。「継続的デリバリー勉強会」「JUnit勉強会」「ユーザストーリー勉強会」など、多くの勉強会がふりかえりに基づいて開催されています。
KAIZEN合宿
もともと、kintoneには、一日かけて技術的負債を返済する「KAIZEN DAY」と呼ばれる日がありました。しかし一日で行える活動には限界があるといったProblemが提示されたため、泊まりがけで集中して活動を行なう「KAIZEN合宿」が行われました。詳しくは以下の記事で解説されています:
KAIZEN合宿のススメ - Cybozu Inside Out | サイボウズエンジニアのブログ
他チームとの情報共有
kintoneは分散開発されており、東京と大阪にプログラマーが、松山に品質保証のメンバーがいます。今までプログラマーと品質保証のメンバー同士は交流が少なく、お互いの現状や問題点があまり共有できていませんでした。この問題がふりかえりで議論され、プログラマーが松山へ出張し、品質保証のメンバーと現状の活動の共有や問題点を議論しました。
ここに挙げたもの以外にも、細かな開発プロセスの改善が多数行われています。
「ふりかえりのふりかえり」でさらなる改善
kintoneチームでは、今までお伝えしたふりかえりの方法を長い間行なってきましたが、特に最近、今までのふりかえり方法に対する課題も感じるようになってきました。そこで、「ふりかえりのふりかえり」と題して、現状のふりかえり方法の問題点を洗い出し、改善策を考える会議を行いました。
以下の写真は、実際に行われたふりかえりのふりかえりの様子です。ふせんに問題点を書き出しながら、東京と大阪のメンバーで改善案を議論しました。
洗い出された問題点の一部は以下のようなものでした:
- Tryが具体的でないことがある
- Tryに締切がない
- KPTがマンネリ化している
- KeepやProblemの登録数が少ないときがある
これらの問題点について深堀し、改善策を実行することにしました。
Tryが具体的でなかったり締切がなかったりする問題については、サブチームでの話し合いの際にTryの期限を設定し、チーム全体のふりかえりで、期限切れになったTryを確認することにしました。Tryを実行するのが難しいようであれば、別のTryを設定したり、Tryを細かく分割するなどの対応を行います。また、今まで登録された、期限が設定されていないTryについては棚卸しを行い、進捗を確認することにしました。
KPTがマンネリ化していたり、KeepやProblemの登録数が少ないなどの問題については「タイムライン*1」と呼ばれる新しいふりかえり手法を併用することにしました。タイムラインは、期間内に起こったことや感じたことをふせんに書きだし、時間順に並べ、チーム内に共有する手法です。サブチームでのふりかえりの冒頭でタイムラインを行なうことで、各自が期間内に起きたことを思い出しやすくなり、その場でKeepやProblemを発見することができるようになりました。
以下の写真は、タイムラインを行なったときのホワイトボードです。個人ごとにふせんを色分けしており、時間軸上に並べています。
そのほか、サブチームのメンバーが固定化されていたのでふりかえりごとにシャッフルする、今まで使っていた会議室は広すぎるのでちょうどいい大きさの会議室に変更する、といった細かい改善も行われました。
サイボウズ全社に広がるふりかえり活動
もともと、kintoneチームをはじめ、いくつかの開発チームで行われていたふりかえり活動ですが、現在では、サイボウズの様々なチームが導入するようになってきています。最近では特に、人事の採用チームや面接官のグループが、KPTに基づいたふりかえりを行なっています。また、kintoneチームのふりかえりを見学する人も、開発チーム内外問わず、増えてきています。
kintoneでは既存のアプリを再利用して、新しいアプリを作成することができるので、各チームごとにKPTアプリを簡単に作成することができて、とても便利です(宣伝)
おわりに
kintoneチームで行われているふりかえり活動について紹介しました。
ふりかえりは、さまざまな改善のもととなる有意義な活動です。この記事を読んだみなさんが「ふりかえりをやってみたい!」「今やっているふりかえりをさらに改善したい!」と思っていただけたら、とても嬉しいです。
*1:出典: アジャイルレトロスペクティブズ 強いチームを育てる「ふりかえり」の手引き https://www.amazon.co.jp/dp/4274066983