Basecamp社のプロダクト開発メソッド「Shape Up」を6ヶ月実践した振り返り

Product Development

こんにちは。grooves エンジニアの福井(@bary822)です。

突然ですがみなさんはスクラム以外でソフトウェア開発を行ったことはありますか? 私はありませんでした。

私が社会人としてお金を頂きながらコードを書き始めた2014年頃、スクラムは当時としては画期的な概念をソフトウェア開発に持ち込んだ革新的な存在であり、それを採用しているのはいわゆる「イケてる開発チーム」でありました。そして私は幸運にもこのイケてるチームでソフトウェアエンジニアとしてのキャリアをスタートした一人だったのです。

それから7年という、この業界では長いとされる年月が過ぎてスクラムは大衆化しました。私の感覚ではWeb界隈の自社開発企業ではデファクトスタンダードになっていると思います。

実際、Forkwell Jobsで「スクラム」と検索すると300件以上の求人がヒットします。組織の実情や置かれている環境によってその形は様々かと思いますが、スクラムは多くの開発チームに支持されているようです。

もし私が新しい開発チームを立ち上げるとしたら、何の疑いもなくスクラムを採用していたでしょう。なぜなら私はそれしか知らなかったからです。何も整備されていないチームに経験していない新しい開発手法を取り入れるのはリスクが高すぎるため、合理的な判断とは言えないでしょう。

そんな中、今年の1月に出会ったのが「Shape Up」でした。

Shape Up

Shape UpはBasecamp社で実践されているプロダクト開発手法です。

同社が15年以上のプロダクト開発から得た経験や、上手く機能したプラクティスを抽出して開発プロセスとして整理したもので、アジャイルでもスクラムでもない独自の思想、概念が数多く散りばめられてます。

Basecamp社といえばRuby on Railsの作者であるDHHが共同創業者であることで知られているだけでなく、米国内のおいてはそのユニークな経営方針や働き方が話題に上がることも多く、オピニオンリーダー的な側面も持っています。

かく言う私も同社のファンであり、特にPodcastシリーズのREWORKは毎回欠かさず聞いていました。

そんな中、あるエピソードでShape Upを一般に公開することにした、という発表がありました。しかもWeb版は無料で読めるとのことで、早速流し読みしてみるとなんだか良さげです。スクラム開発にどこか窮屈さを感じていた当時の私に一つの答えを与えてくれるような内容が盛り沢山です。これはじっくり読みたい! と思い、有料の書籍版を購入して読み進めることにしました。

shape-up-book-photo
読み返したい本は紙で持っておきたい派です

特徴

詳しい内容はぜひ原書で読んでいただきたいので、ここではShape Upにおける特に重要な用語と開発の進め方を簡単に紹介していきます。

Shaping

shaping-overview Shapingはいわゆるプランニングのフェーズで、「何を作るか」を言語化して形作っていきます。

プロダクトの戦略や中長期的な目標をベースとしたあるべき姿と現実とのギャップを抽出し、それを埋めるために必要なピースを適切なスコープで形作るようなイメージです。

ここで最も重要なのはソリューションを適度な抽象度で記述することです。

原書によると"Wireframes are too concrete. Words are too abstract."とのことです。つまり、ワイヤーフレームまで細かく落とし込むとエンジニアが仕様を調整したり、デザイナーが創造性を発揮できる余地がない。また、言葉だけで作りたいものを伝えようとすると十分な情報が伝わらず、思っていたものとは異なる成果物が出来上がってしまう。ということです。

(Basecamp社でShapingを行うのはいわゆるプロダクトマネージャーや時には共同創業者のJason Fried自身が担当することもあるそうです。)

原書にはBasecampのカレンダー機能を例として実際にShapingが行われる様子が細かく記載されています。ぜひご覧になってみてください。

Appetite

AppetiteはShapingを行う時に考慮すべき項目の一つです。直訳すると「食欲」ですが、個人的な意訳は「希望工数」としています。

