チームとして成果を出すために情報共有と振り返りを

―なぜエンジニアにとって情報共有、振り返りが大切なのですか？

前提として我々は複数人のチームで開発をしているので、チームで成果を出すということが、ビジネス面でも組織としても求められています。個々の能力も大事ですが、個人が困っていることの理解や助け合い文化の構築、チームを継続的に強くするために、情報共有や振り返りが必要だと考えています。

例えば、あるプロジェクトで、今月中にシステムの内部結合まで仕上げるスケジュールが組まれた時、2人は終わっているけれどＣさんはまだ機能実装が想定より重く、期日までに仕上げられないというシーンで、先に終わっているＡさんとＢさん他のチームメンバーが手伝えるような情報共有の場を設け、課題の抽出がちゃんとできるようにするという話です。

その情報共有と振り返りの場として、KPT会議を週1回、ウィークリーで行っています。

―KPT以外にも情報共有や振り返りの会議はありますか？

グループやチームによっても違いはありますが、私の例で言うと、朝会をチーム単位でやるようにしています。今日やること、昨日やったこと、困っていることなどの共有を15分～30分ほどデイリーで行っています。振り返りに関してはチームごとに1weekで行い、その週の振り返りをしています。

また、部会も毎週金曜日に行っています。私が案件の窓口を担当しており、経営層や他部門からの情報共有が目的です。表に出ていない情報があるので、それをメンバーに落とすことによって、どんなことがビジネス面で求められているのか、何を必要とされているのか、何が案件として落ちてきそうなのかを把握するための場です。部会ではお互いのKPTの横連携も行っていて、Problem＝課題や、Try=解決方法を共有し合うなどのコミュニケーションもとっています。

KPT会議の進め方と注意点

―KPT会議はどのように行われていますか？

KPT会議の時間は60分。まずは先週のT（Try）＝次にやること、挑戦することが達成できたのか、それとも持ち越しなのかの振り返りを行います。これをやらないことには、改善できているかどうかのチェックができません。

次に、K（Keep）＝良かったことや今後も続けること、メンバーへの感謝、P（Problem）＝改善したいこと、問題、課題を挙げる。だいたい5分くらいでそれぞれ記入してもらい、ファシリテーターが読み上げていきます。その後、それらを踏まえてTryを出します。Tryを出す時間が短いと雑なTryになってしまうので、必ず30分以上とるように注意しています。

また、KPT会議では個人攻撃はしないこと、個人の問題はチームの問題として捉えること、明るく楽しくやってねということを注意点として伝えています。

「個人の問題はチームの問題」真剣にチームで考えるように、Problemを出すときに根本的な鋭いProblemが摩擦を恐れず出せる雰囲気を作るのが大事ですね。性格上発言しづらい人もいるので、「発言のない人にも想いあり」というのをちゃんと伝えて、ファシリテーターが引き出すように心がけてもらっています。

―KPT会議でMiroを使用している理由とメリットとは？

リモートが主流になる前は、ホワイドボードをK、P、Tのカテゴリーで区切り、そこに付箋をぺたぺたと貼り付けていく形で行っていました。時世的にリモートが多くなったタイミングで適したツールを探し、Miro（オンラインホワイトボードツール）を採用。色々と改善しながら進めてきました。

アナログの場合、付箋を貼る際に3人ほどしかホワイトボードに行けないのですが、Miroでは全員で一斉に行える利点があります。対面で人の目を見ながらKPTをやった方がコミュニケーションの連携はしやすいので、本当はそうしたいのですが、皆が同期的にできるツールとしては、今のところMiroが一番適切なんじゃないかなと思っています。

KPTを導入する理由と目的

―なぜKPTを導入しているのですか？

単純に色んな現場で採用されていて、振り返りの手法として経験しているエンジニアが多いのがKPTなのかなと思います。でも、たまに違うこともやっていますよ。ファシリテーターが点で質問したことに答える「チェックイン」という方法もあり、何かリーダーやメンバーから議題があった時に実施すると新たな気づきがあり、雰囲気も変わります。基本的にはKPTのほうがProblemを継続的に出しやすいし、翌週にも振り返りやすいですね。

