#book #r2021

[https://basecamp.com/shapeup](https://basecamp.com/shapeup)
Basecamp がプロダクト開発をしているときにどうやってるかを紹介してる本
基本的にはBasecampは 6 week cycle (タイムボックス的な) でプロダクトを開発していて、その中で価値の高いものを品質よく作っていくためのいろいろ
# Shaping
- プロジェクトを実際にスケジューリングする前に行うフェーズ
- Shapingをするときには、具体的すぎず、曖昧すぎずほどよいレベルのものを成果物としないといけない。
- 具体的すぎると、エンジニア や デザイナー が専門スキルを活かす余地が減ってしまい、局所最適な解しか選べなくなる
- 曖昧すぎると、要件の内容がわからなかったり、何を作るか、どんな価値を提供したいのかという意思疎通が難しくなる
- 重要な要素
- It's rough
- デザイナーや開発者は、専門性を活かす余地が必要
- 詳細化をしすぎると、局所最適解しか選べずROIの悪化につながる
- It's solved
- 具体的なタスクなどについては言及しない rough ではありながら、何を解決するべきかということは明確になっていないといけない。
- プロジェクトのリスク現象のために、すぐに思いつくような質問や落とし穴は全て解決されていなくてはいけない
- It's bounded
- 何をしないかということも決まっている
- これはチームに対してどこで止まるかというこを示す
- チームには当然リソースの制約があるわけなのでスコープを明確に絞る必要がある
- 誰が Shaping をするか
- 技術的な可否やビジネスの優先度どちらも理解している必要がある
- これらのスキルを1人で持つか、複数人で共同作業するかが必要
- Basecampでは、Shaping中のものと開発中のもので2つのレーンを用意してる
- Steps to shaping
- Set boundaries
- Rough out the elements
- Address risks and rabbit holes
- Write the pitch
## Two Tracks
Basecamp では、 Two Tracks を利用してる
- [[Dual Scrum]] に近いかも
- あるチームが Shaping を行い、あるチームが開発とデザインを作ったりを行う
## Bread Boarding
- UIを必要以上に詳細化してしまうとデザイナーにバイアスを与えてしまいクリエイティブを発揮できない
- とはいえ、何も絵などがない状態だとラフすぎる
- したがって以下の要素のみを最低限のUI制約のみを定義する
- Places
- どこに置くか (どの画面におくか)
- Affordances
- ユーザーが取れるアクション
- e.g タップ、トグル、フィールド
- Connection lines
- Affordance の結果ユーザーの画面推移などがどう変化するか
- 
## Write the Pitch
- ここまでタスクが Shaped になると、今度は Betting Table (案件をやるやらないを決める会) に持っていくために Pitch に改めてまとめる
- 以下の要素を含むべきとしている
- Problem
- どんな問題か、誰が何ができないかなど
- Appetite
- この問題を解くのにどれくらいの時間やリソースを割きたいか
- Solution
- Bread Boarding の内容などをさらに説明のために補足したもの
- Rabbit Holes
- Solutionのうち後に判断が必要になるような制約や障害になり得る情報
- No-gos
- 今回のスコープの中には明確に入れないもの
# Betting
- BasecampではBacklogでタスクを管理するようなことはしていない
- 6週間ごとに 2週間の Betting Table の機会をもうけている
- この会に漏れたものについては、次に持ち越されることはなく次の Betting Table に新規に持ち込まれることになる
- したがって常に6週間分のゴールしか存在しない
## Team and Project sizes
- 1つのプロジェクトは1人のデザイナーと1,2人のプログラマによって構成される
## What about bugs
- まずはそもそもそのバグには今このタイミングである任意のリソースをかけて修正する価値があるかを考える
- Use cool-down
- 6週間ごとに2週間の Betting Table を設けるので開発チームは手が空くためこの時間を使ってリファクタリングなどを行ったりする
- Bring it to the betting table
- Schedule a bug bash
- 1年に1回程度、休みの近くのcycleを丸ごとbug fixにあてるときもある
## Question to ask
- Does the problem matter?
- Is the appetite right?
- Is the solution attractive?
- Is this right time?
- Are the right people available?
# Building
## Map the scope
- プロジェクトごとにScope Mapを作ってる


- こういう形でタスクではなくより抽象的な機能郡でスコープを切っていく
- これらは、徐々に発見されていくものになる
## Work is like hill
- スコープに分割していったら、それらのスコープがどういう進捗かというの

- スコープと対応した、[[Hill Chart]] で進捗などを表現する

- 進捗は、具体的な日付などではなく、山として表現する
- 不確実性を下げるというフェーズとあとはやるだけというフェーズに分かれると考えてる
## QA for the edges
- Basecampは今の規模でQAが1人しかいない
- QAはエッジケースを見つけるのを責任にしており、基本的なUXやソフトウェアの品質は開発者やデザイナーがそれぞれ持つ形になっている
> Therefore we think of QA as a level-up, not a gate or a check-point
- いい言葉だ
# 感想
- 全体的に、[[プロダクトマネジメント ビルドトラップを避け顧客に価値を届ける]] とかにあるようなプロジェクト型の体制になっているので全面的に賛成できるかは微妙なところだなあとは思ったが、「要求」の粒度 (Shaping) と6週間以上のバックログを考えない仕組みに関しては学びがあった
- 特にエンジニアとデザイナーがクリエイティブを発揮する必要があるから要件定義を荒すぎず、具体的すぎずというところがかなり参考になった
- 6週間サイクルでの開発はバックログって本当にそんなに長い必要あるんだっけ?ということを改めて考えさせてくれるものがあったのでこの辺は参考にしていきたい
- 基盤開発チーム的なところではこういうマインドでロードマップを作っていってもいいんじゃないかとか思った
- deeetさんの発表でメルカリがこういうマインドセットでリリースサイクルを組んでるという話もあった
- [https://speakerdeck.com/tcnksm/how-we-structure-our-work-at-mercari-microservices-platform-team](https://speakerdeck.com/tcnksm/how-we-structure-our-work-at-mercari-microservices-platform-team)
- [https://deeeet.com/writing/2020/10/07/internal-platform-product-management/](https://deeeet.com/writing/2020/10/07/internal-platform-product-management/)
## 参考
- [https://tune.hatenadiary.jp/entry/2020/08/23/130913](https://tune.hatenadiary.jp/entry/2020/08/23/130913)