みなさんがふりかえりをする時、もしくは参加している時にこんなことを意識したり考えたりしたことはありませんか？

• 今日はいつもより発言が少ないかも。
• 今日は雰囲気が暗い感じがする。
• いつもAさんがいると場が和む気がする。

その感覚は「場づくり」を意識するのにちょうど良い感覚です。ふりかえりなど何かをするために集まっていることを「場」として捉えて、事前に「場」に対して準備したり、その「場」を観察してファシリテーションしたり、今回の「場」と次の「場」の間にできることをしたり、「場」というものは「つくる」ことができます。

いい感じのふりかえりを行うために「場づくり」という意識の仕方、考え方をを知ってみませんか？

今回は、ふりかえりカンファレンスのセッションで実際に「場づくり」して、それを解説して、みなさんに「実体験」として持ち帰っていただければと思います。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ふりかえりカンファレンスに参加する多くの方が、アジャイル開発の文脈の中での「ふりかえり」を期待している、というイメージを私は持っています。

しかし、「ふりかえり」はアジャイル開発だけのものでしょうか？
いいえ。世の中にはたくさんの「ふりかえり」があります。
その中から「ふりかえり」の手法を学ぶきっかけに、このセッションがなるでしょう。

その中で、ボードゲームの一種である「TRPG」の中には、独自の「ふりかえり」の文化を発達させ、定着させたものがあります。

「TRPG」は、どの様にふりかえりの文化を発達させ、定着させていったのでしょうか。
これは、僕の「ふりかえり」の原体験の物語でもあります。

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

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

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

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

社内で自称ふりかえりエバンジェリストとして活動しています。
チームでのふりかえり経験も100回をこえ、別の開発チームから、ふりかえりの設計・ファシリテーションを頼まれたり、社内でふりかえりで大事なことについて発表した結果、他部署からもふりかえりの相談を持ちかけられるようになってきました。

「このチームのコミュニケーションをもっと良くしたい」
ふりかえりをやろうと思う人の多くが考えていると思います。

ただ厄介なのは、コミュニケーションの課題の多くを占める「遠慮」は「目に見えない」ということです。課題として捉えづらいからこそ、放っておくとジワジワとチームの創造性や生産性は低下していきます。

そこで、チームの心理的安全性を可視化するワークショップ「片思いマッピング」を設計して社内のチームで実施してみました。記事化してみたら「Twitter」や「はてぶ」で思ったよりも反響があったので、チームでのふりかえりをする方々の役に立てればと思い紹介させていただきます。

また今回のふりかえりカンファレンスでは、ふりかえりの設計に興味をもっている人向けに記事には書いていないワークを作り上げた過程も一緒にお話ししたいと思っています。ヒアリングによる課題抽出や、コンテンツの設計など、片思いマッピングを作るまでに僕が考えていたことをお伝えすることで、ふりかえりの設計・ファシリテーションに関心のある方々のヒントになればとても嬉しいです。

ふりかえりカンファレンス2021で「ふりかえりの傾向と対策～ふりかえりのふりかえりから作法を学ぶ」というテーマで一部ワークを交えて発表させていただきました。スライドリンク
その際に、私がふりかえり実践を通じて実感している「ふりかえりの効能」として（発表スライド5）

(1)相互理解
(2)チーム学習
(3)合意形成と実践促進
(4)価値観共有・共創～そして浸透

の4つを挙げましたが、今回は(4)をテーマにした実体験に基づく考察結果をお知らせします。

顧客や社会により高い価値を、スピード感を持って創り出し、提供しつづけるために、人間一人でできることはそう多くはありません。
だからチームで立ち向かう必要がある。
しかしベストメンバーが揃わないのはあたりまえ。
その場に集められたメンバーで、VUCAな環境下で度重なる難題・逆境に立ち向かうのは簡単ではありません。
そんな時にこそメンバー間の連携や協調等による相乗効果の発揮が求められます。

私は自らの経験則から、チームのチカラを高める相乗効果を獲得する条件の一つが「チームの価値観」なのではないかと考えています。
この発表では、以下の内容をみなさんにお知らせする予定です。
・価値観？なにそれおいしいの？
・それは意図的に創れるの？
・ふさわしい価値観の共創、浸透には何が必要なの？
・ふさわしい価値観が浸透すると何が起きるの？

この発表を通じて、単なる反省会としてのふりかえりではなく、ふりかえりが持つ隠れたポテンシャルを一緒にイメージできればうれしいです。

私は、悩んでいました。

普段はアジャイルコーチとしてエンジニアと対話する機会はあるのですが、
自分が体験していない技術的なプラクティスを彼らに提案することに違和感がある。。。
自分が体験して、感じた言葉でないとエンジニアには通じないのではないか。。。

エンジニアと同じ言葉で話せれば、ふりかえりでもきっと、もっといい対話ができるはず！！
しかし現実には、JavaScriptがjavaの進化系と思っていたレベルの知識の私が、
ウェブ開発の広大な技術を今から習得するのは不可能に近い。。。。

と、悩んでいても仕方がないと、一念発起。
現役プログラマーである、さとりゅーさんを頼り、
業務の傍ら、
最初の1ヶ月で、人生初のJavaScriptでのウェブサービスをローンチ！
次の1ヶ月で、GitHub,heroku含むパイプライン整備やORMを用いたDB操作を行ってサービスを拡充。
その次の1ヶ月では、AWSの入門と言われるソリューションアーキテクトアソシエイトを取得。
現在は、Terraformとコンテナを用いて上記のサービスをAWS上で再構築中、と。
なんとか、エンジニアの言葉を理解することができるようになってきました。