通常スクラムなどアジャイルベースの開発プロセスでは、課題選定 -> ソリューション -> 見積もり という順番で「この課題を解決するにはこれくらい工数がかかる」という観点から優先度をつける際に考慮することが一般的です。

しかし、Appetiteはこれと逆の発想です。つまり、 課題選定 -> 解決にふさわしい工数上限(希望工数) -> ソリューション という流れでプランニングが進行します。

希望工数の根拠を示すのは簡単なことではありませんが、例えばその課題解決によって削減される工数や防止できる機会損失額などを引き合いに出してROIを意識したものにすると説得力があるものとなりやすいです。

原書ではAppetiteを考える際に、1~2人の開発者が1~2週間でリリースできる「Small Batch」と1チームが6週間を費やす「Big Batch」のどちらかのサイズに当てはめるて考えることが一般的であるとのことでした。

Pitch

Shapingで考案したソリューションや算出したAppetite、その他の要素をまとめて1つのドキュメントとしてまとめたものがPitchです。

Pitchのフォーマットは定められていませんが、以下の要素を含むものだとされています。

  1. Problem (解決したい課題)
  2. Appetite (希望工数)
  3. Solution (どのように課題を解決するか)
  4. Rabbit Hole (リスク回避のために考慮すべきこと)
  5. No-gos (やらないこと)

実際に見てもらうのが一番イメージしやすいかと思いますので、Basecamp社が公開しているものをいくつか掲載しておきます。

Pitchを書くにあたって、時には開発者に実現可能性をヒアリングしたり、関係者間で議論を重ねることもあるそうです。このような作業を繰り返すことで質の高いドキュメントが出来上がります。

Betting Table

betting-overview

Pitchを持ち寄って次の開発サイクルで実際にどれにGoを出すのかを決定するミーティングがBetting Tableです。

(Basecamp社では1サイクル = 6週間 で回しています)

参加者はCEOやCTOなど経営幹部クラスやシニアプログラマ、プロダクトチームのリーダー格など、チームを代表するメンバーで構成されます。

CxOクラスの人は得てして時間が取れないことが多いものですが、内容が洗練されたPitchを参加者全員が事前に読んでおくことが参加条件となっているため、Betting Tableは通常 1〜2時間程度で終わるとのことです。

ちなみに"Bet"というワードが選ばれた背景として、(1) 投資にはリスクが伴うこと (2) 関係者全員がそれにコミットすること という意味が込められているそうです。

採用されなかったPitchは担当者個人が持ち帰り、次のBetting Tableまでに内容をより魅力的にしたり、計画を変更するなどします。

Building

building-overview

実際に手を動かしてソリューションを現実のものにしていくのがBuildingです。

Pitchにある「丁度いい抽象度」のソリューション案を実装可能な開発タスクに分解し、それを自らの手で実装していくのが開発者の責任です。個別に分解された細かいタスクを開発者にアサインするのではなく、開発者自身で設計から実装まで責任を持って行うことで "Code Monkey" になるのを避けるべきだと言及されています。

タスクはTo-doリストとHill Chartと呼ばれるユニークな曲線グラフを使って進捗を可視化することになっていますが、この詳細については説明が長くなってしまいますので原書でご確認ください。

Cool-down

6週間のBuildingが終わると、2週間のCool-down期間に入ります。

開発者、デザイナーはこの期間の時間を基本的に自由に使うことができます。

Building期間中に生まれたり前から気になっていたバグを直したり、なにか新しい技術を試す、次に何をやるべきかを考えるなど、日常の開発からは一歩離れて全体を見直したり、一息ついて次の開発サイクルに備える期間とされています。

試してみた

前置きが長くなってしまいました。いよいよ私のチームでShape Upを採用するにあたってアレンジを加えた点や、やってみて得た気づきを共有していきます。

前提として私のチームは「クラウド推進室」という、主にインフラレイヤーに責任を持つものであり、ユーザーの目に見える機能を開発するチームではない点にご留意ください。(このチームが誕生した経緯は別のエントリーでまた詳しく共有したいと思います)

6週間は長すぎる

