アジャイル開発がうまくいっていない気がするというチームに確認すべきこと

みなさんこんにちは。@ryuzeeです。

仕事柄さまざまな会社のいろいろなチームから相談を受けます。具体的な相談のこともあれば、抽象的な相談のこともあります（内容が具体的になっていればもう解決までそう遠くありません）。

抽象的な相談で多いのは「なんとなくうまくいっていない気がするけど、何を確認したらいいの？」というものです。今日はこの質問に対して、どう対応しているかを共有したいと思います。スクラムをベースに書いていますが、スクラムでなくても構いません（その場合は適宜用語を読み替えてください）。

確認ポイント

いきなりほぼ結論です。

このような相談を受けたときに、いちばん重要な確認ポイントは

「毎スプリントごとに動作するソフトウェアを作って、チームの外側に見せてフィードバックをもらっているか？」

です。この確認をしないうちに「スクラムイベントは全部やっているか？」とか「プロダクトバックログがどうなっているか？」とか「インセプションデッキがどうたら」とか「最近○○というプラクティスが流行ってる」とか効率とかは無意味です。

なぜこれが重要なのか

アジャイル開発を適用するような性質（つまり不確実性が高い）の仕事では、リスクの制御は「動作するソフトウェア」でしか行えないからです。大きなリスクとして挙げられるものとしては「作ったものが価値を生み出すか」「ビジネスにあった速度で作れるか」があります。

まずは、「作ったものが価値を生み出すか」への対処についてです。作ったものが価値を生み出すかどうかは、チームのなかだけでは決まりません。 プロダクトの価値は基本的に「チームの外側で決まる」 のです。そのため、作ったものは早い段階から定期的にチームの外側に披露し、評価を受け、フィードバックを貰わなければいけません。

「完成度が低いものを外部に見せたくない」とよく言われます。気持ちはわかります。でも完成度を上げてもリスクに対する制御にはなっていません。時間をかけて作り込んで自分たちが満足できるものが作れたとしても、価値を生み出していなければ投資した時間は無駄になります。また、見せない期間が長ければ長いほど、外部の人の期待値は上がります。その上がりきった期待値に応えるのはかなり大変です。

次に「ビジネスにあった速度で作れるか」への対処です。多くのプロダクト開発には予算や想定のリリース時期があります（もちろんうまくいったプロダクト開発はずっと続きますが、投資対効果は気にしますし、ざっくりとした計画を立てるのが普通です）。これは最近流行りの「開発生産性」の観点ではありません。重要な関心事は、ビジネスの観点として妥当な速度で作れているのか、会社のさまざまな計画に適合できそうなのかです。つまりそれなりの確度で見通しが立てられるかです。アジャイルで見通しを立てるときに基準になるのは、「動作するソフトウェア」です（アジャイルソフトウェア開発宣言に書いてあります）。動作するソフトウェアがどれくらいの速度で作れるかが明らかになっていれば、計画やチーム構成を見直したり、プロダクトの機能の優先順位やロードマップを変えたりできます。タスクをこなしているからといって「動作するソフトウェア」ができるとは限りません。したがってプロダクトバックログアイテムやタスクの達成率や消化個数を見てもあまり意味はありません。

なぜできないのか？

「毎スプリントごとに動作するソフトウェアを作って、チームの外側に見せてフィードバックをもらう」ことができない理由はさまざまです。経験上よく遭遇するものを4つ紹介します。もちろんこれ以外の理由もあります。

1. フィーチャーファクトリー

チームの外部で作るものが決められていて、社内受託開発のようになっているケースです（受託開発のコンテキストも同じです）。この場合、チームには短い期間で区切って、動作するソフトウェアを見せ続けるインセンティブがありません。つまり「作ったものに意味があるか」は二の次になります。

チームにとってのリスクは「決められたことが期限内に終わらない」ことなので、それへの対処を最優先にします。フィードバックをもらってそれを反映するのはチームにとってはマイナスだということです。

2. 効率重視

先に答えがわかっているような仕事であれば、いかに効率的に終わらせるかが重要になります。つまり、誰かがタスクをすべて用意し、それを効率的に終わらせるように分業するのが、合理的な選択になります。これは一過性の仕事や、仕事が終わったらチームが解散するような状況だと特にです。

この分業の考え方をプロダクト開発やアジャイル開発に持ち込むと残念な結果になります。タスクをこなすという観点では、数多くこなせるかもしれませんが、スプリントの最後に動作するソフトウェアが手に入らない可能性が高くなります。たとえば、結合の作業が最後にまとめて残ったり、結合はできたもののテストが終わっていないものが最後に残ったりします。

実物で評価するのが何よりも重要であり、効率を追求するのはそのあとでなければいけませんが、そうなっていないのです。

3. 不適切な作業分割

アジャイルでは、何か実現したいことがある場合、それをプロダクトバックログアイテムなどで表現します。そしてアイテムが1回のスプリントやイテレーションで開発するには大きすぎるときには、分割します。分割するときは、分割したものそれぞれが単体で意味があり、独立して評価可能にするのが基本ですが、慣れていないと「設計」「開発」「テスト」のように工程で分割してしまいます。このように分けてしまうと、動作するソフトウェアとして評価できるようになるまでに3回のスプリントが必要になってしまいます。

これはチーム全体が学習不足のときによく起こります。つまり、動作するソフトウェアの意味を理解していないということです。