WASD TECH BLOG

WASD Inc.のTech Blogです。

ワスドのスクラム開発で芋煮会をやっている話

ワスド株式会社 Development Division(開発チーム)の okkun です。

弊社では「デジちゃいむ」という店舗向け呼び出しシステムを開発しています。その中で、開発チームでは SCRUM BOOT CAMP THE BOOK を共通の参考図書とした上で、スクラムをチームにフィットするようカスタマイズし運用しています。

digichime.com

スクラムとは?

ラグビースクラムが由来してます

そもそもスクラムとはアジャイル開発という概念を達成するために考案されたフレームワークです。

大きな特徴として、

  • スプリントという予め決めた1週間〜1ヶ月の期間で区切って繰り返し開発すること
  • そのスプリントの最初に決めたスプリントゴールの達成に向けてチームが一丸となって取り組むこと

が挙げられます。

スクラム開発では、

  • 5つのイベント
  • 3つのロール(役割)
  • 3つの成果物

が定義されており、メンバーそれぞれが持つ役割を全うしチームで協力して成果物の完成を目指します。

後述で登場する一部のものについてここで簡単に説明します。

スクラムマスター

スクラムチーム(開発者、ステークホルダー:利害関係者)の業務をスムーズにするため、ファシリテートを行ったりチーム外からの干渉(割り込みで発生するタスクなど)からチームを守る役割を持つ人物。

プロダクトバックログ

プロダクトの改善に必要なものをまとめた一覧。Todoリストのようなもの。

スプリントレビュー

直近スプリントの成果物をチームで確認するための場。

スプリントプランニング

次のスプリントの方針を定め、どの課題の改善に着手するかを決める場。

スプリントレトロスペクティブ

直近スプリントについての振り返りの場。 スプリント中に発生した問題や解決方法などをチームに共有し、次回以降のスプリントに生かすことでプロダクトの品質向上に繋げられる。また、プロダクトバックログの中身について再度精査し、必要に応じて優先度などの再調整も行う。

その他のものについては下記SCRUM GUIDESにドキュメントがありますのでこちらをご覧ください。 サイト自体は英語ですが、日本語のドキュメントも掲載されています。

scrumguides.org

ワスドなりにカスタマイズしている点

スプリントについて

弊社では1スプリントを水曜〜翌週水曜の1週間としています。

私が入社した時点では既に水曜日がスプリントの区切りでしたが、聞いたところ、以前は金曜日をスプリントの区切りとしていたようです。 これは、金曜日に向けて開発を集中していくという点でリズムは作りやすかったのですが、

  • 週明けにやることを思い出すところから始まってしまう
  • 金曜日に有給をとりづらい

などの理由から水曜日に移したという経緯があったようです。

スプリントの周期と曜日は最も基本的ですが、開発体制に大きく影響を与えるファクターだと思います。

使っているツールについて

弊社はドキュメントツールとして全社的に Notion を使用しています。

開発に関わるプロダクトバックログも Notion 上で管理することで、インターンを含め社内関係者が誰でも見れる風通しのいい環境を作っています。

プロダクトバックログへの起票は誰でも行っていいことになっています。

www.notion.so

ちなみに、私の入社以前は JIRA でプロダクトバックログの管理を行っていました。 スクラム専用のツールだけあってストーリーポイントやバーンダウンチャートなどの機能が備わってあります。

Notionにもこれらの機能がほしいと感じることもありますが、Notionは頻繁にアップデートされていますので今後の機能追加に期待したいです。

www.atlassian.com

プロダクトバックログの考え方

プロダクトバックログ上に起票されるものは単なる「タスク」ではなく「ユーザーストーリー」として扱われ、ユーザーに提供される価値に焦点が当てられます。

具体的には、「どんなペルソナが」「どんな結果を得られるように」「そのために我々が何をするのか」という視点で起票されます。

そのため、具体的な実装方法や実装方針等はここでは起票せず、GitHub Issueとしてまとめて開発チーム内で議論を行います。

asana.com

その他のミーティングの進め方

ワスドでは専任のスクラムマスターは置いておらず、スプリントレビューは開発チームが主体となって運用、プロダクトバックログはビジネスチームと開発チームが協力して運用、という形をとっています。

デイリーミーティングは毎日10時に行っています。 この場で前日やったこと、今日やること、進行で困っていることなどを共有します。

振り返り(スプリントレトロスペクティブ)は月1回で行っていますが、これは毎週行っているとKPTを無理やり絞り出したりして形骸化する可能性があるためで、この間隔で丁度いいように感じています。

「このあと芋煮会よろしくお願いします。今日は長芋です。」

楽しそうに芋を煮る社員の様子

誰が言い出したのか、社内ではプロダクトバックログ「欲しいものリスト」「干し芋と呼ばれ、そこから派生しスプリントプランニングは芋煮会と呼ばれています。

月1のスプリントプランニングは長めの芋煮会ということで「長芋」「ポテロング」などと呼ばれており、スプリントレビュー後にスプリントプランニングを行う日の場合は、

「このあと芋煮会よろしくお願いします。今日は長芋です。」

という会話が発生しています。ここまでくると何が何だかわかりません。(そもそも干し芋って煮るのかな...?)

親しみやすい名称を使うことで社内全体を巻き込みやすくなっているというメリットがありますが、一方で正式名称が浸透していないことで正しい理解に辿り着き伝いというデメリットもあります。

「スプリントプランニング」という単語を知ってれば検索してそれに関する記事を見ることができますが、「芋煮会」と検索しても私の出身である山形の芋煮会フェスティバルの記事が出てきてしまいます。

記事冒頭で挙げたSCRUM BOOT CAMP THE BOOKを開発チームの参考図書としているのはこういった背景もあるためです。

おわりに

この開発スタイルは私が入社する以前から運用されていたため、この記事を書くにあたっても初期からいるメンバーに背景などを教わり初めて知ることもありました。

立ち上げ期のスタートアップの開発ではメンバーもスケジュールも限られていることが多く、その中でユーザーに少しでも早く価値を届けることを考えた時にテンプレ通りのスクラムでは成立しないこともあります。

組織やプロダクトが大きくなるにつれて課題も変わっていくと思うので、その時点でのよりよい方法を開発チーム内外で協力して模索しつつ、価値のあるサービスを提供し続けたいです。

そのためにもまずは SCRUM BOOT CAMP THE BOOK などで一般的な知識を得た上で現状を分析することが重要だと思いました。