見よう見まねで始めたアジャイル開発は、苦難の連続でした。最大でもせいぜい5人程度の少人数のチームだというのに、まったくまとまらず、チームは崩壊寸前（正直言って今もいつ壊れるかわからない）。
それでも、頑張って続けました。そして苦節半年、スプリントのバーンダウンチャートが、ようやくバーンダウンしたんです。感動です。そして、なんとベロシティも出せました。当たり前？いや、これが全然できなかったんです。本当につらかった。
本記事は、とある開発チームが紆余曲折を経てそれなりのチャートを描くようになるまでの、血と汗と涙の軌跡です。
アジャイル開発の軌跡
Webサービスの開発に携わったのは初めてで、どうすればいいのか右も左もわからない状態だったが、とにかく現状はまずい、ということだけはわかっていました。目まぐるしく変わる仕様に開発はまったく追いついていない（そもそもその仕様自体に多くの問題があることはおいといて）。進め方も、ツールも、なにもかもがしょっぱい。
ネットに溢れる今どきっぽい開発について語る記事やら、アジャイル開発について語る書籍やらを読むにつけ、このままじゃまずい、と危機感を抱き、見よう見まねでアジャイル開発なるものを始めようとしたのが、2018年の秋頃だったかな。
はじめてのバーンダウンチャートは悲惨の一言
アジャイル開発といっても、決まった手法があるわけではありません。しかしそれではなにをしてよいかわからない。ということで、参考にしたのはスクラム開発です。これは少人数でできるし、なによりもやるべきこと、体制がわかりやすかった。
しかし、この時点で開発者はスクラム開発の最低人数ギリギリ……いや、本当を言うと足りていなかった。スクラム開発は、PO一人、スクラムマスター一人、開発チーム3人が最低の人数。で、PO、スクラムマスター、開発チームは、推奨されないが兼任できる。
で、なんとPO、スクラムマスターは独自ではなく、それぞれ開発チームを兼任することになります。それで開発チーム3人。まぁつまり、実質的に人数足りていないんだけれど、そうするとスクラムの人数を満たさないから、無理やり帳尻を合わせたんだね（ちなみに僕はスクラムマスター兼開発チーム）。ということで、やる前から失敗することが決まっていたようなものだったのですが、兎にも角にも、アジャイル開発を自分たちなりに始めました。
バックログをTrelloに記録して、終わったものを記録していく。で、スプリント内の残タスクの推移をバーンダウンチャートで記録する……よくあるやり方。で、記念すべき最初のバーンダウンチャートがこれ。
じゃじゃーん。なんだこのツッコミどころしかないチャートは。いや、チャートかこれ？
まず、記録できてない。1日目で挫折してる。そして、その一日だけの記録を見ると、全然バーンダウンしてない。実績自体は増えているので（バーンアップチャートを併記していた）、仕事はしている。しかし、それ以上に見積もりが増えている。つまり、想定外の仕事を片すだけでいっぱいいっぱいの状態。そして、よしんば想定内の仕事しかなかったとしても、最初の見積もりの総量の時点で、5日で終わるとは思えない状態。これは酷い。
まーやってみてわかったけれど、やったことを記録するって難しい。しかも自分だけじゃなく、チーム全体がやらないといけない。
ということで、初めてのスプリントは散々でした。レビューとレトロスペクティブも紛糾したような気がする。このスプリントイベントにかかる時間がまた長かったなぁ。
しかし、問題しかないということが可視化された点で、やはりやる意義はあった。
2回目のスプリントでとにかく記録だけはした
大いなる反省点を踏まえて、二回目のスプリントが開始される。その結果は……
なんと！最後まで記録が続いている！とにかく記録しないことには話にならない、ということで、一生懸命記録するようになりました。これは大いなる進歩。
ただし、まったくバーンダウンできていません。最終日に至ってはダウンどころかアップしています。この頃はバーンアップチャートを併記していたのだけれど、本当にこれだけが精神的な救いだった。バーンダウンだけ見ていたら、凹むしかなかったもの。とにかく仕事はしているんだ、という実感をバーンアップチャートは与えてくれた……。
が、それだけに「謎のタスクに忙殺されている」ことも、このチャートは教えてくれている。また、実績の勾配とバーンダウンチャートの勾配が一致しないところに闇を感じる。ちなみにこの実績は「時間」単位です。ストーリーポイントではない。なので、生産性がしょぼくても、会社にいる時間だけ増えていく日本的実績です。闇が深い。
あとツッコミどころは、1回目のスプリントと日数が違うことです。これは、しかも中途半端。これは、日数についてどれくらいがいいのか、まだわからなかったから、まぁ実験的だったんですね。自分はずっと2週間はないとキリよく仕事ができない、と現場の肌感覚から思っていましたが、POは対応が遅れてしまうんじゃないかと心配していて、まぁつまり、チーム内で意見がバラバラだったんですね。3人しかいないのにね。
まぁ兎にも角にも、メンバーがタスクを記録するようになった、は進歩と捉えてよいでしょう。そして想定外のタスクが多すぎる、ということも可視化されました。
バーンダウンしない日々が続く
3回目のスプリントは以下のようになりました。
また日数変わってますね。バーンダウンしてませんね。実績の勾配に闇を感じますね。
この実績の勾配は、もちろん青天井の残業地獄が一因ですが、それだけではなく、タスクの完了の仕方にも問題がありました。つまり、日をまたぐタスクが多かったのです。だから、日によっては全然実績が伸びない、そしてある日突然伸びる、ということに。
バーンダウンチャートではスプリントバックログをカウントしていました。で、これはスプリントバックログの粒度が大きすぎる、という話になりました。また、日をまたぎそうになるなら、スプリントバックログを分割しても良いだろう、と。
また、日数がバラバラなのは管理しづらい……ということで、日数も統一するようになりました。
という反省を踏まえて、スプリントを繰り返しました。
スプリントが1週間刻みになりました。2週間刻みにならなかったのが残念です。2週間刻みだと、柔軟な対応ができなくなるのではないか、とPOは恐れたんですね。僕もそれに対して確たる反論はできませんでした。
しかし、スプリントが短くなった分、試行回数は増えました。相変わらずバーンダウンしません。5回目はちょっと惜しいですが6回目でまた闇の深いチャートになっています。
ちなみにこの頃に、開発メンバーが一人増えて、それに伴って、開発チームを兼任していたPOをPO専任にしました。僕は相変わらずスクラムマスター兼開発チーム。まぁ正直、スクラム開発の形になってなかったと思うけれど。
ややバーンダウンし始める？
さらにスプリントを繰り返すと、少しマシな形を描くようになってきました。
まぁまぁちゃんとバーンダウンし始めているような気がします。ただ実績の勾配にはやはり時々闇を感じさせます。
多分、少しずつよくはなっていたんだと思います。でも、本質的な問題は改善されませんでした。バーンダウンしても地面についていないことです。それはつまり、スプリントプランニングが機能していないことを意味しています。
この頃、スプリントプランニングは本当に鬱行事でした。いや、今でもスプリントプランニングはタフなイベントなのですが、あの頃はタフとかそういうレベルではなく、最悪な空気で喧嘩状態になったこともあります。ひどかった。
それと言うのも、プロダクトバックログが整っていなかったからですね。一応作ってはいたのですが、活かされていませんでしたね。今もこれ、整っているとは言い難い状況なんですけれど、それでも、当時よりは全然マシ。
プロダクトバックログが整っていないと、なんとなくやりたいことに合わせて、スプリントバックログを見繕うんですけれど、これがびっくりするくらい甘い見積もりになるんですよね。もう本当に、全然終わらない。マジで。
そうして、計画どおりに進まない、という負の感情は蓄積されていきます。
……ちなみに、この頃に開発メンバーがまた一人増えています。
そして事件は起きた
しばらくは、問題を抱えつつもスプリントを回していました。
あまり成長していません。が、まぁなんとかスプリントを回している状態です。しかし、実は事件が起きています。
11回目のスプリントが終わったあと、次のスプリントが始まりませんでした。たまり続けるタスクをこなすのにいっぱいいっぱいで、プランニングさえも開かれなくなったのです。
そしてようやく12回目のスプリントが、何週間かぶりに始まった時のチャートがこれです。
振り出しに戻る。いや、最初より酷いですね。だってこれ、プランニングだけして、それっきりです。
なにがあったか、まぁお察しくださいといったところです。あの時チームは崩壊してもおかしくなかった。いや、実は崩壊していたのかもしれない。
この頃だったかなぁ、「スクラム開発をやめる」と言ったのは。POも反対しませんでした。だって、明らかにうまくいってなかったものな。でも、アジャイル開発自体はやめてはいけない、と考えていました、なんとか自分たちのあり方に合わせようと、ない頭をひねることになります。
初めてのバーンダウン（無理やり）
まぁ色々ありました。で、次のスプリントでは。
なんとバーンダウンしています！ってもう、明らかに無理やりですね。見積もりの下がり方がエグい。できそうにないところを、全部次のスプリントに回した。それだけ。たしかこの時、開発メンバーが一人減ることになって、まぁ最後くらいっていうので、形だけ有終の美を飾ったんだったかな。
本当にバーンダウンさせたいだけだったら、こういうこともできちゃうんですよね。でもそれはなんの意味もないことで。
でも、とにかくバーンダウンさせたのは、意識的なところで意味はあったかもしれませんね。
とにかくスプリントは続けた
その後、スクラム開発の形はとらなくなりましたが、朝会は続けたし、プランニング、レビュー、レトロスペクティブなどスプリントイベントも引き続き続行。つまり何が違うのかと言うと、POとスクラムマスターという役割がなくなった、この一点につきます。POがいないので、プロダクトバックログを作るのは開発チームの仕事になりました。これが一番大きい。
相変わらずに見えますが、17回目のスプリント、実績の伸び方が綺麗なのがわかります。実績の伸び方が綺麗ということは、タスクの記録が確実でかつ、無理な残業もしていない、ということです。
まぁつまり、なんだかんだやりながら、チーム自体は少しずつスプリントを回す、ということに慣れてきていたのだと思います。また、開発チームに無理をさせると、チーム自体が崩壊する、ということが、組織的にも理解され始めていたのでしょう。
プロダクトバックログ中心の開発へ
変化の中で、18回目のスプリントで、ついに2週間スプリントが採用されました。また、ユーザーストーリーマッピングを経て、プロダクトバックログをよく見るようになりました。で、チャートはこれです。
最終日さぼってますが。ちょっとそれらしくなっている、と思います。バーンアップチャートは廃止しました。バーンアップチャートは、元々「バーンダウンしない予感しかしない」という消極的な理由でつけていたものです。実際、そのとおりだった。まぁ、「実績+見積もり」チャートがバーンアップチャートみたいなものではあるんですが……。
で、その代わりに「理想の直線」をつけました。これは最初からやっとけばよかったんですが、多分、「どうせ終わらない」というのが、心の何処かにあったんでしょうね。
結果だけを見るとさんざんなのですが、個人的には手応えを感じていました。今までと違う、綺麗さがある。見積もりさえうまくやれれば、いけるんじゃないか？
この時、「けっこう仕事しているはずなのに、プロダクトバックログが全然消化できていない！」という問題が、真剣に取り上げられました。これは大きかった。
プロダクトバックログをベースに考えるべきだ、ということで、未消化のプロダクトバックログを片付けて、そこから半ば無理やりベロシティを出しました。で、次のスプリントはこのベロシティに基づいてやろう、という結論。
ベロシティに基づくプランニング
で、ベロシティに基づいてプランニングし、実行したのが19回目のスプリント。結果は以下です。
おおぉ……おおぉ……これは、ネットで見たバーンダウンチャートの見本みたいなチャート……。
実は、プランニングの時点では、「これ余裕で終わるんじゃないか？」という感じだったんですけれど、終わってみればベロシティどおりだったという。ベロシティすごい。最終日間近、見積もりが減っているのは、プランニング時点で僕が色気を出してプロダクトバックログにない項目を入れていたのを、「あ、無理だわ」と思って外したんです……はい、こういう感じだから駄目だったんでしょうね。
ちなみに、前半部分の実績+見積もりが平たいのは、スプリントプランニングが遅れてしまったからです。なぜ遅れたかというと、プロダクトバックログができていなかったからです。
今までなら、プランニングが始まるまではスプリントを開始しない……としていたのですが、それだとスケジューリングに使えないと気付き、たとえプランニングできなくてもスプリントは開始する、としました。で、プランニング開始時点の見積もりと、それまでの作業量から、前半の見積もりを逆算で推測した感じです。
どうなるかなーと思っていたのだけれど、この結果には感動しました。このチャートが描けるようになったことが、チームとして一番の成果だと真面目に思います。
教訓
得られた教訓。
なぜスクラムはうまくいかなかったか？
最初に採用したスクラム開発のフレームワークは、うまくいきませんでした。この失敗の原因は、プロダクトオーナー（PO）とスクラムマスターの機能不全だったと思います。明らかに無理がありました。POもスクラムマスターも、それぞれの役割を全うできませんでした。POは雑務に追われ、スクラムマスターである僕は開発でいっぱいいっぱいでした。POの助けなどできなかった。
ただ、その本質的な原因はなにかと考えると、POに裁量権が実質的になかったことだと思います。だから無理なスケジュールになって、開発が破綻した。で、裁量権のなさは今も変わらないんですよね。ただ、無理は無理、ということが真面目に考えられるようになったことが、一つ大きいかなぁ。
スプリントプランニングの前に、スプリントが成功するかは決まっている
スプリントを回すようになって、最初にうまくいったのは、スプリントバックログを作成して、それをこなすことでした。
つまり、スプリントプランニングの時点で、いい塩梅の見積もりができていれば、しっかりバーンダウンするはずなんです。それができなかったのは、プロダクトバックログがちゃんとできていない、あるいは、意識できていなかったからです。
そしてプロダクトバックログは、スプリントプランニングの前にあらかた作っておかないといけません。つまり、プランニングが始まった時点で、そのスプリントがうまくいくのかどうかは、ほぼ決まっている、ということです。
アジャイル開発で一番必要なものは、チーム全体のマインドセット
チーム全員が、開発の進め方に理解がないと、どうにもなりません。プランニングとかタフだし、自分がやっているタスクを明確化して、状況を反映させるとか、やってみるとなかなか面倒。なんでこんなことしないといけないの？という気持ちだとまず続きません。特に自分たちは今回は実績の記録をしているので、何のタスクにどれだけ時間かかったかまで記録しています。これすごくたいへん（でも開発以外の作業がこれだけあるんです、ということを外部に説明するために仕方ない……）。
マネジメントの観点からも、「無理なものは無理」だと思わないと、結局無理を承知でプランニングをして、無理だから終わらずに最悪の雰囲気でレビュー、レトロスペクティブ、そして次のスプリントプランニング……という悪循環に陥ってしまいます。それだけならまだしも、低品質でのリリースを敢行することになって、問題が出て炎上します。しました。
正直、どんなプラクティスを採用するかなんてのはどうでも良い話で、開発手法さえも多分本質ではなくて、無理をせず、やるべきことを優先して開発するマインドを得るための半年間だった、と思えてなりません。
開発は技術だけの問題ではない
スプリントはなんとか形になってきたとは思うけれど、それで開発がうまくいくかというと、そうとも限りません。スプリントを成功させるにはプロダクトバックログが命ですが、プロダクトバックログは仕様から決まります。その仕様は誰が決める？ビジネス側？エンジニアはいいなり？社内発注なの？
それでうまくいくはずはありません。つまり、技術側とビジネス側が、一体となって問題に取り組まないといけないのですが、それはスプリントを成功させるよりも、大きな大きな課題。開発の道は険しい。
参考書籍
書籍が私の先生でした。オススメは、カイゼンジャーニーで全体を知って、具体的なスクラムフレームワークのやり方をSCRUM BOOTCAMPで知り、ユーザーストーリーマッピングでプロダクトバックログの作り方を知り、エンジニアリング組織論で全体をまた包括的に考える感じです。人月の神話は教養ですが、ブルックスの法則とか今でも大事なので、読んでおいて損はないかと。
コメント