immitというChrome拡張を、夫婦二人で作っています。英語のドキュメントやGitHubのissueを読んでいるときに、マウスを乗せるだけで単語が引けて、気になった単語は文ごと保存して、あとで復習できるというものです。デザイナーの私が仕様書を書いて、本業持ちの夫が週末に実装しています。
今回は製品の話ではなくて、その仕様書やらバグ報告やら細かい修正依頼やらを、どこにどう積んで、週末に何から手をつけてもらっているかという運用の話です。Linearを使っていますが、たぶん本来の使い方からはだいぶ外れています。
前提：エンジニアの時間は週末にしか来ない
夫は平日は丸一日、本業の仕事をしています。immitに使えるのは週末だけ。私は平日に動けます。この非対称が、普通のチーム向けの運用をそのまま持ってこられない理由でした。
スプリントって、全員が毎日少しずつ進める前提でできていますよね。週に一度しか手が動かない人に2週間のサイクルを当てても、サイクルの中に実働日が2日しかない。それならサイクルという単位そのものが要らないな、と。うちのLinearは、平日に積んで週末に空にするキューとして使っています。
捨てたもの：サイクル、見積もり、朝会
Linearのサイクル機能は一度も有効にしていません。ポイントの見積もりもやっていません。ステータスも初期設定のBacklog / Todo / In Progress / Done / Canceled / Duplicateのままで、独自の状態は足していません。
残したのは優先度だけです。Urgent / High / Medium / Lowの4段階を、週末に上から順に手をつける順番として使っています。見積もりをしない代わりに、チケットの大きさのほうを揃えておけば、週末に何件くらい進むかは読めます。その話は次の節で。
ツールの機能を使わないのも運用設計のうちだと思っています。二人しかいないのに機能を全部使おうとすると、ツールを整えること自体が仕事になってしまうので。
チケットの大きさは2種類だけ
4月から今までに作ったチケットは130件くらいで、作ったのはほぼ全部私です。見返してみると、大きさがきれいに2つに分かれていました。
- 仕様書型。タイトルの末尾が— Implementation Specで、本文にはMarkdownの仕様書をそのまま貼っています。1枚で週末1回分。時間を指定して復習する機能、メールのリマインダー、文ごと保存する機能あたりは、この形で1枚ずつ渡しました。
- 微修正型。Dark Mode Border Color、Dashboard - Calendar Chevron Displayみたいに、タイトルの頭に画面の名前を書いて、本文は1〜2行とスクリーンショットだけ。iterationというラベルを付けています。平日に自分で製品を使っていて気づいたことを、その場で1件1枚にして積んでおき、週末に夫がまとめて片付けます。
中間の大きさは、意識して作らないようにしています。週末の時間を、大物1つと細かいもの数件で使い切る前提にしているので、どちらにも収まらない中サイズのチケットは週をまたいで持ち越されます。持ち越された時点で文脈が薄れて、だいたい止まります。
平日に積んで、週末に空にする
- 平日：私がチケットを作る。まとめて書かずに、気づいた瞬間に1件ずつ入れる。あとでまとめようとすると、細かいものから忘れていくので。
- 週末：夫が優先度順に消化する。Claude Codeにはチケットの中身をそのまま渡すので、チケットの書き方がそのまま実装指示の質になる。
- 月曜：私が結果を確認する。直っていなければ新しいチケットを作る。直っていればDoneのまま。
これを毎週繰り返しているだけです。
口頭やチャットでの依頼はしません。チケットにないものは存在しない、というのが唯一のルールです。
質問もチケットにする
管理画面の英語の文言を自分で編集できるようにしてほしい、みたいな相談も、記事を書くために夫に聞きたいことも、全部Linearに入れています。
口頭で聞くと、週末の時間を会話で使ってしまうんですよね。チケットにしておけば、夫は週末の最初に返事だけ書いて、残りを実装に使えます。私のほうも、聞きたいことを文章にしている途中で、半分くらいは自分で答えが出ます。
優先度は私が付けて、最終判断は夫に任せる
優先度を付けるのは私です。プロダクトとして先に出したいものは私のほうが見えているので。ただ、その順番どおりに消化されるとは限りません。
技術的には、優先度の低いチケットを先に片付けたほうが筋が通ることがあります。簡単なものから、という意味ではなくて、あるチケットの土台になる変更が別のチケットに含まれている、とかそういう話です。二人で開発時間も限られているなら、順番を守ることより早く回すことのほうが大事だと思っています。
平日に擦り合わせる時間はほとんどありません。あるときは、大まかな方向性と重要なところだけ合わせます。細かいチケットの振り分けや優先度の判断は、どうしても二人の間に少しずつ隙間ができる。そこは担当する側の判断に任せて埋めています。優先度は私の希望、順番は夫の裁量です。
うまくいっていないこと
6月に作った辞書まわりのチケットが、9月や10月まで残った一群があります。大物が週末1回に収まらないと、In Progressのまま何週間も止まる。仕様書を分割すべきだったんですが、分割の仕方を決めるのにも夫の時間が要るので、後回しになりました。これはまだ解決していません。
もうひとつは、私が平日にチケットを作る速さと、週末に消化できる量の差です。積むほうが速いのでBacklogは増える一方。残っていてもいいと割り切ってはいますが、増え続ける一覧を見るとやっぱり気になります。
結び
Linearは本来、もっと大きなチームのためのツールだと思います。でも二人xなら、週末に空になるキューとして使えば十分でした。機能を使い切らないのも運用設計のうちです。
