BasecampのShape Upを実践してみた

January 04, 2021

Basecampというプロジェクト管理のためのソフトウェアサービスを提供している会社がある。つい最近、HEYというEmailのアプリもこの会社の新たなサービスとして登場した。Basecampといえば、その前身は37signalsという会社で、Getting Real(日本語版: 小さなチーム、大きな仕事)という書籍の著者でもある。

そのBasecampが2019年に新たに公開したプロダクト開発メソッドがShape Upだ。Shape Upが何なのかについては、英語の原文が無料で公開されているのでそちらを読むのがベストだと思う。とはいえなかなかのボリュームなので、3行で説明すると以下のようなものだ。

  • Basecampが自社のソフトウェア開発で採用している。
  • 6週間の開発サイクル、見積もりではなく予算、タスクではなくプロジェクト。
  • バックログなし、スプリントなし、進捗確認のためのミーティングもなし。

Shape Upをやってみた

私は現在、Quartzというオンラインメディアを運営する会社に所属している。普段はQuartzのウェブサイトやアプリ、ニュースレターなどのサービス開発に携わっており、2020年の初めからこのShape Upをベースにしたフレームワークに沿ってプロダクトを開発している。

これまで約1年間にわたって様々なプロジェクトでShape Upを実践してきたのだが、まだ比較的新しいフレームワークということもあり、あまり外では語られていないように感じる。この記事では、私が実際に携わったプロジェクトを例にあげて、Shape Upがどういったフレームワークで、それが私たちのプロダクト開発にどのような変化をもたらしたかについて共有できればと思う。

Shaping

Shape Upではまずプロジェクトを開始するときにプロジェクトをShape(形作る)ことから始める。このプロセスは、問題を定義し、解決策となるアイデアを考え、ラフスケッチとともにドキュメントにまとめる作業だ。成果物となるドキュメントはPitchと呼ばれる。スタートアップのエレベーターピッチのようなもので、なぜその問題を解決することが会社にとって重要なのか、を伝える手段だ。

Shapingのプロセスについては、Part 1: Shapingに詳しく書かれている。このプロセスは、ウォーターフォールモデルでいう要件定義、スクラムでいうユーザーストーリーの作成に相当するかもしれない。

Shapingに関して、私が特に面白いと感じた点は、適切な抽象化Appetiteの設定である。

適切な抽象化とは、プロジェクトの内容を「具体的過ぎず、抽象的過ぎない」ちょうどいいレベルで定義することである。Shape Upの言葉を借りれば、ワイヤーフレームは具体的すぎるが、言葉だけだと抽象的すぎる、その中間くらいが良いということだ。抽象化に関する細かなテクニックについては、ぜひ原文を読んでみてほしい。

Appetiteの設定は翻訳するのが難しいのだが、直訳すると「欲望」となる。これは文脈によっては「時間的予算」と読み換えることもできるだろう。ウォーターフォールやスクラムでいうEstimates(見積もり)が、ある問題を解決するのにどれだけの時間がかかるのかを推定するプロセスであるのに対し、Appetiteはその問題を解決するのにどれだけの時間をかけたいかを決めることに重点を置く。AppetiteにはSmallまたはBigのいずれかを設定し、その大小によって3週間または6週間の期間が開発チームに割り当てられる。この連続した3週間または6週間(Six-Week Cycles)という期間もまた、Shape Upを特徴づけるキーワードだ。

QuartzにおけるShapingの重要人物はプロダクトマネージャーである。またプロダクトマネージャーの助けを借りる形で、社内の誰もがこのプロセスに参加することができる。普段困っている問題や新しい機能のアイデアがあるスタッフは、所属に関わらず誰でもPitchを通じてプロダクトの改善に貢献することが可能だ。

Betting

社内の様々なスタッフから集められたPitchは、Betting Tableと呼ばれる、CEOを含むC-レベルの社員とプロダクトチームの代表者による会議の場にかけられる。Betting Tableとはその名の通り、会社としてどのプロジェクトにBet(賭ける)するかを決める場である。Betting Tableで承認されたPitchはBetとなり、各Betに開発者やデザイナーなど必要なメンバーをアサインすることでプロジェクトが開始する。

Building

ひとたびプロジェクトが開始すると、プロジェクトの詳細な決定権はアサインされたメンバーに全て委ねられる。たいていの場合、初日にキックオフ会議を行い、その後数日かけて各メンバーはBetの内容を精査し、プロジェクトの遂行に必要な情報を集める。既存のコードベースを読んだり外部のサービスを調査したりと、各プロジェクトによってアプローチは様々だ。このプロダクトの設計、開発、テスト、ローンチまでを実施するプロセスについての詳細は、Part 3: Buildingにまとめられている。この章には仮にShape Upを実践しなくとも、普段プロダクト開発をしている人にとって有用なヒントがたくさん詰まっていると思う。

プロジェクトの具体例

ここまでShape Upについて簡単に要約してきたが、ここからは私が実際に携わったプロジェクトの中から印象的だったものをひとつ紹介したい。ちょうどパンデミック発生直後の2020年4月ごろに開発した、インタラクティブなニュースコンテンツを新たに追加するプロジェクトだ。

この機能は、読者がウェブサイト上のニュースに関する質問に回答すると、その回答に関連したニュースコンテンツが表示される、というものである。プロジェクトはR&D的な位置付けで、Small Appetiteだった。私はプロジェクトの主にバックエンドを担当する開発者としてアサインされていた。

