システムリプレース案件にスクラム開発を用いた失敗について考える

つい先日、担当していたプロジェクトのリリースが終わり、不具合対応もようやく落ち着いてきたように見えます。_(:3」∠)_ いろいろと失敗も多く、リリースして割と余裕が生まれてきたこのタイミングでぜひ振り返りせねばならんな、の流れになり。

その振り返りが明日(というより今日か)実施されるわけでして、個人的に感じたことを先に言語化してしまおうか、というのがこのエントリ。

プロジェクトについて

今回の案件、これまで使われていたRails4のEC系サブシステムを、Rails5にしつつ設計を整理するリプレース案件でした。今年2月くらいから動いていた話で、自分がJoinしたのは7月の開発後期というタイミング。

前のコードが大変に酷い出来で、問題が多々あったんですよね(´・ω・`)

利用者がそれほど多くないとはいえ、さすがにDAU十数万のサービスで500req/1sec捌けないのはどうよ？といった性能的な問題もあったわけです。

この状態では追加の機能拡張のコストが尋常じゃなく高いため、それを払拭する目的でのリプレースと相成ったと聞きました。

さて、コードの悲惨さは今後どこかでネタにするとして、今日はプロセスの話。

今回のシステムリプレースでは、スクラム開発を実践してました。チームに専任のスクラムマスタに入ってもらい、プロジェクトオーナーがプロダクトバックログを捌く、まあよくある図式のやつです。

ここに朝一のデイリースクラムが加わり、まさにこの体制通りの理想的なスクラムです。 https://www.ryuzee.com/contents/blog/7124

と、盤石なスクラム体制で挑みましたが、結局、リリース一月前に途中でスクラムやめました。理由は以下の通り。

スプリントでやる作業だけに集中した結果、既存システムでできることが考慮から漏れており、度々要件漏れに悩まされる(今でも地獄見てます)
マイルストーンが不明確。このときまでに動いておくべきものに意識が向いていなかった(結局すべてのAPI完成するのに、リリース2週間前までかかりました。QA is どこ？)
テスト期間中想定以上にバグが生まれ、バグチケットを捌くのに時間が取られた結果、スプリントバックログが消化できない
バグ対応の長時間労働でチームが疲弊し、スプリントバックログの消化未達が増える
そもそも開発メンバーの自走力に差がありすぎ、見積もったポイントが消化しきれない。結果当初7月予定のリリースが10月までずれ込む。

個人的に感じるスクラム開発の強みですが、「継続的に」、「一定のサイクルで」、「機能拡張や改善」をリリースし続けることにあると考えます。小さく作って育てる新規開発だったり、運用を長期に渡って続けていくケースではパワーを発揮します。

ところが、期間が明確に決まっていて開発スコープが動かしづらいリプレース案件には向いていないと感じました。『1スプリントでできることをやる』といった特性上、1スプリント中のタスクに意識が向きすぎ、全体の作業感の管理が難しいのでは？というのが私の一番感じたところです(´・ω・`)

スコープが動かせないリプレース案件的なものはスクラムで押し切るより、ウォータフォールで機能を漏れなく期間中に作り上げることを目指した方が、より幸せだったかもしれません。

全体の工数感やマイルストーンを把握するためにより長いスパンで振り返りできれば、もう少し余裕をもって開発できたと感じます。

スプリントバックログの未達問題も、1週間スプリントを振り返って4週間スプリントに反映していければ、解消できたかな、と。

「今のシステムと比べて出来なくなったことはありませんか？」の問いかけを最初にしっかり固めていれば、要件漏れは防げたのかもしれません。

そのタイミングで上がってきた課題は早急に潰しておく。今回はスプリント回しながらの改善をしようとしましたが、そもそもスプリントバックログの未達が続き、問題に向き合う時間が少なかったと感じました。

個々人の自走力の問題は、これを適切に行えていれば防げたのかもしれません。

スプリントを回しながらバグ対応は無理です。割り込みが多すぎる(ヽ´ω`)

割り込みが多い中でなんとかスプリント回すことを考えるより、割り切ってリソースの振り方を考え直すことが必要と感じました。

ここまでつらつらと書いてきましたが、最後に言いたいことは、「開発に銀の弾丸はない」ということですね(´・ω・`)

今回の失敗や感じたことをもって、振り返り、参加してきたいと思います。