プロダクトのリプレイスにスクラムは向いているのか

はじめに

僕は現職では、プロダクトのリプレイスをしていて、スクラムで開発を進めています。
入社当時からスクラムで運用していたので、そういうものだと思っていましたが、スクラムを体験して早 1 年。プロダクトのリプレイスでスクラムを採用してみて感じていることを言語化してみようと思います。

リプレイス = そのまま移管であればスクラムを採用する必要はないかも

リプレイス、といっても社内でどういう方針で進めるかはそれぞれだと思います。
旧プロダクトの機能や見た目はそのままで内部の使用技術や設計を新しく差し替えるだけであれば、それはまさに「移管」にあたるのでスクラムでやる必要はないんじゃないかなというのが現時点での僕の感想です。

一方で、旧プロダクトの画面の見た目や仕様まで変更して、まさにリニューアルのような形でリプレイスするのであれば、スクラムは大いに真価を発揮するのではないかと考えます。

スクラムのメリットって作ったものを検査して、本当に価値が提供できるかを素早く検証・改善できることだと思っていて、そのまま移管するのであれば、ユーザーやステークホルダーが期待するものってわかりきっている（= 旧プロダクトと同じ見た目・挙動で上がってくるのが当たり前だよね）のでスクラムはそこまで刺さらないんじゃないのかなとおもいます。

スプリントレビューでステークホルダーにフィードバックを求めても、デモしたインクリメントの挙動が旧プロダクトと同じことを確認するだけなので、何も上がらない、っていう結果になるのが予想できますね。

完了予測を建てれるメリットはありそう

リプレイスにあたり、必要なタスクをプロダクトバックログに片っ端からおろして、ポイントの見積もりをすることで、ベロシティからある程度の完了目処は立つので、そういう側面ではスクラムでやるメリットはありそうですね。

とはいえ、前提として、ステークホルダー含め開発に関わる人たち全員が、当初立てた計画へのこだわりを捨て、作業の遅れから計画を変更させることを厭わない体質が必要そうです。
あくまで計画を仮定や仮説程度にあつかわなければいけません。

スクラムにとらわれなくてもよい

まとめると

• 中身だけを差し替えて機能や見た目を変えないリプレイスであれば、スクラムでやるメリットは薄い

• 部分的もしくは全面的に機能を変える、削るリプレイスであれば、スクラムでやるメリットはある

が僕の考えです。

また、最近ではガチガチのスクラムにとらわれる必要も無いんじゃないのかな、と思っています。
それは、X での下記のポストを見てからより一層感じました。

DeNAでスクラムによるプロジェクトマネジメント、メルカリでOKRによる目標設定を初めて経験した時にも思ったけど、フレームワークって先人の経験を活かせることと、共通認識を得られやすいという意味で有用なんだけど、導入するときに原理主義になると絶対に反発が生まれるし、結局普及しない問題って…

— hidek (@hidek) May 17, 2024

スクラムを推し進める人には原理主義者も一定数いる気がしていて、僕もそうだったのですが、フレームワークの思想は大事にしつつ、少しアレンジする勇気や覚悟も必要だよね、と感じます。

極論、全員がプロダクトの価値最大化のために考え、開発できるのであれば、プロダクトオーナーは必要でもないですし、全員がロールを越境し、支え合うことができれば、スクラムの 3 つのロールにメンバーをアサインさせる必要も無いんじゃないかな、とも思います。