株式会社リブセンス アルバイト事業部エンジニアの村山です。 マッハバイトの一部開発ではスクラムを使っていましたが、やめました。 後半半年くらいのスクラムマスターをやっていたのですが、せっかくなので個人的に振り返ろうと思いこちらを書いています。
内容の関係上、スクラムマスターのノウハウを求めている人よりも これからスクラム開発の導入を検討している人の助けにはなるかもしれません。
最後まで読んでいただけると嬉しいです。
スクラム導入までの経緯
マッハバイトでは2020年1月の組織改編に合わせて、スクラム開発を取り入れ、2021年4月にスクラム開発をやめました。 約1年の間、レトロスペクティブなどを通して様々な改善をしてきました。 時には輪読会で本を読みながらお互いに意見を交わしたり、スクラムイベントのやり方を変えてきたりなど大小様々な改善をしてきたスクラムチームではあったのですが、最終的には馴染まなさ故に生産性や品質の向上に直結していない感じがあり、辞めることになりました。
なぜ、スクラムは自分たちのチームに馴染まなかったのか 個人的な考えを述べていこうと思います。
なぜスクラムが馴染まなかったのか
最も大きな原因は スクラムに適した開発体制ではなったこと だと思います。
組織改編を行った際に、開発体制は以下のようになりました。
※伝えたい本質とは外れるので人数や取り巻くチームはかなり簡略されています。
元々は右側のチームにエンジニアが配属されているチーム構成でしたが 改変後はエンジニアはエンジニアでまとまる体制になりました。 この体制はエンジニアが個々のプロダクトに配属されていることで発生する属人化の解消やその他様々な問題の解決を目的としたものでした。 スクラム開発はこの体制への変更とともに始まりました。
プロダクトに縛られない様々な施策にトライすることが可能になり開発可能領域は確実に増えている実感はあり、開発メンバーはプロダクトを浅く広く知ることができました。 ただ、この体制でスクラムを回していくのは無理がありました。開発者に紐づく開発対象のプロダクトが多すぎたためです。
開発対象のプロダクトが多岐にわたるため、一部のスクラムイベントで機能不全が起きてしまいました。 例えばプランニングでは、ポイント見積もりが難航しました。 開発者の中でもプロダクトに対する専門領域に差があったため見積もりが不完全に終わることが多かったです。 見積もりが不完全だとプランニングが難しくなったり、ベロシティからチームの健全性が計りづらくなります。 最終的にレトロスペクティブをしてもチームを改善できたのかが判断できない状態に陥ってしまいました
見積もりの正確性が初期には低くなるのは仕方がないのですが、チームがプロダクトへの理解を深めていくほど正確性が上がるのが定石です。 ですが、対象プロダクトの多さ、規模の大きさでどうしても不明瞭な範囲が生まれてしまい定石通りに行くことはありませんでした。
また、仕様に対して議論を交わす時間（グルーミング）を用意していたのですが ステークホルダー、対象プロダクトの多さから、毎回かなりの時間をつかってしまいました。 時に有用な話ができることもあったのですが、そのコストに見合っているか、と言われると難しいところでした。
こうした、スクラムイベントの機能不全による違和感が積み重なって馴染まなさに繋がっていました。
また、関わるプロダクトの多さは目的意識の薄れにも繋がっていました。 スクラムが漸次的に開発を進めていくのは、達成したい目標、ゴールに対して自分たちの進みを細かに確認し、進行方向の修正を行えるようにするためです。 複数のプロダクトにまたがって開発を行っていると自ずと複数の目標や方針と付き合っていくことになるのですが、多すぎるため開発者には浸透していかず、状態の確認や方針の修正まで一緒に考えていくことがでできませんでした。
シンプルな解決策として、スクラムチームを増やして複数の開発チームとステークホルダの図式にするのが考えられるのですが、開発者が圧倒的に不足しているため実現に至っていません。
これらの出来事を通して、最終的にはスクラムを使わないことをチームで決定しました。
まとめ
マッハバイトではスクラム開発を行っていましたが、辞めてしまいました。 個人的には原因は体制にあったと思います。 体制とスクラムフレームワークのミスマッチでスクラムイベントの一部が機能不全になってしまい、有用な時間を過ごすことができませんでした。
残念な結果に終わってしまったのではあるのですが スクラム開発はやめても振り返りの習慣は続いていて、チームのあり方について話し合う文化は残り続けています。 組織について視点を向ける人も確実に増えました。 このように良かったこともたくさんあったと思います。
これからスクラムの導入を考えている方がいるのでしたら 開発対象プロダクトの規模が、スクラムチームが主体的に関われる程度なのか、という点を考えると良いかもしれません。
色々ありましたが、上述したように組織に対して目を向ける文化ができたことは素晴らしいことだと思います。 そして、まだまだ一緒になってチームを改善してくれるメンバーを常に募集しているので もし少しでも興味を持っていただけたら、お声掛けください。
