みなさんこんにちは！RSGT2022で私たちが「インプロふりかえり」という新しいふりかえりの手法を紹介したのをご存知ですか？
その反響は我々の予想を超え、登壇後にはさまざまな方から「実際にはどうやってやるの？」とお声を頂きました。

実は、「インプロふりかえり」には決まった形はありません！（今のところ）
私たちはお客さんの課題や希望に合わせてインプロ（即興）でワークショップを作っているのです。

そこでふりかえりカンファレンス2022では、みなさんの前で実際に「インプロふりかえり」を作っている様子をお見せしようと思います。

当日、数名の方に実際にお話を聞きながら現場の課題を伺い、それに対してインプロの内海がアセスメント（見立て）と最適なインプロワークの提案をし、ふりかえりの田中がそれをどうフリカエルのかを提案します。

参加者のみなさんはその様子を見ることで、私たちがインプロふりかえりをファシリテーションするときに、何を考えているのかを知ることができます。また随所でそれぞれの背景理論を混じえた解説も行います。

私たちも当日何が出るのかわかりません。RSGT2022を見て気になっている方、見ていないけれどなんか興味が出た方、私たちのスリリングなチャレンジを見に来てください。どうぞ、どうぞお楽しみに！

みなさんのチームでは、ふりかえりをしていますか？

今日では、ふりかえりに関するさまざまなプラクティスや経験知が共有されるようになりました。
私たちにとってふりかえりはより身近なものになり、さまざまな場面でふりかえりを活用しやすくなりました。
ついにはこのカンファレンスのように、ふりかえりをテーマにしたカンファレンスが開かれるまでになりました。

その一方で、私たちのチーム「Silver Bullet Club」ではある時期からふりかえりをしなくなりました。
その当時は、モブプログラミング（常にコミュニケーション）しているので必要性が薄れたことと、長く続くチームにとって形式に則ってふりかえりをすることが窮屈になったことが原因だと自分たちで分析していました。

ところが、その後チームの活動を観察したり、他の長く続くチームとの共通点を分析する中で、あることに気が付きました。

ぼくらはふりかえりをやらなくなったわけじゃない、ふりかえりが習慣になったんだ

書籍「エクストリーム・プログラミング」には、次のように書かれています。

コードレビューがよいのであれば、いつでもコードレビューを行う（ペアプログラミング）
テストがよいのであれば、全員がいつでもテストをして（単体テスト）、顧客もテストを行う（機能テスト）
設計がよいのであれば、設計を全員の日常の仕事の一部にする（リファクタリング）

私たちのチームはふりかえりをやらなくなったわけではなくふりかえりが習慣になった、ということに気づきました。それは単に形式的なワークショップとしてのふりかえりを習慣化したのではなく、ふりかえりというふるまいを習慣にしていたのです。

今回は私たちのような長く続くチームがふりかえりをどう捉えているのか、ふりかえりが習慣になるとはどういうことかについてお話してみます。ふりかえりを点／線／面で捉えて、ふりかえりという活動をより深く理解してみましょう。

どんな道をだどったにせよ、当時の知識・技術・能力・利用可能なリソース・状況の中で、みんなができる限り最高の仕事をしたはずです。それを心から信じます

Norm Kerthの最優先指令は、誕生してから21年が経った今なお定期的に取り上げれれる台詞であり、ふりかえり手法の一つにもなっています。
自分自身も非常に強く共感している台詞の一つであり、定期的に思い返し、Retrospectiveを実施する際は勿論、仕事をチームで進める上で意識し続けています。

本セッションでは、この台詞が登場した、Retrospectiveの原点と言えるProject Retrospectivesの本を読み解きながら、本で紹介されているRetrospectiveの意義やRetrospectiveを効果的に進めるためのコツを参加者の皆さんとふりかえっていきたいと思います。
また、セッションの後半では、自身がProject Retrospectivesで特に共感している点を紹介しつつ、Project Retrospectivesではあまり触れられていないRetrospectiveを効果的に行うための観点(Project Retrospectivesにプラスしたいと個人的に考えている観点)についても言及します。

