フィードバックループ、レトロスペクティブ周辺を改めて整理する

この記事はAgile Advent Calendar 2024 22日目の記事です。昨日は尊敬する小田中育生さんの『変化に対して閉じてしまうとき』でした。

こんばんは。以前ウォーターフォールの流儀に慣れ親しみ、ここ数年はアジャイルな開発を試行錯誤しているinouehiといいます、よろしくお願いします！

アジャイルな開発を構成する要素にフィードバックループというものがあると認識しています。これによって、プロダクト、開発プロセス、組織構造、人のふるまい等を継続的に改善できると考えられていると理解しています。スクラムイベントはフィードバックを得る機会と捉えられますが、この中でふりかえり（レトロスペクティブ）は時に扱いが難しく感じることがあります。例えば、言うことが思いつかない、改善につながるような発見が得られない、解決困難な課題が積もってしまうといった具合です。そして、そもそも必要なのかという命題もあるように思います。そこで、いくつかあるフィードバックを受ける機会の中でレトロスペクティブにはどのような特徴があるのか、どんな発見を得るのに適した機会なのか、どんな条件下において実施する必要がなくなるのかという視点で整理してみることにしました。

想定読者

• フィードバックの機会設計を模索している方
• レトロスペクティブの意義を模索している方
• 私

目的

まず目的を見失わないように、確認しておきたいと思います。私達はなぜレトロスペクティブを行うのか？
それは顧客、ユーザーに価値を適時に届けるためだと考えます。（本ポストではそう仮定します）

目的から導かれる留意事項＋α

プロダクトやその開発を取り巻くもの（開発プロセス、組織構造、人のふるまい等）をよりよくするためにフィードバックを得たい、そして、レトロスペクティブからもフィードバックが得られると期待するから行うと言えそうです。逆に言うと、もし有効なフィードバックを得られないならばレトロスペクティブを行う必要はないのかかもしれません。その場合、フィードバックを得る機会を他のものに求めるのが建設的のように思えます。あるいは、十分なフィードバックを得られる機会が他にあるならば、レトロスペクティブにこだわる必要はないとも言えるかもしれません。

その他にも重要なポイントとしては、一般論としてではなく個別のチームにおいてそれを確認すべきということでしょうか。また、過去の成功体験、失敗体験から判断するのではなく、今の状況においてそれを再確認すべきということでしょうか。

フィードバックとは

本ポストではフィードバックを以下のようなものとして捉えています。

• "上位者が部下に向ける評価"のような仰々しいものでは必ずしもない。
• 何らかの出来事に伴いそれに対して生じる反応。
• 人が他者に対して贈るもの。
• 人が自身に対して贈るもの。（これを内省と呼ぶ）

人はアウトプットし、そこから生じる出来事や他者あるいは自身と対峙することでフィードバックを得られると考えます。フィードバックから自身や他者のふるまい、アウトプットや環境を顧みることができます。そして、そこから学びを得られます。ポジティブなフィードバックに対しては再現性を高めるアクション、ネガティブなフィードバックからは改善を促すアクションを起こすのがヘルシーなのではないかと考えています。

フィードバックの種類と機会

便宜的にフィードバックと、それを得る機会を分類してみます。（整理の仕方は様々あると思いますが一例として）

1. プロダクトに対するフィードバック
   • ペアプロ
   • ビルド、自動テストや静的解析の結果
   • コードレビュー
   • QAテストや受入テスト
   • スプリントレビュー
   • ユーザーからのお問い合わせ・ご要望
   • ユーザーインタビュー
   • プロダクトのデータ分析結果
   • Issueやプロダクトバックログ
2. それ以外（開発プロセス、組織構造、人のふるまいなど）に対するフィードバック
   • デイリースタンドアップ
   • 1on1
   • （情報共有するようなある意味汎用的な）ミーティング
   • スプリントレトロスペクティブ
   • インシデント等のポストモーテム
   • （例えばFour KeysやEngagement Surveyのような）データ分析結果（※）