ニュースコンテンツのバックエンド

この機能を仮に投票機能と呼ぶ。投票機能はトップページのニュースコンテンツの一部として、Webとアプリの両方で見られることを期待されていた。

当時のQuartzのバックエンドシステムは、ニュースコンテンツを配信するCMSとしてのWordPressと、トップページ用のコンテンツを編成するための独自の編成ツールを併用していた。投票機能を新たにトップページに追加する場合、フロントエンドのデザインに加えて、バックエンドとなる編成ツールのデータモデルやAPI、それから編集者向けのダッシュボードにも手を加える必要がある。3週間で技術調査からバックエンド、フロントエンド、モバイルアプリの開発、テスト、QA、リリースまでを終えるには少しタイトなスケジュールだ。この限られた期間で、よりシンプルに実装する方法はないだろうかと、少し角度を変えて調査してみることにした。

WordPressのプラグイン

ニュースコンテンツのCMSにWordPressを利用していたので、WordPressのプラグインで似たようなものが既に利用できるのではないかと考えた。そこでまずは最初の数日を使って、既存のプラグインを調査、検証することにした。いくつか良さそうな候補をリストアップし、プロジェクトの他のメンバーと手分けしながらひとつずつ試したのだが、残念ながら要件に見合うようなものは見つからなかった。

WordPress用に新たにプラグインを自社で開発する、という選択肢は残しつつも、さらに別の方法を検討することにした。

Google Sheets

メンバーの一人がとても面白いアイデアを提案してきた。Google Sheetsをデータベースを使うのはどうか、というものだった。

プロジェクトのボトルネックはバックエンドの編成ツールの開発だったので、ここを出来るだけ素早く作りたい。Google Sheetsのスプレッドシートなら項目を自由に定義し、簡単なバリデーションも追加でき、かつSheets APIを使えば直接コンテンツを読み込むこともできる。編集者にはツールが不完全であることを伝えて(ニュースルームの編集者も同じプロジェクトに関わってもらっている)、最初はスプレッドシートに直接コンテンツを書き込んでもらう。まさに斜め上の、悪い言い方をすればパッチワークのような解決策だ。おそらくこのような提案ができるのは、Appetiteによる強い時間的制約と、そのような制約があることを各スタッフが十分に理解し、コミットしてくれているおかげだろう。

Google Sheetsを使うことが決まると、早速スプレッドシートに必要なカラムとダミーデータを入れ、GraphQLのスキーマを定義した。スキーマを早い段階で定義しておくと、その時点からフロントエンドとバックエンドが並行して開発に取り組めるので効率が良い。フロントエンドの開発者がデザイナーと細かなインタラクションについて議論している間に、バックエンドではGoogle Sheetsに接続するためのResolverを書く。そうして約1週間ほどで、バックエンドからフロントエンドまでフルスタックで動く最初のバージョンが完成した。この最初のバージョンをなるべく早く作りきることを社内では最初のイテレーション(First Iteration)と呼んでおり、Shape UpのGet One Piece Done(最初のピースを完成させる)やリーンスタートアップの実用最小限の製品(MVP: Minimum Viable Product)から影響を受けている。

最初のバージョンが完成した後は、細かなデザインの調整や、バックエンドのパフォーマンス改善、リファクタリング等を行い、無事期間内に最終盤をローンチすることができた。

まとめ

投票機能のプロジェクトは決して技術的に難易度の高いものではなかったが、Shape Upを実践したことで普段とは少し違ったアプローチで問題に取り組むことができた。またこれは結果論にはなるのだが、諸々の事情によりこの投票機能はローンチからわずか数週間で廃止されることとなる。このような結果になると予想はしていなかったものの、開発する機能の重要度や期待度に応じて開発リソースを適切に割り振り、重要度の低い機能を作り込み過ぎずに済んだのはよかったと思う。品質やスピードの判断を個人がなんとなく勘や経験によって下すのではなく、フレームワークの一部として会社全体でシステマティックに実行できるのはShape Upやその他の開発メソッドを導入するメリットであると感じた。

いっぽう、6週間の開発サイクルなど制約が強すぎるために柔軟さに欠ける点はデメリットとしてあげておきたい。仮に今すぐに実行したいアイデアがあっても、フレームワークの形式上、最大で6週間、Cool Downも合わせると8週間待たなければならない(例: COVID-19に関する機能開発を今すぐ始めたい、など)。また、開発者やデザイナーの自由度が高すぎるが故に何から手をつけて良いかわからなくなる、といった点は各個人の好みやスキルレベルによって意見が分かれるところだろう。加えてBetting TableやSix-Week Cyclesなどプロダクトチーム以外への影響も大きいため、特にC-レベルの意思決定層の合意をしっかりと得ることが実行する上での鍵となる。

Shape Upはウォーターフォールやスクラムなどの開発メソッドと比較するとまだまだ認知度が低く実践例も少ないと思う。個人的には1年間やってみてたくさん学びがあった。もしShape Upに興味がある、Shape Upを導入している、という個人や会社があればぜひ体験を共有してみたい。この記事がそのきっかけとなれば幸いである。


Hi there, I’m Tatsuya, a software engineer from Japan currently living and working in New York. You can also find me on Twitter.