f:id:tune:20200823130404p:plain

はじめに

Basecamp社が公開しているプロダクト開発ガイド「Shape Up」の存在を知り読んでみました。 Basecamp社はプロジェクト管理SaaS Basecampの開発元で、以前は37 Signalsという社名でした。 Ruby on Railsの作者 David Heinemeier Hansson氏がCTOを務め、最近だと新機軸のメールサービス Hey を立ち上げています。

basecamp.com

特徴

Basecamp曰く「アジャイル開発でもスクラム開発でもない」、Basecamp社で15年近く試行錯誤して改善してきたやり方だそうです。

「6週間の開発サイクル」と「2週間のクールダウン期間」を繰り返して開発を進めます。サイクルの途中で中断・見直しはせず、期間内にリリースに至らなかった場合でも期間延長はされません。 6週間は「何か意味のあるものを最初から最後まで作り上げるのに十分な長さ」であり、「誰もが最初から期限を感じることができるほど短い」、経験から導き出した開発期間とのことです。

開発チームが着手する前に少人数のシニアグループが事前に検討を済ませておきます。ただしこの事前検討(Shaping)は適切な抽象度までで留めるよう留意します。「チームが何をすべきかを知っているほど具体的である」一方、「詳細を自分たちで考え出す余地がある」程度を目指します。

進め方

Shaping
Betting
Building

Shaping

開発する項目を考えますが、「適切な開発スコープを切り、事前に決めすぎないようにバランスをとる」ことに留意する必要があります。

「開発前に決めすぎない」とは下記のような事例を指します。

ワイヤフレームを描いてしまうと具体的すぎます。開発着手後にデザイナーが創造性を発揮する余地がありません。
言葉による説明は抽象的すぎます。開発着手後にチームが要件を満たす中でトレードオフを見つけるのに十分な情報を与える必要があります。

ガイドではプロジェクト管理ツールにカレンダーを追加しようとした例が挙げられています。通常カレンダーには月・週・日のビュー切り替え、予定の移動などたくさんの機能が求められていますが、6週間内でリリースするには機能を絞り込む必要があります。そこで「月表示のカレンダーにイベントをドットで表し、クリックすると詳細が見える」ところまでに機能を限定したそうです。その際のShapingでのデザインが下記です。

これが開発完了時にはこうなりました。見比べると当初のデザインは詳細が省略されているものの必要な要素は満たしており、何がスコープの範囲外になるのかが明確になっていたことがわかるかと思います。

Shapingはインターフェース・技術的な実現性両方を考える必要があり、ジェネラリストが行うか、デザイナーが主導し他のメンバーと協力して進める必要があります。インターフェース検討時にワイヤーフレームは具体的すぎるため、インターフェースを構成する主要なコンポーネント・関係を元に議論します。

Places : 画面・ダイアログ・ポップアップなど、ナビゲートできるもの。
Affordances : ボタン・入力欄などユーザーが操作できるもの。
Connections : ユーザー遷移

Shapingのアウトプットは開発スコープを説明する「Pitch」です。 Pitchは下記から構成されます。

問題点 - 生のアイデア、ユースケース、またはこの作業に取り組む動機となる何か
Appetite(食欲) - どのくらいの時間を費やしたいのか、そしてそれがどのように解決策を制約するのか
ソリューション - すぐ理解できる形で提示されたコアな要素
リスク
スコープ外の項目

Pitchはステークホルダーが時間のあるときに読めるよう、課題管理システムのIssueにまとめているなどして置いておくそうです。

各Pitchに対しては以下の2種類に分ける程度の見積もりしかしません。Shape Upの用語では"Appetite(食欲)"と呼びます。

Small Batch : 1人のデザイナーと1〜2名のプログラマーが1〜2週間で実装できるサイズ。
Big Batch : チーム全員で6週間かかるサイズ。

Betting

次の6週間で取り組むPitchの候補は"Betting Table(賭け)"の場に持ち込まれ議論されます。 Betting Tableはクールダウン期間に行われる会議で、CEO・CTO・シニアプログラマー・プロダクトストラテジストが参加します。全員が事前にPitchを読み込んだり、関係者と話して勉強してきているため長くかからず、1〜2時間程度で終わるそうです。

計画ではなく期待値を決める賭けの場であり、6週間後に何か意味のあるものが完成することを目指します。失敗しても高々6週間分のリソースが失われる程度に抑えるリスクヘッジの仕組みでもあります。

チームは「デザイナー1名・プログラマー1 or 2名・QA担当者 (サイクルの後半で統合テストを行う)」で構成されます。 6週間の間、割り込みがないように留意します。

バグが見つかった場合、下記のいずれかで対処します。

2週間のクールダウン期間を使う
Betting Tableにバグ修正を持っていく
バグ対処だけを行う日を決めてそこで対応する

Building

早期にPitchをタスク分解してしまうと全体像を見失ってしまいます。これはタスクが割り当てられてしまうと、互いの作業の関係性に注意が向かず、判断する責任を感じなくなってしまうためです。

そこでチームは手を動かしながら適切なスコープ(単体で価値が提供できる切れ目)を見つけ、開発タスクを徐々に分解していきます。

スコープが正しいことを示すサインは下記の通りです。

プロジェクトの全体を見渡せるような気がして、心配するような重要なことが細部に隠れていない。
スコープが適切な言葉を与え、プロジェクトについての会話がスムーズである。
新しいタスクが出てきたとき、どこに配置すればいいのかがわかる

進捗は「できたこと」「できていないこと」ではなく、「わからないこと」「解決したこと」にフォーカスします。プロジェクトを丘にたとえ、スコープごとに今現在どこにいるかを示すことで進捗を見える化します。

6週間で終わらなかった開発を継続する場合、下記の両方を満たす必要があります。

価値が十分に議論され重要である
丘を登り終え、下り途中である

リリースすると顧客から負のフィードバックをもらうこともありますが、しばらく待って注意深く観察します。安易に対応したり、過去バージョンに戻したりせず、機能修正の対象としていた顧客の反応をきちんと見ましょう。またフィードバックはすぐに対応せず、次の賭けとしてBetsにかけます。

HEYの開発事例

すべてShape Upのプロセスに従って進めた。1年間のシニアチームによるR&Dと1年間の製品開発、リリース前の整理に2サイクルを費やしたとのこと。

1年間のR&Dモード(Jason（CEO）、David（CTO）、Jonas（シニアデザイナー）の3人のチーム)
1年間の開発期間
2サイクルのクリーンアップ

感想

ポジティブな面

スクラムが明示的に規定していないノウハウを埋めてくれそう。
- 着手前の設計・技術調査
- 事前に設計しすぎないとはどういうことかという事例。

ネガティブな面

Basecampのような思想(少数の価値ある機能に注力し磨いていく)を前提にしていないと合わなそう。
運用するのが難しそう。
- 方向転換できるまでに8週間かかる。スタートアップでは長すぎ、ビジネスモデルを確立した企業では享受できるメリット(機能を絞り込んで開発し磨く)が小さいのでは?
- 原文を読むとわかるがBetting以降の章はルールでなく運用ノウハウ・コツが多い。