ユーザーが直接対峙するのがプロダクトなのだとすると、1のフィードバックをポジティブにすることが日々私達が目指すところの一つと捉えられそうです。一方の2は、それを達成するための土台と捉えられそうです。2は、プロダクトの品質、デリバリー速度、開発コストを改善するきっかけとして作用し、1のフィードバックの質に影響を与えるという視点です。

こうして眺めてみると、2は1と比べて機会が少なそうに見えます。データ分析を除くと、1はプロダクトを作る人、使う人、販売する人、問い合わせを受ける人がフィードバックの贈り手になる一方で、2は多くの場合作り手が贈り手になりそうです。

※レトロスペクティブがそもそもデータ分析を含むべきものという考え方は承知した上で、関心事としては個別に存在していることや、データを含まないレトロスペクティブが行われることもあろうことを考慮し、個別に記載する。

組織に固有の前提条件も考慮する

例えばリモートワークの組織を想定してみます。

人と人が関わる時、フィードバックが生じえます。つまり、雑談もフィードバックの機会の一つと捉えられます。リモートワークにおいては偶発的な雑談が構造的に生じづらいと言われています。この場合特に、人と人とが関わる場の設計の重要性が相対的に増すと考えられます。

フィードバック機会の特性

フィードバック機会にはそれぞれに特性がありそうです。棲み分けあるいは相互補完できるのかもしれません。

• デイリースタンド・アップは、進捗、課題や今日やることにフォーカスするため、フィードバックを得る機会としては限定的です。問題を即時に解決してタスクを進めることが目的であり短時間でもあるため、深掘りして改善策、学びを見つける推進力は弱めと考えられます。
• 1on1は個別のフィードバックを得る機会ですが、チームとして学びを得るには適さないと考えられます。
• 汎用的なミーティングは話題が分散するため、相対的にフィードバックが生じにくいと考えられます。
• ポストモーテムはトラブル等の発生を契機に行われるため、フィードバックが頻繁には得られません。それに、できれば予防したいものです。
• データ分析は、仕組みを作ったり、人件費とは別の追加費用がかかったりというハードルがありますが、客観的なフィードバックを得られる機会として固有の価値をもっています。ただし活用するには分析する機会と、それをチームで共有する機会も必要です。

これらを眺めながら考えてみるに、チームで話し合う（結果として、チームに共有ないし合意形成されもする）、時間をとって考察する、定期的に行う（結果として、課題が顕在化する前に行われることがある）、話題に制約を与える（フォーカスする）、課題だけじゃなく成功にも焦点を当てるというのがレトロスペクティブの特性として挙げられそうです。

特性から導かれるレトロスペクティブの（不）必要性

裏を返すとチームとしての学びを必要としないケースではレトロスペクティブが必要とされにくいかもしれません。チームとしての学びを必要としないケースというのは、例えば、少人数のチーム（例えば課題解決にあたって学んだ人が雑談する範囲でチーム全体に伝搬させられるようなイメージ）や少人数ではないが学びを求めないチームでしょうか。学びを求めないというのは、メンバーが十分に成熟しきっており機会を作るコストに対して学びのコスパが悪い場合や、成長せずとも十分な成果が出せるように仕組み化された仕事を扱う場合などでしょうか。

定期的に行うというのは、フィードバックを得る機会を確実に訪れさせるという意義がありそうです。忙しい時、ふりかえりにマインドシェアを割けないなんてこともあるでしょう。また、ふりかえりを習慣的にやる人もいれば、やらない人もいるでしょう。どんな人にも機会をもたらすという意味がチームでの定期開催にはありそうです。裏を返せば、そうでなくてもふりかえることができる人の集まりならば、定期開催であることの必要性は乏しいと言えるかもしれません。

話題に制約を与えるという工夫は、どんな機会にもアドオンできそうですが副作用もありそうなので、個別の判断が必要です。

