注意：このコンテンツは自動翻訳されたものです。 フィードバックを送る

Linear、Codex、Claude Code、GitHubでグロース実験をリリースする方法

2 分で読了

ai, agents, linear, growth, productivity

プロジェクトの仕組みとしてLinearを、実行レイヤーとしてコーディングエージェントを、そしてレビューとリリースの場としてGitHubを使う。グロース実験を回すための、私の実践的なワークフロー。

グロース実験はたいてい、良いアイデアときれいな引き継ぎのあいだの隙間で死ぬ。

アイデアは鋭く始まる。オンボーディングの質問を変える、ランディングページの新しい約束を試す、ライフサイクルのナッジを足す、デモのフローを引き締める。それがドキュメントにコピーされ、Slackで要約され、タスクに変換され、デザイン・データ・エンジニアリング・マーケティングに分割され、そして少しずつ形を失っていく。実験がリリースされる頃には、もとの仮説が何だったのかを完全に覚えている人は誰もいない。

ここで私はLinear、Codex、Claude Code、GitHubを組み合わせて使う。

Linearはエージェントが作業をする場所ではない。作業が整理されたままでいる場所だ。私はこれをタスクとプロジェクトの管理に使う。受け入れ、スコープ、オーナーシップ、依存関係、受け入れ基準、そしてステータスだ。

実行はエージェントが担う。CodexとClaude Codeが、コードを書き、レビューし、テストし、変更を準備するのを助ける。GitHubは、その変更が具体的になる場所だ。branch、pull request、CI、レビュー、そしてマージの履歴。

ポイントは「Linearのエージェントが実験を回す」ことではない。ポイントは、エージェントがGitHubを通じて実装を進めるあいだ、Linearが実験を読み解けるままに保つ、ということだ。

ループ

私のワークフローには6つのステージがある。

  1. 受け入れ
  2. 実験ブリーフ
  3. タスクグラフ
  4. 計測の仕込み
  5. ローンチQA
  6. ポストモーテム

Linearの仕事は、意思決定そのものをすることではない。推論を可視化し、欠けているピースをあぶり出し、すべての成果物を同じ仮説につなぎとめておくことだ。コーディングエージェントは、ばらばらのプロンプトからではなく、その構造から作業する。

ステージ1: 受け入れ

ループは、たった一つのLinear issueから始まる。

スクリーナーの前に「睡眠の目標」を尋ねる質問を追加すると、完了率が上がるかどうかを検証する。

弱い仕組みは、これをタスクに変えて文脈を失う。

役に立つLinear issueは、これを問いに変える。

  • これはどのセグメント向けか?
  • 成功を定義する指標は何か?
  • これはコンバージョンのテストか、クオリフィケーションのテストか、それとも学習のテストか?
  • 検出可能な最小の効果はどれくらいか?
  • 悪化しうる下流の指標は何か?
  • コピー、イベントトラッキング、ローンチを承認する必要があるのは誰か?

最初のアウトプットはタスクリストではない。より鋭くなった問題設定だ。

Hypothesis:
If we ask users to choose their sleep goal before the screener, completion rate will increase because the flow starts with user motivation instead of clinical qualification.

Primary metric:
Screener completion rate

Guardrail:
Qualified lead rate should not decrease by more than 5%

Decision rule:
Ship if completion improves by 10%+ and guardrail holds.

これだけで、作業の質が変わる。チームはボタンやフィールドについて議論しているのではない。メカニズムについて議論しているのだ。

ステージ2: 実験ブリーフ

私はLinearの中にブリーフを作り、もとのissueにリンクする。

ブリーフは退屈に保つ。

  • コンテキスト
  • 仮説
  • オーディエンス
  • 主要指標
  • ガードレール指標
  • 必要なイベント
  • バリアント
  • オーナー
  • レビュアー
  • ローンチのチェックリスト
  • 意思決定ルール

退屈でいい。退屈とは、再利用できるということだ。

コツは、ブリーフが生きたままでいることだ。バリアントが変わったら、そのトレードオフをissueに可視化してほしい。変わったのは仮説なのか、それとも実装だけなのか。指標が追加されたなら、それは主要指標なのか、ガードレールなのか。コピーが変わったなら、そのメッセージはまだメカニズムに対応しているのか。

ブリーフは実験の背骨になる。

ステージ3: タスクグラフ

たいていの実験トラッキングが破綻するのは、作業がフラットなチェックリストとして表現されているからだ。

実験はフラットではない。依存関係のグラフだ。

このテストでは、こんなふうにリンクしたissueを作る。

  • バリアントのコピーを書く
  • オンボーディングのステップをデザインする
  • フロントエンドのバリアントを実装する
  • アナリティクスのイベントを追加する
  • Statsigで実験を設定する
  • イベント発火をQAする
  • ローンチノートのドラフトを書く
  • 最初の24時間をモニタリングする
  • サンプルのしきい値到達後にリードアウトする

各issueは、それが依存するブリーフの一部を持ち運ぶ。

アナリティクスのissueはイベント名を持つ。デザインのissueはオーディエンスと仮説を持つ。QAのissueはガードレール指標を持つ。リードアウトのissueは意思決定ルールを持つ。

これが、プロジェクト管理とワークフローの記憶の違いだ。

Linear issues grouped by status, showing the task graph for a growth experiment project.

Codex、Claude Code、GitHubはどこにはまるのか

Linearはプロジェクトの仕組みだ。Codex、Claude Code、GitHubは、その周りを回る実行ループだ。

私はLinearで作業を定義する。仮説、受け入れ基準、依存関係、イベント計画、QAチェックリスト、意思決定ルール。それによって、コーディングエージェントは曖昧なプロンプトの代わりに、安定した対象に向かって作業できる。

