- はじめに
- アポトル開発がんばり中（2023年初頭〜2024年1月）
- アポトルリリース直前（2024年1月〜2024年4月）
- アポトルリリース直後（2024年4月〜2024年10月）
- 現在（2024年11月〜）
- おわりに
はじめに
こんにちは！セールステック開発ユニットの田島です。
私はここ１〜２年ほど、新規プロダクトである BtoB セールスツール「アポトル」を開発するチームに所属していました。
「アポトル」は2024年４月にリリースを迎えたのですが、リリース前後やその後のグロースにおいて繰り返し開発プロセスの変更・改善を行なっていました。今回はそんな開発フローの変遷について紹介します。一つの事例として何かの参考になれば幸いです。
ちなみに結論としては「フェーズやその時求められている状況に応じて開発プロセスは柔軟に変えていけるといいよね」です。
この記事は「ウィルゲート Advent Calendar 2024」の １１日目の記事です。
アポトル開発がんばり中（2023年初頭〜2024年1月）
アポトル開発チームでは当初スクラム（を解釈したもの）を導入していました。 思想としては「インクリメンタルな開発」を目指しており、毎週何らかの動くものを作ろう！と意気込んでいた覚えがあります。
この時はスプリントの単位を2週間と定め、下記のようなスクラムイベントを定義しました。
- スプリントプランニング
- プロダクトバックログ（プロダクトの課題）から対応する課題を選択する
- 対応する課題をタスクに分割
- プランニングポーカー等でタスクの見積もり
- デイリースクラム
- 日々の困りごとや進捗を共有
- スプリントレトロスペクティブ
- スプリント単位での振り返り
- スプリントレビュー
- スプリントごとに生成された生成物を確認
- その他リファインメントを不定期で実施
また、スプリントプランニングの内容はConfluenceに議事録として残していました。 レトロスペクティブからのTryや、このスプリントのゴールなどを文章として残しておくことで明確化しています。
この辺りは決まり事や相談事が明文化されてよかったですね。やはり文章は大事です。この記事を書いている今も簡単に振り返れますし。
一方で当時はこの活動が開発チームで閉じており、プロダクトマネージャーをうまく巻き込むことができていませんでした。
その結果としてプロダクトオーナー不在のままスクラムイベントが進むことが多く、特にスプリントレビューは形骸化してしまったなあと思っています。（それが後々機能に対する認識ずれや、全体的なスケジュールの遅延につながりました......）
アポトルリリース直前（2024年1月〜2024年4月）
前項の最後に少し不穏なことを書いてしまいましたが、ともかくいよいよリリースが迫ってきました。
この時開発チームとして重要視していたのは、ズバリ「残りの時間で何ができるのか」です。
当初想定していた機能はもちろん、進めるにつれて明らかになる課題や社内からのフィードバックなど、隙を見せるとやりたいことは無限に生まれていきます。 「インクリメンタルな開発」というと聞こえはいいのですが、そのような状況の中で何をやるのか、どこまでやったらゴール（＝ひとまずのリリースなのか）が曖昧だったんですね。
そこでプロダクトバックログというより、「何をしなければならないのか」という観点で課題一覧を作り、管理することになりました。
またスプリントプランニングの見積もり部分をより厳格に管理し、「どこまで終わるのか」「どこまで終わらせられるのか」を突き詰めました。
アポトルリリース直後（2024年4月〜2024年10月）
そしてなんとかリリース。リリース後は不具合対応やスピード感の求められる機能開発が続き、少しずつ前述の開発体制が噛み合わなくなってきます。
問題点
- 形を変えつつ続けてきたスクラムイベントがコストの割にワークしていない
- 改修を重ねるうち原義のスクラムイベントと徐々に離れていったため
- 求められている判断や課題解決のスピード感と現状の開発フローがマッチしていない
- 特にリリース直後は飛んでくる球をガンガン打ち返していきたい
- その中で何がいつリリースされるのか、認識を揃えていきたい
- 特にリリース直後は飛んでくる球をガンガン打ち返していきたい
そこで、開発プロセスを下記のように改修しました。
- 課題はWhyのレベルでプロダクトマネージャーより下ろしてもらい、開発チーム全員でHowを揉む
- Howが見えた段階でnotionの課題一覧に追加
- チームで揉むことにコストがかかることは許容（フロー効率重視）
- スプリントという単位に拘って課題は用意せず、逐次的に優先度の高い課題をこなしていく
- 事実上スクラム（のようなもの）との離別
- 一方で週次で足並みを揃えるため、優先度や着手課題をざっくり確認するMTGは用意
とにかく課題感の強い問題に対して全員で揉み込み、最速で解決させようという体制です。
振り返ってみれば、これは特にリリース直後というプロダクトの初期段階において有効であったなと思います。リリース後数ヶ月は明らかに以前よりもスピード感を出せていたのではないかと思います。
今回の記事の主題とは少し逸れますが、この辺りのスピード感はPRの粒度や生存期間にも影響を与えていた気がします。
現在（2024年11月〜）
リリースから半年経ち、無事アポトルの利用者も増えてきた中でようやく落ち着いてプロダクトに向き合えるようになってきました。
ある種当然のツケなのですが、とにかく課題を積み上げ順次打ち返していった結果、下記のような問題が出始めます。
- 課題一覧が粒度の整理されていない大量の課題で埋もれている
- それも優先度が全て"最高"！
- 大量の課題の温度感がチームに共有しきれていない
- 直近対応する課題以外のリリース予定が立たない
要するに、「もう少し計画的に課題に取り組んでいきたいよね」ということです。かたっぱしからちぎっては投げ、ちぎっては投げていく時代は終わりました。
その結果、現在は下記のような形式をとっています。
チーム定例（週一）
- 先週取り組んだ課題に対して、完了の判断を行う
- 課題一覧に新たに記載された課題を確認し、温度感含めた認識をそろえる
- 温度感踏まえた上で今週対応する課題をピックアップ
課題管理
- 誰が何に困っていて、解決するとどう嬉しいのかにフォーカスし、あくまで課題のみを管理
- ぱっと見タスクが明確なものも「なぜするのか」「何を成したいのか」を記載し、その優先度で対応を判断
- 保守作業など細かいタスクは課題に上げず、必要に応じて差し込みで対応
- 誰が何に困っていて、解決するとどう嬉しいのかにフォーカスし、あくまで課題のみを管理
その結果、とにかくタスクを打ち返していた頃よりも「いつまでにどういう課題が解決されるのか」の見通しが立ちやすくなりました。
なんだか一周回って原義のスクラムに近づいてきたような気がしますが、そういうフェーズになってきたということかもしれません。
おわりに
さまざまな開発プロセスで開発を行なってきましたが、どのプロセスにおいても得たものもあれば失ったものもあったなと思っています。
繰り返しになりますが、大事なことは常に当たり前を疑い、柔軟にプロセスを改善し続ける姿勢にあるのかなと感じています。これからもそうありたいですね。
「ウィルゲート Advent Calendar 2024」、翌日は吉田さんの「エンジニアからプロダクトマネージャーへの挑戦」です。 お楽しみに！
