スクラム開発の効果を最大化するゴール設定のコツ

これは株式会社TimeTree Advent Calendar 2023の22日目の記事です。

https://qiita.com/advent-calendar/2023/timetree

はじめに

TimeTreeでフロントエンドエンジニアとして働いている susiyaki です。

この記事では、TimeTreeでギフトプロジェクトにスクラムフレームワークを導入し、 特にアウトプットやチームメンバーのモチベーションの向上に効果があったことについて振り返りをまとめています。

スクラムマスターを担当するまで

私は今年の5月に入社しました。
入社後からの改善の流れについて重点的に振り返っていきます。

【入社前】プロジェクトへのスクラムの導入経緯

TimeTreeでは、各プロジェクトごとにチームを分割し、それぞれのチームでスケジュールやタスクの管理を独自の方法で実施していました。
それぞれのチームでスクラム開発の導入を目指してバックログの作成やスクラムイベントの実施を行っていましたが、全体としてはスクラムの理念と実践方法に関する共有の理解にまだギャップが存在していました。
このため、スクラムの効果を最大限に引き出すことにはいくつかの課題がありました。

【入社から1ヶ月】スクラムの改善点の洗い出し

メンターのお二人に夕会の場で私がギフトチームに感じているスクラムの改善に関する相談に乗っていただきました。
そこでは、下記のような課題が見えました。

• スクラムイベントの目的、やることやメリットがチームに伝わっていなさそう
  • 参加者が適切に絞られていない(または足りない)
• ベロシティの計測をしているが、それをうまく利用できていない
• POのロールを持つ人物がいないため、プロダクト全体の開発優先度や仕様の決定権の所在が曖昧

また、私なりにイメージする現状の課題とどうすればいいかをざっくりと洗い出しました。

---

洗い出しの一部を抜粋

メンターシップの価値

TimeTreeのメンター制度は、私のスクラム改善の旅において欠かせないものでした。
特に fujikky さんと ta1kt0me さんの支援は、私の成長とプロジェクトの成功に不可欠でした。

fujikky

• 業務メンター
• フロントエンドエンジニア
• ギフトチームのスクラムマスターを兼任
• TimeTreeのイチロー

https://zenn.dev/fujikky

ta1kt0me

• 業務外メンター
• バックエンドエンジニア
• TimeTreeのバックエンドの守護神

https://zenn.dev/ta1kt0me

これらのメンターの存在は、私がスクラムの理解を深め、実践的な改善を実施する上で、計り知れない支援となりました。ありがとうございます！

【入社から1~1.5ヶ月】スクラムフレームワークについて周知

いきなり既存の開発フローをチーム全体の理解なしに進めることは困難なので、ひとまずスクラム運用に関する進め方をドキュメントにまとめることにしました。

主にスクラムフレームワークにおいてベースとなる

• 3つの成果物
• 3つのロール
• 5つのイベント

に関してそれぞれの役割や現状との差異、また、その改善案をまとめました。

---

ドキュメントをの一部を抜粋

(ロールについて)

(スプリントレビューの進め方案)

---

【入社から1.5~2.5ヶ月】スクラムイベントの改善 (混沌期)

スクラムマスターのfujikkyを主体に下記を実施し、約1ヶ月運用しました。

• POのロールを持つ人物を据える
• イベントの時間・参加者の調整やフローの変更

スクラムイベントに関しては以前より円滑に目的を果たしながら進められている実感がありましたが、新たな下記の課題が出てきました。

• POの経験がなく手探り状態
• 人員が偏っており、POが企画も兼任している状況

この状況は、開発チームの効率性やPOのワークロードバランスに影響を及ぼす可能性があり、業務フローの見直しポイントを探ることにしました。

特に問題となっていた課題が下記の2点でした。

• 仕様に関する質問がPOに殺到し、その返答に時間がかかり通常業務にも影響が出てしまっている
• 進行可能なタスクに対してエンジニアの人数が多く、仕様の決定が追いついていない

この状況を解決するために夕会で議論した結果、細かな仕様の洗い出しと受け入れ条件の決定を開発チームで実施することを試してみることにしました。

フロー	改善前	改善後
仕様の決定の流れ	企画の担当者とデザイナーで実施する。	企画の担当者とデザイナーで実施する。
要件定義の流れ	POがドキュメントを起こして開発チームに共有する。仕様に疑問があれば適宜POに質問する。	開発チームがドキュメントを起こしてバックログリファインメントでPOに合意を取る。
詳細設計の流れ	開発チームが担当者がタスクを作成しながら実施する。	バックログリファインメント完了後、予めチームで集まって設計を実施し、タスク化と見積りを行う。

