ふりかえりについてのふりかえり

作者 Deborah Hartmann Preuss , 翻訳者 和智 右桂 投稿日 2009年9月27日

セクション

エンタープライズ・アーキテクチャ,

プロセス/プラクティス

トピック

リーダーシップ ,

ガバナンス ,

Agile ,

補完実践 ,

マネジメント ,

エンタープライズアーキテクチャ ,

Retrospectives

共有 |

原文(投稿日：2009/09/17)へのリンク

組織内のどのチームもアジャイルを用いており、それぞれ局所的な改善を実装していたとしたら、正式に「IT」ないし「システム開発」と呼ばれるような、より大きな組織では何が起こるだろうか？これについて、巨大なアジャイルプログラムの経験があるコーチが、自分たちの立てた戦略を共有した。この戦略は、より大きな組織がその傾向をつかみ、そこから学ぶことで利益が得られるように作られている。ThoughtWorksのPaulo Caroli氏はこの戦略のことを「ふりかえりについてのふりかえり（"Retrospective of Retrospectives"）」と呼んでいる。巨大なプログラムに関しては常に言えることだが、ここにも考慮すべきトレードオフがある。

フィードバックはソフトウェア開発に対するアジャイル的アプローチの基盤である。これはチームが定期的に立ち止まることにより、「調査・順応（"inspect-and-adapt"）」を行い、プロセスやプロダクトにおける赤信号を監視してそこに対応し、また、そうでなければ絶え間ないリリースの中で見落としてしまうであろうチャンスをつかむという重要なものだ。ThoughtWorksのPaulo Caroli氏によれば、15人のチームが多く集まった彼のプログラムにおいては、チームレベルの改善が行われていたのに対して、プログラム全体は継続的な改善に関してまとまりがつかなくなっていた。

あるチームのふりかえりから生じた行動提案（"action point"）が他のチームに依存していたり、２つのチームの行動提案が相互に矛盾していたりということが時々ありました。

このプログラムが直面していたもう一つの課題は、プログラムレベルのマネジメントにとって、議論し改善するための窓口がないということだった。「プログラムマネージャ（や他の人々）は各チームのふりかえりに参加したいとは思っていました。しかし、同時に複数のミーティングに参加することは単純に不可能だったのです。」

Caroli氏のソリューションは「スクラムについてのスクラム」という知見の上に描かれている。それがふりかえりについてのふりかえりであり、略してRoRと呼ばれている。

日次スクラム（"daily scrum"）がどのようにして「スクラムについてのスクラム」へと拡張されるのかということと同じように（中略）巨大なアジャイルチームにおいて、ふりかえりについてのふりかえりを持つという考え方に行き着きました。（中略）RoRのコンテキストは次のようなものです。「プログラム全体のアウトプットを改善するために、１つのチーム（プログラムチーム全体）として何ができるでしょうか？」

RoRの参加者には各チームの代表者とプログラム全体の代表者が含まれる。ここには各チームのマネージャとそれにチームメンバがもう１人加わる（このチームメンバが加わるということについて、可能であればローテーションで行うことが望ましい）。氏の記事ではプロダクト・マネジメントの参加について言及されていないが、これは記事内で使用されている役割の名称の問題であろう。このミーティングのスタート地点は各チームのふりかえりで挙げられた優先度の高い５項目である。重複は排除され、結果について投票が行われる（これはおそらく議論の順序を決めるためのものだろう）。

ここで巨大なプログラムのジレンマに行き当たる。マネージャにとって、全てのチームに対してメンバ１人１人と向き合っていくのは難しいのだ。そこでチーム単位でマネージャの所にやってくることになる。この他対他のミーティングはおそらく、アジャイルが推奨する小さなグループよりもはるかに大きくなってしまうだろう。そしてこのミーティングにおいて、通常のふりかえりと比べると親密な関係性が失われているということは、ファシリテーションによって埋め合わせる必要があるものだろう。

Caroli氏が挙げた主な恩恵は以下の通りである。

• マネージャとステークホルダが皆、各チームにとって優先順位の高い項目を見ることができる。
• これらは全て、たった１度のミーティングで得ることができる。
• 共通の目標：参加者全員が定期的にプログラム全体の目標を理解し、それに対して行動することができる。
• 全員の意見が聞かれる － どのチームの問題も全てのチームによって共有される。

この一覧が投げかけるのは「ふりかえりにおける守秘義務について何が起こるだろうか？」という疑問だ。この構想においては、期待値の設定はチームレベルにおいて行われるだろうが、将来行われるチームのふりかえりのダイナミクスに影響を与えかねないことが分かっている。チームメンバではない人（チームのコンテキストを知らない人）が結果を聞くかもしれないということが分かっていながら、なおチームメンバは面倒な話題を掘り下げようとするだろうか？強い信頼で高度に統合された組織において、この構想が持つ恩恵はリスクを上回るのだろう。