そして、歩んできた道のりの中心には、
さとりゅーさんとの結構なふりかえりの時間とふりかえりのやり方の試行錯誤がありました。
最初は、作業ログをつけて、30分ごとに自身がやったことをふりかえることからはじめました。
気がつくと、デイリー俯瞰して、できたことをできないことのふりかえりが習慣になりました。
そして、デイリーのふりかえりの結果を、ウィークリーでのメンタリングセッションで共有することをはじめました。
結果的に、マンスリーで自分の成果も見えるようになって来ました。
これって、もしかして、フラクタルでのふりかえり構造なのではないかということを思い始めています。
（https://kyon-mm.hatenablog.com/entry/2019/09/11/083000）

知識レベル最底辺から、知識獲得にトライしてみた私たちのふりかえりスタイルを紹介することで、
なにか、みなさまの知見になればと思ってご紹介します。

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

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

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

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

「失敗を許容する文化」という言葉をよく聞きます。
しかし実際には、失敗するとだいたい叱られます。
なので、失敗したくありません。

叱られると「反省」し、改善方法を考えるのでまだましかもしれません。
失敗した事自体に気付いていない状態が最もよくない状態かと思います。

どうすれば失敗した事に気付けるのでしょうか？
どうすれば成功した事に気付けるのでしょうか？
どうすれば、”やった事”から学びを得ることができるのでしょうか？

そのためには、何を「実験」するのかを明確にする必要があります。
実験なので、うまくいく事もいかない事もあります。
うまくいってもいかなくても、学びがあります。

しかし、我々はすべての活動を「実験」と捉えて活動しているわけではありません。

そこでご紹介するのがClebration Gridというツールです！
Celebration GridはManagement 3.0という考え方で紹介されているプラクティスの１つです。

実施した活動がどういった位置づけの活動だったのかを明らかにし、何を学んだのかを引き出す手法です。

本セッションでは、Celebration Gridを明日から使えるように、5分間で説明と勘所をおつたえします。

Celebration Gridの勘所を知りたい方、Celebration Gridって何という方、新たなふりかえり手法を知りたい方、ふりかえりが形骸化していると感じられている方は、ぜひご参加ください！

私はふりかえりが嫌いです。正確には「定期的にチームや他者と行うふりかえりの場」が嫌いです。(※嫌いなだけで重要性は重々承知しているので、ちゃんと能動的に参加するようにしています。くれぐれも誤解なきよう)

なぜ「定期的にチームや他者と行うふりかえりの場」が嫌いかというと、ふりかえりなんて24h/365days 常に行い続けるものだと思っているからです。チームの定期なふりかえりの場に参加すると、既に自分の中で何度もふりかえりを実施済みなので、新鮮味が薄くて勝手にダレてしまうんですよね。(それはそれとして、他者と意見のすり合わせや合意形成することは非常に重要なので、もちろんチームのふりかえりにもちゃんと参加しています。大事なことなので2度言いました。)

じゃあ、「一人で」「勝手に」「常に」やり続けるふりかえりってなんなんだ？ どうやってやるんだ？ それをどうやってチームと共有するんだ？ そもそもそんな方法あるのか？

私が今もやり続けている常中ふりかえりの内容をお伝えしたいと思います。

KPT に始まり YWT やカスタマイズしたふりかえりなどいろいろ試行錯誤してきました。ふりかえりはいつも盛り上がり、予定しているタイムボックスをオーバーしてしまうことがしばしば。しっかり押さえるところは押さえつつ、効率良く時間内に終わらせるために辿り着いたプラス／デルタ。単に「良かったこと」「カイゼンしたいこと」だけではないプラス／デルタのやり方をご紹介いたします。

人生ではじめて 『ふりかえり』をやってみて、感じたことをお話しします。

さらに、実験的に毎回異なる手法でやってみて、気づいた各手法の得意/不得意な点も共有します。

初めてのふりかえりファシリテーションを、ZoomとＭiroをつかって実施した際の工夫と結果を話します！

これからファシリ初挑戦する人の参考になれば幸いです。

「ふりかえりを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を実施したことでその後のふりかえりの本題にどのような影響があったのかをケーススタディとしてご紹介します。

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

カンファレンス運営にもふりかえりは必須です。
毎回カンファレンスを開催するたびに、今回のカンファレンスをふりかえり、次回のカンファレンスについて話します。
さらにあじゃてくでは、ふりかえり実践会の森さんにファシリをお願いし、
５年後10年後のあじゃてくの未来の姿について、語り合うことができました。
ビジョンが共有できてとてもよかったので、この経験を共有したいと思います。

三菱UFJ銀行のシステム部門でアジャイル開発を始めてから7年目になりますが、
アジャイル開発案件はごく一部で、新しく始めた場合にはチームメンバー全員がアジャイル初心者、というケースも多いです。
アジャイルコーチの初心者チームへの支援を見ていると、ふりかえりを行うことでチームメンバーが徐々に改善の意識を持っていき、チーム立ち上げ期のふりかえりの重要性を実感しました。
1年目案件の事例から、チーム立ち上げ期ふりかえりのポイントを語ります。

また、立ち上げ期を過ぎたチームは、その後どうふりかえりをチームに最適化させていくのかについても、3年目～7年目のチーム事例と併せてご参考で説明します。

みなさん、ふりかえりのファシリテートをするとき、どんなことを考えていますか？
「準備をしないと」、「タイムマネジメントをしないと」、「意見を引き出すために問いをださないと」など様々なことを考えると思います。
しかし、これらは最初から誰でもできるわけではありません。できたとしても、負担に感じてしまう人もいるでしょう。

そこで、誰でも簡単に質の高いふりかえりができるWebアプリを作れないかと、半年前に思い、開発を進めてきました。
今回は、そのβ版を使ったふりかえりをご紹介します！