立ち止まって、立ち止まって、ふりかえる

GLOBIS Advent Calendar 2023 15日目の記事です。

　グロービスでスクラムマスター、テックリードなどをしている@tom_bo_meganeといいます。今回はスクラムマスターを担当しているチームのふりかえりの仕掛けを紹介します。

はじめに

　スクラムマスターという立場をやっていると、よく「ふりかえりってどうやってる？」と相談を受けます。その中で以下のような質問をいただきました。

• いろんなやり方・ツール・雰囲気作りなど、「どうやるか？」は調べると書いてあるけど、「どう考えてふりかえりを導入しているか」を知りたい

そんなわけで、チームの作業プロセスを設計するにあたり、「どう考えてふりかえりを導入しているか」を紹介します。

ふりかえるために、ちょこちょこ立ち止まる

　いざ、ふりかえりをしようとしたときに、「覚えていない」「記憶によると・・・」「～だったかもしれない気がする」などの言葉が出ていませんか？これらはふりかえりの破綻状態を示す言葉たちです。

　こういったことがないように、ふりかえりに備えて立ち止まりが必要です。今回挙げる立ち止まりとは、やったことを記録して、記憶にもできるだけ留めることを目的としています。私たちのチームでは、意図的に立ち止まりを入れて作業プロセスを設計しています。

　といっても、何か特別ことをしているわけではありません。開発手法はスクラムを取り入れており、その中のイベントに対して、意図的に立ち止まりとして紐づけています。なお、スクラムのスプリント期間は１週間としています。

デイリースクラム

　まず、ひとつめの立ち止まりにしているのは、デイリースクラムです。朝の始業直後１５分の枠で毎日実施しています。やっていることは以下のように、標準的なデイリースクラムの内容を扱っています。

• 状況確認
  • スプリント進行状況について、スプリントバックログ・バーンダウンチャートをみんなで見る。
• 昨日やったこと・わかったこと
  • 昨日やると言った作業、割込みで入った作業の対応結果や状況を話す。
  • 状況がより具体に連携できるため、サッと成果物を見せて説明する。
• 困っていること
  • やってみて困っていること、やろうとしていることの障壁になることを話す。
  • 適宜、別途ディスカッションするか決めている。 |
• 今日やること
  • 困っていることの対応も踏まえて、各自やることを話す。

　　↑ はいつも見ているバーンダウンチャートの一例

　意識している点は、メンバー間でより具体的に状況を共有できるように、成果物を見せ合い話していることです。こうすることで、メンバー間で取り組んでいることが、聞いたことではなく、見て・聞いて・説明したこととしてチームに残ります。定性的ですが、何も見せずに状況共有している状態と比較して、説明の質がまったくちがう印象です。

　「そんなことすると時間がかかって、デイリースクラムが終わらないのでは？」と心配されるかもしれません。そのような場合は、他のメンバーが何かに気づき、意見を持ったということなので、別途時間を取って会話をしています。

　私たちのチームの例ですが、継続すると、成果物をもとにメンバー間でやったこと・やっていきたいことが共有されていきます。デイリースクラム後に時間を取るケースは、スプリント内に１回あるかないか、かつ別途時間も１５分に満たないぐらいです。

　このように１日単位の大きさで立ち止まって、記録を残し、かつできるかぎり記憶にも残るようにしています。

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

　ふたつめの立ち止まりは、スプリントレトロスペクティブです。毎週、スプリント最終日に４５分の枠で行っています。YWT（＊１）という手法を取り入れて、以下の内容で行っています。

• スプリント結果の確認（５分）
  • 未消化・仕掛・完了のタスク状況を、スプリントバックログ・バーンダウンチャートをみんなで見る。
  • スプリント完了時点のプロダクトバックログの状態をみんなで見る。
  • スプリントプランニング時点で各自が予定していたキャパシティと、実績の差異をみんなで見る。
• YWT（１０分間で書き出し、３０分間で共有・質疑）
  • Y：やったこと
    • スプリント内でやったことをひとつひとつ挙げていく。粒度はタイトルのみの記載。
    • 対応した作業経緯・結果や完成した成果物などを確認して書いていることが多い。
  • W：わかったこと
    • スプリント内でやったことを通して、わかったことを書く。
    • 「わからないことがわかった」ものも書く。
    • 作業を実施したものではなくとも、気づいたことは書く。
  • T：次にやること
    • 次のスプリントでやることを書く。
    • 備忘録として、やることを残す場合も役に立っている。
  • Done
    • 次にやることとしていたものが、終わったらこのレーンに入れる。
    • やったことが記録として残る。

　　↑はYWTの一例

　スクラムを取り入れられている方から、「ふりかえりで効果的なアクションが出ない」といった相談をいただくことがあります。KPTなどで、がんばってアクションを絞り出そうとされているようなケースも見られます。賛否あると思いますが、そのような効果的なアクションがどんどん出てくるような期待を持って実施していません。

　私たちのチームが複数システムの環境整備を行っているからかもしれませんが、初見で調査を行っていくことも多いです。そのため、取り組んだことの良し悪しの判断をして改善すること（ダブルループ学習）よりも、チーム全体への取り組んだことの気づき共有（シングルループ学習）を主目的としています。このような目的において、相性の良いYWTを取り入れています。

