Linear - それは魔法のプロダクトマネジメントツール
![Linear - それは魔法のプロダクトマネジメントツール](/content/images/size/w2000/2023/09/OG-IMAGE-ARTICLE3--3-.png)
アジャイル開発やスクラム開発を支援するためのマネジメントツールとして、みなさまはどんなツールをお使いでしょうか。GitHub (GitHub Project)、 Jira、Zenhub、Pivotal などなど... 優れたツールは数多あるなか、Awarefy では Linear (リニア)を導入し、日々の開発タスクにはじまり、採用関連タスク、経営にまつわる Issue などをこのツールで管理しています。
![](https://linear.app/static/og/home.jpg)
Awarefy が Linear を導入したのは 2023年3月のことで、お試しから切り替えの意思決定まで同日のうちに完了しました(当社チームのフットワーク軽くていいなとしみじみ)。
そのときの当社 Slack の様子 ↓
![](https://www.awarefy.dev/content/images/2023/08/image.png)
そんな Awarefy 開発チーム、というか僕の溢れんばかりの Linear 愛を語るべく、当エントリで、Linear の何が優れているのかについて紹介したいと思います。
スクラムではなくサイクル
Linear を "魔法のツール" たらしめるのは、Linear の哲学ともいえる Linear Method にあると思っています。
![](https://linear.app/static/method/methodHero.jpg)
これは(賛同するしないに関わらず)一読の価値のあるテキストなので、是非全文をお読みいただきたいと思います。その中でも特に僕が気に入っているものをいくつかピックアップして紹介します。
スプリントではなく、モメンタムをつくろう
Create momentum – don't sprint
We should find a cadence and routine of working. In cycles, we decide priorities and assign responsibilities. Our goal is to maintain a healthy momentum with our teams, not rush towards the end.
私たちのゴールは健全なモメンタムをチームとともに維持することであり、終わりに向けて急ぐことではない。といったところでしょうか。この哲学から、いわゆるスクラム開発における「スプリント」という言葉が Linear では登場せず、代わりに Cycle(サイクル)という言葉が用いられます。
言葉の "あや" といえばそうなのですが、スプリントというと短距離を走りきるイメージが想起されますが、そうではなく、イテレーションを高速で回すモメンタムのほうが望ましい、という思いが込められているのかなと解釈しています。
また、Generate momentum というテキストにこうも書かれています。
Startups rarely die because they made too much progress or because of a single bad decision, but they do die when they move too slow or give up.
スタートアップが滅びるのは、前進しすぎたからとか、たったひとつの間違った意思決定のせいだとかいうことはほとんどない。動きが遅すぎたり、あきらめるといったことによって滅びるのです。
ユーザーストーリーではなく Issue を書こう
これは賛否が分かれそうということを承知で書きますが、個人的には好きな一説が Write issues not user stories の一説です。
ユーザーストーリーにつじて、前提として「これはいいものだ」と評されることが多いと思うんですが、僕の感覚では抽象表現の具体化のための抽象表現になってしまうことがあり、結局どこかで誰かがタスク、Issue にコンバートしてるんですよね。だったらコンバート後の Issue を最初から書いとけばいいんじゃないかな、、というまさにその感覚が言語化されているようで、非常に共感度が高いです。
At Linear, we don’t write user stories and think they’re an anti-pattern in product development. We write short and simple issues that describe the task in plain language instead.
Linear ではユーザーストーリーはアンチパターンであるとまで言い切っています(僕はそこまでは言っていません)。
User stories evolved over twenty years ago as a way to communicate what a customer wanted into product requirements that a software team could deliver. Fast forward to today and a lot of things have changed about how we build software. Customers are tech-savvy enough to articulate basic product requirements. We’ve developed standards for common features such as shopping carts, todo lists, and notifications so there is no need to explain how they should work. The best product and engineering teams understand their users deeply and are familiar with how their product should work.
超意訳 : ユーザーストーリーは20年以上昔に発明されたものであり、当時に比べユーザーのシステムに対するリテラシーが爆上がりしたため、「ユーザーが達成したいこと」みたいなことを書かなくても「ショッピングカートをつくる」という Issue からその価値は充分に類推される、したがって Issue を明確に書くことでみなの理解は得られるし、それと比べてユーザーストーリーは回りくどい、というような意味になるでしょうか(繰り返しになりますが僕の主張ではないです!同意はしていますが!)。
Linear Method の説明はとても具体的なので、ここで取りあげたもの以外のものも含めて、ぜひ原文全体を読んでみてください。Linear Method の並々ならぬ熱量が伝わるのではないかと思います。
スクラム開発支援ツールとしての Linear
前段で「スクラムではなくサイクル」という部分にフォーカスしたのですが、機能としてはサイクルはスプリントといえますし、サイクル期間(1−2週間のスプリント)の設定や、ポイントによる相対見積もり、カンバン、バーンダウンチャートなどなど、いわゆる「スクラム開発支援ツール」が備えているベースの機能は Linear に大抵備わっています。
Linear Method の哲学としてスクラムやスクラム周辺のプラクティスとは明確に異なる部分を示しながら、スクラムチームが迷い無く導入できるようになっているという柔軟性も Linear の良いところかなと思っています。
Awarefy の採用面談で開発プロセスの話をする際に Linear の話をすることもあるのですが、「まぁだいたいスクラムです」と説明することが多いです。
Linear の各機能については、公式の機能紹介ページをご覧いただくのがよいのではないかと思います。
![](https://cdn.sanity.io/images/ornj730p/production/6c12b048038fdd812469c9c08b0260d035ba6f6a-2638x1525.jpg?q=95&auto=format&dpr=2)
というわけで、現状スクラム開発を行っているチームにもお勧めできるツールなのですが、話のついでのお節介としては、スクラムは令和のプロダクト開発に適用するには課題が多すぎると僕は考えていて、Linear Method だったり、スクラム以外のプラクティスを取り入れることを考えるのもよいのではないだろうか、と考えています。
![](https://assets.st-note.com/production/uploads/images/51341510/rectangle_large_type_2_12cf481e0bc5e3452ce8e0d96d57c172.jpg?fit=bounds&quality=85&width=1280)
Linear の何が "魔法" なのか
Linear はプロダクト / プロジェクトマネジメントツールです。そのなかでも「アジャイル開発 / スクラム開発」のワークフローを意識したつくりになっています。では Linear はスクラム開発支援ツールの one of them なのでしょうか。ユーザー体験という面で、それはまったく違うと言い切れます。
レンダリングの軽やかさ、複数人で操作したときのデータ同期の速さ、といった非機能領域の使用感の高さと、機能についてもミニマルながら痒いところに手が届く、という絶妙な取捨選択の妙がそうさせている、という具体はいくらでもあげられるのですが、それを下支えしているであろう Linear Methodと、フロントエンド実装の技術力(デザイン含む)の高さが垣間見えるという点において、他のツールとはまったく違うポジションに位置していると感じます。頭角を現し始めた頃の Slack や Notion のような、というと伝わるでしょうか。少なくない既存製品があったが、引き込まれる魅力がある。Linear もそのようなプロダクトのひとつなのではないかなと思っています。
繰り返しになりますが、ひとつひとつの機能は、既にあったものだし、既存のツールでも代替は可能であると思います。しかしながら、プロダクトの提供するユーザー体験、開発体験はこれまでのツールとはまったく違う、という仕上がりになっています(伝われ!)。
最近、日本のスタートアップでも Linear の採用事例が増えているように感じますが、もしこの記事で Linear を知ったり、試そうと思っていたけど手が出せていなかった、というかたは今回を機会に是非試していただくとよいのではないかと思います。
現場からは以上です。