Retrospective Patterns 〜 ふりかえりのパターン集の紹介とその補足
『Retrospective Patterns』とはなにか
2011年のAsianPLoPにてチームのふりかえり(レトロスペクティブ)の運営についてのパターン集をまとめたことがある。
ながらくAsianPLoPのサイトからPDFが参照できていたのだが、ここ数年は見当らなくなっていた。オリジナルをどこかにアップしようかとも思ったのだが、ACMの論文サイトからダウンロードできるようになっていたので、そちらのリンクを貼るとともに、少しアジャイル初学者の方向けに解説を付け加えたいと思う。
論文: https://dl.acm.org/doi/10.1145/2524629.2524654
ダウンロード: https://dl.acm.org/doi/pdf/10.1145/2524629.2524654?download=true
Retrospective Patterns＝ふりかえりのパターン集
筆者が2000〜2011年にかけて自分自身のアジャイルの実践や、お客様のアジャイル/非アジャイルのプロジェクトでふりかえりを行ってきた経験をもとによいふりかえりを実施するためのコツをパタン形式でまとめたものだ。
実際は単に「よいふりかえりをする」ためのパタンではなく、チームがふりかえりを通じて成長していく上でぶつかる課題を乗り越えて成長を続けるためのパターン集とも言える。
この読者対象者はチームをファシリテートする人だ。リーダー、ファシリテーター、スクラムマスターがその代表的な対象読者だ。
論文には共に創世記からKPTを実施してきた天野勝さんにもいくつかのパターンを寄稿してもらった。
図2をみていくと、一見矛盾するようなパターンが存在する。
たとえば、8. 《絞り込まれたテーマ》と、9.《自由な意見交換》は一見テーマを設定するものとしないものが混在しているのが不思議に思えるかもしれない。他にも20.《見える難問》と22.《棚上げ》なども一見矛盾しているように見えるかもしれない。
しかしこれらは共に必要であり、状況に応じて使いわける必要があるということを示している。どちらを選ぶかは、まさに読者の文脈にかかっており、そこがパターンとして表現した理由のひとつでもある。
PF、アジャイル、KPTの文脈
このパターンの背景として影響を与えているのがプロジェクトファシリテーション(PF)だ。
もちろん自身のアジャイルプロジェクトでのふりかえりの経験も大きいが、それと同じくらい日本にアジャイルが浸透していなかった時代(2005〜2010)にPFという形でウォーターフォールの現場に週のリズムを作りその中でチームで仕事のやり方を改善していくという試みが大きな影響を与えている。
プロジェクトファシリテーションではKPT(Keep/Problem/Try)を中心にふりかえりを構成しつつ、節目にタイムラインなどを挟み混んだり、たまにその他のアクティビティを交えつつチームの成長や改善を促すということをやっていた。
ちなみに余談だが、Retrospectiveを「ふりかえり」と平仮名で表記するように提案したのは筆者だ。『アジャイルレトロスペクティブス』の後書きにも書かれているマニア的なネタだ。当時の経緯は今は亡きブログのアーカイブに書かれているので物好きな方は見てほしい。
アジャイルネイティブ時代のふりかえり
この数年「YWT(やったこと、わかったこと、ためすこと)」や「Fun/Done/Learn」のようなアジャイルネイティブ時代に生まれたり使われはじめたフレームワークも浸透してきているように思う。
本パターン集は若干「現場改善」「問題解決」という文脈の影響が強い内容になっている。本来は「改善」「問題解決」という枠組みに囚われないチームとしての学びや成長の機会である「ふりかえり」というアクティビティの、ある一側面のパターン集と捉えてもらえると嬉しい。
メタなふりかえり(36. 《ふりかえりのふりかえり》)、ファシリテータ不在の成熟したチーム(37. 《ファシリタティブチーム》)、外部チームとの交流(39. 《異文化交流》)についても触れている。成熟したチームの人が読んでも「ああ、そうだよね」と共感できるところは多いと思う。決して内容は古びてはいないはず…だ。
どのようにパターンを使えばよいか？
このパターンは、ふりかえりというアクティビティのライフサイクル全般についてパターンを列挙している。
冒頭のパターンマップを眺めてみて、自分がうまくいかないと感じているフェーズはどこか、そこに書かれているパターンは何か、という順序で調べていくとよいだろう。
それぞれのパターンについては論文という体裁もあって非常にシンプルな記述になっており、具体例にまで行き着いていない点はご容赦頂きたい。
このパターン集に足りていないものの補足
『Retrospective Patterns』をまとめてから、早や10年近く経つが、その間に自分の中でも様々な気づきや学びがあった。
このパターン集に含まれていないものを簡単に列挙して、読者の役に立てればと思う。
心理的安全
この数年「心理的安全性」の重要性が様々な場面で言われている。ふりかえりは当然として「心理的安全性」が前提になっており、パターンの中でも《安全な場》というパターンでその解説をしているが、実際にどうやって心理的安全性を高めるかについては大きくは触れていないので別途心理的安全性についての情報を参照してほしい。
学びの共有
ふりかえりを、「チームの学びの機会」と捉えると、チームとして何を学んだか、学びどうどう促進させるか、どのように共有するか、という観点が足りていない。
《行動からの学び》というパターンはあるが、そこに書かれているのは行動の評価というべき内容に留まっている。このあたりは学びを促進させる工夫が必要だ。
仮説検証
ふりかえりは「チームの成長を仮説検証しながら進むこと」と捉えるならばすべての行動は仮説検証となる。チームは「自身の成長仮説」を各ふりかえりで立てそれを実証していくことになる。
仮説については《行動優先》にて触れているが、まだまだ踏み込み方が足りていないと感じる。このあたりはプロダクトの仮説検証の応用として様々な工夫ができるだろう。
アジャイルはすべてが仮説検証といってもよい。仮説を立てそれを検証しながら進むことで、チームもプロダクトも進化していくのだから。
ECRS
このパターン集は特に「現場の改善」という部分に着目している。これは時代背景として非アジャイルプロジェクトでのふりかえりの目的が「現場改善」を指すことが多かったというものがあるためだ。
改善という観点で言うならばECRSの観点は常に持っておかないといけないがECRSについては本パターンをまとめた時に抜けおちてしまっていた。
ECRSは、Eliminate（排除）、Combine（結合と分離）、Rearrange（入替えと代替）、Simplify（簡素化）の英語の頭文字を選択したものである。
本パターンでは何らかの行動によって改善しようとする表現をしているが、ともすると改善とは「何かを付け足すこと」という視点で捉えてしまいがちだ。
ECRSの順番の通り「何をするか」だけでなく「何をやめるか」にフォーカスしなければならない。現在行っていることを批判的にみつめて「そもそも必要があるのだろうか？」という問いかけをしていかないといけない。
プロダクトを作る上でも、チームを改善する上でも「そもそも、それって必要だっけ?」という問いは常備しておきたいところだ。
感情表現
現在の自分は「チームは適切に感情を表現できているか」が重要だと考えている。これは前述の心理的安全性にもつながるのと、感情そのもの、その感情が生まれる理由や本人が求める具体的な要求をうまく表現できていないとコミュニケーションを円滑に行えないからだ。
《開かれた心》でNVC(非暴力コミュニケーション)について補足はしているが、実際に実施する上では足りない。是非NVCについても学んでほしい。
「いのち」のサイクル
今は、KPTに変わるふりかえりのフレームワークとして「いのち」のサイクルというのを提唱しています。こちらは徹底的に自己を肯定してのびしろを伸ばしていくというスタイルです。御興味のある方はこちらも是非御読みください。
最後に
論文に含めるべきだったが含められてないこととして、本パターンは当時、児玉公信さんにシェパーディング頂きました。シェパーディングのやりとりを通じて様々な示唆を頂き論文の改善に大変役立ちました。時を越えて改めて感謝を述べさせて頂きます。