Linear project overview with properties, milestones, and project context attached to the work.

Codexは、実装のレーンを走らせる場所だ。より大きな実験では、タスクグラフを狭いLinear issueに分割し、各レーンをそれぞれのbranchやworktreeで動かす。あるレーンはフロントエンドのバリアントを配線する。別のレーンはイベントトラッキングを足す。また別のレーンはコピー、テスト、ドキュメントを引き締める。大事なのは、各レーンが同じLinear issueの構造に報告を返すことだ。何が変わったか、何が検証されたか、何がブロックされているか、どんな証拠があるか。

Claude Codeは、ターミナルにもう一つのコーディングの面が欲しいときに役立つ。実装の形をレビューする、リポジトリを探索する、マイグレーション計画のドラフトを書く、あるいはコードがまだ実験ブリーフに合っているかをプレッシャーテストする。これを別の真実の源とは扱わない。同じLinear issueに向けられた、もう一つの実行の面だ。

GitHubは、作業がレビュー可能でリリース可能になる場所だ。pull requestが、コードのdiff、CIのステータス、スクリーンショット、実装の議論を束ねる。Linearは「なぜ」を保つ。GitHubは「正確な変更」を保つ。PRがLinear issueにリンクを返し、検証の証拠がLinearに戻ってくるとき、このループは機能する。

ワークフローはこんな形になる。

Linear issue -> Codex / Claude Code implementation -> GitHub PR -> review + CI -> Linear readout

これが、システムを長持ちさせる部分だ。LinearはGitHubを置き換えない。GitHubはLinearを置き換えない。CodexとClaude Codeは判断を置き換えない。それぞれのツールが、ループの別々の部分を担う。

ステージ4: 計測の仕込み

計測の仕込みは、良い実験が静かに失敗する場所だ。

Linear issueは、実装の前にイベント計画を持ち運ぶ。

Events:
- sleep_goal_step_viewed
- sleep_goal_selected
- screener_started
- screener_completed
- lead_qualified

Properties:
- variant_id
- sleep_goal
- traffic_source
- device_type
- market

そうすれば、すべての実装タスクを計画と突き合わせてチェックできる。

  • そのイベントは追加されたか?
  • 命名は一貫しているか?
  • 発火の時点でプロパティは利用可能か?
  • アナリストはバリアント、市場、デバイスでセグメント分けできるか?
  • dashboardは意思決定ルールと一致しているか?

これは華やかではない。だが、実験が知識を生むのか、それともただの活動に終わるのかを決める、まさにその種のディテールだ。

ステージ5: ローンチQA

ローンチの前、私はプロダクト全般ではなく、その実験に固有のQAチェックリストを用意する。

このテストの場合はこうだ。

  • バリアントがモバイルとデスクトップでレンダリングされる
  • 目標の選択がスクリーナーを通じて保持される
  • 既存のスクリーナーの経路がまだ機能する
  • イベントが正しい順序で発火する
  • Statsigのバケッティングが安定している
  • dashboardに主要指標とガードレール指標がある
  • ロールバックのオーナーが割り当てられている
  • ユーザーが新しいステップについて尋ねてきたときのサポートノートが用意されている

ローンチの意思決定は、作業と同じ場所で起きる。ミーティングのメモの中ではない。あとで見つけるのが不可能になるSlackのスレッドの中でもない。

Linearが、実験の状態にとっての真実の源になる。

ステージ6: ポストモーテム

ポストモーテムは、ループ全体が最も役に立つ場所だ。

たいていのチームは、リードアウトを使い捨てのサマリーとして書く。

バリアントBは完了率を8%改善したが、統計的に有意ではない。ローンチしない。

これでは足りない。

役に立つポストモーテムは、こう答える。

  • 私たちは何を信じていたか?
  • 何が起きたか?
  • ユーザーへの理解はどう変わったか?
  • 次に何を試すべきか?
  • その結論を裏づけるissue、ドキュメント、イベント、スクリーンショット、dashboardはどれか?

アウトプットは再利用できる記憶になる。

Learning:
Motivation-first onboarding increased early engagement but did not improve qualified completions. Users selected goals, but the added step created drop-off before clinical questions.

Next test:
Move goal selection after screener completion and use it to personalize follow-up copy.

その学びは、スライドの中に消えていかない。次のバックログ項目にリンクされる。

このスタックが得意なこと

このスタックの最良の使い方は、「私の仕事をやる」ことではない。

こういうことだ。

  • 文脈をタスクに紐づけておく
  • 曖昧なアイデアを構造化されたブリーフに変える
  • 欠けている計測を特定する
  • 正しい依存関係グラフを作る
  • 意思決定ルールを保存する
  • ポストモーテムを再利用可能にする
  • 次の実験を、前回の学びとつなぎとめる
  • エージェントに、明確なissueに対してコードを書き、レビューし、検証させる
  • GitHubに、正確なdiff、レビュー、CI、マージの履歴を担わせる

だからこそ、AIネイティブなプロダクト開発のワークフローにおいてLinearは面白い。それはすでに、作業が交渉される場所に座っている。issueは、プロダクト、エンジニアリング、デザイン、サポート、セールス、マーケティングのすべてが同じ対象に触れる場所だ。

CodexとClaude Codeがその対象から作業すれば、コードを生成する以上のことができる。実装を、その作業が存在する理由に沿わせつづける手助けができる。

より大きな要点

グロースチームに必要なのは、より多くの実験アイデアではない。より良い実験の記憶だ。

必要なのは、仮説、タスク、イベント、QA、意思決定、そして学びが、アイデアからリリースされた作業までの旅を生き延びることだ。

それが、私がLinear、コーディングエージェント、GitHubを使って回しているループだ。

より速いチェックリストではない。

チームがどう学ぶかについての、より良い記憶だ。