※この記事は hey アドベントカレンダー2020 22 日目の記事です。
一年の終わりにやることといえばなんでしょうか？
...
そうですね、振り返りです。
今年いくつかのプロジェクトに関わりまして、プロジェクトが終わるごとに毎回プロジェクトの振り返りをしてきました。
なんとなくこんなことを考えながら振り返りを実施するといいんじゃないだろうか、というのが見えてきたところでもありますので、プロジェクトの振り返りについて少し振り返ってみたいとおもいます。
なぜ振り返るか why
振り返りのそもそもの目的ですね。
いろんなところで言及されているところでもありますが、振り返りをなぜするかというと
- よかったことに再現性を持たせるため
- 何かしらの問題があった場合、その問題を繰り返さないようにするため
の２つになると思っています。
改善を進めていくためのメジャーなフレームワークとして PDCA がありますよね。
振り返りは PDCA でいうところの C の Check に当たります。
Do した後に Check をして、しっかり次の Action を決めると振り返りの意義が非常に出てきます。
また振り返りを実施して内容をまとめることで、自分が所属しているチームだけではなく他のチームの参考にもなるのもいいですよね。☺️
誰が振り返るか who
基本的にはプロジェクトに参加したみんなで振り返ります。 人数が多すぎたら適宜調整して、みんなが満遍なく発言できるようにすると良いです。
いつ振り返るか when
振り返りはタイミングも重要
プロジェクトの途中で振り返る
半年以上ぐらいの長期のプロジェクトになるとリリースした頃には、プロジェクト初期段階のことは忘れてしまうことがあります。😵
プロジェクトの途中でドキュメントをまとめていればそれを見返すことで思い出すことはできるかもしれませんが、思い出すコストがかかったり、それでも記憶が曖昧だったりする可能性があるのでポイントポイントで振り返りをするようにすると内容が濃い振り返りができそうです。
例えば
- 要求仕様書が完成したタイミングで、決め方のフローに問題がなかったかどうかの振り返り
- 3ヵ月たったぐらいでの振り返り
などなど
すぐ振り返る
プロジェクトが終わってやれやれと思うとどんどん記憶が失われていくので、なるべく早いタイミング（１週間以内が目安）で振り返りを実施できると良いです。
リリース前に振り返り日程を事前にスケジュールしておくと良さそうです。
どこで振り返るか where
どこというと場所の話になりますが、リモートで働くことが多くなってきていることもあって、みんなが同じ場所に集まるということがなかなかできなくなってきています。
というわけで振り返りに使えそうなサービスの紹介です。
自分が使ったサービスになります。
Miro
Web 上で付箋が使えるので、みんなでワイワイしながら進行をしていくことができるのでおすすめです。ホワイトボードの大きさも自由に変えられるので比較的多めの人数でも大丈夫。
esa
会社としてドキュメント管理に esa を使っていることもあり、esa もよく使っています。
esa はリアルタイムで共同編集ができるので、サクッとやる場合は esa に書いていくのでも十分です。
何を振り返るか what
ここが重要👆
次に繋がることを振り返る
これができた、あれができたというのをあげていっても、じゃあ次にどうするのかというイメージが湧かない時があります。
よかったことの場合は、 「なぜそれができたのか」の深掘りをする と再現性が出て来やすいです。
例） 〇〇さんが、XXをしてくれたのがよかった。 → 〇〇さんはなぜ XX をすることができたのか → XX を他の人ができるようにするにはどうしたら良いのか
こんなことを考えると良さそうです。
問題があった場合は、発生してしまった原因に対して、次にどうやったら防げるかを考えます。
「次のプロジェクトではこうしましょう」と具体的な行動レベルまで落とし込めると最高です。
例） 特定のデータを持つユーザーがエラーになるケースがあった → 問題になりそうなデータのパターンを出して、それを持っているユーザーのリストでテストフェーズの時にチェックする
職種別の振り返り
チームが小さい単位（3〜4人）ぐらいであれば、意識しなくても良いですが大きくなってくると、自分だけに関わるような内容を振り返りの時に出しにくくなってくる傾向はあります。
また時間的な問題も出てくるので、細かい内容まで洗い出しきれないかもしれません。
例えば
プロジェクトの途中でデグレを起こしてしまった
という問題があったとします。
この問題をどうやって解決するかをその場で話し合うのが良いのですが、エンジニア以外の人がいる場合踏み込んだ議論ができない可能性があります。
そこで職種別に振り返る機会を設けて、より具体的な内容を振り返る場を作るとそういう話がしやすくなります。
参加人数が少ないことで発言がしやすいメンバーがいたりする可能性があるので、そうするとメンバーが抱えていた問題をより深掘りできるかもしれません。
個人の成長の振り返り
チームが成長することも大事ですが、個人が成長することも大事です。
そこで、 「プロジェクトを通して自分が新しくできるようになったことは何か」 というのを振り返ると良いです。
- 〇〇の知識がついた
- 〇〇を意識して動くことができた など
これは流れで自然とやっている可能性はあるのですが、振り返りの時間の時に1つコーナーを設けて自分自身だけに意識を向けて振り返る時間を作ると良さそうです。
例えばですが...採用面接の時に話せるようなネタとして、今回のプロジェクトを通してどんなことが得られたのかというのをイメージすると良いです。
大雑把にするよりかはもう少し詳細度をあげて考えていくといい感じです。
例） Elasticsearch についての理解が深まった → ngram や kuromoji_analyzer といった Elasticsearch の検索の仕組みの理解が深まった
どうやって振り返るか how
時間配分
参加人数が多いと時間配分が結構難しいです。
特に解決が難しい問題が上がった場合に、その解決策を考えていたら時間が経ってしまったという事態にもなりかねないのである程度の時間配分は欲しいところです。
特に、最後にちゃんとまとめて「じゃあ次のプロジェクトではこうしていきましょう！」と決めるところは欲しいので、どのタイミングからまとめに入るかは事前に決めておいた方が良いと思います。
プロジェクトの規模や参加人数によって振り返りの時間が変わってくると思いますが、参加人数が 8 人で半年ほどのプロジェクト場合は、3時間ほどかかりました。
雰囲気づくり
これは一番重要かもしれない。
心理的安全性というワードが世の中に出回ってしばらく経っており、この考え方の重要性は理解されてきていると思います。 振り返りにおいても重要で、なんでも言える空気感があって初めて良い振り返りができると思います。
書籍「チームが機能するとはどういうことか」の引用ですが、
マネジメントとシステム・ダイナミクスの専門家であるピーター・センゲは次のように述べた。「今後、真に卓越した存在になるのは、組織内のあらゆるレベルで、人々のコミットメントや学習する力を引き出す組織だろう」
学習する力というのは、継続的に改善ができる力と捉えています。
これは 強いチームというのはチームが能動的に問題を改善して成長できるようになっていないといけない 、っていうことだと勝手に解釈してます。
そしてチームが能動的に問題を解決できる状態を作るためには言いたいことが言えない状態（通称ポイズン状態）では改善のサイクルが生まれません。
こうした振り返りの場というのは、チームで問題解決をする絶好の機会なので、メンバーそれぞれが言いたいことを言える状態になってなければならないと思っています。
雰囲気が良くなるための魔法なんていうのは当然なく、結局は普段の行動の積み重ねがこうしたところに出てきます。
この辺の話は長くなりそうなのであまり言及しませんがしいて自分が意識していることで言えば、
「あまり肩肘張らずにいくこと」と、
「発言したことに対するリアクションをちゃんとすること」
でしょうか。
とは言え、今いるチームはみんなめちゃくちゃいろんな意見いってくれるし、意見した内容はまず肯定してくれるし、別にそんな細かいことを意識せずとも雰囲気はマジ最高です 🥳
あとは意見を出しやすいようにするポイントとして、what の項目で出てきた話と若干矛盾することになってしまいますが、 無理して深掘りしすぎないようにする のも大事かなと思います。
「それってなんでできたんだっけ」とか「この問題を解決するためにはどうしたら良いのか？」とか
毎回やっていると疲れます 😇
これをやっているとふわっと思ったことをパッと言い出しにくくなってしまうので、ここの問題が重要だと感じたところや比較的多く出た意見のところを深掘りしていくと良いですね。
振り返り手法
振り返りの手法は色々あります。 色々やってみたもののそんなに差がないような気がするのでお好みでという感じですね。
where の項目にも書きましたが、文章だけだと味気ない感じがするので付箋とか使えるようなサービスがワイワイ感出やすいです。
KPT
なんだかんだで KPT 最強説があります。 困ったらとりあえずKPTで問題ないです。
タイムライン振り返り
タイムラインがあることで、振り返りの時に思い出すきっかけになります。 長い期間のプロジェクトのは「プロジェクトの途中で振り返る」のが良さそうですが、タイミングを逃してしまった時は振り返るタイミングでタイムラインを作ってみて出来事をある程度洗い出しておくと思い出すきっかけにはなりそうです。
FDL
Fun Done Learn の略
楽しかったこと、できたこと、学んだことを上げていく振り返りです。
ほぼほぼ KPT と一緒になりますが、Fun という言葉の響きが好き。
参考
リモートでのチームふりかえりにファンダンラーン(FDL)をやってみた
まとめっぽいもの
2 週間ぐらいの規模がそこまで大きくないプロジェクトを対応したのですが、開発規模がそこまで大きくなかったので振り返りをやる予定はそんなにありませんでした。
ただリリースまでに色々問題が起きたこともあって、振り返りを実施することにしました。
結果的にそこではすごくいい議論ができてやってよかった！と思ったのですが、そこで 「なんとなくもやっていたことを話す場ができてよかった」 という意見がありました。
先ほども少し触れましたが、基本的にチームの雰囲気は非常に良いので「言いたいことが言えない状態」ではないと思っています。
ただいつでもなんでも言えるということではなく、適切な場の提供が大事、というのを改めて感じると同時に、振り返りはみんなの意見を集める場として、非常に有効だなと思いました！
明日は @howdy39 の 「 Slack App でワークフロー作った話」の予定です！
