スクラム開発のレトロスペクティブを多国籍なR&Dで最適化した話

こんにちは。R&D事業部のユンインヨンです。
早速ですが本日のテーマ、R&Dで行っている振り返りについてご紹介したいと思います！

振り返りとはなんでしょう

皆様がすでにご存知の通り、振り返りとはこれまで行われてきた物事の一連の流れを総括することです。
R&Dではこの振り返りをプロジェクト毎に行っております。
プロジェクトを進めながら感じた問題点を洗い出し、次のプロジェクトでは同じミスを繰り返さないように改善策について議論します。
更に改革できることがあると、提案してみんなで話し合って決めて行きます。

このような振り返りを、以前は一つのプロジェクトが終わる度に行っておりましたが、
約1年前からR&Dではスクラム開発を導入し、スプリント単位で振り返りを行うことになりました。
スクラム開発とスプリントについては以前の記事をご参考ください。＞＞ 開発手法の改善とスクラム開発

スクラム開発方法では振り返りがレトロスペクティブという形でしっかりと定義されています。
R&Dではこのレトロスペクティブをどのように導入して試したか、皆様へ噛み砕いて説明します。

R&Dでのレトロスペクティブの導入

まず、R&Dでは世の中に紹介されているレトロスペクティブの代表的なKPT法を選定いたしました。

プロジェクトメンバーの全員が、スプリント終わりに振り返って感じたKeepとProblemを共有し、みんなでProblemの解決方法や新しく挑戦することを話してTryを決めていく方法です。
一般的には、各自の意見を記述した付箋をホワイトボードに貼り、アナログな手法でKPTを共有することが多いです。

ですが、R&Dには「外国人が多い」「新卒間もない若手社員が多い」という特徴があり、上記のままレトロスペクティブを適用させるのが難しかったのです。それを踏まえ、以下のやり方で導入を試みました。

外国人が多いことによる問題と対策

R&Dでのやりとりは日本語で行われますので、付箋にKPTを書く手法だと外国人も日本人も「書きづらい」「読みにくい」という問題がありました。
更には、書いた内容について口頭で説明してもらうと、「聞き逃す」「わかりにくい」「伝わらない」「後でまとめづらい」などの問題もありました。
そのためとあるプロジェクトでは、付箋に書かずに自分の考えを事前にドキュメントにまとめ、KPTを行うときにみんなと読み合わせる方法を導入してみました。このやり方にしたことで、外国人は自分の意見を正確に伝えることができるようになり、自信を持って発言できる機会が増えました。また、内容が事前に記録として残せますので、振り返りの内容を後からまとめるコストを減らすことができています。

新卒間もない若手社員が多いことによる問題と対策

意見を言うことを遠慮してしまいがちな新卒社員の立場などを踏まえ、KPTを出すときには他の人と相談せずに自分一人で振り返りを行うようにしました。
他人の意見を聞くとその意見に寄り添ってしまう場合が多くなってしまうので、素直に自分の意見が言える環境を作ることを第一にしたためです。
実際に、新卒入社したばかりの社員にこの対策がどうだったか尋ねてみたところ、レトロスペクティブの際に他のメンバーと同じ問題を感じていたことが分かり、気楽に意見が言えたそうです。
また、素直に自分の意見を述べることができるので、当人がどのようなところを苦手にしているか周囲が分かるようになり、若手社員の個性把握に役立てることができました。

レトロスペクティブを進めて直面した問題

このレトロスペクティブを取り入れて1年。上記の内容だけでなく、色々と試行錯誤しながら多くの問題を解決してきました。しかし、まだまだ改善するところはたくさんありますし、次々と新しい問題に直面しています。
下記は実際に私が参画したプロジェクトがどんどん忙しくなっていく中で新たに感じた問題です。

・プロジェクトに対する正確な問題を見つけられない
・間違った問題を認識してしまったため、正しいTryを出すことができない。
・Tryを実践する時間がない

