〜2023年11月版〜 Leaner見積の開発プロセス

こんにちは。Leaner Technologiesの小久保(twitter:@yusuke_kokubo)です。

これはなに

Leanerでは「Leaner見積」と「Leaner購買」という二つのプロダクトを開発提供しています。
ここでは「Leaner見積」の開発プロセスをざっくり説明します。
開発プロセスはプロダクトや事業、組織のフェーズによって日進月歩で変わっていきますので、あくまで執筆時点のスナップショットとしてご覧ください。

この開発プロセスの狙い

顧客フロントに立っているセールスや、カスタマーサクセスのメンバーと共同でプロダクト開発をするにあたり、以下の課題を設定して考えました。

• （ビジネス側とDev側で）開発粒度の認識をいい感じに合わせたい
• （ビジネス側とDev側で）開発するうえでの難しさの認識をいい感じに合わせたい

今の開発プロセスになる前は、ここの認識が上手く合っていなかったため「いつごろリリースできそう？」「やってみたけど上手くいかないときにどうする？」という話をするのが難しい状況になっていました。（詳細は後述）

開発プロセスの概要図

開発プロセスの概要です。
この記事では２つある黄色い枠の「Backlog」の方を中心に解説します。

ポイント1: Product Backlogを３つの観点で分類する

仮説検証が必要なものと、そうでないものを分類する形でBacklogを管理しています。
上述した概要図と合わせて読んでいただけると関係性がわかりやすくなると思います。
3種類のBacklogをそれぞれ呼び分けやすくするためにYO,FOOYO,ZUMIと名付けてます。

仮説検証が必要なBacklog（社内では「YO」と呼んでる）

問題をどう解決するのか検証が必要な状態

• ユーザーニーズの掘り下げ
  • インタビュー
  • 行動データ収集分析
• 影響範囲調査
• プロトタイピング、UIイメージ作成
• 一部顧客に限定リリース & フィードバック回収
• 社内へのお披露目

仮説検証済み（社内では「ZUMI」と呼んでる）

つくるべきものが定まってあとはプロダクトに組み込むだけの状態
（仮説検証時に作ったものは破棄する前提でプロダクションに必要な設計を考える）

• アーキテクチャ設計
• DB設計
• アクセシビリティ設計
• 運用設計
• セキュリティ検討
• QA
• 実装
• E2Eテスト
• VRT

仮説検証が不要なBacklog（社内では「FOOYO」と呼んでる）

検証が不要、もしくは失敗してもダメージが少ない（リリース後にリカバリーしやすい）。
実現可能性も問題なく、必要性を議論する余地が少ない。

• バグ修正
• （合意済みの）文言変更
• 管理画面の改善
• 内部品質の改善
• 例
  • 入力フォームにサジェスト機能をつける

ポイント2: スクラムではない

「Product Backlog」という呼び方はスクラムから拝借してますが、スクラムイベント的なことはやっていません。代わりにいくつかの定期ミーティングを行ってます。

• 朝会（日次）
  • 進行中のBacklog状況共有
  • 連絡事項・相談
  • 問い合わせ・エラーの棚卸
• 仮説検証YO!FOOYO!会（週次）
  • カスタマーサクセスと一緒に顧客要望を掘り下げる
  • 要望を元に仮説を立てて検証の要不要（YO!FOOYO!）を判断する
  • Backlogの優先順位付け
• チェックポイント（週次）
  • 1週間の感想
    • スクラムでいう「レトロスペクティブ」に近いがもっとふわっとしてる
  • 開発系のメトリクス、リードタイム、パフォーマンスを確認
  • （あれば）プロセスやエンジニアリングの課題について対応策を話す

（スクラムはやってませんがアジャイルソフトウェア開発宣言で重視する4つの価値にはとても重きをおいてます）

ポイント3: 制約事項

• 同時並行についての制約
  • 期日のあるBacklogは同時に一つしか持たない
    • YO, ZUMI, FOOYO含めて一つだけ
    • 厳密な定義: 期日を複数持っても良いが、チームとしてコミットメントするのは一つだけ
  • ZUMI, FOOYOは同時並行しない方が良い
    • 新しいことを始める前に今やってることを終わらせるのが原則（絶対ではない）
