先日記事を書いた通り、ふりかえりカンファレンスに参加&登壇してきました。
当日はlean coffee形式でセッションを進めたこともあって、話せるように準備をしてきたものの一部しかお話することができなかったので、今日は話していなかった部分について、事前に準備していた話の一部を公開してみようと思います。(事前に準備しておいたものを全て公開することも考えたのですが、分量が多く読むのがなかなかしんどそうなのと、事前に準備していたものは口語形式でブログに乗せるために文体や表現を整える作業が大変だったので断念しました。。。)
また、一応有料のカンファレンスということもあり、当日話した部分については載せていません。
- 前提
- Project Retrospectiveがスクラムに与えた影響
- Retrospectiveという言葉に込められた想い
- Retrospectiveの前に行う準備
- Retrospectiveをなぜやるのか？
- Retrospectiveを具体的にどのようにやるのか？
- Retrospectiveを組織に広める(上司に理解してもらう)ためには？
- Retrospectiveのファシリテート
- Retrospectiveでネガティブなことをふりかえる時に気を付けること
- 個人的に本書で好きなポイント : 長期間のふりかえりを推している所
- 個人的に本書で好きなポイント : チームにふりかえりの形を適合させる試みをしている所
- 個人的に本書で好きなポイント : Norm Kerthが実際に立ち会った現場の物語が記述されている所
- 個人的に本書で補いたいポイント : ファシリテーターが必須だと話している所
- 個人的に本書で補いたいポイント : 失敗からの方が多くのことを学べると考えている所
前提
当日も話しましたが重要なことで最初に前提をお話ししておくと、このProject Retrospectiveは半年程度のプロジェクトが終わった後に、3～4日かけて行うふりかえりのことをRetrospectiveと定義しています。
以下、Retrospectiveという言葉が出てきても、スクラムでいうSprint Retrospectiveの話ではありませんのでご注意ください。
Project Retrospectiveがスクラムに与えた影響
ここは当日皆さんが興味あったようで、準備していたことのほとんどを話しました。
(スクラムの話ではありませんが)唯一話していなかったこととして、Norm kerthは2000年, 2001年にアリスターコーバーンとワークショップを開催したり、パネルディスカッションをしていたりしていたことがあります。
Agile Software Developmentで提唱されたリフレクションワークショップにも、何かしらの影響を与えていたのかもしれません。
Retrospectiveという言葉に込められた想い
ここも当日にある程度話をしました。
個人的に面白いのは、心理的安全性という概念が登場する以前から、Norm kerthは参加者が恐れなく思っていることを気兼ねなく言える場を重視していたということです。
ホーソン実験の話に通じるところもありますが、心理的安全性という概念が生まれる前から(多様性の重要性や対人コミュニケーションの重要性が騒がれるようになる前から)、既に心理的安全性で言われているような概念は見つかっていたんだなーという点は非常に興味深いです。
Retrospectiveの前に行う準備
幾つか話を用意していましたが、個人的に面白いと感じている部分を3つお話します。
参加メンバー(特に管理職)とつながりを持っておく
レトロスペクティブの参加者(プロジェクトのステークホルダー全員)の中でも特に管理職の方の意見は貴重ですが、参加メンバーの中で管理職は発言が持つ意味が重くなりがちなので、話を事前に聴いて、当日はなるべく話をしないようにしてもらうなどといった工夫をしておくことが大事です。
管理職がそれでも当日話しすぎてしまうという場合は、議事録係をやってもらって、議事録に取れた発言内容に対してもコメントしかしないというルールにすると、多くの場合は話す余裕がなくなるはずです。
管理職から引き出しておきたい話としては、ステークホルダーの整理があります。
ステークホルダー整理のTipsとしては、なんでこの人がいるのか？というのを明らかにするのと、非公式なネットワークを記載することの2点に気を配るのも重要です。
定量的なデータをなるべく集めておく
これは分かりやすくて、例えば
- ソースコードの行数がどれくらい増えているのか
- バグの数は幾つか
- 何月に何をしていたのか
- どれくらい外部ライブラリを使ったのか？
- テスト密度
- 残業時間
などなど、レトロスペクティブのネタになるような指標は事前に集めておいた方がふりかえりは捗りますし、こういった指標はないの？というものがあれば次のPJでは開始地点から収集しておくことが重要です。
チームがふりかえりにスムーズに入れるようにしておく
安心安全な場を作るというのは勿論、事前にアンケートをとっておくことで一人でふりかえりをする時間を確保して置いたり、いわゆるDPAのようなエクササイズを通して、どのようなふりかえりの場にするかを検討したり、あとは心身に蓄積しているダメージを回復させたり、ということが重要です。
心身に蓄積しているダメージの回復については、本書の中でもかなり分量が割かれていて、Norm Kerthが大事にしていた概念であることがよくわかります。
Retrospectiveをなぜやるのか？
びばさんが書いてくれているふりかえりチートシートでも複数の目的ごとに手法がマッピングされており、多数の目的があることは既知の話ですが、レトロスペクティブの目的としては、書籍内でも様々な目的が挙げられています。以下、幾つかピックアップをしてみます。
チームメンバーが仕事の進め方を改善するための動機付けになる
レトロスペクティブというイベントを通して強制的に立ち止まることで、よりよくなるための改善点を洗い出す動機がチームメンバーには生まれます。
また、表現がやや不適切かもしれませんが、みんなの貴重な時間を取って開催したレトロスペクティブで出た改善アイテムだから、という改善をする必要がある口実が生まれます。*1
チーム間の協力関係を築く
問題に対してチーム全員で向かい合うことで、チームが協力して仕事をする意識づけができるのは勿論、普段は別で働いている多数のステークホルダーが集まることで、チーム同士の関係性について見直し、どのような協力関係が望ましかったのか？今後望ましいのか？ということを考えることができます。*2
学習
ここは当日も少しだけ話をしました。
定量的なデータを基にふりかえりをしたり多くのステークホルダーが集まり様々な観点を出し合うことで、特に学習の効果は高まるとされています。
その他
スクラムの文脈に近い所では、定期的に立ち止まって検査をすることで変化のスピードに対応するためという理由があったり、メンタルヘルスとしてもやもやしたものを出し切ることで心身のダメージを軽減させることも目的として記載されています。
Norm Kerthは、過去と同じ形式で行われるレトロスペクティブを懐疑的に考えていて、チームの姿に合わせて実施することを推奨しているので、レトロスペクティブの目的がこれだけ多いのも個人的には納得がいきます。
Retrospectiveを具体的にどのようにやるのか？
実は本書の中で一番分量を割いて解説されているのが具体的にレトロスペクティブをどのようにやるのか？です。
なので、とても全部は紹介できないですが、一部個人的にやってみたりプレゼンで過去に事例を聴いたりして面白いと思っているものを紹介します。
Artifacts Contest
PJに寄与した重要な成果物をみんなで出し合い、一番チームの皆から賛同を得た成果物を出した人が優勝する、という手法です。
重要の定義はチームごとに異なる想定で、例えば単純に成功/失敗に寄与したかどうかでもいいですし、一番誰しもが想像できていなかったけど大切だったもの、とかでも良いです。
また、優勝した成果物は後継のチームが見える所に飾っておくと、体験が物体として残り、皆の記憶に残りやすくなります。
Passive analogy
これは、好きな映画をみんなで見て、自分たちのプロジェクトにどんなところが似ていたか、どんな所が教訓として得られそうか？というのを考えるというふりかえり手法です。
リラックスしながら普段使わない認知スキーマを起動して、普段得られない洞察を得るのが狙いです。
メタファーを参考にアイデアを考えるという手法は熱気球とかもありますが、これと比較すると、映画の方が自由度が高いかつコンテキストを共有しやすいため、チームに合わせたふりかえりにすることがよりやりやすいのかな、と思います。
Repair Damage Through Play
これは文字からも連想されるように、チーム協働で何か遊びをしたり、場合によっては一人にして散歩してもらったりして、とにかく参加者のダメージを軽くしようというふりかえり手法です。
レトロスペクティブの目的の一つに、Norm Kerthは身体のダメージの修復も上げており、まさにその目的に特化したようなふりかえり手法となっています。
project retrospectiveで紹介されているレトロスペクティブは半年のPJを3日間で行う前提で書かれているということもありますが、Norm Kerthは上記で紹介した手法をはじめ、本書に記載されているふりかえり手法を組み合わせるということを大切にしています。
なお、Norm Kerthはパターンランゲージにも影響を受けていたようで、これがふりかえりを組み合わせるみたいな考え方に影響しているのではないか？という推測もあります。
Retrospectiveを組織に広める(上司に理解してもらう)ためには？
パターン1
変化に対して前向きな上司や組織に対して使うパターンです。
このパターンでは、とにかく変化する自信を上司や組織に与えることで、行動を促していきます。
パターン2
変化することに痛みや恐れを感じるけれど現状に満足していない人に対して使用するパターンです。
この人には、過去に変化を怖がるきっかけとなった経験をヒアリングし、その時に経験したことが起こらないようにふりかえり手法を工夫します。*3
更に、これはちょっと個人的にはどうかと思う所もあるんですが、学びをレトロスペクティブで重ねないと今回と同じようなPJになってしまうリスクがあるという話を失敗したPJのメンバーには伝えることで変化を促すことが効果的だという話も挙がっていました。
パターン3
変化することに痛みや恐れを感じるし現状に満足している人に対して使用するパターンです。
このパターンの人には、レトロスペクティブをやることを押し付けずに、積極的に悩み相談にのり、解決をしてあげることが重要だとNorm Kerthは話しています。
悩みを解決していくことで、次第に変化が素晴らしいものだと気が付き、自分でもそのコツをつかみたくなるため、コツをつかみたくなるまではレトロスペクティブという方法にこだわらず、とにかく悩みを聴くことを大事にしているということです。
なお、どのパターンにも共通して、Norm Kerthが提言している注意点もあります。
まず、押し付けをしないということです。レトロスペクティブをやるといかにいいのか、ということは勿論伝えるのですが、レトロスペクティブをどんな時も絶対やらないといけないとか、絶対やるものだ、といった押し付けはレトロスペクティブを仮に開催できても効果が期待できないので、的外れなアプローチだと言っています。
また、これはよく言われることですがその人が何に困っているかを大切にして、手段にこだわらないことが重要だという話もしています。過去うまくいった方法でふりかえりを続けることや、ふりかえりという手段にこだわりすぎることも注意しています。
最後に、正しい選択をしたり失敗に目を向けることを恐れないこと、チームが夢を見ることを恐れないこと、というのも挙げています。
Retrospectiveのファシリテート
ここは当日話をしました。
自分以外のセッションでも、ファシリテーターとしてレトロスペクティブでどのように振舞うのかを悩んでいると話されていた方は複数人いらっしゃり、皆さん興味があるテーマなんだなあと当日感じました。
Retrospectiveでネガティブなことをふりかえる時に気を付けること
こちらも当日話しましたので、内容を省略します。
個人的に本書で好きなポイント : 長期間のふりかえりを推している所
Norm Kerthは、長い期間、具体的には3日間かけてふりかえりをすることを強く推奨しています。*4
勿論プロジェクトの期間が半年という前提もありますが、自分はこの長期間のふりかえりには多く学べることがあると考えています。
自分はイベントに参加して色々なチームの事例を聴くのが好きで、色々なイベントに参加していますが、ふりかえりが絡む事例の話は本当に多く語られる印象があり、2021年の1年間で439の事例を聴いています。
でも、ここで長期間のふりかえりをしたよっていう話は2件しか聞いたことがありません。頻繁にふりかえりをすることでチームがよくなった、とかふりかえりを日常的にやった、とか、ふりかえりを短くすることで得られる効果の話が殆どな印象があり、長期間のふりかえりはあまり重要視されていない気がしています。
自分は長い期間のふりかえりの方が短い期間のふりかえりよりいいよね、という意見を持っているわけではないのですが、本書で書かれているような長期間のふりかえりを何日もかけたからこそ得られるようなメリットは、実はあまり多くのチームが享受できていないんじゃないか？というのは今一度問いかける必要があると思っています。
ちなみに、自分がこういうことを思うきっかけになったのは、夜のOSTとかコミュニティ活動で出逢った雑談です。
すごく長い時間をかけて話をしていくことで、自己開示のハードルが下がってなかなか人の目を気にして言えないことが言えたり、自分の気持ちを味わいきったりして心身のダメージが回復するとか、そういう経験をOSTでは多くしてきました。
これって、勿論参加者の皆さんが素敵だから、というのはあると思うんですけど、かける時間の単位を大きく変えていることで、無理なくステップバイステップでコンテキストが形成されて自己開示につながったりとか、もあるのかな、と考えています。
個人的に本書で好きなポイント : チームにふりかえりの形を適合させる試みをしている所
ここは当日話をしました。
Project Retrospectiveとはあまり関係ありませんが、個人的には、手法は変えずにふりかえりの中身をどう変化させていくといいのかみたいなことを考えた話、そこでどんな議論が出たのか？みたいなのは非常に興味があるので、是非事例があれば聴いてみたいです。
チームにあったふりかえりを探す事例だと、色々なふりかえりをするという話はよく聴きく印象があり、これ自体は本当に素敵な方法だと思っているのですが、*5多くのチームはふりかえり手法を変えるって言うのに結構戸惑いがあったり準備が大変*6とか、ふりかえり手法を変えにくい力が働いているようなチームに対して適合するやり方ではないと思っています。
また、同じふりかえり手法の中でチームにあったふりかえりを見つけていくっていうある種の制約をつけることで、何かしらふりかえりに対して新しい発見があったりとか、より色々なチームに取り入れられるふりかえり改善案みたいなのがでてくるのかな、とも勝手に期待しています。
個人的に本書で好きなポイント : Norm Kerthが実際に立ち会った現場の物語が記述されている所
本書では、True Storyという名前で、Norm Kerthが立ち会ったプロジェクトで起きたリアルな話が至る所で書いてあります。
今日のようなカンファレンスとか、あとは日々されているイベントとかがすごく好きで色々なイベントに参加している所とも繋がるんですけど、これが個人的には気に入っています。
実際にNorm Kerthの様子を追体験することで、文字を読んだだけでは「まあそれはそうだよね」位のテンションで読んでいたアイデアが、どういうコンテキストでどれ位価値があるのかをイメージできたりしますし、物語としてインプットされることでやっぱり記憶に残りやすいですし、伝達もしやすいです。
個人的に本書で補いたいポイント : ファシリテーターが必須だと話している所
ここは当日話しましたし、ふりかえりカンファレンス当日も含め、色々なところで議論がされているので、割愛します。
個人的に本書で補いたいポイント : 失敗からの方が多くのことを学べると考えている所
プロジェクトレトロスペクティブでは、失敗したことを繰り返さないことが大事だと話をしていて、失敗からの方が多くのことを学べるということを言っています。
勿論失敗から学ぶ意義って言うのは分かるのですが、個人的には失敗からの方が多くのことを学べる、というのは少し違和感を持っています。
もう少しちゃんと言うと、自分は失敗から学ぶことが大事なのではなくて、失敗から学ぶことができる関係性を築くための土台を作る過程を経ることが大事なんだろうな、と思っています。
失敗したことをふりかえるのってすごく難しくて、誰かのせいにしないようにコミュニケーションコストを高く払ったり、大きな象をみてみぬふりをするという話があるようにそもそも勇気を持って失敗に向き合うっていうことが必要になってきます。
こういうことができるようになるために、色々やることはあると思いますが、例えば日頃から向き合えるだけの時間とか体力を作るとか、率直にフィードバックをしあうことに慣れるとか、失敗をふりかえれる土台をつくるっていう行為を積み重ねる過程に凄く価値があるのかな、と個人的には考えています。
なので、失敗から学べるチームになるためにはどうしたらいいんだろう？っていうことを考え続けることに意義があるのかな、と思います。
また、もう一個の側面として、そもそも失敗から学ぼうとか成功から学ぼうみたいな軸をあまり持たない方が学びって得やすいかな、と個人的には感じています。
ふりかえりから学びが得られたと感じる時って、「何かしらの行為を捉えて、その行為ってどのような因子がどうやって寄与したかというのを特定することができた」という状態が個人的には多いのですが、この時に、結果として起きた行為に対して失敗とか成功みたいな概念を持たせてしまうと、「こういうことをしたらうまくいく」とか「こういうことをしたら失敗する」という教訓が生まれやすくなり、結果と行為の結びつきが曖昧になって学びの転用が難しくなることが自分は多めです。
なので、成功よりも失敗からふりかえることが大事だ、みたいな視点をあまり持ちたくないな、と個人的には思っています。
