DIGGLE開発者ブログ

予実管理クラウドDIGGLEのプロダクトチームが、技術や製品開発について発信します

ふりかえり(レトロスペクティブ)を活用してチームの自己組織化を促す

UnsplashRavi Palweが撮影した写真

フロントエンドエンジニア兼デザイナーの大澤です。
今回は主にふりかえりによってDIGGLEの開発チームがいかに自己組織化を達成したか、その肝である「ふりかえり」をどのように実施したかについてお伝えします。

なぜ自己組織化を求めるのか

自己組織化したチームには以下の利点があります。

  • 少ないルール
  • 少ない管理コスト
  • 問題が放置されづらい(誰かが拾って対応できる人に渡される)
  • 互いがサポートする中で生まれる安心感
  • 良い意味で交代可能(穴は誰かが埋めてくれるという信頼がある) -> 有給取りやすい
  • そもそもスクラムに必要

DIGGLEではスクラムを採用したので自己組織化は必須でした。
ただ仮にスクラムを採用しなかったとしても上記の利点は魅力的です。
個人的には、ルールを守るために注意を割かれるのが嫌い(そんなことより仕事自体に集中したい)なので、少ないルールで動けるチームであると嬉しいと考えていました。

実際に得たこと

ふりかえりを起点とした改善行動によってDIGGLEの開発チームは、おおよそ自己組織的になったと思います。
上記のメリットに加えて、以下のことも達成できました。

  1. 安定したベロシティ&バーンアップの上昇
  2. 全員がスクラムマスターになれる(輪番制)
  3. 上記をフルリモート環境で運用できている

これらは継続的なふりかえりによる問題発見と改善によってもたらされたと考えています。

過去の失敗経験と学び

狭い経験内の話ではありますが、DIGGLEほど自己組織化に成功したチームはありませんでした。
過去に自己組織化に失敗した事例を思い返すと、以下の理由が思い当たります。

  1. スクラムやアジャイルのプラクティスを綺麗に回すことだけに気を取られる(形式重視)
  2. 既にあるチームや組織の慣習から離れられない
  3. プラクティスの適用を急いでしまう

特に3番目は、1と2が合わさると発生しやすくなります。
素早くプラクティスを適用して、悪い/非生産的(と思っている)文化からの脱却を図ろうとします。しかし、急いで適用するためプラクティスは浸透しません。メンバーは怒られないために仕方なくやっている状況となり、主体性に欠けた受け身のチームが出来上がります。

自分なりの回答: 自己組織化は時間がかかる

自己組織化はチームが主体的に改善を繰り返していく中で達成できます。改善のほとんどは小さなものですが、この積み重ねが大きな変化をもたらします。チームが自分達のものだと強く認識でき、結果として自己組織化が促されます。

自己組織化は一朝一夕で達成できるものではなく、継続的に取り組んだからこそ得られる状態です。
そして、チームの改善行動を促す仕組みこそが「ふりかえり(レトロスペクティブ)」なのです。

シンプルに始める

DIGGLEでは以下のことを重視しました。

  1. 必要なスクラムプラクティスから少しずつ取り入れる
  2. ふりかえりでの問題発見と改善行動の繰り返しの中で「少しずつ」改善する

スクラムを取り入れた当時、必要最小限と考えたプラクティスは以下のものです。

  • スプリント(タイムボックスの役割)
  • プランニング(タスク見積もり)
  • ふりかえり(問題発見と改善)

初期はデイリースクラムもレビューもリファインメントもありませんでした。
今でこそこれらのイベントも実施していますが、加わったのはふりかえりの中で問題が見えてきた後になります。
問題が顕在化してから適用することで「なぜやるのか」が明確になります。

問題を率直に共有することの重要性

「部屋の中の象」という言葉があります。
誰の目にも明らかな問題が存在するのに、誰もそのことに触れない状況のことを指します。もし部屋に象がいたら、それこそが「本物の問題」です。ふりかえりで共有される問題が「本物の問題」でなければ、ふりかえりの効果が極めて限定的になります。

以下のような状況では率直な共有がされません。

  • 問題報告者が面倒ごとを押し付けられる
  • 問題を共有したけど無視される
  • 切断処理(「君の問題だよね?」)
  • 心理的安全性を欠く

上記のような状況を引き起こさないためにファシリテーター(スクラムの場合はスクラムマスター)が率先して状況を切り開く必要があります。
と言っても自分から問題に突っ込むというより、メンバーに率直さと積極性を促すことが重要です。呼び水となる問いかけをしましょう。ふりかえりの場ではチーム全員が話して良いという雰囲気を作り出すことで、本物の問題を引っ張り出すきっかけになります。

ふりかえり手法について

DIGGLEではKPTを用いていますが、問題を共有して改善行動に繋げることができれば何でも良いと思っています。
大事なことは以下の通りです。

  • 定期的に開催する
  • 対象を限定する(ex: 直前のスプリント)
  • 思いつく限り書き出す(書き出すハードルは低めにする)
  • 具体的な改善行動につなげる(次のスプリントで実行できると望ましい)

具体的な改善行動まで繋げられると理想です。とはいえ、最も重要なことはチームメンバーが感じている問題を共有することにあります。問題が共有されていれば、後はどうとでもなります。

反対に最も怖いのが「問題が見えない」ことです。チームメンバーが萎縮したり、無力感を感じていると必要な共有がされません。ふりかえりには心理的安全性が必要です。ファシリテーターはこれを維持する努力をしましょう。

「ふりかえりではどんな問題も話し合える」と感じてもらえるのが理想です。

結果の出ないふりかえりになる覚悟を持つ

ここまで色々書いてきましたが、いつだってうまくいくわけではありません。
例えば、以下のような状況になって十分な成果を出せないときもあります。

  • 議論が長引いて、残りの問題について話し合う時間が不足する。結果、適当に終わらせてしまう。
  • 疲労などの影響で注意が逸れて必要な議論が不足する(面倒になってしまう)
  • 自信を失って話し合いを打ち切ってしまう

毎度完璧で効果的なふりかえりができるなんてことはありません。うまくいかない日は必ずあります。
そんな日があったとしても、改善プロセスを繰り返すことこそが重要なのです。
「次こそはもっと良くしよう」「小さくても良いから次の改善に繋げよう」という意識を持ち続ける限り、チームを成長させることができます。

諦めずに続けていきましょう。

まとめ

DIGGLEではふりかえりを改善プロセスの中心に据えることで自己組織化を達成できました。
この結果としてスクラムの運用とチームの独立性を保てていると思います。

もちろん今後がどうなるかは分かりません。
しかし、ふりかえりを中心にした改善プロセスが回り続けることは変わらないと思っています。

We're hiring!

DIGGLEでは主体性を発揮してチームで最高のプロダクトを作りたいエンジニアやデザイナーを募集しております!少しでも興味があれば、ぜひ下記採用サイトからエントリーください。

herp.careers

herp.careers