プロダクト開発組織・人材を対象に、開発パフォーマンス・生産性の最大化インフラ Offers MGR と副業転職プラットフォーム Offersを運営する株式会社 overflow のエンジニアの shun です。今回は、弊社で実施しているスクラム開発において、ベロシティ（チームがユーザストーリーを動くソフトウェアに変換する速度）が開始当初から約 3 倍になったので、その話をしようと思います。弊社ではだいぶ前からスクラムを採用していましたが、あまり機能していませんでした。そこで私が運良くチームをリードする立場になったことをきっかけに小さなチームでスクラムを再建しようと思いました。もしスクラム開発でお困りの方がいらっしゃれば、微力ながらお力になれればと思います。
スクラム開発とは
ChatGPTに聞いてみた。
スクラム開発を一言で説明すると、「柔軟で迅速なアジャイルソフトウェア開発フレームワーク」です。
だいぶ銀の弾丸感のあるレスポンスですが、正解だと思ってます。顧客が求めるプロダクトを素早く提供してあげることを実現するには非常に相性の良いフレームワークだと思ってます。
また、アジャイル開発との違いってなんですか？という問いかけを多く見かけますが、スクラムはアジャイル開発におけるフレームワークの 1 つです。世界的に人気が高いのでアジャイル = スクラムという認識でも特に不便はありません。私の大好きな海外ドラマ「シリコンバレー」でも カンバン という手法のアジャイル開発をするシーンがあります。付箋でタスクを管理していくような手法ですね。
ベロシティが約3倍になるまでの軌跡
早速本題ですが、まずは結論から紹介いたします。
| Sprint(#n) | Velocity | 上昇率(対前回) |
|---|---|---|
| Sprint(#1) | 67 | - |
| Sprint(#2) | 65 | ↓3% |
| Sprint(#3) | 154 | ↑137% |
| Sprint(#4) | 173 | ↑12% |
Velocity（ベロシティ）とは、スプリントの期間内で完了できたタスクのストーリーポイントの合計値です。ストーリーポイントとは、タスクの規模感を示す数値になります。（この概念に筆者はだいぶ苦労しました。後半でどう突破したか説明します。）
極端に示すと、Velocity の最小・最大幅で見たときに 2.7 倍(約 3 倍とさせてください w)の Velocity 向上となりました。[1]
スクラムを実施しているチーム構成
まず、上記の実績を出したチーム構成は以下です。本来のスクラムではマーケ人員はあまり登場しないイメージがありますが、弊社の場合はプロダクト開発の進捗によって日々のマーケターの動きに影響するケースがあるため、参加してもらっています。
- スクラムマスター(1 人) ※筆者がエンジニアと兼業している
- PdM(1 人)
- デザイナー(1 人)
- エンジニア(2 人)
- マーケ(1 人)
私がスクラムマスター兼エンジニアを担当しているので紛らわしいですがチーム的には 5 人です。
では早速どんなことを取り組んで成果に結びついたのかをご紹介できればと思います。
取り組んだこと
スクラムをきちんと学習しなおした
チームリードになった頃、スプリント運営も私がとりあえず引き受けることになったのですが実際スクラムについては知識 0 でした。スクラムと聞くとドラゴン桜に登場する「生徒たちがラグビーの格好をして肩を組んでいる描写」が頭に浮かぶ程度でした。長谷川京子さんの表情と同様、私も「???」状態です。故にスクラムに詳しい方と意見が割れたり、上手くスプリント運営ができずに悶々とした経験があります。せっかく引き受けたのであれば、きちんと自分で勉強してチーム・会社に還元しようと思いました。全ては網羅できませんが、実際に私が学習したものをいくつか簡単に紹介できればと思います。某サービスで実際にスクラムマスターを担当している方とお話ししたりもして、よりリアルな現場を教えていただきました。この場を借りて感謝申し上げます。
スクラムガイド
スクラムの親である Ken Schwaber & Jeff Sutherland さんが展開している スクラムガイド です。どんな思いでスクラムを開発したかというところから、メンバーの責務・具体的なスクラムイベントの説明など、なんと PDF18 ページで網羅されているのがまず驚き。
アジャイルサムライ
鉄板ですね。アジャイル入門からアジャイルの実践方法・「センセイ(侍)と弟子」との対話で学ぶ Q&A により、全体的にアジャイル開発を理解できます。私自身、スプリント運営で「どうすればいいんだっけ？？」という時はこの本を読み返してます。
【アジャイル開発】スクラム基礎講座(Udemy)
動画での学習は個人的に楽なので、Udemy でも探してみました。海外で人気のコースの翻訳版で、ぼーっと眺めているだけでも理解できるくらいわかりやすいです。スクラムガイド・アジャイルサムライ、その他ネットにある記事などを頭に入れたのち、この動画でおさらいと深掘りをすると効率的だなと感じました。また、スクラム導入の経験豊富な方がコンテンツ提供しているので、現場をイメージしながら学習できました。
ストーリーポイントの再定義
既存で運用していたストーリーポイントは以下の点で問題がありました。
タスクを「時間的工数」と照らし合わせて算出していたこと
時間的工数での判断が必要な場合も多くあるため、一概に NG!ということではないです。本質的な問題は、ストーリーポイントの値は、付与する人に依存してしまうケースがある ということです。例えば弊社の ahomu さんはバリバリのフロントエンドエンジニアです。フロントエンドのタスク A をに対して「時間的工数」をフロント弱い人と ahomu さんでストーリーポイントを付与すると、偏りが出てくることは歴然ですね。ストーリーポイントをつけた人がそのタスクを行うとは限らないという前提に立つと、チーム内の共通認識指標であるストーリーポイントとしては不適切とされます。
消化可能ストーリーポイントの設計が非現実的
時間的工数でストーリーポイントの設置をしていると、「8 時間 * メンバー数 * スプリント日数」という最大幅を持たすといい感じで管理ができそうに思われます。しかし、一日 8 時間フルで開発・デザイン業務を実現している正社員は皆無だと思います。MTG があったり面談があったりと少なくとも 1 日 8 時間という軸を決めるのは計画的に破綻しています。なので、毎回スプリントに積まれたタスクが残ることとなり（意外と時間見積もりは正確だったのかも）、開発メンバー的には「間に合わなくてもいいのか」という変な癖がついてしまいます。また、PdM 的にはこのような状態だとスケジュールが立てにくく、ロードマップの調整など計画に影響を与えてしまいます。
実践したストーリーポイントの定義・付与方法
上記のような問題が存在し続けると、計測する値にブレがあるのでスプリントの評価も難しいです。まずは定義を整理する必要がありました。
弊社でいい感じに運用できているストーリーポイント付け方法は以下の手順です。
- ストーリーポイントに使用する数値を定義する
- 過去に完成させたタスクを 1 つ選択し、現メンバー（主にエンジニア）で どのくらい大変そうかをとりあえず 数字で表現する
- メンバー間で提出した数値にずれがある場合、背景を共有
- とりあえず そのタスクに数値をつける
- スプレッドシートや Notion を用いて、ログとして残しておく
- 次に選んだ過去のタスクに対し、2-5 を繰り返す
1. ストーリーポイントに使用する数値を定義する
自由に数値をつけることも可能ですが、大きいポイントを分割しやすくするためにもフィボナッチ数列の「1 2 3 5 8 13 21 34 55..」を採用しています。
例えば 55 のタスクの場合かつ、チーム内で「規模でかめ」という判断をした時、分割をしないと進捗管理できないケースがあります。その場合、フィボナッチ数列の特性である「55 = 34 + 21」を利用することで分割ができ、細かく進捗管理ができるようになります。
2. 過去に完成させたタスクを1つ選択し、現メンバー（主にエンジニア）で どのくらい大変そうかをとりあえず 数字で表現する
プランニングポーカー という手法を用いています。「せーの、どん」で GoogleMeet のコメント欄に自分が思う規模感を示す数字をポストします。
3. メンバー間で提出した数値にずれがある場合、背景を共有
メンバー間で数値がずれる場合は、ドメイン知識のある方が大きくなる印象です。「実はあそこの処理えぐいんだよね...テスト含めても結構大変そう」みたいのがこの場でチームにシェアできるのも付加価値としてメリットがあります。
4. とりあえず そのタスクに数値をつける
これが本当に最初の一歩です。本当に とりあえず つけましょう。筆者は謎に厳密性の縛りからなかなか逃れられず、「うーん...本当にこれでいいのだろうか...」と頭を抱えていました。
5. スプレッドシートやNotionを用いて、ログとして残しておく
これが非常に大事です！以下は NotionDB を用いたサンプルです。
6. 次に選んだ過去のタスクに対し、2-5を繰り返す
上記のスクショ内部では「トップページに XXX という文言を追加する」タスクに対してストーリーポイント付与しています。次に「Google ログイン機能の実装」タスクを上げ、仮に「13」とします。この時も、とりあえず 付与してしまいます。さらに次に「おすすめ質問データ取得 API の実装」タスクが出現しました。この時に「相対見積もり」を体感できると思います。
「おすすめ質問データ取得 API の実装」は「Google ログイン機能の実装」と比べるとどちらが 大変そう？ という流れが自然に出てきます。結果的に前者の方が後者よりも 楽そう だが、規模としては小さくはない、よってストーリーポイントは「8」としよう。という議論ができます。
また、この時点では一度決めたストーリーポイントについては変更可能とし、微妙なラインのタスクが出てきた時に「Google ログイン機能の実装」を「21」に引き上げて他も調整すると、あらゆるタスクの見積もりをする際にこの対応表が役に立ちます。
デイリースクラムの実施
話している内容はすごくシンプルで以下になります。
- 昨日、行ったことは？
- 今日やることは？
- 現状障害となっている事象はあるか？
- その他、この場で相談したいことは？
とりあえず実施をしていたのですが、会を重ねるごとにベロシティへ与える良い影響を体感できました。
- 軽い動作確認依頼タスクをその場で解消したことによりリリースまでのリードタイム短縮
- 大規模タスクにおける仕様理解を細々確認・意思統一できた
- 毎日顔を合わすことによる心理的安全性の向上
- 本来の目的である「スプリントを完成させるための進捗共有と相談」を追求したことで、認識齟齬解消でき、出戻りがほぼなくスループット向上。
スプリントレトロスペクティブの実施
スプリントレトロスペクティブ実施により、ベロシティに与えた影響は以下です。
- 現状無駄だと思う部分を洗い出すことができ、改善をすぐ適応できた
- チーム内部のボール渡しが上手くいっていない理由などを背景含め議論・改善ができた
私は自分で実装もしつつバックログ管理・プロジェクト進行管理をしているのですが、以下の問題があり気付かぬうちに結構な時間を消費してました。
- 特定機能のフィードバックの起票は Notion で、やると決まったら JIRA へタスクを作り直す
- Notion 側に JIRA リンクを貼る。JIRA 側に Notion リンクを貼る。JIRA 側でバックログ整理
- etc..
冷静に考えれば明らかに無駄だよな。と今では思うのですが、なかなか切羽詰まった状況だと慣れた方法が一番早いと勘違いしてしまう。PdM がスプリントレトロスペクティブにて提言いただき、タスク管理を Notion に全て移行したことで、私の実装ピュアタイムもかなり捻出できたと思っています。PdM もタスク管理が楽になったとのことです。こういった気づきと改善のきっかけになる場は今後とも重要ですね。また、上手くいった理由もチーム内でシェアできるので無意識に 継続してこう となっております。
Notionを使いこなす
弊社のエンジニアで Notion マスターがいます。目から鱗が出過ぎてドライアイになる程使いこなしています。タスク管理が全て Notion に移行されることによるデメリットも少なからず存在していましたが、彼のアイデアと技量で見事払拭できました。実際に発生した問題で一番活躍してくれたのは以下です。
「これって今誰ボールだっけ？」問題
「これって今誰ボールだっけ？」問題は結構発生している印象です。Notion はプロパティを柔軟に設定できるので、シンプルに「ボール保持者」と言う項目を追加しました。
その後、「自分がボール持っているタスク一覧」を新規でテーブルを作成して実現しています。
これにより、ベロシティに与えた影響は以下です。
- 一目で自分待ちになっているタスクがわかり、あちこち探したり誰かに「私ボールになってるものある？」と聞かなくても良くなったことによる不要なコミュニケーションの削減
- 個人的な意見ですが、ずっと自分がボール持ってると爆弾のように思えてくるので、早く片付けようという心理が働く
今後の課題とトライしたいこと
詳細は割愛しますが、ベロシティ向上の要因として DevOps の環境が整っていたということも挙げられます。検証環境への自動デプロイや CI の充実などの恩恵があったことも大きいです。
ただし、Unit テストの実行速度についてはまだまだ改善の余地があり、この時間が長ければ長いほどスループットも低下することが予測されます。今後は技術的負債の返却とともに、スループット低下の原因となっている箇所を整備していくことが直近のトライになります。
まとめ
今回は、スクラム開発でベロシティが約 3 倍になった話をざっくり致しました。
ChatGPT の登場など時代がどんどん進んでいる中で、 高速に安定した価値を提供する ことは非常に重要だと思っています。そのためにもアジャイル開発・スクラムフレームワークは有効だと感じているので、誰かの助けになれば非常に嬉しいです。
最後にはなりますが、本記事を最後まで読んで頂き、ありがとうございました。「こんな記事を書いてほしい！」などありましたらコメントいただけると幸いです。
更新履歴
- ベロシティの説明に解釈違いがあったので訂正しました
-
#1〜#4 はすべて、後述するストーリーポイント再定義後の Sprint および Velocity であり、同じ定義で比較しています ↩︎
副業転職の Offers 開発チームがお送りするテックブログです。【エンジニア積極採用中】カジュアル面談、副業からのトライアル etc 承っております💪 jobs.overflow.co.jp
Discussion