QAから見たWebサービスのスクラム開発の理想と現実

はじめに

QAエンジニアとしてスクラム開発を経験して感じた疑問点をまとめてみました。

スクラムメンバーの多様性

スクラム開発は8名前後のチームが最適とされますが、その中にQAエンジニアは入っていますか？スクラム内に入る場合も入らない場合もどちらもあり得るのではないかと思います。

QAエンジニアに限らず、Webサービスの特にアプリケーション開発においてはスクラムメンバーのスキルは同じではないと思います。同じではないというのはレベルが高いか低いかということではなくて種類が違うということです。具体的に言えば、Webアプリの開発ではiOSとAndroidとWebとで別々の開発言語を使われると思いますし、もし8人の開発メンバーにQAエンジニアも入れるとしたら、iOSエンジニア1人、Androidエンジニア1人、Webエンジニア1人、Backendエンジニア4人、QAエンジニア1人の様になるでしょうか？

8人のチームだとクライアントエンジニア複数体制というのは難しいのかもしれません。そうなると、優先度を決めても決めなくても結局、例えばiOSの開発タスクはiOSエンジニアが行って、Androidの開発タスクはAndroidエンジニアが行って、それが終わらなければ次のタスクに取りかかれないという状態になると思います。そうだとしたら、スプリントプランニングで優先度を決めて見積もりをする意味も薄くなると思います。

チームを10人にして複数エンジニアを配置すれば解決するかもしれませんが、採用計画含め必ずしもエンジニアの数が揃うとも限りません。また、フルスタックエンジニアが居れば足りない工数分をフルタックエンジニアが補うということも考えられますが、現実的には難しい現場が多いのではないでしょうか？

スプリント内のタスクの粒度の差

スクラム開発では通常、1週間から4週間のサイクルを反復します。一般的にはあるチームが2週間と決めたら2週間のサイクルで運用し、次は3週間とか次は1週間とか変えたりはしないと言われています。

タスクをストーリー単位に細かく細分化したとしても、ストーリーの大きさは一様では無いので、あるスプリントでは5個以上のストーリーを終了させることが予定されることがある一方、細分化しても大きなストーリは、1回のスプリントでは終わらなくて複数のスプリントにまたがって開発されることもあり得るのではないかと思います。また、アーキテクチャーの方向性がまだ定まっていない段階でも、1回のスプリントで決定しきれなくて1回のスプリントで終了するものがない可能性もあると思います。大きなストーリーがQA開始できることになったらそのQAも当然のように1週間のスプリント内では終わらない可能性も出てくると思います（リグレッションテストを自動化できているかどうかに関わらず）。

そのようなスプリントについて通常のマトリクス（バーンチャート等）で判断したり、振り返りを行っても無意味であると思います。

あまり考えたくはないのですが、スクラム開発がうまく行ってるように見えて、実は大きな課題を避けて細かい課題をたくさん消化しているだけで満足してるチームが相当数あるんじゃないかと危惧してはいます。

複数チームある時の部分最適と全体最適

スクラム開発は8人前後のチームが最適とされ、開発規模が大きくなれば当然の様に複数のチームが組織されます。

そして一つのサービスに対して複数のチームが組織された場合は、おそらくテーマごとにチームが組織されるのではないかと思います（例えばあるチームは新規ユーザーを獲得することにフォーカスした施策を担当して、あるチームはロイヤルユーザーを増やすための施策を担当してのように）。

そのような場合、プランニング中にチームAはPriority中のタスクをリソース不足を理由にスプリント対象から外して取り組むのを止め（Priority高のみ取り組む）、別のチームBはPriority低のタスクをスプリント対象にして取り組むことがあり得るのでは無いかと思います。その場合に、もしQAはスクラムの中に入らないというスタンスを取っている場合に、もちろんPriorityの高いものからやるべきだと思いますので、チームBのタスクが停滞することになるのでは無いかと思います。

プロダクトオーナーやスクラムマスターがチーム内のマネジメントを考えれば考えるほど、サービスの全体最適から遠ざかることがあり得るのではないかと思います。