こんにちは。ferixエンジニアの清水です。
今回はフェリックスで行っている振り返り会についてご紹介します。

振り返り会とは？

そもそも振り返りとは何でしょうか？弊社の振り返りガイドラインから引用します。

振り返りとは、自分が目標達成のために行ったことを理解して整理し、次の行動につなげるための対策や改善点を導き出す行為を指します。

フェリックスでは様々な案件を受注しており、それぞれの案件ごとにプロジェクトを組んで、日々業務に勤しんでいます。
振り返り会は、プロジェクトの節目に目標の経過や経験を振り返り、共有し、そこから学びを得て次に繋げるためのミーティングです。

フェリックスの振り返り会の特徴

フェリックスの振り返り会は、プロジェクトのメンバーだけでなく、社内のプロジェクト外のメンバーも任意で参加しているのが特徴です。

弊社はエンジニアやデザイナーといった職務の違いはあれど、プロジェクトに関する固定の部署やチームといったものはなく、各プロジェクト毎に編成されたメンバーで仕事をしています。
また、プロジェクトの内容も長期のものはあまり多くないので、短期間毎に違うメンバーと仕事をすることが多いです。

そういった背景もあり、以下のことを目的に、それぞれのプロジェクトの内容を（共有できる範囲で）社内で共有しています。

• プロジェクト参加メンバーの人となりについて知る
• このプロジェクトを通して誰がどのような経験をしたのかを知る
• 別のプロジェクトに活かせる知見やノウハウを会社全体で集積する

プロジェクトが終わった後、全社振り返り用の共通フォーマット(目標の振り返りや、できるようになったこと等の項目がある)に沿って、Wikiに個人やプロジェクトで振り返った内容を記載します。そして社内でアナウンスして、30分〜1時間ほどミーティングを行うのが慣例となってました。

振り返り会の重要度と実施タイミングの変化

先ほどの一文が過去形で終わっているのには意味があります。

実は今年、弊社では人事評価制度の大きな変化がありました。
その中で、評価軸の一つである成長を評価するための記録として、振り返り会が非常に大事な役割を持つことになりました。

そして、冒頭で出てきた振り返り会のガイドラインが新たに定められ、振り返り会の実施タイミングが以下のように変更になりました。

旧：プロジェクト終わりに全社振り返り会を行う

↓

新：以下の振り返りを実施する

• 推奨・任意
• • 日次振り返り
  • 週次振り返り会
• 必須
• • 月次振り返り会
  • プロジェクト振り返り会（プロジェクトメンバーのみで実施）
  • 全社振り返り会

また、今まで実施していた全社振り返りも、プロジェクト振り返り会の内容を元にしたディスカッションや、知見やノウハウをより抽象化することが求められるようになりました。

ガイドラインが定められ、振り返り会のやり方はどう変わったのか？

実はまだ決まったフォーマットはありません。
従来の全社振り返り会の共通フォーマットも利用しつつ、新たにKPTやYWTなど、各プロジェクトで様々な方法を試しているところです。
（実は、ガイドライン制定前から共通フォーマット以外の振り返りを導入しているプロジェクトはありましたが、今年度より制度として具体化しました。）

振り返り会のやり方を変えてみたログ

実は清水、稚拙ながら社内のPMOとなるべく、現在ソフトランディングの途中です。
振り返り会の仕組みづくりも、取り組みのうちの一つです。

まず自分が関わっているプロジェクトで試してみたので、その内容をKPTのフォーマットで共有してみようと思います。

出来事（やってみたこと）

プロジェクト振り返りでKPTを選択した
振り返りといっても、調べてみると様々なやり方があることがわかります。
振り返り手法を調べる際に、私が参考にしたのはこちらの記事です。

上記からリンクされているふりかえりカタログ（コミュニティ版）に、様々な振り返り手法がまとめられており、圧巻です。知らない手法だらけでした。（ポジティブ星人とかかわいいですね。）
しかし、急に知らないやり方を取り入れるのも難しいので、まずはスタンダードなKPTを選びました。