要件定義を開発チームで実施することでPOの作業量の軽減ができるほか、コードを知るエンジニアならではの細かい点まで先に要件を決めることができて詳細設計の質や速度も上がりました。
その上、詳細設計のタイミングになってPOへの仕様の再確認による手戻りも減りました。
また、これまで設計を担当者に一任していましたが、チーム全員で行う方針にしたため副次的にチームのコードへの理解の向上もありました。

【入社から2.5~3.5ヶ月】新たな開発フローの定着・スクラムマスターの引き継ぎ

この時期は混沌期の改善策を実践して、少しずつ開発チーム全体の開発速度や安定感が上がることを実感していました。

しかし、別プロジェクトの開発にブーストをかけるためにギフトプロジェクトの再編があり、スクラムマスターを兼任していたfujikkyも別プロジェクトに移動しました。
スクラムの改善を提案して一緒に進めていたこともあり、このタイミングから私がギフトプロジェクトのスクラムマスターを引き継ぎました。

次章では、解決した課題の中でも特に重要だったポイントについて詳しく振り返ります。

スクラムマスターをやってみて効果的だったポイント

スプリントゴール設定の改善

得られた効果

• デリバリーする内容がより明確になった(スケジュールの把握がしやすくなった)
• チームの開発モチベーションの向上
• エンジニア間での連携がしやすくなる

スプリントゴールの立て方

スプリントゴールを立てる上で大事なポイントはざっくり下記の通りです。

• スプリントゴールの粒度を小さくする
  • 可能な限り終わりを明確に定義することが大事
    • ex) 「XXの機能実装の要件のY%まで進める」→「XXの機能実装のタスクA,Bを終わらせる」
• ベロシティより少し多めのポイントで見積る
  • 業務に対して程よい緊張感を保てる
• スプリントゴールの進捗状況とその詳細を追跡し、可視化する
• 朝会のタイミングで全員でスプリントゴールの確認をする
  • 全員がスプリントゴールの進捗に関して責任感を持てる

スプリントゴールの運用

スプリントゴールは立てて満足せず、適宜更新をする必要があります。

• 優先度の変更
• 進捗状況
• 考慮漏れの発覚

などがあった場合、朝会のタイミングで共有して更新するようにしました。
無理をして期日に収めるより正しい対処の方法をチームで考える方がよりいい解決案が出てくることが多いと考えます。

スプリントゴールの管理に使用しているNotionのテンプレート

これらのポイントを基にギフトプロジェクトではこのようなNotionのテンプレートを使って運用しています。

スプリントゴール全体	スプリントゴールアイテム1	スプリントゴールアイテム2

これは、チームの認識を合わせ、成果を明確にするのに役立ちました。

やるべきことは見えるところにまとめる

スクラムフレームワークとは直接的には関係しませんが、やることを見えやすいところに置いて確実に消化していくことの重要さを実感しました。

改善前	改善後
スプリントレビューで提案された改善点のタスク化に時間がかかっていた(または忘れられることがあった)	改善案は出たタイミングで即タスクにして見える化する
レトロスペクティブでチームの課題が出たとき、その場でどうするか議論して認識を合わせて解決としていた	常に見える位置に改善点をリスティングし、次回のレトロスペクティブでチーム全体で解決としていいと判断したらリストから外すようにした
スプリントでやることは各々でTODOとして管理し、朝会でざっくりと共有していた。しかし、自分以外の全てを把握することは難しい状況だった	スプリントゴールを作成し、それに対する進捗も共有するようにした

データのアクセスをしやすくする

TimeTreeではバックログ管理にNotionを使っていることもあり、拡張しやすいものの正しくチームが欲っしているデータを取得する仕組みは自力で作っていく必要があります。
レトロスペクティブで拾えないような潜在的な不便さもあるため、常にチームメンバーが使いやすいテンプレートを継続的に編集することで、日々の業務の効率化に寄与しています。
このあたりは細かい積み重ねですが、生産性を下げないために重要なのでスクラムマスターは人一倍アンテナを張ってツールの改善をするべきだと考えています。

おわりに

この1年間はスクラムマスターとしても、エンジニアとしてもとても密度の濃い経験ができました。
TimeTreeのメンバーの皆さんは自走力が高すぎるが故に、スクラムの導入がサクサクと進んだので私が何かしたという実感があまり湧かないことが度々ありますが、振り返ってみると細かい改善のサイクルが大きな成果をあげられていたんだと実感できました。

来年は他プロジェクトのスクラムイベントなどに参加させていただいて、社内全体のスクラムの向上を目指していきたいと考えています。
がんばるぞー！