Qiita×Findy記事投稿キャンペーン 「今の開発組織でトライしたこと・トライしていること・トライしようとしていること」 - Qiita に向けて書いた記事で、このうちトライしようとしていることについて書いてみたいと思います。
なお、今の「システム開発組織で」とありますが、この記事はあくまで私の個人的な感想・視点に基づいた個人的な意見であり、組織や所属するチームを代表するものではございません。
また、過去の複数の開発組織やプロジェクトを思い返しながら書いているため、必ずしも「今の」開発組織の話にフォーカスした話ではありません。
予めご了承ください。
これまでの開発をふりかえってみて思っているふりかえりの難しさ
背景として私は現職で4社目になり、いくつものプロジェクトに参加してきました。
参加したプロジェクトについては途中で抜けてしまったものの（現場都合や、組織上の再配置など原因は多岐にわたります）、最後まで参加できているものについては比較的うまく終わることが多いように思っています。
一方で、プロジェクトとして納期やコストを守りつつ機能やビジネスニーズを満たすような成果は出せているものの、いろいろな課題が見つかることは多いです。
例えば、コミュニケーションですとかスケジュールを守るために労働時間でカバーするなどがあり、プロジェクトを完了することはできていても、その過程での課題を解決できなかったことも多いです。
そのためふりかえりを行うことは非常に重要だと考えています。
ふりかえりはプロジェクトの成果を振り返るだけでなく、その過程での課題や問題点を見つけるための手法としてもとても有効であると感じています。
手法に対する課題
一方、ふりかえりの実施はメンバーとしての参加、ファシリテーターとしての参加の両方で場数を踏んできましたが、その中でいくつかの課題を感じていました。
特に期間が長かったもののふりかえりが難しい、と考えています。ファシリテーターとして参加する立場になってからも、期間が長いふりかえりは回数が少なく、またその度に難しいなと感じています。
ふりかえり期間が長いと、その間に起きたことを思い出すのが難しくなります（期間が長い、は1～3か月以上のイメージです）。
その時は確かに問題であったものも、プロジェクト中で解決されたことで忘れてしまい、埋もれてしまうことも多いです。
また、ふりかえりの手法についても課題を感じています。
KPT フレームワークを採用してのふりかえりは多いですが、KPT フレームワークでのふりかえりは個人的に長期間のふりかえりに向いていないと感じています。
理由としては下記です。
- 期間が長すぎてその間に起きたことを思い出すのが難しい
- 期間が長いと付箋がふえて、KPTの性質上Tに対して紐づくK, Pが多く関係性が複雑になってしまう
- 悪い印象のあった思い出が想起されやすく（？）、P ばかりが出てしまうケースが何となく多いように感じる
- 感情や価値観を含んだ意見が出しずらく、ぼやけやすい
なお、KPT フレームワークはスクラムのスプリントなどで、短く見て傾向と対策を考えていきやすいと考えています。
知っている方も多いので学習コストも低いという点から実施しやすい優秀なフレームワークであると思います（後で触れますがふりかえり手法は適材適所であり、ふりかえりの目的に合わせて選択することが重要だと考えています）。
タイムラインによるふりかえりを試したい
タイムラインはふりかえりの一つです。下記の記事がわかりやすいと思います。
ふりかえりのアクティビティ紹介：Timeline #ふりかえり - Qiita
タイムラインは、プロジェクトの進行を時系列で振り返る手法です。
タイムラインでのふりかえりは性質上、どのタイミングで何が起こったか・何を行ったが明確になるため時間軸をもとにふりかえることに向いています。
なので、長期間であっても相対的に物事を並べていくことで、比較的その間に起きたことを思い出しやすくなると考えています。
またタイムラインでのふりかえりは、感情面も含めてこのときに思っていたことを共有することができます。
心境の変化というものは長期視点だと大事だと私は考えています。つらい時期はどうしても物事の進捗などが悪くなりがちです。
そういったものも含めて、要因を考えつつ最終的にうまくいく方向に向かって心境が改善していくというのも大事だと考えています。
一方で私はまだタイムラインでのふりかえりを実施したことがないため、実際にどのような効果があるのかはわかりません。
そのため今の開発組織でトライしたいこととして、タイムラインでのふりかえりを試してみたい、試すぞ！と思っています。
ふりかえりは複数の方法を試していい
ふりかえりというと、私の経験上はどうしても慣れた手法が選択される傾向にあるように思います。
一方で、ふりかえりは目的やターゲティングによって手法を変えることが重要だと考えています。
例えば、スプリントごとの課題を発見していきたいというメンバーが多い場合では YWT ではなく KPT が適しているかもしれません。
それは Problem を確実に発見して改善することでプロジェクトの障壁を取り除きたい、という目的があるからです。
逆にふりかえりで後ろ向きになってしまう場合などもあるかもしれません。
そういったときは一度、自分たちができていることに目を向けもっと伸ばしていきたいことを見つけるために YWT などを試してみて自分たちを見直してみるのもいいかもしれません。
そういったようにふりかえりは向き不向きがあり、これだけでよい！というのはないと考えています。
下記の記事でいろいろなふりかえり手法が紹介されているので、ふりかえりを試してみたいと思った方は参考にしてみてください。
ふりかえりを拡張する「ふりかえりカタログ」 #ふりかえり - Qiita
ふりかえりから向き直りたい
また、ふりかえっただけでなく、今後に生かしていくむきなおりも大事です。
むきなおって現状の先にあるものをさらに良いものに変えていくための分析材料として、ふりかえりが活用できると考えています。
これからも試行錯誤しながら開発組織をリードし、よりよいプロダクト作りやプロジェクトの成功に貢献できるよう、ふりかえりという題材を通じて自分自身・チーム全体の改善につなげていきたいです。