出来事からはじめてみた
上記のカタログ内のKPTは、出来事→Keep→Problem→Tryの順で話し合うとあります。
この「出来事」は、私は今までの振り返りの経験上やったことがなかったのですが、重要そうだと思ったので、チームメンバーに説明して、Googleドキュメントに記入してもらうことにしました。

出来事に投票機能をつけて、気になるものに投票してもらった
10分程度時間をとって、出来事をメンバーに書いてみてもらったところ、私が想定した以上の数の出来事 (1人10個以上！)が記入されました。
ひとつずつ追っていると時間が足りなかったので、他のメンバーの発案で、メンバーにそれぞれ気になったものにKかPを投票してもらい、そこから各々のKeepの強化、Problemの解消につながるTryを抽出することにしました。
それでも1時間の枠には収まらず、Tryについての話し合いは別途30分時間を取ることになりました。

全社振り返りでも出来事に投票してもらって、投票者からの質問を元にディスカッションした
全社振り返りのディスカッションを促すため、これも他のメンバーの発案で、気になる出来事に投票してもらって質問をもらう形式にしました。
Googleドキュメントの投票チップ機能を使ってみました。誰が投票したかもチップの上にポインタを置いたら表示されます。

良かったこと

KPTを出来事から始めるのは良かった
今まで実施していたKPTだと、Keep、Problemから考えることになりますが、どうしてもProblemが多くなりがちです。そうするとProblemのことばかり考えて、振り返りが楽しくなくなったりします。
出来事から書き出すことで、Keepにつながる事象がたくさんあることがわかりました。また、Tryを考えるまでの流れがスムーズにできたように思います。

問題点

時間が足りない
プロジェクト振り返り会を1.5時間、全社振り返り会を1時間でやりましたが、本来のKPTの一部をスキップする必要が出てきたり、ディスカッションの時間が足りなかったりしました。
過去うまくいった経験から、プロジェクト振り返り会で従来のフォーマットのWikiも併用していたので、余計に時間がかかっています。
プロジェクト振り返り会と、全社振り返り会で、各自のTryなどといった、同じことを話す時間があったので、その重複がうまいこと改善できれば、ディスカッションにより多くの時間を取れるような気がしました。

次回やってみること

出来事の継続
KPTを出来事から始める流れは今後も続けたいです。
Keep、Problemといった区分なく書き出す方が、自身の経験を振り返りやすくなりますし、ポジティブな作用があると思いました。

反復を減らす
連続する振り返り会で同じ内容を読み上げる時間は、メンバーにとって負担になると個人的に感じました。全社振り返り会では、プロジェクトの概要をプロジェクト外のメンバーに共有する必要があります。プロジェクト振り返り会の内容を工夫して、どうにか反復を減らす方向に持っていきたいです。

今後の展望

今回試してみて、とにかく時間がかかるなーと思いました。
複数プロジェクトを兼務しているメンバーも多いので、あまり時間を取らせるわけにはいきません。
あと私自身もGoogleドキュメントのフォーマットを考えるのは地味に大変でした。
（フォーマットは一度作れば、あとは使い回すだけなので、今後は時間短縮になると思います）

ただ、個人的にはプロジェクト振り返り会が結構楽しいです。
プロジェクトで話し合った内容を、全社振り返り会により抽象化して持っていけるような仕組みにしたいと思っています。そのために他の振り返り手法を試してみるのもいいですね。
各プロジェクトでの振り返り会の習慣化やフィードバックなどを通じて、フェリックスの振り返りサイクルを作っていきたいです。

最後に

ご覧いただいた通り、フェリックスの振り返り会はまだまだ改善の途中です。

しっかりとした振り返りの仕組みによって、個人やチームの学びと成長に繋がる好循環を目指していきたいです。そんなチームで一緒に成長していきませんか？

その他、フェリックス全体のチームビルディングを改善・強化するアイデアを大募集中です。
あなたのやりたいチーム改革、ぜひうちで試してください！