はじめに
近年、スタートアップからメガベンチャーまで多くの開発チームで導入が進んでいるプロジェクト管理ツール「Linear」。その UI の美しさや圧倒的な動作速度はよく語られますが、実はその背後には「 Linear Method 」と呼ばれる確固たる開発哲学が存在します。
今回は、単なるツールの使い方ではなく、現代のソフトウェア開発が失いかけている「勢い」や「作る喜び」を取り戻すためのマニフェストとも言えるこのドキュメントについて、プロダクトエンジニアの視点で解説と考察を行います。
1. 著者はどんな人物か
Linear Method の背後にいる中心人物は、Linear の共同創業者兼 CEO である Karri Saarinen（カリ・サーリネン） 氏です。
経歴のハイライト
- Airbnb (Principal Designer): Airbnb のデザインシステムの構築をリード。
- Coinbase (Head of Design): デザイン部門のトップとして、使いやすいクリプト体験を設計。
- Y Combinator: 自身のスタートアップで YC を通過した経験を持つ（エンジニアリング背景もあり）。
現在の活動
現在は Linear の CEO としてプロダクトの指揮を執っていますが、経営者であると同時に、細部のインタラクションや CSS の書き方にまでこだわる「作り手」であり続けています。
評価される理由
彼がプロダクトエンジニアやデザイナーから支持される理由は、「 デザインとエンジニアリングの境界線を溶かしている 」点にあります。彼は「美しいが実装不可能なデザイン」も「機能するが使いにくいシステム」も許容しません。
彼の実績は、「クラフトマンシップ（職人気質）」と「ビジネスのスピード」はトレードオフではなく、両立可能であることを証明し続けている点にあります。
2. なぜこのブログ（Linear Method）が執筆されたのか
なぜ Linear は、単なるヘルプページではなく、このような思想体系を公開したのでしょうか。その背景には、「8現代のアジャイル開発へのアンチテーゼ*」があると考えられます。
かつて開発プロセスを軽量化するために生まれた「アジャイル」や「スクラム」は、多くの現場で形骸化しました。
- 目的を忘れて「ベロシティ（速度）」を競うだけのスプリント
- エンジニアを「チケット消化マシーン」に変えるマイクロマネジメント
- 「ユーザーとして、私は〜したい」という、誰も読まない形式的なユーザーストーリー
著者は、こうした「仕事のための仕事（Work about work）」が、クリエイターから情熱と勢いを奪っているという危機感を持っていたはずです。
Linear というツールは、「本来あるべきソフトウェア開発の姿」を体現するために作られました。つまり、このLinear Methodはツールの説明書ではなく、「 失われた生産性と創造性を取り戻すための思想的ガイドライン 」として執筆されたのです。
3. 記事の要点解説と考察
プロダクトエンジニアの視点で、特に重要だと感じるポイントを 3 つに絞って解説します。
① 「スプリント」ではなく「モメンタム（勢い）」を作る
「目標は、チームと共に健全な『勢い』を維持することであり、終わりに向かってただ突っ走ること（スプリント）ではありません。」
【解説】
多くの現場では「スプリントの消化率」や「バーンダウンチャートの美しさ」が目的化しています。しかし Linear Method では、未完了タスクが次のサイクルに持ち越されることを「普通のこと」として許容します。重要なのは管理上の数字ではなく、チームがリズムに乗って価値を出し続けているかという「勢い」です。
【考察】
エンジニアとして、「見積もり通りに終わらせること」に精神をすり減らした経験はないでしょうか？ Linear Method は、見積もりはあくまで予測であり、現実は変わるものだという前提に立っています。これにより、エンジニアは「期日を守るためのハック（質の低いコード）」ではなく、「ユーザーへの価値提供」に集中できるようになります。
② 「ユーザーストーリー」の廃止と、エンジニアの自律
「ユーザーストーリーは、気分は良いものの多くのリソースと時間を無駄にする『カーゴ・カルト（形式だけの模倣）』的な儀式となってしまいました。」
【解説】
Linear Method では、「ユーザーとしてログインしたい」といった冗長な記述を禁止し、シンプルに「ログイン画面の実装」と書くことを推奨しています。そして何より重要なのが、「 自分の Issue（タスク）は自分で書く 」という原則です。
【考察】
これはプロダクトエンジニアにとって非常に重要なメッセージです。「PM が書いた仕様通りにコードを書く」という下請け的なマインドセットを否定しています。
エンジニア自身がプロダクトの文脈を理解していれば、細かな指示書は不要です。「仕様を決めてから作る」のではなく、「作りながら最適な解を模索する」権限と責任をエンジニアに返還しようとしています。
③ デザインと開発の「ハンドオーバー（引き渡し）」をなくす
「デザイナーとエンジニアはプロジェクトで協力し合い、自然な『押し引き』を生み出すべきです。」
【解説】
ウォーターフォール的に「デザイン完了 → 開発開始」とするのではなく、プロジェクト初期の「Explore（探求）」フェーズからエンジニアが関与することを推奨しています。
【考察】
「Figma 通りの実装が技術的に難しい」「実装してみたら触り心地が悪かった」という手戻りは日常茶飯事です。Linear Method のアプローチは、デザイナーとエンジニアが 同じチームの「共同制作者」 として振る舞うことを求めます。これにより、技術的な制約を早期にデザインに反映させたり、逆にエンジニア発案の UI 改善を取り入れたりする「健全な衝突」が生まれます。
さいごに
『Linear Method』は、単なるプロジェクト管理の手法にとどまらず、「 信頼に基づいた自律的なチーム作り 」の提案です。
ここには、「エンジニアを管理しなければサボるリソース」として扱う視点は一切ありません。代わりに、「目的さえ共有されれば、クリエイターは自ら最善の道を選び取れる」という強い性善説と信頼があります。
私たちプロダクトエンジニアにとって、このメソッドは一つの指針になります。
「チケットを消化すること」に満足せず、プロダクトの「方向性」を理解し、自らタスクを定義し、デザイナーと膝を突き合わせて「本当に良いもの」を作る。
ツールとしての Linear を使うかどうかに関わらず、この「作り手（Creators）ファースト」のマインドセットこそが、今の私たちに必要なのかもしれません。