ブログに戻る
·
EN/中文/日本語

Linear代替ツール：マーケや非エンジニアのチームに「自分はエンジニアです」と振る舞わせるのをやめる

この春のユーザーインタビューで、想定していなかった話題がくり返し出てきました。SaaS企業（14名）のマーケティング責任者の方が、少し決まり悪そうにこう話してくれました——「非エンジニア向けに無理がないLinear代替ツールを探しているんです。社内全体がエンジニアチームのLinearに移行してから、私の仕事はぜんぶissue化させられていて、estimateフィールドの埋め草に意味のないstory pointを入れています」。同じ月に、似た話を聞いたのは3人目でした。

公平に見て、Linearは本当に良いプロダクトです。2025年6月にARR 1億ドルを突破し、評価額12.5億ドルでシリーズC 8,200万ドルを調達、顧客数は15,000社超、ARRは年200%以上の成長を続けています（TechCrunch, 2025年6月）。この10年でエンジニアチームに最も愛されたissue trackerと言ってよい存在です。ただ、2026年の急成長のかなりの部分は「エンジニアの同僚に引っ張られて非エンジニアチームも入ってくる」という形で起きていて、そこに歪みが出始めています。

Linearが本来想定しているもの

Linearは強い意見を持ったプロダクトで、それが長所です。意見をざっくり言うと、こうなります——「ソフトウェアはissueを積み上げ、それを1〜2週間の作業ウィンドウであるcycleに並べ、新しい依頼はチームへ配る前にtriageで受け止め、規律を持ってリリースする」。キーボードショートカット、レスポンスの速いUI、整った視覚階層は、すべてこの意見に奉仕しています。

エンジニアチームにとっては、このモデルは仕事の形と一致しています。issueはコード変更1単位、cycleはスプリント、triageは外から飛んでくる不具合や機能要望のインボックス、estimation pointは「ざっくりどれくらい」の規模感。仕事＝ソフトウェア出荷であるかぎり、Linearの基本要素は1つ残らず元を取ってくれます。

問題は、その同じ基本要素が「ソフトウェアではない仕事」とは噛み合わないことです。マーケのキャンペーン企画書はissueではありません。デザインレビューはtriageイベントではありません。マーケティング施策の週次振り返りはcycle retrospectiveではありません。それらを無理にコンテナへ押し込むと、症状が静かに積み重なり、非エンジニアチームは「仕事をすること」より「仕事をLinearの形に翻訳すること」に多くの時間を使うようになります。

マーケ・デザインの方が見れば一発でわかる症状

非エンジニアのLinearユーザーに十分な数だけ話を聞くと、ほぼ同じ不満リストが浮かびます。1つ1つは大した話ではありません。しかし積み重なります。

  • 保存するためにstory pointを埋める。 マーケはポイントで考えていません。「価格ページのリニューアル」を何ポイントか聞かれたら、それっぽい数字を選んでそれ以上は考えない。データに意味はなく、チーム全員それを知っています。
  • 本当はFigmaのコメントなのにissueを切る。 デザイナーが「ボタンの色をワントーン濃く」と一言残したい。Linearでの「正しい場所」は、タイトルとステータスとアサイニーが付いたissueを新規作成することです。結局、その一言は書かれないか、こっそり個人のNotionに書かれます。
  • cycleが週次のお説教会になる。 エンジニアはcycleをきちんとしたスプリント規律として使います。マーケが真似ると、よくあるのは「今週のcycleに入りきらなかった30%を、申し訳なさそうに来週へ持ち越す週次会」です。
  • 仕事がプライベート文書に隠れる。 これがいちばん深い症状です。workspaceが仕事の形と合わないと、人は仕事をworkspaceに入れなくなります。Linearのボードは見た目きれい。でも本物の仕事はNotion、Slack DM、Google Docsの中。エンジニアチームは「導入は順調だ」と思っています。

Linear比較記事でしばしば引用される2024年Product Management Instituteの調査では、メイン業務ツールとしてLinearを使うクロスファンクショナルチームの満足度は約26%、純粋な技術チームでは83%、というギャップが報告されています（Growth Method, 2026）。これはUXのバグではなく、設計意図どおりに動くプロダクトが、想定外の業務に当てられているだけです。

Linearが本当に得意なこと

短所だけを並べるのはフェアではありませんし、分析としても弱い。Linearの強みは本物で、しかもその強みがそのまま非エンジニアにとっての違和感の正体になります。

  • キーボード優先のスピード。 ヘビーユーザーがLinearを操る速度に追いつくPMツールは市場にありません。すでにキーボードに住んでいるエンジニアにとっては、純粋な生活品質の向上です。
  • 意見のあるissue階層。 Project → Issue → Sub-issue、ステータスはすっきり、入れ子は14階層もない、無限のカスタムフィールドもない。形を強制することが価値です。
  • 強制的なcycle規律。 cycleはオプションではなく、毎週／隔週で必ず開始・終了し、未完了は次に持ち越されます。安定して出荷したいエンジニアチームにとって、強制リズムこそ求めていたものです。
  • 一級市民としてのtriage。 入ってきたissueをまずまとめるための共有インボックス。サポート起点・顧客要望・社内アイデアと入力ソースが多いエンジニア組織には本当に役立ちます。

正直な要約はこうです——強みのどれもが、ツールをマーケ・デザイン・運用・人事へ広げた瞬間に摩擦に裏返ります。キーボードのスピードは「1時間練習する気がある」ヘビーユーザー前提。issue階層は「仕事＝issue」前提。cycleは「スプリントが正しいリズム」前提。triageは「入ってくる仕事はエンジニアっぽい役割の人がフィルタすべき」前提。

判断のための1行ルール

