Linear.app
https://gyazo.com/5c9699188f99043dbe0b22da6f75e235
ソフトウェア開発にフォーカス当ててる感じ?sta.icon
plan
cycles。スプリントではなくサイクルという期間単位を使っている。アジャイルのスプリントの概念にとらわれず一般化したイメージかな
自動で計算されるってのがポイントみたいだね。たとえば2week 1cycleとした場合、2weekのレンジが順番にポツポツと自動で設定される感じ。俺達は「今回のcycleでは何をしようか」とかを考えるだけでいい(今見えているcyclesだけみればいい)。で、これはデイリータスクリストに放り込まれるルーチンタスク達、という構図と全く一緒
おおーsta.icon
なるほどなぁ、ルーチンタスクの概念をソフトウェアプロジェクト管理ツールに持ってきたかー
projects。プロジェクトという単位でくくれる。要所はマイルストーンにて定義。ドキュメントを書く機能が備わっているのが何気に新しくね?PRDとか勧めてる ドキュメントはmarkdownベースだね
roadmaps。プロジェクトの俯瞰。この概念も新しいな、というかGTD的に上から下までの整合を取ることに力を入れている印象
teams。メンバーをチームという単位でくくれる。プロジェクトにnチームが入ってる、とかもできる。有料プランでprivate team用意するのは上手いな。
backlog。automatedと冠されている。一定期間更新されてなかったのを自動で閉じるとかできるらしい。auto closingとauto archivingと書いてる
progress
git integrations。github、gitlabのPRやMRの連携もサポート。ステータスも自動で更新してくれるよ。まあシームレスに連携、つか同期してくれるってことよな
notification inbox。要は自分のinboxだが、キーボードショートカットでザクザクできるのが特徴らしい。「あとでスヌーズ」という形でガンガンスキップできるのもいいね。チームレベルでアラート出す、とかもできる
名前がカッケー。この名前で俺もPFしたいくらいだぜ……sta.icon
filters and views。まあ観点が色々ある感じ。ビューとしてはリストとボード
labels。k8sやAWSのTagsのようなラベルの使い方。ガンガン貼ろうぜ
powerfull search。ワークスペース全体を全文検索できる感じ(コードじゃなくてissuesなどこのプロジェクト管理系の情報から探すって意味)
collaborate
project updates。プロジェクトにはRSSみたいに更新通知する、購読できる的な概念がある
triage。他チームがぶっこんできたissuesに対して俺達が行う初手の分類。
Linear's Triage view showing the actions "Accept", "Merge", "Decline", and "Snooze".
おお、ここでも「スヌーズ」があるねsta.icon*2
「また後で教えて」 ← この概念よな
Zendeskとかと統合もできるみたい
discussions。どう提供されてるかは読み取れなかったが、issuesと同じ機能でコンテキストの共有もできるよって話。まあGitHub Discussionsと同じ感じ、なのかな? slack sync。slackスレッドとlinearを同期。slackから/linearでissue切ったりとかもできる
figma integrations。興味ないからいいや
support workflows。zendeskみたいなサポートツールとの連携って話
analyze
linear insights。状況ビジュアライザ。かなり力入れてるみたいで別ページあるな
data export。csv。
level up
リアルタイム同期頑張ってるみたいだね
keyboard first design。たしかに強調してはりましたね
integration。これも色々ありましたね。特にzendeskなどサポート系も対応してるのが便利そうやわ
sta.icon
以下2つかなぁ。
Cycles。スプリントの概念を一般化して、ルーチンタスクの定期性の便宜も合流させたのは面白い。アジャイルのスプリントの概念によく抗いましたね。
Snooze。「あとでまた教えて」。ありそうでなかった。俺も注目してたけど、もう組み込まれてるとはなぁ
linearがどういう選択肢用意してるかは気になるsta.icon*2
miyamonz.iconの琴線に触れたのなら面白さはあると言えるだろう、俺もあとで読んでみるか
Principles & Practices
creator(実際に開発する開発者)にとっての使いやすさが重要。管理者ではなくて
+1
opinionatedである必要がある
+1
いわゆる「やり方の是非よりも皆のやり方が揃っていることの方が重要だ」的なやつsta.icon
柔軟に何でも使えるソフトウェアだと各自が好き勝手するのでカオスになる
momentum(勢い)が大事
スプリントという期間を守ることではなく、俺達のリズムを理解してそれに則っていこうって話だよねsta.icon
Cyclesの概念、まだあまり理解できてない……sta.icon
いわんとしていることはわかる。個人のタスク管理で育成していくものの一つだからな
用語つくるな
projectはprojectと言え、混乱するだろ、とのこと
文脈よーわからんけど俺はちゃんと定義すれば別にいいとは思う
ただ誰かが定義した用語を受け付ける・受け付けないがあるからなーsta.icon
これは俺も他人事ではない。俺も他人がつくったセンスない用語でうげーってなるし、逆に皆も俺の用語に(無能ゆえに)ついてこれないかもしれない。
忙しい仕事は断るか、自動化しろ
Decide and move on
答えなくてもいいからいったん決めて動こうぜって話
意外と難しいやつ
だからといって納得感無い決め方されてもうざいから、納得いくように皆で議論して決めてこうぜが必要
そのためにいちいち集まってあーだこーだは非現実的だから非同期が要る
Linearではプロジェクトドキュメントとかで担保するんだよね?sta.icon
---
ロードマップを設定しろ
年間、クォーター、月単位にブレイクしてくって話
GTDも一緒sta.icon
Connect daily work to larger goals with projects
プロジェクトという単位を使って紐付けろって話
roadmap
project ★このレイヤー
daily work
PARAメソッドだけど、
要は「目標」と「アクション」の間に「プロジェクト」と呼ばれる単位がある
Work in n-week cycles
サイクルの話
サイクルに入る分だけやる。入らないものは自動的に次へ回す
サイクルは2weekは一般的らしい
ブレない程度に短く、本質的な機能をつくれる程度に長い
管理可能なバックログを維持する
Scrapboxの思想でもあるけど、重要なものは浮いてくるしそうじゃないものは沈む
沈む側も全部等価に扱って管理コスト肥大化してぐえーになるなということsta.icon
Mix feature and quality work
何言ってるかわからんsta.icon
実際は直接明示されてるタスク「以外」の手間も意外とかかるよ的な話?
すべてのソフトウェアには私達が認識している以上のバグがあります、という言い方
要はリファクタリングやリーダブルコードといったことを行う余裕も担保しようねってこと?
Invest
直訳すると「投資」
技術的負債を減らすための活動枠、みたいな概念かしら?sta.icon
Specify project and issue owners
他の人は協力する必要がありますが、責任は 1 人の人間が負うべきです。
+1sta.icon*4
Write project specs
ここではチームの方向性を揃えようってニュアンス
簡潔さを目指します。 短いスペックは読まれる可能性が高くなります。 仕様の目的は、プロジェクトの「なぜ」、「何を」、「どのように」をチームの他のメンバーに簡潔に伝えることです。 理想的には、これらの短いドキュメントにより、チームは作業の範囲を絞り込むことができるため、優先順位が明確になり、チームが間違ったものを構築することがなくなります。
で、方向性を揃えるだけなら簡潔に書ける可能性は高い
Understand your users
ユーザーからのフィードバックで受信箱がいっぱいだよぉぉは良い兆候
傾向を見つけてみてください。 ユーザーのことを知り、特定の機能が必要な理由を説明してもらう機会として、苦情も含めたフィードバックを利用して、ユーザーのニーズを把握します。 機能を構築するだけではなく、問題を解決します。
まずバカ真面目にユーザーの意見一つ一つを取り上げるというよりは本質を掬い上げるということ
Scope issues to be as small as possible
でかい問題もブレイクダウンしてこまめに進捗出せてるように見えた方が精神衛生が良いって話
TODOリストが一つずつ潰れていって 3/13 → 4/13 みたいに見えたら楽だよねって話
これが「でかいタスク 1」だと 0/1 なので精神的にきつい
Measure progress with actual work
字面上はリーンみたいに定量で計測するってことかなと思いがちだけど、違いそう
何かが完了したかどうかを確認する最も明確な方法は、コードまたは設計ファイルの差分を表示することです。 タスクの範囲が小さい場合、変更も小さくなり、レビューも容易になります。 大規模なプル リクエストや大規模な設計変更は避けてください。
要は「小さく変更していけ」ということだなsta.icon
一気に1000行変更して13のタスクを解決するコミットするんじゃなくて、数十行で1タスクを終わらせるコミットを重ねていけという話
(もちろんシチュによっては数タスクくらいは一気にやった方がいいこともあるけど、あくまで説明として)
部門を超えたチームを運営する
ここではデザイナーとエンジニアが同じ場所で協調しないとねって話
+1
Linear.appにはそれができるのだと思う
GitHubだと正直キツイよね
デザイナー側(非エンジニア側)が相当勉強して追いついてこないといけない
デザイナーは生産性とツールを気にする生き物側だからまだマシだけど、ビジネス職になるとさらについてこれなくなる
だから後者でも使える、でも前者も削がないような塩梅のツールが必要で、Linearはそこを実現しているんだよね?sta.icon
Write a changelog
リリースノート書くって話?
投資家向け広報や人材募集もできるというレベルみたいsta.icon
毎週以上のペースで出す
アーリーアダプター達も読んでいる。それ見て盛り上がってる
ここに投資家や応募者も混ざるのよなsta.icon
Remember to write about things that are interesting to a human. Don’t include everything you do.
ですよね。読まれるものを書け。言語化下手なエンジニアまたは早口興奮オタクみたいに全部書くみたいなアホなマネはやめい、と
可能であれば、機能のスクリーンショットまたはビデオを 1 つ以上含めてください。
大事……
ツールは重要ではありません。重要なのは、変更ログを書くことです。 プレーンテキストで書いたり、Github に置いたり、Notion を使用したり、ブログを使用したり、Twitter でスクリーンショットを共有したりできます。 マークダウンで記述し、next.js ベースのマーケティング Web サイトでレンダリングします。
+1sta.icon*2
ここがわからず必要以上に形式を重視するアホがなんとおおいことか
投資家向けなんだからちゃんと公式文書でPDFで提出しなきゃ~とか
おー、面白えsta.icon*2
これ、革新会計を実現する一要素じゃね?ポテンシャルを感じる あ、一つ思いついたわ
---
2と3はいったんパス。
読後感想
うん、俺の感性は鈍っていない
やっぱり俺、強いわ
概念や原理を大事する海外なら見出してもらえるか?
改めて自信に繋がったsta.icon
リリースノートの話が一番面白かった
サイクルだけはまだイメージが湧いてない
使ってみないとわからんだろうね
まあ気が向いたらsta.icon