• YO仮説検証についての制約
  • YO仮説検証Backlogは原則オプション機能＋ベータ機能として提供する
    • （仮説検証できたらZUMIへ移行する）
• 見積についての制約
  • YOは事前にスコープやサイズ感を見積もることは不可能
  • ZUMI, FOOYOは見積りして与実管理して生産性を指標として管理することもできる（今後の課題の一つ）

なぜこうしている？

このプロセスに至るまでは、Product Backlogを大玉・小玉という分け方で運用していました。「4週間以上かかりそうなものは大玉」「それ以外は小玉」というざっくりとした分類をしていました。
その結果、小玉だと思って進めていたはずだけど意外と難しいというBacklogが定期的に発生するようになり、小玉の開発が滞ってしまう事態になりました。

大事なのは仮説を立てて検証すること

その反省から学び、原因を考えてみて、開発に着手する前にわかっていること、わかってないことの差分に着目しました。スタートアップのプロダクト開発では、誰のどのペインを解決するのか？どういう解決方法が正解なのか？ をずっと手探りしながら開発を繰り返します。

仮説を立てて、それを検証する、という当たり前のことですが、そのプロセスを自然と意識できる仕組みを作れば良いのでは、と思うに至りました。

仮説を立てなくてもできる開発もたくさんある

仮説検証は大事ですが、仮説を立てなくてもできるプロダクト改善もたくさんあります。
重要なのはそれらを分けて扱うことです。開発は頭と手を使う行為ですが、その頭と手のバランスは場面に応じて変わります。

顧客の要望を整理してくれるカスタマーサクセスのメンバーから見ても 「仮説を立てて検証が必要な開発」と「手を動かせばできる開発」に仕分けられると、顧客との期待値の調整もやりやすくなります。

これは個人的な意見ですが、プロダクトの機能を増やすよりもマイクロインタラクションに関わるユーザー体験をどれだけつくり込めるかで、プロダクトの価値が大きく変わるはずだと思ってます。
（現状どこまで理想通りにできているかはおいといて、そういう思想を持ってやってます）

デュアルトラックアジャイルを参考にしている

デュアルトラックアジャイルでは「ディスカバリー」と「デリバリー」という考え方を持ってBacklogを分類します。Leanerではそこから「仮説を立てて検証する」というエッセンスを拝借して自分たちのプロセスづくりに応用しました。
（ここでデュアルトラックアジャイルを説明すると本題からズレるので詳細はググってください）

やってみてどうか

7, 8月くらいから今のプロセスに落ち着いて3ヶ月ほど経過しました。

Good

• 仮説を検証が必要という話をビジネスサイドも含めて自然と意識づけできるようになった
• 仮説検証が必要or不要という判断をビジネスサイド含めて話すことでその後の開発を進めやすくなった
  • 「検証が必要な開発」 or 「検証が不要な開発」という大前提の認識がズレる心配がない

今後の伸びしろ

• 仮説検証をスピード感を持って進めるのは難しい
  • エンジニア全員でプロダクトマネジメントを意識した行動が必要になる

手段と目的を履き違えない、という思想的な話

（個人的な意見です）
どのようにチームの構造と開発プロセスをつくるかは、チームづくりそのものであり、チームづくりは良いプロダクトをつくるために必要なことです。
自分たちにとってスクラムやデュアルトラックアジャイルはあくまで参考にする手段の一つだと思っています。開発プロセスの正解は、どんなプロダクトをつくりたいかによって変わります。なので、スクラムや特定のプラクティスを導入すること自体に価値はないと思ってます。
自分たちの目的は良いプロダクトをつくって事業に貢献することであり、ユーザーに価値を届けることであることを常に意識しています。そのため、チームの構造もプロセスもプロジェクトのフェーズとチームの成熟度によって常に移り変わるものであると考えて、その変化を楽しみたいと思ってます。

まとめ

冒頭にも説明した通り、現状のプロセスもあくまでも通過点だと思ってます^[1]。
プロダクトとチームが生きてる限り、常にプロセスはアップデートされていくものだと思っているので、今後も走り続けます。

興味を持っていただけたらこちらも合わせてみていただけると嬉しいです。
https://careers.leaner.co.jp/engineering
（Twitterなどでフィードバックもらえると喜びます！）

脚注

1. なんとこの記事を書いてる当日にも細かいところで変更する話が出てます