ハウテレビジョンで若手社会人向けプラットフォーム Liiga の開発とスクラムマスターをしている 59k です。

Liiga プロダクト開発チームでは、スクラム開発を取り入れて機能開発・保守運用を行なっていますが、つい最近「脱なんちゃってスクラム」をできたのではないかと思える変化があったので、それについて記録を残そうと思います。

また私がハウテレビジョンに入社して 3 年、Liiga プロダクト開発チームのスクラムマスターになって 1 年という節目でもあるので、これまでのチームのスクラム開発についても振り返りつつ、本題について書ければと思います。

そもそもスクラム開発とは

「なんちゃってスクラム」について語る前に、そもそもスクラム開発とは何かについて軽くふれておきます。Notion AI さんの力を借ります。

NotionAI

スクラム開発とは、プロジェクトを小さな部分（スプリントと呼ばれる）に分割し、それぞれのスプリントで具体的な成果物を作り出す形のアジャイル開発の一種です。スプリントは通常、2〜4週間の期間で設定され、その間に特定のタスクを完了する目標（スプリントゴール）が設定されます。スクラム開発では、プロジェクトチームが日々の進捗を確認し、問題点をすぐに共有・解決することを重視します。これにより、プロジェクトの進行中に新たな要件や問題が発生した場合でも、素早く対応することが可能となります。また、スクラム開発では、開発チーム全体が互いの進捗状況を把握し、共同で問題を解決するための環境作りが求められます。これにより、チーム全体として問題解決能力や生産性を高め、より質の高いプロダクトを効率的に開発することが可能となります。

補足として、スクラムとは？を正しく理解したい方は、公式のスクラムガイドのご一読を進めます。

https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf

Liiga プロダクト開発チームにおけるスクラム開発のこれまで

まず、Liiga プロダクト開発チームがこれまでどのように開発フローを変えてきたかを振り返りたいと思います。

~2022.6 （スクラム開発ではない）アジャイル開発期

まず、私が知る限りチーム発足(2015年頃)〜2022年6月まで続いた、「スクラム開発ではないアジャイル開発期」です。

この記事の本題とは遠いので深掘りはしませんが、この時期の私は1メンバーとして、「頑張ってはいるつもりだが、どこまで頑張れば合格点なのかわからない…」といった悩みを抱えていました。

「自分に降ってきたタスクを、自分のペースでやるだけ」みたいな日々で、「これがベストではない気がする、でもどうすればいいのかわからない」とモヤモヤを感じていた時期だったと記憶しています。

2022.6~2023.8 スクラム開発導入、なんちゃってスクラム開発期

そんな中、外資就活チームから異動されてきた方により、Liiga プロダクト開発チームにスクラム開発（2週間スプリント）が導入されました。

私自身はここで初めてスクラム開発という開発手法の存在を知ったので、個人的にはとても大きな出会いです。バーンダウンチャートで日々の進捗を確認できるようになったことで、スクラム導入前に感じていた「どこまで頑張っても、これでいいのかわからない」モヤモヤからも、無事解放されたように思います。

チームにも小さくない変化を与えました。具体的には各チケットの見積もりを人日ではなく作業量ベースで行い、スプリントごとのベロシティをモニタリングするようになったことで、それまで関心ごとでなかった「中長期的なチームの成長度」に嫌でも関心が向くようになりました。

しかし、この時期はまだ「なんちゃってスクラム」だったと思います。理由は以下2つです。

スプリントレビューを行っていなかった
スプリントゴールを設定せず、ベロシティが上がればいい、みたいな空気だった

スプリントレビューを実施していなかった背景には、役割が近い別MTG がすでにあったからではありますが、そのMTGは以下3つの点でスプリントレビューとは異なっていました。

営業の方のみが参加しており、オープンにレビューを集める場ではなかった（マーケ等他部署に開かれていなかった）
インクリメントに対してではなく、直近リリースされた機能について共有する場だった
開発チームからは固定の代表者1人のみが参加しており、全員参加ではなかった

ちなみに「なんちゃってスクラム」かどうかの判定はこちらの記事の「スクラムの各イベントで、『スプリントゴールの達成のために』という言葉が出ているか？」のイメージです。

2023.9~ 脱なんちゃってスクラム、マジスクラム開発スタート

そして 2023 年夏、チームで経験したある失敗をきっかけに、ついになんちゃってスクラムを卒業します。

この頃に行っていたある新機能開発において、リリースの直前に「本当にこの仕様で良かったんだっけ…？」という迷い・不安がチーム内で生まれてしまったのです。この機能自体は不安を抱えたままリリースし、結果的には多くのユーザーに利用いただいたものの、これがチームにとって脱なんちゃってスクラムのきっかけとなりました。ここからはその仔細を説明します。

なんちゃってスクラム開発期に抱えていた問題

