見出し画像

どんなときも続けてきたカスタマイズし続ける振り返り

Ghelia Tech Blog｜ギリア株式会社


はじめまして。ギリアでインフラエンジニア組織のマネージャーをしている永嶋と申します。

お客様向けのAIシステム基盤の設計構築や社内のAIエンジニアが使う計算機基盤の運用などをタイピング肉体労働によって担当する組織で、わたしは課のマネジメントをしています。

2023/04/08に開催されたふりかえりカンファレンスに提出していたのですが、リジェクトされてしまったプロポーザルの内容について、テックブログが開設されると聞いたので供養も兼ねて書かせていただいています。

前置き：振り返り活動についておさらい

本題に入る前に、そもそも振り返り活動とは何なのかを確認しておきましょう。

個人的には改善策を得ることではなく、成長することが目的だとは思っていますが。

自分が行ってきた振り返りについて

ということで本題なのですが、タイトルの通り振り返りの方法については色々とカスタマイズしながら続けています。
どのような変遷を遂げてきたのかを説明し、読んでいただいてる人向けにポイントをまとめようと思います。

最初の頃(2人チーム)の振り返り

仕事のクオリティが思った通りに上がらないので振り返りをやろう、となった頃の話です。
振り返りのフレームワークと言えばKPT(*1)。しかし永嶋はよくあるKPTが嫌いであった…。

Problem祭りでひたすらツラい時間、自分事や他人事をチーム事として捉えられないチームメンバー、そしてProblemに書かれるメンバーへの非難…

かつての嫌な記憶がKPTという単語で呼び起こされたその時、ふと閃いた！このアイディアはチームでの振り返りに活かせるかもしれない！ 

よし、自分でフレームワークを作ろう。

ということで、ゆるい振り返りフレームワークが誕生しました。

  • 振り返りは週に1回、30分

  • 「よかったこと」「改善したいこと」「アクション」を出す

最初はたったこれだけ。とにかくカジュアルにやれることだけを考えて作りました。
かれこれ2年以上は続けているので、結果的にカジュアルにやれることを念頭に置いたのは正解だったかと思っています。

途中で、「なんでこのアクションになったんだっけ」を忘れたことがあり、アクションを考えるときの議論を残すようにして、「先週のアクションができてたかどうかチェックしないと意味ないね」となり前回のアクションの達成状況確認を追加して、最終的に以下の項目を議論することとなっています。

  • よかったこと

  • 改善したいこと

  • 改善アクション

  • アクションリスト

これは現在まで変わっていません。
余談ですが、過去に知人にこの話をしたときに「+/Δというフレームワークが似ている(*2)」と教えてもらいました。やっぱり同じようなものを考えてる人はいるものですね。

1人チームの振り返り

数ヶ月継続しながら振り返りの効果が実感できるようになってきた頃、一緒に仕事をしていたメンバーが退職してしまいます。
ここでの悩みは、1人チームとなって振り返りを継続できるのか？継続するとしてもどのように継続するのか？というものでした。

振り返り活動をメンバーが増えるときまで中止することも考えたのですが、最終的には1人のままで引き続き毎週継続することに決めました。
当時の上長が快く振り返り時の壁打ち役を引き受けてくれたこともあったのですが、いざ復活させようとしたときに振り返りのマインドが自分の中から消えてしまうかもしれないという懸念と、組織の文化として将来にわたって残していくことを考えると人数は止める理由にならないと考えたことが決め手です。

さて、1人でどのようにやっていたかという話ですが、2人でやっていた頃と振り返る項目自体は変わらないので、実は書くことがありません。
壁打ち役の上長が適宜いい感じの指摘をしてくれていたことで主観的になりすぎることもありませんでした。
今思うと、やはり中止しなかったことで今でも組織の文化として残せているのかなとは思います。

人が増えてきたときの振り返り

そうしてだいたい9ヶ月ほどでしょうか、1人チームでインフラ関連の仕事を全てやっていたのですが、今では自分を含めて4人の部署になりました。
4人になって1年以上経ちますが、少しだけ形を変えつつ今でも継続しています。
毎週の振り返りの内容は変わっていないのですが、毎週の振り返りに加えて毎月・毎年の振り返りをやるようにしています。

より間隔の長い振り返りをやる理由はいくつかありますが、一番大きな理由は「組織の目標やミッション・ビジョン・バリュー(以下MVV)に対しての振り返りを行うため」です。
毎週の振り返りは今でも30分の枠でやっているのですが、4人で30分では先述の4項目だけでも時間が足りないことがあります。

そして、組織目標やMVVは、思い出したときに発信するだけでは、日々の作業に追われているメンバーに意識してもらうことは難しいです。
目標やMVVに対する振り返りを取り入れることで、メンバーに意識してもらい、それに沿ったアクションを取れるようになってもらうことを狙っています。

他の理由については、振り返りの目線を変えてちょっと長めの過去まで振り返りをしたいことと、毎週の振り返り自体の改善ポイントを議論する場が欲しいためです。
1週間では解決できない問題に対するアクションを考えたり、毎週30分ギリギリを使って振り返りをしていると、振り返りの振り返りができないためです。
1年の振り返りはシンプルに「今年どうだった？」という話と、毎月の振り返りの総括をします。

ところで、ITエンジニア界隈では振り返りという言葉が市民権を得て久しいですが、「振り返りの振り返り」を実践している人はあまり多くないのではないでしょうか？
目的を達成するのに寄与していないか？やりざまを修正する必要はないか？等、振り返り活動自体を振り返る取り組みが「振り返りの振り返り」です。
やったことがないという読者の方がいましたら、「今やっている振り返りは自分たちの成長に正しく寄与しているのか」を振り返る時間をたまにでよいので設けることをおすすめします。

振り返り活動において気をつけているポイント

さて、ここまで、わたしがギリアのインフラエンジニアとして働き始めてから殆どの期間で継続してきた振り返りについて紹介させていただきました。
最後に、わたしが振り返りを設計するときに気をつけているポイントについて紹介させていただきます。

  • 以下の3つを徹底する

    • メンバーへの感謝/尊敬/謙虚を忘れない

    • 常に「問題 vs 我々」のスタンスを崩さない

    • 「誰かの困りごとはチームの困りごと」と認識する

  • 良かったこともちゃんと取り上げる

    • Problem祭りでは人の心は疲弊してしまう

  • ファシリテーターは意見を出しすぎず、他の参加者に積極的にコメントしてもらう

    • 雑に「${誰か}さんどう思います？」みたいなぶん投げでもいい

  • 高頻度短期間で行う

  • 可能であれば短期間(〜毎週)と長期間(毎月〜隔月)の振り返りを両方とも行う

  • 隔月より長い期間での振り返りは単体で行ってはいけない

    • 人は忘れる生き物なので2ヶ月前のことを覚えていない

  • 振り返りの振り返りは必ず行う

最後に

ということで、振り返りカンファレンスに出そうとしていたネタを供養しました。
書いたことが読んでいただいた皆様の良質な振り返り活動につながれば幸いです。

それではこのへんで。

*1: 過去の経験を活かす：振り返り　KPT（ケプト）https://www.projectsprint.org/ja/v3.0/tutorial/section4-1/section4-1-1#kptkeputo
*2: 過去の経験を活かす：振り返り　+/Δ（プラス/デルタ）https://www.projectsprint.org/ja/v3.0/tutorial/section4-1/section4-1-1#purasuderuta

この記事が気に入ったらサポートをしてみませんか？