01 Introduction

原則とプラクティス

原則

目的に向かってスプリントしない。代わりにサイクルという概念を使い、チームの健全なモーメントを維持する。
ロードマップ、プロジェクト、マイルストーンによって長期的、短期的の方向づけをする。
用語を作り出さない。プロジェクトはプロジェクト。

プラクティス

ロードマップを設定する
ロードマップからプロジェクトをつくり、プロジェクトから目標日とサイクルを計画する
1サイクルは n 週間（2週間が一般的）←これはまあアジャイルでもそうか
バックログをすべてとっておく必要はない
個々の issue (後述するが、Linear では user story を書かない) を可能な限り小さくスコープする
Changelog を書く

aximov 2021/02/13に更新

02 Direction

ロードマップがチームの方向性を決める

小さな会議でロードマップを作成する
ロードマップを時間、ゴール、テーマに基づいてマイルストーンに分割する。それぞれ成功の意味が違う。
価値のあるプロジェクトに取り組む。どうしてもやらなければならないプロジェクトはロードマップに組み込んで作業の種類と強度を均す。細々とした issue は1つのプロジェクト（「バグウィーク」など）に束ねて楽しくやる。
インパクトのある（顧客体験を向上する）基幹的プロジェクトを優先する。プロジェクトリードをローテする。ロードマップを10個の中途半端なプロジェクトで終えるより3つの重要なプロジェクトを出荷するほうがいい。
ロードマップを定期的にレビューする。
ロードマップは不可能になることなしに価値あるものであるべき。常に見積もりよりも多く時間がかかるものだし、ロードマップのプロジェクトは少なすぎるよりちょっと多いほうが出荷のモチベーションになるしモーメントを上げられる。
Linear 自身は四半期のはじめにロードマップを2週間くらいかけて作る。プロジェクト単位のリリース日は決めないが、外部調整が必要なローンチやスコープの限定のために期日が必要なこともある。

aximov 2021/02/13

有用なゴールの設定

ゴールは会社の中期的、長期的成功を左右するものを意識させてくれる
測定可能な方法で先へ駆動してくれるゴールを作る

イネイブラーとブロッカーに優先順位を付ける

新機能をイネイブラー、またはブロッカーの除去と解釈する
今やるべきか、後でもいいのかを考慮する

プロジェクトのスコープを限定する

初期はプロジェクトは1-3人チームで1-3週間で完了するサイズにする

aximov 2021/04/21に更新

03 Building

モーメントを生む

多分に心構えのセクション。

何かをやることを考えたり議論したりする代わりに、やるかやらないかを決めてその日のうちに着手する
何をすべきかわからない数週間もあるが、直感を信じて何かをし、フィードバックを得る。素早く動いて学習するようオペレーションを設計しておけば意思決定を修正できる。
スタートアップは進捗しすぎたり意思決定を1回間違って死ぬことはまずないが、ゆっくりすぎたり諦めたりすると死ぬ。

ユーザーストーリーを書かずにタスクを書く

このセクションはかなり独特。ユーザーストーリーがカーゴカルト化しているとし、その目的から手法全体を見直す。

ユーザーストーリーが時代遅れな理由

Linear ではユーザーストーリーを書かない。代わりにタスクを簡潔にわかりやすく説明する issue を書く。Issue はタスクを伝えるために書く、十分なコンテキストと共に。
ユーザーストーリーは顧客の望みを要件に変えるための意思疎通の手法として20年以上前に生まれた。今日では、顧客は十分に技術に精通しているので基本的な要件を説明できるし、最良のプロダクトチームとエンジニアリングチームはユーザーを深く理解している。
ユーザーストーリーはカーゴカルトになっている。回り道であり、タスクを曖昧にする。書くにも読むにも時間がかかる。エンジニアを、プロダクト全体のUXを考える代わりに要件をコーディングする機械的な役割に矮小化してしまう。プロダクトレベルの話をタスクレベルに持ち込むのでスコープが切りづらく複雑になる。普段の会話と馴染まない。

Issue を書くより良い方法