KPTでは取りこぼしなく効率的に振り返りが行えます。Tryはチームの改善であり、これがないと開発は進んでも、本当は歯がゆくて改善したいという部分をチームとして出す場がない。でもTryを出すことで、1週間で次の週までにタスクを消化し、1つでもチームを前進させ強くすることができるので、仕組み化するという面でも優れていると思います。

―KPTを行う目的とは？

大きく3つあります。1つ目は"チームとプロダクトを改善し強くする"こと。ProblemからTryを出したり、時にはKeepからさらに良くするためのTryを出したりします。それでチームの開発やプロセス、環境が改善されていきます。プロダクトも良くなるので、案件を受けて上から降りてきたものを消化するだけではなく、自らPBI（プロダクトバックログアイテム）を作って、自分たちもタスクを作っていると自覚してもらうのは、前向きな効果があるかなと思っています。

2つ目は、"定期的な観測をチームでしっかりチェックする"こと。課題がそのまま置き去りにならないように、点を決めて1weekで行っています。

3つ目は"チームビルディング"。これは私が特に強く思っている部分で、KPTは楽しくやってねという話です。チームの信頼関係も上がりますし、半分真剣、半分ふざけるくらいでとお願いしています。「(Problem)運動不足で太った」とか「（keep）趣味の山登りに行けた」とかプライベートの話題も出ますし、お互いがどんな人物なのかを知ることにも繋がっています。

KPTがエンジニアにもたらす効果

―KPT会議を通してチームやメンバーに変化は起こりましたか？

私のチームでは業務委託のエンジニアも多く参画しており、プロパーと業務委託の比率は3:7ほどです。通常、業務委託のエンジニアは上から降りてきたものをこなすパターンが多いですが、我々のチームでは、チーム開発として自分たちから改善のチケットを出せる。

「自分たちもプロダクトに思いをのせていいんだ」、「より強くするようなタスクを作ってもいいんだ」と、業務委託のエンジニアも好感が持て、チームの一員として、Problemから出たスキル不足の部分をチームで勉強会しようということもあるので、全員が"自己成長ができる場所"という認識を持ってもらえていると思います。

あとは、KPTの場があることにより、言いづらいことが発言しやすくなる効果もありますね。口では言いにくいけれど、付箋だと勇気を出せることもあったりしますので。また、KPTの場におけるコミュニケーションで、共通趣味がわかって交流が広がったりと、プライベートの繋がりも出てきたりしています。付箋で出すことによって可視化もされますし、なんでも言いやすい雰囲気を作ることで、お互いの仕事だけでは気が付けなかった部分も知ることができる。だから、楽しくふざけてねというのは伝えています。

何度も繰り返し伝えていますが、チームビルディングがすごく重要なんです。一人でずっと喋っているリーダーがいたり、ハレーションを生んで個人攻撃するメンバーがいて萎縮したりすると、その人だけのTryになってしまいます。そういう雰囲気にしない、そういう人に対しても改善できるようにチームを作っていくのが大事だと思いますね。

T字人材と信頼関係の補強でチームの底力をあげていきたい

―今後の展望をお聞かせください。

エンジニアはそれぞれ、サーバーサイド、フロントエンド、インフラのように得意領域を持っている人たちが集まって開発をしています。チームを強くするという意味で、勉強会やハンズオンを行ったり、講師を呼んだりして、Ｔ字人材を増やしていきたいなという思いがあります。

例えばサーバーサイドが得意な縦軸だけど、フロントエンドもちょっとできるなど、横軸にも得意領域が広がるイメージです。そうするとチームも強くなるし、誰かが休んでいる時や困っている時に手伝える人がいるので、チームの開発がどんどん早くなる。そういう方向を目指せればいいなと思っています。

KPTをやったり情報共有を強めていったりと、お互いが顔を合わせる機会が増えて、今後より一層信頼関係が築けるといいですね。ちょっと幼稚かもしれませんが、学校に行くのが楽しいみたいな世界観があればすごく嬉しいなと。そういう雰囲気ができれば、会社に行くのも業務開始するのも苦じゃないでしょう？　仕事するには楽しいほうがいいと思うので、そういった環境を与えていきたいですね。