dinii のプロダクト開発を担うチームのスクラムをカイゼンした話
こんにちは、dinii のエンジニアの谷藤 (@HiroIot) です！
愛猫が大好きすぎて、最近は仕事以外の時間をすべて愛猫に注いでいます😽
さて、dinii では、次の 50 年の飲食インフラとなるべく、飲食店内向けモバイルオーダーと CRM サービス「ダイニー」を開発・運用しています。
dinii のエンジニアチームは創業からずっとワンチーム体制でいましたが、 2022 年にプロダクト開発を担う Feature team と プロダクトの基盤開発・運用を担う Platform team に分割しました。
Feature team
ミッション: dinii のプロダクトの全ての開発
Platform team
ミッション: 飲食のインフラサービスを安定的に提供し、継続的にスケールさせるための開発・運用を行う
チーム分割の背景などは CTO 大友 (@dinii_k_otomo) の記事に詳しく書かれているので、気になる方はぜひ見てみてください！
今回はそのプロダクト開発を担う Feature team が実際に直面した開発プロセス (スクラム) の課題やそのカイゼンについて共有します！
特に以下のような方に読んでもらえると良いかなと思っています。
dinii の Feature team の開発プロセスに興味がある方
チームでスクラムを本格的に運用しようと考えている方
チームでスクラムを運用しているが上手く回っていない方
それでは始めていきます。
課題
まずは実際に Feature team が直面した課題についてです。
2022 年 9 月 くらいから、事業的な要因やチームの体制変更などに伴い、Feature team が並行して進めるべき開発 Epic の数や Epic 間の依存関係が増え、ロードマップの複雑度が一気に増しました。
Feature team のスクラムは元々以下のような状態だったのですが、何となく上手く回っているように見えていて、大きな問題にはなっていませんでした。
関係者を巻き込んだ Planning がしっかり行われず、本来優先すべきものが優先されていない
定期的な検査がしっかり行われず、リリース後に手戻りが発生していた
開発者が Sprint にコミットメントしておらず、開発が思ったように進まないが、振り返りもしない
しかし、ロードマップが複雑になったこのタイミングで、Feature team によるプロダクト開発 (スクラム) が曖昧かつ不安定になっていることが一気に可視化され、全社的な課題になりました。
以下、実際に部署内外からもらった声の一部です。
開発が安定していないから事業計画や長期のロードマップが立てづらい
計画通り機能がリリースされないから Sales 活動には使えない
いついつリリースされることをお客様に伝えてしまった
改善をお待ちいただいているお客様に具体的な案内ができず、不信感に繋がっている
この段階でチーム内でも課題意識が強くなり、Feature team のスクラムに関する議論が何度もされました。
カイゼン策
チームで何度も議論を重ね、個別具体の課題やそれに対する解決策が多く挙がりましたが、「それらってスクラムを本格的にやれば解決するのでは？」というふうに落ち着きました。
今だから言えることではあるのですが、何となくスクラムをやっているよりも、チームや組織の現状課題を洗い出し、その解決策としてスクラムを本格導入するという順番だとスクラムの腹落ち度合いが全然違います (当たり前ですが)。
チームにスクラムが上手く浸透していないという方は、後付的ではありますが、「なぜスクラムをやっているのか？」を改めて言語化してみると良いかもしれません。
Feature team としてスクラムを本格的に始めるにあたり、チームで考えて実施してきた施策のうち、特にやって良かった以下の 4 つについて紹介します！
チームのスクラム理解度を上げる
スクラムイベントの整備
スクラムメトリクスの可視化
PBI の徹底的な整備
【チームのスクラム理解度を上げる】
スクラムガイド がスクラムのすべてのベースになるので、大前提チーム全員が理解している状態を作りました。
読み合わせは行わず、各人が事前に読んできたスクラムガイドを基に議論して、チームとしての解釈を作ることにフォーカスしました。
例えば、「コミットメントとは、責任を持ち、最大限の努力をすること」のような感じです。
個人的には、日本語に翻訳されたスクラムガイドだと若干ニュアンスが伝わりづらいところがあると思っているので、本家の英語版のスクラムガイドを見ることをおすすめしています。
その他、スクラムに関するプラクティスは 吉羽 龍太郎さんのブログなどを参考にして、チームでさらに理解度を上げました。
【スクラムイベントの整備】
チームのスクラム成熟度が上がるかどうかは、各スクラムイベントの質に依ると思います。
スクラムイベント中はイベントの本質的な価値にフォーカスできるように、事前にアジェンダをチームで言語化しました。
各イベントの最後に会自体へのフィードバックをもらう時間を取っており、それによってイベント自体もどんどん改善 (適応) しています。
以下、一部のスクラムイベントのアジェンダです。
【スクラムメトリクスの可視化】
スクラムにおいて大事なのは、Sprint ごとの結果的な指標に一喜一憂するのではなく、Sprint ごとに Sprint ゴールの達成に向けて改善していくことですが、その改善が上手く回っているか、不健全なポイントはないかを知るための方法として、メトリクスの可視化と定期的な振り返りは有効だと思います。
ただ、結果的な指標に一喜一憂しないと書きましたが、Sprint ゴールの達成にスクラムチームで 100% コミットメントすることは大前提大切で、100% コミットメントするから健全な課題が見つかり、健全な改善に繋がります。
そういった前提や目的を持ちながら、スクラムチームで議論して、長期的にウォッチする指標を決めました。
以下、ウォッチしている指標の一部と解説になっています。
Sprint ゴール達成率
Sprint Planning で決まった Sprint ゴールをどれくらい達成できたかを表す指標
数値が高ければ高いほど良い状態で、事前に定めたフォーカスすべき価値が高いことにコミットメントできていたことを表します
理想は、ストレッチな Sprint ゴールを設定して、毎週それが 100% 達成されること なので、目標値や適正値は 90% としています
バグチケット率
Sprint で扱ったチケットのうち、バグ対応に分類されるチケットが占める割合
数値が低ければ低いほど良い状態で、Sprint において新たな機能開発に時間が使えていることを表し、また、以前の Sprint における機能開発の品質が高かったことを表しています
0 にしようとするとコスパが悪くなってしまうので、10 ~ 20% を目標値にしています
ベロシティ (絶対量 & 安定性)
Sprint で完了したチケットの SP の合計値
高ければ高いほど、より多くのアウトプットを出せていることを表しますが、単なる主観で見積もったアウトプットの量に過ぎないので、チーム内外で重要視しすぎたり、誤った見方をしないように注意しています
ただ、スクラムチームのパフォーマンス安定性がわかったり、Sprint の計画やビジネス上の計画に使っていたりするので、ウォッチはしています
Sprint 達成率
Sprint Planning で計画した Sprint のチケットがどれくらい達成できたかを表す指標
数値が高ければ高いほど、高精度な計画が立てられていることを表します
Sprint で一番重要なのは Sprint ゴールの達成ですが、Sprint ゴールを達成したら何もしなくなるというのは不健全なため、ウォッチしています
事例として、Feature team のある Quarter のメトリクスの一部を公開します。
チケットの管理は JIRA で行っているのですが、JIRA のメトリクスだとかゆいところに手が届かなかったりするので、Google Sheets で管理しています… (本当は JIRA で完結させたい)
【PBI の徹底的な整備】
元々 Sprint が不安定だったり、機能開発の品質が上がらない大きな原因の一つとして、PBI の質が悪かったことがあります。
PBI が曖昧だと、不確実性が高まり、開発者は完了にフォーカスできなくなってしまいます。その結果、Sprint 中に完了できなかったり、考慮漏れなどによるバグを生んでしまうことに繋がっていました。
スクラムチームで議論し、PBI の質を担保するために最低限書くべき項目を決め、これが満たされていない PBI は Sprint Backlog には入れることができない制約を作りました。
以下がその項目と解説になっています。
ユーザーストーリー
このチケットが生み出すアウトカムの仮説で、どんな顧客のどんな課題をどう解決してどのような状態にしたいかをまとめたもの
5W1H でいうところの Who と What にフォーカスしたもの
受け入れ要件
ユーザーストーリーで書いた開発すべき機能の仕様を細かく言語化したもので、「○○画面で、□□ボタンを押したら、△△になる」くらい具体的なもの
これがチーム内外に共有される細かい仕様にもなり、QA のテスト項目にもなる
完了の定義
何が達成されれば PBI が Done になるのかの基準で、以下のようなものになる
受け入れ要件をすべて満たしている
コードオーナーのコードレビューが通っている
Sprint Review でデモが可能な状態になっている
受け入れ要件は PBI ごとに変わるものだが、完了の定義は基本的にはすべての PBI で同じ
実装項目 (任意)
機能の実装方針・手順をざっくり羅列したもの
基本的には書かずに着手する人が考えて進めることになるが、特定の背景によって実装方針を固定したかったり、newcomer が着手する場合、詳しい人が書くことがある
5W1H でいうところの How にフォーカスしたもの
結果
上記のような施策を数多く実施してスクラムをカイゼンしてきましたが、その結果、スクラムイベントや日常のコミュニケーションの中で、自然と「透明性」「検査」「適応」「コミットメント」というスクラムのワードが出てくるくらいチームのスクラム理解度・成熟度が上がりました！
また、Sprint ゴール達成率の安定だけでなく、Sprint 自体の達成率やベロシティの安定性が向上し、長期のロードマップが立てづらい課題だったり、新機能が Sales 活動に使えない課題がおおよそ解消されたと思います。
ここまで、dinii のプロダクト開発を担う Feature team が実際に直面したスクラムの課題やその解決策を紹介してきました。
同じようにチームのスクラムに課題を持っている方に、少しでも参考にしてもらえると嬉しいです！
また、Feature team の開発プロセスが気になっている方が、少しでも雰囲気を掴んでもらえたら嬉しいです！
ダイニーは外食産業の今後50年のインフラを担うプロダクトです。
飲食店のみならず、来店するお客様の外食文化を支える極めて重要な役割を担っています。
友人と楽しく会話したり、恋人とドキドキする時間を過ごしたり、家族と心温まる団らんをしたり、取引先とタフな交渉をしたり……。
私たちが生まれてから今日まで、人びとの生活や文化を支えてきた尊い空間が “外食” には存在します。
そんな外食産業を、ぜひ一緒に楽しく面白いものにしていきましょう！
この記事が気に入ったらサポートをしてみませんか？