　デイリースクラムで１日単位の大きさで共有していたことが、スプリントレトロスペクティブで１週間を通したストーリーとなり、共有されます。成果物をもとに説明していたことに加えて、どう考えて・どう捉えたかを説明する場になっています。記録と記憶の厚みが増していると感じています。

　毎週繰り返していると、改善した方がよいこともみつかります。そのような場合は、ちゃんと「T：次にやること」に改善事項として記載しています。例えば、スプリントの予定キャパシティオーバーが繰り返し続くような場合、途中追加するスプリントバックログアイテムの追加上限を設定するなどがあります。

　ここまでで、立ち止まりによる記録を残すことと、記憶に刷り込む取り組みを紹介してきました。

ふりかえり（任意間隔）

　ここから表題どおり「ふりかえり」です。先述したスプリントレトロスペクティブでは、取り組んだことの良し悪しの判断をして改善することよりも、チーム全体への取り組み共有を主目的に行っていると書きました。

　では、いつ「取り組んだことの良し悪しの判断をして改善する」ふりかえりを行うのがよいのでしょうか？こちらは任意の間隔だと考えています。なぜなら、「取り組んだことの良し悪しの判断」ができる状態になるには、何回か類似作業を繰り返して学習する必要があり、プロジェクトの性質などによってちがいがあるからです。ちゃんと、いつふりかえりを行えばよいかを、プロジェクトの性質やプロダクトの状況と向き合って、決める＆見直していく必要があります。この点はふりかえりの難しさの１つかと思います。

　「と言われてもどうしようか・・・」となるかもしれないので、まずは毎月やってみようとか、３ヶ月おきにやってみようと試してみるのがよいかと思います。ふりかえらずに放置するより、よっぽど良い状態になると思います。

　私たちのチームでは、３ヶ月に１回、６０分の枠で実施しています。複数システムのEOL対応など、全体として３ヶ月ぐらいでカテゴライズできる作業のカタマリが存在するからです。有名な手法KPT（＊２）を取り入れて以下の内容で行っています。

• KPT（開催１週間前から事前書き出し、６０分間で共有・議論）
  • K：よかったこと・よくなったこと
    • 3ヶ月前の状態と比較してよくなったこと、よかったと判断できることを書く。
  • P：よくなかったこと・改善したいこと
    • 3ヶ月前の状態と比較してよくなかったこと、改善が必要と判断できることを書く。
  • T：よくするためのアクション
    • 次の3ヶ月で取り組むアクションを書く。

　個人単位でのふりかえりを目的に、事前書き出しをするようにしています。その際、取り組んできたプロダクトバックログ、スプリントバックログ、全体マイルストーン、スプリントレビュー資料など、いろいろな記録を参照します。やみくもに参照しているわけではなく、記憶をもとにした事実確認として参照しています。

　デイリースクラム・スプリントレトロスペクティブで意図的に立ち止まって、記憶に刷り込んできたので、その効果がここで出てきます。立ち止まったタイミングで、説明する状況を入れていくと、良いアウトプットの機会になって、記憶に残るんだなと感じています（＊３）。

　これまでの実施結果では、改善に向けた具体作業やチームスタンス変更などが挙がっています。例えば、以下のようなものがありました。

• ３ヶ月前
  • K：どんどん業務アプリチームの範囲にも入っていって、巻き取ってでも進行した。EOLまでにシステム更新が完了した。
  • T：この積極性はチームスタンスとして続けていこう。
• ３ヶ月後
  • P：どんどん巻き取って進行したことにより、業務アプリチームがシステム操作方法がわからないケースが散見される。結果、運用フォロー稼働の増加により、スプリントのキャパシティが少なくなっている。
  • T：業務アプリチームへのシステム操作の立ち合いを少なくとも２回以上立ち合う。その際に受けた質問やわかりにくい部分について、マニュアルやスクリプトを更新する。

　このケースでは、EOLのように期限遵守を優先しなければならなかった状況から、スピードよりも丁寧さを優先する状況に変化していました。私たちのチームでは、このような変化のペースが、３ヶ月ぐらいだと考えています。

　以上が、私たちで行っている立ち止まりとふりかえりの仕掛けになります。

おわりに

　私たちはスクラムを取り入れているので、デイリースクラムやスプリントレトロスペクティブといったイベントを利用しています。特にスクラムではなくても、朝会と称して毎日開催してもよいですし、週次共有会と称して毎週開催してもよいかと思います。作業プロセスのフレームワークにとらわれずに、「普段の取り組まれている仕事と向き合ってみて、どのタイミングで立ち止まり、どのタイミングでふりかえるのがよいかを考えて試して」いただければと思います。その際の参考になれば幸いです。

　読んでいただき、ありがとうございました。

ご参考

＊１ 株式会社 日本能率協会コンサルティング（JMAC）社が開発された手法です。
＊２ アリスター・コーバーン氏が紹介された手法です。
＊３ 樺沢紫苑氏の学びを結果に変えるアウトプット大全で紹介されています。