Basecamp社ではBuildingに6週間という時間を使っていますが、私達にとってはこれが長すぎました。6週間を使って作るべきものを計画するのはインフラを構築・改善するチームにとって適切なスコープで課題を切り出すのに大変苦労しました。つまり、「6週間を使ってでも作るべきもの」を探すことができなかったのです。

また、Cool-down期間を加えると8週間という時間は変化の激しいベンチャー企業にとってはアジリティの不足感が否めませんでした。アプリケーション開発と比べるとその程度は落ちるものの、8週間の間に注力すべき領域が変わったり、リリース期限に厳格な機能リリースに関連したインフラ構築依頼がアプリケーション開発チームから飛んでくることも多々あります。

現在のところ私のチームでは3週間をBuilding期間とすることで、Shapingにおいて十分な価値を提供する課題を、手に収まるサイズのスコープで切り出せるようになりました。

また、原書にもある「価値のある仕事をするために十分長く、最初から期限を意識できるほど十分に短い」期間として機能しているように感じます。

PM不在のチームでは誰がShapingを行うのか

Shape Upの一連のフローはどうやらShapingを行う人(PM)とBuildingを行う人(プログラマ、デザイナー)の分担が明確に行われている前提であるようです。つまり、ShapingとBuilding(Cool-down)が並行して走っているイメージです。

これに対し、私のチームでは専任のPMが存在しません。開発者自身が課題を発見してそれをどのように解決するかを計画することから、実際にそれを実装・リリースするまでを広く担当することになっています。

Shape Upを私のチームに適用するために、ShapingをCool-down期間中に行うこととしました。Cool-downの本来の目的である開発者の自由を尊重した活動を行う機会が減る懸念はありましたが、チームで合意の上やってみることにしました。

また、Buildingを6週間 -> 3週間に短縮したことで本来は1週間となるCool-down期間ですが、これを2週間に延長することでバランスを取ることにしました。

今のところ 2週間のShaping + Cool-down -> 3週間のBuilding をシーケンシャルに行うフローが質の高い課題選定を行いつつ、持続可能な開発を行うことができる組み合わせとして機能しているように感じます。

他チームからの要望

私のチームがインフラレイヤーを担当している都合上、アプリケーション開発チームからの要望に答えることは避けては通れない道です。新機能のためにAWSサービスを使ってサーバーレスに実装したい、MVPのために捨てやすいインフラを構築してほしいなど、その種類は多岐にわたります。

これが一番やっかいなのは、Bettingにて優先度を決める場面です。

自チームからのPitch(施策)は基本的に自チームの目標を達成に寄与するかどうか軸として優先度を決定することができます。これに対して他チームからの要望は他チームの目標を達成するために存在します。それぞれが独自の目的を持っているため、自チームと他チームの施策の優先度を並べて評価することはできません。

この問題に対する私達の解は「あらかじめ他チームからの要望に対する工数を分配しておくこと」でした。

Bettingに先立って、Buildingで使える工数を自チーム、他チームに分けてあらかじめ提示しておきます。現在のところ 自チーム:他チーム = 7:3 の割合で工数を分配しています。

事業部としての優先度や環境の変化によってこの割合は変化させることを前提としていますが、今のところこの割合で運用してみて目立った問題は発生していません。

スクラムとの比較

ここまではShape Upでの開発の流れと、私のチームに適用する時にアレンジした点をお伝えしました。ここでは少し視点を変えて慣れ親しんだスクラムとの主な違いを紹介します。

(ちなみに私自身はスクラムよりもShape Upが好きです。かなりバイアスのかかった比較となっていますので、あらかじめご了承ください)

バックログ

スクラムが中央集約型バックログなのに対し、Shape Upでは分散型バックログと言えるタスク管理を行っています。

Betting Tableにて採用されなかったPitchはその著者に返されます。著者はそれをブラッシュアップしてより魅力的なPitchにしたり、スコープを小さくする代わりに希望工数を減らしたりして次のBetting Tableで採用されやすくする準備を行います。もちろん、次のBetting Tableまでに状況が変わって取り組む価値が無いと判断した場合はBetting Tableに持ち込まれることはありません。

