TL;DR

Linearが「task」でも「story」でもなく「issue」を選んだのは偶然ではない。GitHub Issue Trackerに代表されるソフトウェア開発文化への接続、「task」より広い意味範囲の確保、そしてアジャイル用語への明確な距離感という3つの設計判断が背景にある。さらにLinearは「ユーザーストーリーはカーゴ・カルトだ」と断じ、WhyはProject Documentに、WhatはIssueにという関心の分離を提唱している。

「issue」という用語の選択

Linearを使い始めたとき、多くの人が抱く素朴な疑問がある。なぜ「task」ではなく「issue」なのか。Jiraなら「ticket」や「story」、Asanaなら「task」と呼ぶ。Linearの選択には3つの意図が読み取れる。

1. ソフトウェア開発文化への接続

「issue」はGitHub Issues以来、ソフトウェア開発者にとって最も馴染み深い用語の一つだ。Linearはエンジニア向けのツールとして設計されており、ターゲットユーザーの語彙にそのまま乗っかる形になっている。

2. 「task」より意味が広い

「task」は「やるべき作業」という狭い意味だが、「issue」はバグ報告、機能要望、改善提案、調査事項など解決すべきあらゆる種類の事柄を包含できる。Linearの公式ドキュメントでもissueは「平易な言葉で記述されたタスク」と定義されており、タスクはissueの一形態という位置づけだ。

3. アジャイル用語を意図的に避けている

これが最も興味深い点で、Linearは従来のアジャイル用語（ユーザーストーリー、エピックなど）を意図的に使わないという思想を持っている。あるレビュー記事では、Linearがドキュメント内で「agile」という言葉すら一切使っていないことが指摘されている。

ユーザーストーリーは「カーゴ・カルト」である

Linearの思想で最も挑発的なのは、公式の「Write issues, not user stories」というページだ。ここでLinearはユーザーストーリーを明確にアンチパターンだと位置づけている。その論拠を整理する。

時代遅れになった。 ユーザーストーリーは20年以上前、顧客の要望をソフトウェアチームが理解できる要件に翻訳する手段として生まれた。しかし今日では顧客自身がテクノロジーに精通しており、ショッピングカートや通知といった一般的な機能にはすでに標準パターンが確立されている。わざわざ「As a user, I want to…」と書く必要がなくなったというのがLinearの認識だ。

カーゴ・カルト的な儀式になっている。 「カーゴ・カルト」とは、第二次大戦後のメラネシアで、物資を運んできた飛行機を再び呼び戻そうと現地の人々が木で滑走路や管制塔を模造した逸話に由来する。形式だけ真似ても本質的な効果は得られない、という意味の比喩だ。Linearは、ユーザーストーリーがまさにこの状態—「As a user, I want to…」というフォーマットで書くこと自体が目的化し、「ユーザーを理解する」という本来の目的から乖離している—だと主張している。

エンジニアの思考を矮小化する。 タスクを遠回しに記述することで実際にやるべき作業を曖昧にし、エンジニアを「要件通りにコードを書くだけ」の機械的な役割に閉じ込めてしまう。プロダクトレベルでUXを総合的に考える機会を奪うという批判だ。

Linearの回答：関心の分離

ではユーザーストーリーが担っていた「なぜ作るのか」という文脈共有の役割はどこに行くのか。Linearの答えはシンプルで、WhyとWhatを書く場所を明確に分けるというものだ。

層	書く場所	内容
Why（なぜ作るのか）	Project Document	仕様書、PRD、ユーザーリサーチ、背景
What（何をやるか）	Issue	具体的な作業タスク

Project DocumentsではMarkdown、共同編集、インラインコメントに対応しており、Linear公式も「プロジェクトリードが仕様書を書き、他のメンバーがブリーフに協力した上で、作業を分担してそれぞれ自分のissueを書く」というワークフローを紹介している。

flowchart LR
    A[Project Document<br/>Why: 背景・仕様・PRD] --> B[Issue A<br/>What: 具体的作業]
    A --> C[Issue B<br/>What: 具体的作業]
    A --> D[Issue C<br/>What: 具体的作業]

ユーザーストーリー方式では個々のタスクに背景を毎回埋め込む。Linearのアプローチは「Why」を一箇所に集約し、個々のissueでは繰り返さない。チーム全員がユーザーニーズや要件を深く理解した状態で作業に入るため、タスクレベルでいちいち明記する必要がないという前提に立っている。

批判とその限界

この思想への批判もある。あるMedium記事では、Linear自身の「ピンタブ」機能の実装品質を例に挙げ、ユーザーストーリーを排除した結果「Why」が失われ、目的が不明確なまま開発が進んでしまうリスクを指摘している。

ただ、この批判にはいくつか弱い点がある。

Project Documentの存在に一切言及していない。 著者はLinearのユーザーのようだが、「仕様書やPRDをProject Documentに書き、そこで機能の目的を定義してからissueに分解する」というLinear公式のワークフローについて触れていない。

issueだけ見て批判している。 「タスクしかなかった」ことを問題視しているが、Linear Methodではそのタスクの上位にあるProject Documentに背景が書かれるべきものだ。もしProject Documentにも背景がなかったのだとすれば、それはLinear Methodの問題ではなく、そのチームの運用の問題だ。

ユーザーストーリーでも同じことは起きうる。 「As a user, I want to pin tabs so that I can quickly access them」と書いたとしても、具体的な挙動の議論が不足すれば同じ結果になる。

Jobs To Be Doneとの相性

興味深いことに、前述のMedium記事の著者は最後に「ユーザーストーリーすら古い、Jobs To Be Done（JTBD）の方がモダンだ」と書いている。JTBDとは「人はプロダクトを買うのではなく、自分の”ジョブ（用事）“を片付けるためにプロダクトを”雇う”」という考え方で、クリステンセン教授のミルクシェイクの事例が有名だ。

しかし皮肉なことに、JTBDはタスクレベルではなくプロダクト戦略レベルで使うフレームワークだ。つまりLinear Methodの「WhyはProject Documentで議論し、issueはシンプルに」という思想と実はかなり相性が良い。JTBDで顧客の「ジョブ」を深く理解し、その成果をProject Documentに落とし込み、そこからissueに分解する—この流れはLinearの設計思想そのものだと言える。

まとめ

Linearが「issue」を選んだのは、単なる用語の好みではない。ソフトウェア開発文化への接続、意味範囲の広さ、アジャイルの形式主義からの距離という3つの意図が込められている。そして「ユーザーストーリーはカーゴ・カルトだ」という挑発的な主張の裏には、「WhyとWhatを書く場所を分けよ」という実践的な設計思想がある。

個人的には、ユーザーストーリーを全否定する必要はないと思うが、形式が目的化していないかを問い直す視点は有用だと感じる。「As a user, I want to…」と書くことで思考停止していないか。本当にユーザーを理解するための営みになっているか。LinearのProject Document + Issueという関心の分離は、その問いに対する一つの明快な回答だ。

以上。