Retrospectiveを原点から見つめ直すことで、参加者の皆さんがより効果的にRetrospectiveやふりかえりを実践するためのヒントになれば幸いです。

昔はホイホイ呼ばれたらレトロスペクティブでファシリテーターをして終わることができていた。
だが、しかし
今は気軽に終わりきらない。
それは、ふりかえりやスクラムマスターが深まったからな気がしている。

私は今、チームに何を還元できるのか
私は今、チームに何を期待されているのか

チームに呼ばれ、フレームワークをして去っていくだけでいいのか
「KPTだYo」でいいのか

せっかくの時間をより豊かな体験にするために考えると良いことをお伝えします

「随分太ったわね」と義母から指摘され、一念発起し、(誰にも気付かれず)半年で12kgのダイエットに成功しました。
ストイックにダイエットした訳でもないのに、半年前、ジェネリック二郎に通いつめていた私は、今やほとんどラーメンを食べることがなくなりました。
この経験から、物事をカイゼンさせる秘訣を掴んだように思い、応用して英語学習やコミュニティ運営でもその方法論を活用しています。
さらにそれは、スクラムチームのカイゼンやふりかえりにも活用できると感じ、チームにも提案し始めています。

「ふりかえりを60日間続けると人はどう変わるのか？ 」と疑問が湧いたの4人のエンジニアの記録です。

業種も職種も全く異なる4人のエンジニアが夜に集まって、お互いの1日のふりかえりを始めました。

60日間毎日ふりかえりをします。

ふりかえり手法は毎日違うものを試しているので、ふりかえり手法について毎日学びがありますし、

集まってふりかえりすることでその場に集まった仲間からもフィードバックを得られます。

また60日間継続するために、みんなでAgreementも決めてやっています。

 2/1から始めていて、現在絶賛ふりかえりキャンペーン実施中！

ふりかえりのやり方はこんな感じ

• 何をふりかえるか？
  • おのおのがその日のふりかえる
  • ふりかえりたいことは各個人で決める
  • 60日間のログ（記録）を取って変化を楽しむ
• ふりかえりの手法は？
  • 手法はみんな共通
  • 毎日変える
    • ふりかえりカタログを参考に
  • 前の日に決める
    • みんなが集まらなかったとき 左の図の番号とN日目と合わせる 2/1が1日目
• やり方はやりながら変えていく

ふりかえりを60日間続けると4人のエンジニアは果たしてどう変わるのだろうか！？

お楽しみに！

皆さん、ふりかえりしてますか？

KPTとか、YWTとか、Fan/Done/Learnとか、手法は色々あって迷いますよね。
でも、ふりかえりを始める前にDPA(Design the Partnership Alliance)をやっている現場って、まだまだ少数派なのではないでしょうか？
私もふりかえりはいくつもの現場でやってきて、何十回とふりかえりはしてきたのですが、DPAを実際にやってみたのは最近だったりします。

DPA(Design the Partnership Alliance)とは、ふりかえりのための「場作り」や「雰囲気作り」のための手法です。
KPTやYWTといったふりかえりの本題に入る前にDPAで場作り・雰囲気作りをしておくことで、ふりかえりの本題での意見交換が活発になり、より効果的なふりかえりになることが狙いです。
詳しいことは黄色いびばさんがQiitaに紹介記事を書いてくれているので、そちらが参考になりますね

このセッションでは、とあるチームの事例を紹介しようと思います。

よそよそしい雰囲気から始まった全体ふりかえり会。単にKPTやYWTをやっても良い方向を向くような状態ではありませんでした。

まずは意見を言いやすい場・言っても大丈夫な場であるということを認知してもらい、安心して貰う必要がありました。
そこで最初に実施したのがDPA(Design the Partnership Alliance)です。

DPAの実施前と実施後でどのようなメンバーの行動の変化があったのか、そしてDPAを実施したことでその後のふりかえりの本題にどのような影響があったのかをケーススタディとしてご紹介します。