個人的にはこの仕組みが大変気に入っています。スクラムでよくありがちな「とりあえずタスク化しておこう」で高く積み上がっていくバックログを見て永遠に終わりがないような感覚に陥ることも無いですし、何よりバックログをメンテナンスするコストがかかりません。

私のチームのように少人数でありながらも価値の高い成果物を提供し続けるためには、課題選定 -> 実装・リリース のサイクルを打率よく回すことが求められますが、Shape Upはまさにこれに適していると考えます。

見積もり

先にも少し触れましたが、Shape Upでは「この課題を解決するのにどのくらいの工数をかけられるか」という視点でタスクに対する工数割り当てを決定します。スクラムでは往々にして「開発チームから出た見積もりが大きすぎたからスコープ調整しましょう」という会話がなされ、PM - 開発チーム間でどこまでなら現実的に投資可能な工数で実現できるかというコミュニケーションが頻繁に発生します。

これに対しShape UpではPitchを書く時点で費用対効果(開発工数 vs 課題解決の価値)を考慮したソリューションを考えます。簡単な作業ではないため最初のうちは希望工数の算出に苦労するかと思いますが、この工程を経ることでオーバーエンジニアリングしてしまったり、逆に解決する価値があまりない課題のために工数を支払ってしまうリスクを低減させることができます。

開発サイクル

スクラムが通常1~2週間のスプリントを回すのに対し、Shape Upではデフォルトで8週間が1サイクルとなります。これは市場への投入スピードが重視されるスタートアップにとって許容できる長さではないかもしれません。

6週間のBuildingが推奨されていますが、私は自分たちのプロダクトが置かれているマーケットの環境や求められるスピード感に応じてアレンジすることも1つの手かと思っています。

また、スクラムの大枠の流れは変えずに期間だけを試しに6週間にしてどのような変化が生じるのかを観察してみるのも良いと思います。

ミーティング

スクラムではスクラムイベントとしてスプリントプランニングやバックロググルーミングを行います。チームによってはそれに追加してバックログをメンテナンスするための何らかの活動を行っているかもしれません。これはバックログのタスクに対して適切な優先度をつけたり、メンバー間で理解のばらつきがない状態を保つためには必要なことですが、同時に実装に費やす工数が減ってしまうこととのトレードオフの関係にあります。実際、私がスクラムで開発していた頃は全体の約50%しか実装に使うことができませんでした。

これに対しShape Upでは定期イベントと呼べるものはBetting Tableだけです。もちろん必要に応じてミーティングを設定することもありますが、それでもBuilding期間中は全体の90%以上の工数を実装に当てることができています。

スクラムは高い透明性を確保することやスプリント期間中に生じた問題を振り返り、改善を積み重ねられるように設計されていることがメリットではあるのですが、「スクラムイベントに割く工数が多すぎてもっと重要なことにフォーカスできていないのではないか」という疑問を抱いていた私にとってShape Upはまさに最低限の工数で最大限の成果をあげるための開発手法であったと言えます。

最後に

いかがだったでしょうか。

今回はShape Upの概要や、私のチームで実際に運用して得た気づき、またチームが置かれた環境に適用させるためにオリジナルからどのようなアレンジを加えたかを紹介しました。

日本国内でShape Upを導入しているチームはまだまだ少ないように思います。もし私達以外にもShape Upを実践している人やこれから試してみたい人がいらっしゃいましたらぜひ意見交換できればと思います。どんな開発を行っているのか、やってみて得られた変化、アレンジした点、導入するに当たって心配している点などお気軽にコメントいただければ幸いです!

また、弊社ではアプリケーション開発エンジニアを募集中です。募集中の求人で配属されるチームではスクラムを採用していますが、groovesはチャレンジに非常に寛容な会社です。私が行ったように実績のない開発手法を導入することも快く受け入れてくれます。ぜひ一緒に働きましょう。