Shape Up: B2B SaaSスタートアップRelateチームの製品開発プロセス

Shape Upは、プロジェクトマネジメントソフトウェアとメールサービスHEYを作るBasecampチームが最初に考案した製品開発プロセスだ。

営業CRM SaaSを作るスタートアップRelateチームは、このShape Upプロセスを少し変形して使っているが、本文にあるとおり、さまざまな特徴（uniqueness）がある。その中には、以下の特徴も含まれる。

1. 製品仕様書を書かない。代わりに、適切なレベルの抽象的な形や姿（=shape）を伝える。High fidelity wireframeやprototypeも、ほとんど作らない。サイクルが始まると、Shapingを通じて作られた形をもとに、エンジニアがすぐにコードを書き始め、その後はプロダクトリードがサイクル全体を管理しながら課題に対応する。

2. 合計4週間のサイクルで、3週間の開発期間と1週間のクールダウン期間を持つ。クールダウン中には、QAなどを通じて3週間で作ったものの完成度を高めるプロセスを経る。

3. 開発を減らす、あるいは別の形で開発する。とにかく多く作ることが良いわけではない。顧客の問題を解決することに集中し、どうすれば最もシンプルな方法で解決できるかを考える。

[nicewook]

「シンプル。」というキーワードが気に入っています。

[xguru]

Shape Up - 小さな組織がうまく働く方法

[kbumsik]

私たちのスタートアップでも Shape Up を使っていますが、いくつか注意すべき点がありました。

1. 1サイクルに多くの shape を入れすぎない。欲張ると機能ごとに開発者1人が割り当てられることになり、自律性を優先する開発方式であるぶん、かえって1人でシェイピング（企画）から開発まで全部やる事態が起きてしまいました。
2. ビルディングサイクルの途中で意思決定者が介入しない。自律性を優先しているぶん、途中で上の立場の人が介入すると、そのサイクルは失敗したと見なすべきでした。開発する Shape を決めるベッティング期間に、本当に十分な議論を意思決定者と行っておく必要があります。

私たちの会社は試行錯誤を経て Shape Up の開発方式が定着しましたが、注意点をきちんと守らないと1サイクルそのものが丸ごと無駄になることもあるので、この開発方式は十分に学んでおく必要がありました。