Nstockの開発プロセス - 2024年版

こんにちは！Nstock のじゃがです🥔

開発プロセスって、チームによってフィットする手法が違いますよね。
実際 Nstock でも、私の所属する株式報酬 SaaS チームと、セカンダリー事業の開発チームでは、異なる開発プロセスを採用しています。

セカンダリー事業の開発プロセスについては、こちらのポッドキャストをぜひご覧ください！

https://open.spotify.com/episode/0hWVqYW0pr00oz3waes0u6?si=v8f_Q51eRRSbXHm81HeJ0A

本記事では、株式報酬 SaaS の開発プロセスについて解説します。
今年のはじめは1週間スプリントのスクラムでしたが、今ではもう少し大きな単位で開発をしています。
背景には

• PMF を終え、新機能と改善のバランシングが必要になり、バックログの優先度付けが難しくなってきた
• チームとプロダクトが成熟してきて、1週間単位でのイベントによる軌道修正が必要なくなってきた

といった状況がありました。

同じ課題を抱えているチームの方へ、開発プロセスを考える参考になれば幸いです！

最初にまとめ

• 株式報酬 SaaS では8週間を1つのまとまりとしてアジャイル開発をしているよ
• スクラムと Shape Up を参考にしているよ

前提

• プロダクトのフェーズ: PMF を達成しグロースへ。いわゆる 1→10 のフェーズ。
• チームの人数: 7人 (PdM１人、デザイナー2人、エンジニア4人)

開発サイクル

Nstockでは2つの開発サイクルを組み合わせて開発をしています。

1. 8週間のサイクル(以下、大サイクルと呼ぶ)
2. 2週間のサイクル(以下、小サイクルと呼ぶ)

8週間の大サイクルは、2週間の小サイクル4つで構成されています。
8週間の大まかな使い方はこんな感じ。

1. キックオフ・調査・設計
2. 開発
3. 開発
4. 開発
5. お試し会・バグバッシュ
6. リリース
7. クールダウン
8. クールダウン

最後の2週はクールダウン期間のため、実質の開発期間は6週間です。

キックオフ

大サイクルの最初に6週間をどう使うか、計画を行います。
計画の日は出社し、オフラインで2日間かけてガツッと話します。
大きく3つのことを行います。

1. 大サイクルのゴールを決める
2. イベントストーミングをしてドメインへの理解を深める
3. リファインメントを行い、着手可能なタスクにする

まず、大サイクルのゴールと進め方を決めます。
成果物は「冒険の書」と呼ばれており、以下のことが書いてあります。

• 大サイクルのゴール
• 不確実なことはなにか
• お試し会、バグバッシュ、リリースの予定(後述)
• 今回の大サイクルで試したいこと

冒険の書

次に、開発対象のドメインへの理解を深めるため、イベントストーミングを実施しています。

イベントストーミングの様子

最後に、リファインメントを行い、着手可能なタスクに仕上げます。

必要に応じて、これらの取り組みを行き来しながら、開発の準備を行います。

3つの小サイクルの過ごし方

小サイクルは、スクラムのスプリントと同じような過ごし方をします。

1. 小サイクルの最初にプランニング
2. 小サイクルの間は Daily で進捗確認
3. 小サイクルの最後にレビューと振り返り

お試し会・バグバッシュ

リリース可能な品質にするためのイベントです。

お試し会は、ドメインエキスパート、セールス、CS も交え、成果物をじっくり試してもらうイベントです。

主な観点は以下。

• 一通りの操作感に違和感がないか
• 各画面における情報の過不足
• 文言に違和感がないか
• オペレーション上無理がある操作・入力を行った時の挙動

バグバッシュは、開発チームで行うシステムテストの時間です。
あらかじめ担当者がスプレッドシートにまとめたテストケースを実行したり、テストケース外の操作を行ったりしながら、意図通りの挙動を行うか確認をしていきます。

以前はバグバッシュのみを開催する形でしたが、

• システムテストを精緻にやるのは開発チームでも可能
• ドメインエキスパート、セールス、CS が新機能を触る時間を増やしたい

という理由で、お試し会とバグバッシュに分けることにしました。

この2つのイベントで出たバグ・要望は仕分けされ、リリースまでに対応したほうがよいと判断されたものに関しては、リリース前に対応します。

クールダウン

大サイクル最後の2週間はクールダウンです。

• 大サイクルの振り返り
• 次の大サイクルの準備
• ドキュメンテーション
• リファクタリング
• ライブラリのアップデート
• 改善系の開発
• ブログ執筆
• その他好きな開発

このブログを執筆している期間がまさにクールダウンだったりします。

これらの活動はもちろん6週間の開発期間中に行っても OK ですし、緊急度の高い改善を差し込むこともあります。
が、余裕を持って中長期に資する活動を行える期間を作るために、クールダウンが設定されています。

スクラムと Shape Up を参考にしている箇所

スクラム

株式報酬SaaSのチームは、もともとはスクラム開発をメインにしていました。
今でも以下のイベントはスクラムガイドを参考にしています。

• プランニング
• Daily
• レビュー
• レトロスペクティブ
• リファインメント

一方で、チームの人数が増えたり、1→10 フェーズになったことで、うまくいかない箇所が出てきました。

• PMF を終え、新機能と改善のバランシングが必要になり、バックログの優先度付けが難しくなってきた
• チームとプロダクトが成熟してきて、1週間単位でのイベントによる軌道修正が必要なくなってきた

そこで目をつけたのが Shape Up です。

Shape Up

Shape Up は、Basecamp 社が提唱する開発プロセスです。
主に以下の特徴があります(by GPT)。

• 6 週間の開発サイクル：6 週間を 1 サイクルとし、明確に区切られた期間で機能開発を完了します。サイクル後には 2 週間の「クールダウン期間」で振り返りや次の準備を行います。
• 事前の「Shaping」工程と「Betting Table」での選定：開発前にアイデアを粗く整形（Shaping）し、6 週間で実現可能な範囲に収めます。その後、意思決定者が「Betting Table」で優先度の高いアイデアを選び、実行を決定します。
• Appetite ベースの計画：必要な工数ではなく「6 週間で投下できるリソース量（Appetite）」から逆算し、スコープを絞り込みます。
• バックログを持たない：恒常的なバックログ管理をせず、常に 6 週間サイクルごとに最も必要な取り組みを再選定します。

私達の開発プロセスにおける、6 週間の開発 + 2 週間のクールダウンだったり、バックログを持たない部分は、まさに Shape Up を参考にしています。
一方で、Shaping や Betting Table は、現時点では会社規模が小さいこともあり、まだ導入していません。

まとめ

• 8 週間の大サイクルと 2 週間の小サイクルを組み合わせて開発をしているよ
• スクラムと Shape Up を参考にしているよ

Nstock の開発プロセスが気になった方は、気軽にカジュアル面談しましょう！