読書メモ。2025年58冊目。
『アジャイルレトロスペクティブズ』を読んでの感想となります。（2025/8/7記載）
本の概要
アジャイル開発の核心ともいえる「レトロスペクティブ（ふりかえり）」について実践的に解説し、高く評価されている原書Agile Retrospectives: Making Good Teams Great（2006年7月発行）を翻訳。
チームの状態を点検・改善してプロジェクトを成功に導くレトロスペクティブの方法を具体的に詳解する。
このような方におすすめ
・ソフトウェア開発者をチームで行っている人
・なかでもすでにアジャイル開発を実践している人
引用：
動機
- 今年４月のふりかえりカンファレンスに参加してはじめてチームでふりかえりを行うことの重要性を実感できた。
- ふりかえりカンファレンスでの翻訳者角さんの登壇から学ぶところが多かった。
- 今こそふりかえりを学びなおしたいとき。
今日は我々にとってのレトロスペクティブ、ふりかえりとはなんなんだという議論を交わした熱い１日でした。
— 幡ヶ谷亭直吉@技術書典18さ05 (@asagayanaoki) 2025年7月31日
本書からの学び
自分がエンジニアとしてキャリアを始めた2007年に翻訳された本ですが、今の自分にとっても大きな学びとなる部分がありました。
同時に、今のようなスクラム開発に携わる前のウォーターフォール開発においても、リリース後にふりかえりを行っていたことを思い出しました。
リリース後にチームが解体されることもよくあったので、ふりかえりからの学びは個人成長にも活かせるけど、実際の事業的にはどこに還元されるのだろうともやもやしていたことを思い出しました。
もしかしたら、その当時この本に出会っていたら、もっと違う捉え方ができたかも知れないとも思いました。
また、文章では特別に取り扱われていないものの、今と変わらないふりかえりにおける本質的な価値観があることにも気づきました。
特にふりかえりの主役はチームであって、ファシリテーターはその場を推進していく役割であることの説明は、
2007年から変わっていなかったことに気付き、もっとその価値観に気付けていたらと思うところもありました。
アジャイルレトロスペクティブズ第２版が今から楽しみです。
忘れたくないメモ
本書で特に印象に残ったポイントを振り返ります。
チームのオーナーシップ
レトロスペクティブでは、チームはマネージャーの許可を待たずに解決策を実行することができる。試みや変更はチームの手によって選ばれたものであり、上から押し付けられたものではない。だからこそ、成功に向かって邁進できるのである。
チームが主体的に能動的に動くことが前提。
事実と感情
チームの不具合データを確認して、イベントやフラストレーションを感じたことについて尋ねた。こうすることで、各自が自分の知っているデータだけで考えるのではなく、みんなが同じデータについて考えることができた。そして、 チームメンバーに事実（不具合データ）と感情（フラストレーションの所在）を調査してもらった。
ふりかえるとき、私たちはどうしても「体験の印象」だけで語ってしまいがちです。
そうすることで、印象や思い込みに引きずられている部分がある気もします。
会話を始める前に、もう一度何をふりかえるべきかの事実の確認をしたい。
チームの価値と約束によって、会話や相互作用を生産的に保つ
私たちは、場を設定する時間を無駄だとは思っていない――あなたもそう思うべきではない。この部分の時間を「節約」すると、あとになって高くつくのだ。最初の段階で喋らなかったら、あとから口を開くこともなければ、チームの見解や決定を受け入れることもないだろう。場を設定しなければ集中することは難しいし、 時には話が脇道にそれてしまうこともある。チームの価値と約束によって、会話や相互作用が生産的に保たれるのだ。
何事も準備が大事。
何かを始めるための準備も始まってからと同じかそれ以上に大事にしたい。
感情について話す
みんなが自分たちの感情について話せる仕組みを作ることで、感情的に負担のあるトピックを取り上げることに抵抗がなくなる。感情的な内容に言及することを避けていては事態は進展しない。問題は表面化されず、エネルギーとモチベーションが徐々に吸い取られていくだけだ。そうでなければ、その感情は怒りとして表れる。 怒りにまかせた口論はレトロスペクティブのためにはならない
感情を知ることでチームにダイナミクスが生まれる気がします。
チームを大切にすることを前提に、感情の扱いを大事にしたい。
最初に思いついた解決策はだいたいいつも間違っている
問題が起きると、人はすぐに解決策に飛びつきたくなるものだ。しかし、最初に思いついた解決策というのは、正しいこともあるかもしれないが、だいたいいつも間違っている。このフェーズでやるべきことは、さらなる可能性を調べ、原因とその影響を見て、それらを分析的に考えることだ。またこれはチームが一緒になって考えるときでもある。
自分の過去の経験に刺さります。
ただ、過去に経験したから刺さる部分もあるので、主目的をもって間違いを改善することが重要なんじゃないかとも思います。
それを繰り返すことで、私たちは粘り強くよりよい解決策について考えることができる気がします。
ファシリテーターの議論への参加
議論の内容が自分のチームにかかわるものだと、ついつい議論に参加してしまいがちだ。個人的に関心のある場合は特にその誘惑にかられてしまう。しかし、内容に踏み込んでしまうとプロセスに十分な注意を払うことができない。しばらく考えてから、あなたの考えが必要かどうかを決めること。たいていの場合、あなたが何か言わなくてもチームはうまくやれるものだ。リーダーが何度も割り込んでくるとグループの議論が鎮められてしまう。
ファシリテーターの議論への関与。個人的にも大きな反省があります。
ちょうど本日Xで似た内容のポストがありました。
これ。
— Takao Oyobe (@TAKAKING22) 2025年8月7日
輪番にすることで誰かではなくチーム全員でまわしていきたいということを狙ってるんだろうけど、掃除当番のように作業をまわすだけになってしまって担当者のレベルに合わせてコミュニケーションの質が下がっているのだとすると本末転倒。 https://t.co/shKlCtP8tm
リーダーのものじゃなくチームのものとすることが重要で、失敗してもチームが改善していければと思っていましたが、個人が特別な役割になると改善が難しくなる印象も受けました。
ただ、やっぱりリーダーやスクラムマスターがやるより、チームがやった方が良い。
感想を聞く
すべてのアクティビティについて感想を聞くこと。感想を聞くことで、チームは自分たちの経験を吟味し、新たな見解を抽出することができる。意識的なつながりを作れば、新しいアイデアを生み出すことができる。各アクティビティの感想を聞くことで、レトロスペクティブにおけるアイデアや決定につながっていく。
したがって、感想を聞くことは超重要なのである。
最近、やっと感想を聞くことの重要性を学び始めました。
感想を聞かない限り、個人の感想はチームのものにならない。
個人の感想が発露されることで、チームの体験となっていく。
その積み重ねがチームとしての有機性を生んでいくイメージをしています。
チームの約束
遅かれ早かれチームの約束は破られてしまう。人はどんなに強い意志を持っていても、昔のパターンに戻ってしまうことがある。そんなときは、まず、チームの約束を思い出してもらうこと。チームの約束が破られているのに何も言わなければ、 チームの約束が任意のものだと受け取られてしまう。守っても守らなくてもいい約束には価値がない。チームの約束をチェックすることはチーム全体の仕事である。
チームの約束は、形骸化させず価値を保ち続けることが大切です。
もし形式だけが残ってしまっているのなら、思い切って見直すか、廃止を検討すべきだと思います。
そうした意味でも、主目的を忘れずチームの約束をチェックしたい。
感情的な場面をコントロール
グループが問題に直面していることに気づいたら、特に注意を払ってサポートすること。あなたの仕事は、グループが困難な問題を話題に取り上げられるような環境を作ることだ。場を設定することに重点を置き、感情的な場面をコントロールできる心づもりをしておくこと。
久しぶりのひとりのエンジニアとしての稼働に、テクニカルな領域で引き目を感じて自分の世界にこもることがありましたが、
最近、プロジェクトマネージャーとしての責務として、メンバーが困難な状態に陥ったときのフォローや、感情的な場面でのコントロールは果たすべきだと気付くことができました。
凸凹があるチームにおいて、私は自分に与えられた役割と他のメンバーにはできない領域でチームを活性化していくことができる。
ヒーローの話
・チームが1人のメンバーを救世主と見なしてしまう。あるいは、救世主がそのヒーローという役割に(チームに損害を与えるほどに)酔いしれてしまう場合もある。チームが救世主に頼っていようが、救世主がその役割を自ら担っていようが、それでは共同作業や共同所有を台無しにしてしまう。
・公式あるいは非公式のリーダーが一貫して責任を持つと(ただしチーム外の組織システムの問題は除く)、そのチームは頼りない人ばかりになってしまう。チームは協力して改善に取り組むことで強くなるのであり、その責任を取り除くのはチームにハンデキャップを負わせるということになる。
この資料にまとめた内容と一緒だと思っています。
酔いしれてしまう、という言葉に、何度でもそうならないように気を付ける必要があると思います。