上記「なんちゃってスクラム開発期」においては、以下のようなフローで開発していました。

プロダクトオーナーが要件定義書を作成
要件定義書をもとにデザイナーが UI (Figma) を作成
要件定義書と Figma をもとにエンジニアが実装
リリース前に PdM + デザイナー + エンジニアで UIUX&動作チェック

今思えば、要件定義書を作成している時点で純粋なアジャイル開発とも言い難いですね。実際ウォーターフォールっぽい側面があり、大きな仕様変更やアクシデントがない限りは順調にリリースまで漕ぎ着けていたものの、先述の機能開発のようなケースでは「後の祭り」として片付けざるを得ないような開発フローだったと思います。

また、仕様検討フェーズがプロダクトオーナー（PO）に依存しており、キャパシティオーバー気味だった問題もありました。要件定義書の作成コストや、そこに書ききれない背景をエンジニアやデザイナーに伝えるコミュニケーションコスト、さらには「仕様の質が PO 次第」という心理的負荷もあったと思います。

当時の「仕様策定〜開発」の流れ

graph TB
  b(プロダクトオーナーが要件定義書を作成)
  b-->c(要件定義書をもとにデザイナーがUIを作成)
  c-->d(要件定義書と Figma をもとにエンジニアが実装)
  d-->e(リリース前にPdM、デザイナー、エンジニアでUIUX&動作チェック)

解決策として、スプリントレビューを導入

上記の問題を解決できる可能性があると思い導入したのが、スプリントレビューです。狙いは以下です。

より早く、より短いスパンでチーム内外からレビューをもらうことで、リリース直前での大きな仕様変更を防ぎたかった
よりユーザーに近い、Biz やマーケの方からレビューをもらうことで、仕様の質を高めたかった
開発者全員が仕様検討に参加することで、実装時のコミュニケーションコストを下げたかった

スプリントレビューを導入して 2 ヶ月ほど経過しましたが、上記の狙いは果たせており、最近の開発ではチームで自信を持って仕様策定〜リリースできているように思います。

現在の「仕様策定〜開発」の流れ

graph TB
  b(スクラムチーム+ステークホルダー（Bizやマーケ）でユーザーストーリーマッピング ※)
  b-->c(デザイナーがUIを作成)
　　　　b-->d(PO＆エンジニアがプロダクトバックログアイテムを作成)
  c-->e(エンジニアが実装)
  d-->e
  e-->f(リリース前にPdM、デザイナー、エンジニアでUIUX&動作チェック)
  f-->g(スプリントレビュー)

※仕様検討のとっかかりを作るため、ユーザーストーリーマッピングにも併せてチャレンジしました。

今だからわかる、なんちゃってスクラムをなかなか抜け出せなかった原因

スプリントレビューをやるようになると、チームは自然とスプリントゴールを意識して動けるようになりました。（これをもって「なんちゃってスクラム卒業」できたと考えています。）

実はスプリントゴールが重要であること自体は以前から認識しており、ゴール策定には何度かチャレンジしていたのですが、チーム内で「スプリントゴール達成のために」というワードを聞くことはありませんでした。

今振り返ると当然なのですが、当時はベロシティからなんとなくスプリントゴールを決めており、「なぜゴールを決める必要があるのか？」という疑問に誰も答えられなかったのです。

しかしスプリントレビューを導入すると、自然と「スプリントゴール」が重要な意味を持つようになります。スプリントゴール ≒ 「スプリントレビューで何をお披露目したいか」であり、それが達成できなければスプリントレビューは開催できず、フィードバックをもらうのは 2 週間後。リリース時期にも大きく影響します。

結局大事なのは「守破離」だった。しかし…

結果から言うと、私たちがなんちゃってスクラムをなかなか抜け出せなかったのは「スプリントレビューを実施していなかったから」でした。スクラムガイドにも定義されている重要なイベントをやっていなかったわけですから、当然と言えば当然です。

しかし、「スクラムガイドでこう定義されているから」という理由で何かをするのは、目的と手段を混同する危険性もあると思います。スプリントレビューの導入は、どちらかと言えばメンバーへの負担が増える変化だったので、そのような説明では納得感も得られなかったかもしれません。

私たちの場合はそうではなく「我流でやってきたが、このフローではダメだ」という失敗をチームで経験できたから、スプリントレビュー導入をスムーズに行えたのではないかと思っています。

これもまたスクラム開発で重要な「経験主義」という考え方に通ずると思います。「守破離」は大事にしつつ、でも今後も経験に基づいてチームにあった方法を模索していければいいなと考えています。

最後に

エンジニア絶賛募集中です！

ハウテレビジョンブログ

『外資就活ドットコム』『Liiga』『Mond』を開発している株式会社ハウテレビジョンのブログです。

スプリントゴールとスプリントレビューを導入して、なんちゃってスクラムを卒業できた話