チーム全員が同じ問題を感じている場合、個人ではなくプロジェクトの進め方に問題がある可能性があります。それを一人で解決しようとしても、根本的な解決策にはならないので、正確なTryを定めることが難しいことが分かりました。結局、「何とかしてみます」のようなTryになってしまったり、レトロスペクティブの場でTryが決まらずに「後に時間を作って相談後改善策を探します」のようなTになってしまったりしました。

また、プロジェクトが進むと開発体制は成熟していきますが、逆にこれまでは見つからなかった新しい問題に直面することが多くなり、そのままのやり方ではレトロスペクティブを行うことが難しくなっていきました。

新しいレトロスペクティブ

このような問題にぶつかった私達R&Dは、今まで通りのレトロスペクティブのやり方を変え、改善に取り組むことにしました。
その結果、R&Dで改善を行ったレトロスペクティブは下記の内容になります。

・チームメンバーは一人ひとり自分自身で考えたKeepとProblemを出す。
・全員のKeepとProblemの中で多数決をとり、もっと議論したい、解決したいと思ったものをPICK UPする。
・選んだKeepを発展させるため、Problemを改善するための議論を行う。これをTryにする。
・最後に時間があれば、そのレトロスペクティブ自体の進行や内容がどうだったかの振り返りを行う。

このやり方に変えてからは、皆が選定したKeepとProblemに集中することができ、より多くの改善策をスムーズに議論することができるようになりました。
また、プロジェクトが忙しくなって後回しになった課題や、全員で決めないと進められなかったタスクがレトロスペクティブを通すことによって一気に進められるようになりました。

一方で、このやり方だとレトロスペクティブの内容がプロジェクト全体のことに集中しがちになってしまうこともわかりました。そこで個々人の成長のため、一人ひとりがスプリント期間内に挑戦する内容を決め、それをチーム全体へ共有を行うことも追加しました。このことにより、チーム全体が取り組むTryと個人が取り組むTryが明確になり、より有効的なレトロスペクティブができるようになりました。

R&Dが考えるレトロスペクティブとは？

スクラム開発方法を導入した当初にレトロスペクティブを行ったときは、世の中に紹介されているKPT法をそのまま適用させれば問題なくレトロスペクティブを進めることができました。
しかし、何回もレトロスペクティブを繰り返していく中で、それだけでは足りないことに気づきました。
そこでR&Dではレトロスペクティブの際に以下の内容を念頭に置くことにしました。

・プロジェクトの特徴（運用開発か、スクラッチ開発かなど）
・参加したメンバーの特徴（新人が多い・外国人が多いなど）
・スプリント時期（始まり・中間・終わりなど）

このような状況に合わせて「最適化したレトロスペクティブ」を行うことが最も大事だということです。
何事もフレームに則って進めることではなく、組織ごと、業務ごとに柔軟に対応していく必要があると、レトロスペクティブを行っていく中で改めて実感させられました。

最後に

プロジェクトを進行していくと、どうしても実務で忙しくて、ついつい振り返りを軽視するようになってしまうことがありますが、私はしっかりと振り返りを実行することほど重要なことは他にはないと思います。
過去の自分のミスや問題を探してその改善方法を工夫するからこそ、次の一歩を踏み出せるのだと思います。

全研では毎週、毎月、半年、毎年など…いろんなターム・節目で振り返りを行い、素直に自分と向き合ってから前に進めるような取り組みを行っています。
そのおかげで、私は過去のことを振り返ってどのようなところで間違ったか、今後自分はどんな振る舞いするべきかなどがわかるようになりました。

会社の理念に従ってR&Dでもプロジェクトについて振り返りを行っています。
当たり前なことかもしれませんが、実は多くの時間を用意して振り返りを実施することはかなり難しいことなのです。
しかし、その分得られることがたくさんあることを私たちはわかっています。
ぜひ皆様も今後しっかり自分を、お仕事を振り返ってみたらいかがでしょうか。

以上R&Dのインヨンでした。
ありがとうございます。