1年間 'ふりかえり' を続けてわかったこと・つぎにやること

5 min read読了の目安(約5300字

はじめに

この記事は「ふりかえり Advent Calendar 2020」の、4日目の記事になります。
すてきなカレンダーありがとうございます。
Advent Calendarへの参加は初めてになります、よろしくおねがいします。

今回はタイトルの通り、私がちょうど一年前(2019年11月)から始めた「ふりかえり」をふりかえった内容になります。

注意

  • 「用語の定義」や、「普通だったらこう」という話はあまり触れずに、主観的なコメントが多くなるのでご注意ください。
    ※チームでのユビキタス言語として言葉とビジョンを共有できていることが大事ですし、そもそもこの記事は標準化が目的でもありません。
  • 解釈違いや誤った内容もあるかもしれませんが、その場合はそっと教えていただけるとうれしいです。

tl;dr

  • ふりかえり、チームのプロセスのカイゼンだけじゃなくて個人の成長にもつながった
  • メンバーひとりひとりがリーダーシップをもつことが、チームのふりかえりの成功の鍵かもしれない
  • ふりかえりは万能薬ではなく、毒にもなる。気をつけながら小さく色々試していきたい。

〜 ふりかえりのふりかえり 〜

ふりかえりを始めた当初と今

「ふりかえり」に最初に向き合ったのはウォーターフォール開発をしていたプロジェクトの二次開発で、内部で話し合いアジャイル開発しようと意見がでたことがきっかけでした。
(スクラムマスターの資格を持つ方がいたこともあり、お客様にも共有・調整した上で進めました。)

正直言うと、初めは抵抗がありました。
「時間の無駄では?」「淡々と仕事しているほうが向いてるかも?」「自分の能力のなさで足をひっぱるのが目に見えちゃいそうで怖い」

慣れてきた頃は、むしろガンガンやりたいという気持ちになっていました。
「チームでやれば気持ちよく働ける」「忙しい上司が話を聞いてくれる」「自分の意見を通しやすい」

今は、用法・用量を守って適度にやっていきたいです。
(考えの結論だけ見たい方は「次にやること」の章まで飛ばしてください。)

どんなふりかえりをしてきたか

ちゃんと考えて触れてみた手法は以下です。

  • KPT(KPTA)
  • YWT
  • ORID(ORIMD)

共通するのは、短い期間をふりかえるときはそのまま気づきや考えをを書いていき、
長い期間をふりかえるときは淡々と事実やイベントを書き出してから気づきや感情、考えを掘り起こしていきました。

KPT

Keep,Problem,Tryの頭文字でKPT。
「ふりかえり」に慣れていない人たちにもとっかかりやすい、チームでもソロでも比較的やりやすい部類の手法だと思います。

短い期間でサイクルを回して、KeepProblemを並べるだけでなく前回のTryの内容も評価しつづけることで効果が出ると思います。
逆に、間隔が空きすぎるのは危ないとも思っています。
人間、嫌なことは覚えてるのでどうしてもKeepが頭から抜けてProblemだらけになってしまうので。。

YWT

やったこと、わかったこと、つぎにやることの頭文字からとった振り返り手法。
長期間をふりかえるとき内省(リフレクション)するときにはKPTよりやりやすいかなと思います。

流れとしては

  1. まずやったことをリストアップ
  2. それに紐づくわかったことをリストアップ
  3. 重要そうなトピックを深堀りする
  4. 次にやることを決めていく

一人でモクモクとふりかえるのも、こういうことあったね〜ってなるのでチームでわいわいやるのもおすすめです。

ORID(ORIMD)

ぼくがつい最近出会った、新しく始めた内省手法です。

https://leprofront.tech/index.php/effective-reflection-process/
ORIMDについてはこちらをもとにインプットしたので、イメージがずれないようよければリンク先をご確認ください。

KPT、YWTを回数重ねて「表面的なふりかえりとカイゼン」であることが課題に感じ、もっと深いふりかえりができないかと探してたどり着いたものです。
時間はかかりますが、あとから見直したときに当時の思考の流れ(事実、感情、解釈、意味づけ、決定)が漏れなく残るのがとても気に入っています。

時間がかかりすぎて半年とかの期間のふりかえりにはボリュームてきにしんどいです。
(整理するためにやるときはやりますが!この記事のように!!!)

ちょっとした実例

スプリントレトロスペクティブ(KPT)

※ぼくのチームでそのようにやっていただけで、「スプリントレトロスペクティブ=KPT」ではないです。
スプリントおわりのふりかえりをKPTで実施しました。

オンラインでやるときもオフライン(対面)でやるときも、
DropboxPaperのように同時編集ができるドキュメントを用意してお互いにKPTを出し合うようなことをしています。
誰かネガティブな状態になっていた場合はネガティブの矛先を個人ではなく課題とするようにし、
人と人が対立しないようにファシリテーションするとよいです。

Keepは普段から相手を褒めようとしたり相手の行動をみていないとなかなか出せないので、慣れていないチームの初回はとくに事前に一人一つ称賛できるネタを用意しておくと進めやすいと思います。
それでもProblemだらけになりそうなときはポジティブにいいかえてKeepに置き換えてバランスとったりなども必要。

慣れていないチームだった場合はファシリテーターを招いてもいいかもしれません。

フェーズごとふりかえり(YWT)

やったことも列挙していくこと、ナレッジを記録できることと、考え方やナレッジの継承もできることから
これはチームビルディングよりも人材育成の面が大きい内容です。次のプロジェクトに活かせるようにファシれるとよいです。

たとえば設計フェーズ。プロジェクトごとに固有のイベントがあり、それにたいしてのアクションが起きていたはずです。
それについての評価や、同じイベントに対してそれぞれの気付きが共有されるので全方向への相互フィードバックが発生します。
(マネージャー目線、リーダー目線、メンバー目線)

コーディングふりかえり(フレームワークなし)

とくべつフレームワークを用意していないイベントです。
どこかの振り返りのTRYであげられた、習熟度の低さやスキルの勾配をカバーするためのふりかえりです。

お互いのソースコードの知見が共有されるので、レビューと意思決定がその場ででき納得のできる規約の作成が作られていきます。

ふりかえりしてみたいけどどれがいいの?

まずはKPTやYWTなど、とっかかりやすいふりかえりから始めるのがいいと思います。
あとは慣れているファシリテーターがいるチームや、メンターと一緒にやるのもおすすめです。
一人でやったときはフィードバックもらえる人がチームにいるととても良いです。

ただ、できれば後述する「よかったこと」と「やってしまったこと(失敗事例)」は目を通していただきたいです。

よかったこと

ふりかえることで、上司やチームメンバーの考えを聞く機会ができた

まだまだエンジニアとしての経験が浅いので、人の経験や考えをきくことがとても重要であることがわかりました。
純粋に面白いということもありますが、「いつか自分があの人の立場になったらどうすればいいのだろう」という不安の解消に繋がります。

自分の考えを深堀りできるようになってきた

仕事の中でのイベントにたいして、様々な観点での知見が集まることで自分で考えられる領域が少しずつ増えていきました。
また、人とふりかえることでちょっとした違和感を言語化するトレーニングになっていました。
それは自分ひとりでする内省にもつながっており、考えるくせと手が止まらないで行動できるフットワークの軽さに繋がりました。

やってしまったこと(失敗経験)

氷山の一角をみつけて満足してしまう

気づいて共有して、ふりかえりの場では時間の都合上ほどほどに議論してTryを決めて流してしまう。
氷山の一角では?というものはふりかえりの後の時間に調査するタスクを用意したりしたほうがいいです。

気づいた人が責任をもって調べる・他の人はそんなに興味がないという状況になったら苦しいですね。
チームとして危険であるとも思います。

誰かが苦い思いをするトピックの振り返りの実施

誰かが頑張ってリードして成り立っているプロジェクトだと、Problemが上がるたびにリードする人に小さな棘が刺さります。
何気ないProblemがリーダをきずつけた...ってことはよくあります。

本人からしたら大した事のない指摘かもしれませんが、関係の構築がまだ浅いときなどはとくに空気が固まることがあります。
ファシリテーターも、そうじゃない人も、だれかがネガティブな発言をしたりだれかが傷つきそうな内容を触れられていたらフォローすることが必要です。

もしくは、そういうシーンが起きることが予測できるときはイベント内容や手法を変えるというのも手だと思います。

リードしている人がメンバーを救う場になっている

ふりかえりはプロセスのカイゼンの場になると思っていましたが、実態が「Problemに対してTryやカイゼン案が出せる人がリードしてる人になっていた」ことがあります。
つまり、リードしている人がメンバーの不満を吸収する場になってしまっていたのです。

これはリードする側とメンバー側両方に問題があります。

・リードする人:考える機会をうばってしまっていた。コーチングする場面であった。
・メンバー:全体感がわかっていない、見えていない。(当事者意識がない場合もあるかもしれない)

リードする人がボトルネックになり、どんどん視野が狭い(リーダーができないことがチームのできないことになってしまう)チームになってしまいます。

序盤・立ち上げは仕方ないのかもしれませんが、リスクとして考えるべき状態です。
長く続く前に、何らかのアクションが必要だったと思います。

ではどうすればいいの?

正解はわかりません。メンバーの個性や、メンバー同士の相性もあります。
ただ、ぼくは以下が効果があると思っていますが、色々な方のお話を聞いてみたいです。

  • リードしている人や頑張っている人を称賛する
  • Problemも誰かの成果物(個人の問題)ではなくその人へのフォローができない状態(チームの共通課題)として指摘する
  • メンバー全員が、全体感の把握をできる限り早くできるようにしておく(そして個々がリーダーシップをとる)
  • 品質向上やプロセスの改善を特定の誰かにおさえず、外部に相談できるパスを用意する

次にやること

ふりかえりのスタンスの方向修正

慣れてきた頃はふりかえりをチーム改善の万能薬だと思っていましたが、、
「やってしまったこと(失敗経験)」で触れた通り万能薬でなければ、毒にもなるっていうのがわかりました。
総じて、チームでやるときは特定の誰かに負荷が偏らないような配慮をしていこうと思います。

ORIMDで自身の考えの記録をする

継続的につづけることで自分の考えの記録にもつながりそうです。
カイゼンループ、というのもありますが、ぼく自身気分屋なところがありまして。
考えと感情をちゃんと記録して、気分に流されないことを意識していきたいです。

ふりかえりから始めるチームビルディングも試したい

チームでのふりかえりをしてみて、仕事の向き合い方・チームの動き方の理想はメンバーごとに違うというのもよくわかりました。

バックボーンや知識体系は人それぞれなので、ゴールやビジョンの共有が大事になるのではないでしょうか?
いきなり「このプロジェクトはこういうふうに進めます」という話をしてもいいのですが、先に「前のプロジェクトでこの部分がつらかった、こうすればよかった」という話を出し合ってみたいです。

機会があれば小さく試してみたいです。

おわりに

長くなってしまいましたが、ふりかえり、チームのプロセスのカイゼンだけじゃなくて個人の成長にもつながりました。
用法・用量を気をつけて続けていきたいと思います。