チームで成功を共有することによって学びが拡散されますし、成功を共に祝うことで士気やエネルギーが高まることもあります。定期的に集まって話をする機会はディスカッションの練度を高めることにもつながります。裏を返すとこのようなモメンタムや共創を重要視しない場合もレトロスペクティブが必要とされにくいかもしれません。

レトロスペクティブの典型的な課題と対策

レトロスペクティブにおいて言うことが思いつかないということもあるでしょう。その場合、話題に制約を与える（フォーカスする）ことでアイデアを引き出すという考え方があります。名著『アジャイルチームによる目標づくりガイドブック』にもいくつか紹介されているように世の中にはたくさんのふりかえり手法がありますので、試してみるとよいかもしれません。

あるいは、データ分析が効果的かもしれません。データ分析が新たな視点や気づきを与えてくれる可能性があります。アイデア出しは苦手だけれども、データを読み解くのは得意という人もいるのではないでしょうか。また、そもそもの話、意見と事実を区別しましょうという話もあります。

課題が大きすぎてスプリント期間内に対処しきれないとか、優先度の高い開発の納期が迫っており課題解決に手が出せないといった問題もよく耳にします。その場合は、課題を細分化して少しずつ対処するなどの方法がありそうですが、本ポストの趣旨から外れるので深追いは控えます。

例えばどんなことがレトロスペクティブの話題になるのか

具体例を眺めることでレトロスペクティブがどんな発見を得られる場なのかを確認してみたいと思います。思いつきかつ粒度もマチマチですが、ざっくりとレトロスペクティブで話題になりそうなこと（※）を羅列してみます。ここで挙げる多くの話題にポジティブ、ネガティブなフィードバックがありえます。

話題例

• タスクの優先順位付けが適切さ
• タスク分割の粒度の適切さ
• スプリント計画の精度
• スプリントレビューの進行方法
• デイリースタンドアップの進行方法の適切さ
• プロジェクト全体のタイムラインに適切さ
• 作業手順や効率性
• 会議時間の有効活用の程度
• コードレビューの指摘に一貫性について
• 新メンバーのオンボーディングプロセス
• チーム内での役割分担の明確さ
• スクラムマスターやリーダーの役割への期待と実績
• 意思決定の透明性
• チーム間のコラボレーションの質
• フィードバックを共有する際の心理的安全性について
• 言語や文化の違いからの学びや失敗
• 意見の衝突からの学びや失敗
• チームメンバーのモチベーションに関する洞察
• コミュニケーションツール（Slack、メールなど）の適切性
• 問題のエスカレーションの適切さ
• 技術的負債が発生した原因
• コードの保守性や可読性
• 設計の妥当性
• 使用した技術スタックの妥当性
• テストカバレッジや自動化の改善点
• CI/CDパイプラインの最適化について
• 繰り返し発生した不具合の根本原因
• ドキュメントの過不足
• ドキュメントの質
• 実装における創意工夫
• スプリントのゴールが明確だったか
• チームとしての成功、失敗要因
• チーム文化や雰囲気に関する気づき
• メンバーが異動した際の引き継ぎの質
• 開発中に気づいたシステム仕様の課題認識
• 仕様変更や考慮漏れがあった際のチケットの管理方針
• 動作検証の方法に関する気づき
• QAプロセスに関する気づき
• リファクタリングの実施方針
• ログ監視運用の方針

※諸説ある。個別のタスクではなく、全体的、包括的な視点からこそ発見されやすそうな話題というくらいの意図。

まとめ

2025年、人やプロダクトと向き合い、更によい年にしたいものです。コラボレーションやフィードバックループという観点では

• 目的を見失わないようにしよう。
• 一般論じゃなくて、（過去に配慮しつつ）現場の今にフォーカスしよう。
• フィードバック機会の特性に注目しよう。
• 組織や個人のニーズに注目しよう。
• 制約（フォーカス）を活用しよう。
• データを活用しよう。
• 協力しよう。
• 前向きでいよう。

以上、よいお年を。