毎日朝会をやって、2週間ごとに振り返りをして、ベロシティも安定している。一見するとチームのスクラムがうまく回っているように見えますが、形式通りにイベントをこなしているだけで、実は中身があまり伴っておらずスクラムイベントが正しく機能していないと感じることがこれまでの開発で何度かありました。
気がつくと、メンバーの意識がプロダクトの価値を届けることではなく、目の前のタスクをスケジュール通りに終わらせることに向いてしまっている。こうした手段の目的化は、どこの現場でも起きがちな悩みなのではないでしょうか。
今回は、形骸化しがちなスクラムについて、なぜそれが起きるのか、どうやって現場から変えていけばいいのかを、アジャイルソフトウェア開発宣言の思想に立ち返って考えてみたいと思います。
スクラムが形式的になっている例
まずは、形骸化しているスクラムのよくある状況を思い浮かべてみます。
1. デイリースクラムが単なる進捗報告会になっている
朝会での発言が「昨日これをやりました、今日もこれの続きをやります」という人単位の報告だけで終わっているパターンです。他人が何をしているかに関心が薄れ、自分の担当分を伝えることだけに意識が向いてしまうと、ゴールに向けたチームの対話は生まれにくくなるように思います。
2. レトロスペクティブが感想戦や精神論で終わっている
レトロスペクティブで「今スプリントは忙しかったです」という感想で終わったり、「次はもっと意識を高めます」「レビューを早くします」といった、具体的な行動に落とし込めない曖昧な目標ばかりが出ている状態です。これだと、次のスプリントでも実際の動きを変えるのは難しくなってしまいます。
3. プランニングがタスクの分解作業に偏っている
POから渡されたバックログを、仕様の背景や「なぜ作るのか」を深くすり合わせないまま、機械的にタスクへ切り分けるだけの時間になってしまうことがあります。この状態だと実装に入ってから認識ズレが起きやすく、あとから手戻りが発生して結果的に工数が膨らむ原因となりかねません。
なぜ手段の目的化が起きるのか
スクラムがただのルーティンになってしまうのは、日々の開発に追われていると、決められた型をそのままなぞるのが一番エネルギーを使わずに済むからだと思います。
毎日忙しくコードを書いてタスクを消化している中で、さらに自分たちの進め方まで見直して変えていくのは、いくらかパワーが必要です。そうなると、とりあえず時間通りに集まって、決まったフォーマットを埋めるだけで手一杯になってしまうのも無理はありません。
ただ、アジャイルの思想にある「プロセスよりも個人と対話を」という言葉に立ち返ると、イベントを予定通りに終わらせること自体はゴールではないはずです。
日々の忙しさに流されて、開発を効率的に進めるための手段だったはずのスクラムが、いつの間にか「こなさなければいけない会議」にすり替わってしまう。これが、形骸化が起きてしまう実際のところなのだと思います。
イベントを形だけにしないための具体的なアクション
形だけのスクラムを変えるために必要なのは、定例の進め方を綺麗にすることではありません。日々の開発でやりづらく感じていることを、チームで共有し、そのチームで効果的な形に変えていくことだと考えています。チームでこれまでに実践し、良い効果があった具体的な対策をいくつか挙げます。
1. 朝会を自分のタスクではなく全体のボールを見る場にする
朝会を、昨日何をしたかを順番に読み上げるだけの場にするのを一回やめてみます。
自分の担当分を伝えることも重要ですが、スプリントゴールを達成するためにチームとしてどう動いていくべきかを考えることに時間を割いてみてください。
個人の進捗ではなくチーム全体の詰まりを解消することに朝会を使う方が、結果的に全員の開発が進めやすくなると考えています。
2. プランニングでタスクの完了条件をすり合わせる
渡されたチケットを機械的にタスクへ切り分けるだけの作業は、手戻りの原因にもなります。
実装を始める前に、どういう状態になれば完了と言えるのかという仕様のゴール、受け入れ条件を、POやチームと一緒にその場で書き出してしまう。
プランニングの時間は膨らむかと思いますが、仕様の背景や作らなくていい範囲がプランニングの時点でクリアになっていれば、実装中に迷って手が止まることも、レビュー時の認識ズレによる手戻りも、結果的に減らせるはずです。
3. レトロスペクティブでは、次のスプリントで試す小さな1アクションだけを決める
「次はもっと意識を高く持って、レビューを早くします」のような、中身のない精神論の目標を立てても何も変わりません。
次に試すのは、やったか・やらなかったかが客観的に評価できる、小さな行動ルール1つだけで十分です。例えば、「PRのサイズを最大でも200行以内に収まるようにタスクを細かく分ける」といったレベルで構いません。
実践しやすく、その成果を評価しやすいTRYを立てることで効果的なレトロスペクティブになっていくと考えます。
型をチームに合わせる
アジャイル宣言の原則には、「チームが定期的に、どうすればもっと効果的になれるかを振り返り、それに基づいて行動を調整する」と書かれています。
もし、今のチームに現状のスクラムが合っていないと感じるのであれば、イベントの時間や進め方自体を自分たちに合わせて変えてしまっていいはずです。ルールにチームをハメ込むのではなく、チームに合わせて型を調整していく。イベントをこなすためのスクラムではなく、チームが強くなるためにイベントを使う。そうすることでスクラムの強さを発揮できるようになると考えています。
スクラムの形骸化を避けるために、改めて今のスクラムイベントがチームに価値を生み出せているかを見直してみようと思います。
参考文献
「アジャイルソフトウェア開発宣言」https://agilemanifesto.org/iso/ja/manifesto.html