この記事から1つだけ持ち帰るとしたら、これにしてください。「Linearを全社導入すべきか、それともエンジニアチームだけにすべきか」を見きわめるための、いちばん歯切れの良いテストです。

会社として「ソフトウェアを最初から最後まで出荷している」なら、Linearを全社で使ってよい。workspaceの半分超が「エンジニアのフリをしている非エンジニアチーム」になっているなら、彼らをLinearの外へ出す（または2つめのツールを並走させる）。

前者は分かりやすい。シード期、12人で全員がプロダクトを出している（エンジニア、コピーを書く創業者、デザイナー、運用を担う業務委託）ようなチームなら、Linear全社運用はまったく問題ありません。仕事はソフトウェア。モデルが合っています。

後者は、急成長中の多くのチームが15〜40人あたりで踏むパターンです。マーケは独自の四半期キャンペーンを持ち、デザインはクライアントワークをレビューし、運用はオンボーディングのプレイブックを回し、セールスはパイプラインを追っています。workspaceの大半は、もうソフトウェアworkspaceではありません。この時点で選択肢は2つ：何チームか毎日「自分とは合わないツール」のなかで仕事することを受け入れるか、彼らを「仕事の形と一致するツール」へ動かすか。

そして、正解はたいてい「エンジニアからLinearを取り上げる」ではありません。彼らはLinearを愛していて、生産的で、移行コストは現実的にかかります。正しいのは、「先に来たからという理由で全チームを同じツールに押し込むのをやめる**」ことです。

「外へ出す（または並走させる）」の現実的な姿

ここで多くの会社がもう1つの罠にはまります。いちばん重い代替品——ClickUpやMondayの全面導入、カスタムフィールド、自動化、ダッシュボード、四半期1回のツール管理者会議——へ走ることです。これは別種の不幸せ。「エンジニア寄りすぎ」から「設定可能すぎ」へ振り子が振れただけで、コストは同じくらいかかります。

役立つフレームはこうです——多くの非エンジニアチームに必要なのは、Linearより「意見が少ない」ツールであって、「意見が多い」ツールではありません。彼らが欲しいのは、タイトルとアサイニー、期限、ステータス、コメントスレッドが付いたタスク。kanbanかリストの2ビュー。cycleもestimateもtriageも考えたくない。使っていないときには静かに消えてほしい。

3つの方向性を挙げます：

  1. シンプルな定額ツール（例：Heimin）。データモデルは「タスク＋基本フィールド」だけ、料金はチームまるごと月額固定で席数の計算なし。「単にタスクを記録したいだけで、人数課金にもう疲れた」チームに合います。
  2. Asana。マーケ寄りの仕事——ビジュアルなタイムライン、ポートフォリオロールアップ、コンテンツカレンダー——が中心ならよくフィットします。Heiminより重いが、非エンジニアにとってLinearよりは自然です。
  3. Notion。主たる成果物がドキュメント／wikiで、タスクは副次的なビューで足りる場合。ただし2026年にAIをBusinessプランへ束ねたことで価格床が上がっています。詳しくは per-seat価格モデルの観点で書いた記事 を参照してください。

全社で1つのツールに揃える必要はありません。混成チームに対する2026年のいちばん正直な答えは、しばしば「エンジニアはLinearに残し、ほかは仕事の形に合うツールへ移し、両者は最小限の明確な連携でつなぐ」です。

Heiminの正直な立ち位置

Heiminはあえて、Linearより遅く、Linearより意見が薄いツールです。cycleはありません。triage機能もありません。estimation pointもありません。タスクが1枚——タイトル、アサイニー、ステータス、期限、説明、コメント——表面積はそこまでです。料金はチームまるごと月額12ドル定額、席数の計算はありません。

これは分析を装った営業トークではありません。異なる意見です——Linearは「意見が強く・速く・エンジニアの形をしている」ことが製品の本質に賭け、Heiminは「マーケ・デザイン・運用そして数多くの小規模チームにとっては、意見が薄く・シンプルで・形を選ばないこと」が本質に賭けています。私たちは「エンジニアにとってより良いLinear」を作ろうとはしていません。今まさに自分の仕事をLinearの形に翻訳している、もう半分の非エンジニアチームに合う答えを作ろうとしています。

エンジニアチームがLinearを愛しているなら、そっとしておきましょう。マーケ責任者が保存のためにstory pointを埋めているなら、それは本物の問題で、修正は5分で終わります。

決める前のチェックリスト

  1. Linearの中で、誰が何をしているか棚卸しする。 workspaceを並べて「エンジニア／非エンジニア」を付ける。後者が半分超なら、もう会社の形と合っていない。
  2. 非エンジニア責任者に5分の症状チェックをしてもらう。 story pointを埋めるためだけに数字を入れているか？issueではないものをissueにしているか？仕事をプライベート文書に隠しているか？1つ「はい」が出れば黄色信号、2つ出れば判決。
  3. エンジニアからLinearを奪わない。 彼らにとっては元が取れている。合わないチームには2つめのツールを並走させればよい。
  4. 代替候補は「機能の数」ではなく「形」で選ぶ。 仕事の形と合うシンプルなツールが、合わない高機能ツールに毎回勝つ。
  5. 席数の数字を先に出す。 代替が席数課金なら、現在の人数 × 1.5 で月額を計算する。気持ち悪い数字なら定額制を見にいく。

正解は「Linearが悪い」ではありません——Linearは優秀です。正解は、マーケはエンジニアではない、というふりをやめること。そのふりのコストは、Linearの低いエンゲージメント、プライベート文書のなかに沈む仕事、そして「workspaceに表示されているものが現実だ」とお互いに信じ合えなくなるチーム間の信頼の摩耗、というかたちで隠れています。

関連記事

Heiminを無料で試す →