応用編：ふりかえりと継続的改善

アジャイル開発においてチームを自律的に成長させるための「ふりかえり」の手法、計測指標、よくあるアンチパターンとその対策を解説します。

ふりかえり（レトロスペクティブ）の重要性

アジャイル開発では、定期的に自分たちの働き方を点検し、改善し続ける「カイゼン」の姿勢が不可欠です。スプリントの終了時に実施するふりかえりでは、誰かを責めるのではなく、「仕組みやプロセスをどう改善できるか」に焦点を当てます。

KPT法によるふりかえりの進め方

KPT（ケプト）法は、ふりかえりで最も広く利用されているフレームワークです。

+-----------------------------------+-----------------------------------+
|         Keep (継続すること)       |       Problem (困っていること)    |
| - デイリースクラムの時間が守れた  | - テスト自動化が追いついていない  |
| - ペアプロで知識共有が進んだ      | - 仕様の確認に時間がかかった      |
+-----------------------------------+-----------------------------------+
|         Try (次に挑戦すること)                                        |
| - テストコードの作成時間をスプリント計画に含める                     |
| - プロダクトオーナーと毎日10分相談する時間を設ける                    |
+-----------------------------------------------------------------------+

• Keep (よかったこと・続けたいこと)

  うまくいったことや成果を挙げ、今後も継続する習慣として確認します。

• Problem (問題・課題)

  作業を進める中で発生した障害や困りごとを率直に共有します。

• Try (次に試すこと)

  Problemに対する解決策や、Keepをさらに伸ばすための具体的な行動計画を決定します。次回のスプリントで実行できる小さな粒度にすることが重要です。

アジャイル開発の主要な計測指標

チームの健康状態や開発の安定度を把握するために、以下の指標を活用します。

• ベロシティ (Velocity)

  1回のスプリントでチームが完了できた作業量（ストーリーポイント等の合計）の平均値です。見積もり精度の向上や将来予測に用いるものであり、チーム間の生産性競争に使うものではありません。

• リードタイム (Lead Time)

  要求が発生してから、実際に利用者に価値として届けられるまでの全所要時間です。

• サイクルタイム (Cycle Time)

  開発者が作業に着手してから、作業が完了するまでの時間です。

よくあるアンチパターンと対策

アジャイル開発を導入する際につまずきやすい失敗パターンと、その対処法を把握しておきます。

• 名ばかりスクラム (Zombie Scrum)

  イベントや形だけを実施し、動くソフトウェアの完成や改善への意欲が失われている状態です。成果物の完成基準（DoD）を徹底し、利用者のフィードバックを得る機会を作ることが改善の鍵となります。

• 見積もりのノルマ化

  ストーリーポイントを個人のノルマや達成率の評価に使ってしまう誤りです。見積もりはチーム全体の計画のための目安であり、ノルマ化するとポイントの過大申告や手抜きを招きます。

• ドキュメント不要論という誤解

  「アジャイルではドキュメントを書かない」という極端な解釈です。アジャイル宣言は「動くソフトウェアをより重視する」と言っているだけで、設計思想や保守に必要なドキュメントの作成を否定しているわけではありません。