こんにちは！SmartHR プロダクトエンジニアの @ron です。
ソフトウェア開発では、不確実性の高いフィーチャーを開発する場面が少なくありません。特に、新規機能や大きな変更を伴う開発では、仕様が固まりきっていなかったり、顧客の反応が予測しづらかったりすることが多く、進め方に悩むこともあります。
この記事では、私たちのチームが不確実性の高いフィーチャー開発に取り組む中で「やってよかったこと」を3つ紹介します。
仮説検証を小さく素早く回す
不確実性が高い場合、大きな実装を一気に進めるのはリスクが高くなります。そこで、次のようなアプローチを取りました。
チケットの進め方を調整し、毎週スプリントレビューを実施
既存機能の拡張ではなく、新しい概念を持ち込む新機能だったため、ユーザーが理解しやすいかどうか不安な点が多くありました。 スプリントレビューを毎週開催することで、様々なステークホルダーに高頻度でフィードバックをもらい、細かく軌道修正できました。
最初にリリースするスコープを大幅に小さく設定
当初考えていた仕様は、今になって考えるとかなり大きなスコープのものでしたが、当時は全て必要なものと考えていました。 しかし、本当にユーザーが必要としている機能・仕様なのか確信が持てない状態で作り込みすぎることを懸念し「仮に2週間でリリースするなら、どう作るか？」など議論を重ね、当初の3分の1程度までスコープを削りました。
その結果開発期間も大幅に短くなり、実際に動く機能をリリースすることで社内外から広く要望を集められました。 集まった要望には当初想定していなかったものも多くあり、今後のロードマップを柔軟に変更し、ユーザーが必要としているものをより速くデリバリーすることにつながりました。
概算見積りを複数回行う
開発の進捗に応じてチームで簡易な見積もりを繰り返し行い、確度の高いリリース予測と不確実性の高い要素の洗い出しを行いました。
概算見積の手順
1. フィーチャー開発の初期に、おおざっぱに作成したチケットのストーリーポイントをざっくり見積もる
チケットタイトルと概要を軽く共有しただけの状態で、チーム全員で見積もりを行います。 見積もりの際には Pointing Pokerを使用しており、各エンジニアが出したポイントの平均値（もしくはやや大きめ）のポイントを記録していきます。
2. 見積もる際に生じた疑問や、見落とし、問題点を検討する
ストーリーポイントを見積もる際に不明瞭だと感じたポイントや、思いついた追加で必要な作業など、必要があればチケットとして切り出し、別途調査や設計を行います。
3. 再度見積もる
調査や設計を行った結果を踏まえて、チケットの切り方や順番を変え、再度ポイントを付け直します。
この一連の流れを2回〜3回ほど行いました。
チーム全員の時間を使うため、多少コストはかかりますが、それ以上に大きなメリットが得られたと考えています。
得られたメリット
精度の高い見積もり・リリース予測
このフィーチャーの開発は3ヶ月程度でしたが、当初の予測と実際のリリース日がほぼ一致しました。
予定通りのリリースは、見積もりの精度だけでなく開発チームの努力の結果ではありますが、リリース日のために無理をして働くようなことはありませんでした。
仕様の考慮漏れや設計不足を早期に発見
バックログのチケットを眺めるだけでは気づきにくい点も、ストーリーポイントを付ける際に検討することで発見できました。
チーム全体で仕様や顧客要望の解像度を揃え、議論を活性化
開発初期の段階でチーム全員がフィーチャーの全体像を把握し、「特定の誰かが仕様を決める」のではなく、チームとして活発に議論を交わしながら意思決定できました。 フィーチャーの全体的な仕様から細部に至るまでコンテキストを共有できているので、室の高い意思決定をしつつ、かかる時間は少なくなっています。
未来の各スプリントごとで、どのチケットを完了するか計画を立てる
SmartHRでは、スプリント内での透明性を高めるために「予言の書」を作成するチームがいくつかあります（詳細はこちらのテックブログをご覧ください）。
私たちのチームでは、この予言の書の考え方を拡張し、より長期的な計画を立てるようにしました。予言の書を拡張したものなので、通称「大予言」と呼ばれています。
予言の書よりも荒い粒度でチケットの完了を計画することで、以下のようなメリットがありました。
チケットのブロッキング関係・不確実性を踏まえた計画
進行する順番を計画することで、ブロッキングとなるタスクや不確実性の高いタスクを事前に対処できました。
進捗の可視化
各スプリントの見積もりと実際の進捗を比較し、フィーチャー全体の進捗状況を明確に把握できました。
スプリントゴール・スプリントレビューへの意識
先々のスプリントに対して意識を向けることで、「いつまでに何を作ると、どの時点でどんなフィードバックが得られるか？」「フィードバックを早く得るためにはどんな順番で進めるべきか？」といった部分に目が向くようになりました。 そのため、個々のスプリントでも単にチケットを消化する作業を行うだけではなく目的意識を持って進められる様になりました。
まとめ
不確実性の高いフィーチャー開発では、以下のポイントを意識することで、開発の方向性を見失わずに進めることができました。
- 仮説検証を小さく素早く回す
- 概算見積りを複数回行う
- 未来の各スプリントごとで、どのチケットを完了するか計画を立てる
これらのアプローチが、皆さんの開発にも役立てば幸いです。
We Are Hiring!
SmartHR では、一緒にプロダクトを作りあげていく仲間を募集中です！
アジャイルな開発スタイルで継続的に開発プロセスを改善することに興味がある方をお待ちしています。
少しでも興味を持っていただけたら、カジュアル面談でざっくばらんにお話ししましょう！