わかりやすく簡潔にシンプルな issue を書いてタスクを説明する。UX をタスクレベルではなくプロダクトレベルで議論する。ユーザーストーリーを作る時間で、代わりにユーザーと話し機能を検討する。
具体的なタスクや issue を説明する。タスクは成果物を伴う。タスクでないものはイシューで記述するのではなく、プロジェクトのアイデアや大きな機能のアイデアである可能性があるのでもっと具体化する必要がある。例外はあり、たとえば機能に取り組む前に設計や技術を検討するときにイシューを作り、あとで分割したり成果物を作ったりできる。
直接的で短いイシュータイトルを付ける。リストやボード上で目にするものなのでスキャンしやすいタイトルにする。説明はオプショナル。ユーザーフィードバックは要約するより引用、リンクしたほうがよい。
チーム全員が自分でよくわかっているイシューを書く。タスクを完了に移したり要件リストにチェックを入れるために作るのではなく、プロダクトやプロジェクトの成果物にフォーカスできる。
チーム全体でプロダクトレベルで顧客体験を議論し、プロジェクトを具体化してロードマップを作成してから仕事をプロジェクトチーム単位に委任する。これによってみながニーズ、制約、要件を深く理解するので、タスクレベルで UX を明らかにしなくて済む。

aximov 2021/02/13

ユーザーと作る

顧客と市場の要求を繰り返し学習する。

創業者はビジョンとフィードバックのバランスを取る。
機能ではなく問題を解決する。ユーザーに機能を求められたら、解決したい問題や望ましい体験を尋ね返す。解く価値のある問題と nice to have の区別がつくし、解決策の幅出しでよりよい解決策が選べる。
正しいユーザーからフィードバックを得る。が、反応しすぎない。ゴールとロードマップによってユーザーのニーズと会社のニーズのバランスを取る。

aximov 2021/02/13

ローンチし続ける

一度の大きなローンチよりも、複数回のローンチのほうが低リスクで、ストーリーとブランド、関心の構築に役立つ。それにプロダクトは最初から万人向けなわけではない。Changelog 同様、市場へのリマインドになる。

aximov 2021/02/13

公に作る

作っているものを見せる。危険に思えるがむしろ競合がスピードに怯むかもしれない。
そのために Changelog を書くとよい。ユーザー数が少ないときに changelog を書くのは馬鹿げていると思うかもしれないが、毎週何が起きたのかを思い出せて、継続的に出荷するやる気が湧く。ユーザーにとってもプロダクトがよくなっているとわかるし、投資家にとっても進捗が見える。スピードが足りないと感じたときに、これまで達成したことを見返すこともできる。

aximov 2021/04/17に更新

所感

Linear は現時点ではスタートアップや小規模の企業を主要なターゲットとしているので、その哲学にエンタープライズなビジネスが主な対象である昔からのアジャイルとの違いがあるのは自然だろう。Linear の考え方が適用できるのは、社内の安定した仕組みを自動化するために決められた予算と納期で堅実に作る開発ではなく、顧客へ価値を届けることとそのための繰り返される学習に重きが置かれる開発である。（これはわかりやすさのための対比であって、実際の開発はスペクトルのどこかに位置する。）

aximov 2023/06/21

2年経って改めて見ると、ユーザーストーリーのくだり以外は素直なカンバンだなという気がします（当時の自分はカンバンを一般的なビューの1種としか思っていなかった）。原文を読み返してみると至って健全なアジャイル指南だなあ…あとデザインスプリントのフレーバーがたまに感じられる。

スコープを交渉する必要のない代わりに継続的適応的に実験、学習しなければいけないプロジェクトやプロダクトではスクラムを採用する必要性は確かに薄く、その場合むしろ1つ1つのチケットのリードタイム、すなわちバックログに載ってから完了されるまでの時間の最適化に焦点を当てれば十分でしょうし、プロセスも比較的軽いと思います。

とはいえ運用してみた経験としてはスクラムで Linear が使えないわけでは全然ないです。歩み寄ってくれています。