こんにちは、mayaです！
今回はラッコ株式会社のタスク管理ツールを、BacklogからLinearに全社移行した話をします。
私は経験3年のエンジニアで、このような影響範囲の大きいプロジェクトをリードするのは初めてでした。
さまざまな悩みにぶち当たりながら進めたので、同じような立場の方の参考になれば嬉しいです！
- なぜBacklogじゃだめなの？Linearの良いところは？
- Backlogは安い、Linear導入の費用対効果はどう説明する？
- 上層部や現場からの反発を防ぐには？
- ツール移行で業務効率の低下、混乱を防ぐには？
プロジェクトを振り返りながら、このような疑問にお答えします！
筆者およびラッコ株式会社のステータス
- 創業10年、従業員数36名、主なプロダクト「ラッコキーワード」「ラッコM&A」など
- もとはBacklog運用が6年以上続いていた組織
- 筆者は経験年数3年・25歳のエンジニア、全社のAI推進リード兼、今回のLinear導入プロジェクトリード
プロジェクト全体像
まず全体像から。試験→慣れ期間→一括移行→全面移行→定着、という5つのフェーズで進めました。
| フェーズ | 期間 | 主な動き |
|---|---|---|
| 試験導入 | 2/23〜3/8 | 準備（セットアップ・説明会・全社周知） |
| 試験導入 | 3/9〜3/21 | 試験運用（3チーム） |
| Go判断 | 3/24 | 本導入Go判断（EM/TL合意形成・稟議提出） |
| 本導入 | 4/1 | 全社定例でアナウンス |
| 本導入 | 4/3 | 導入説明会（動画事前配布 + ルール説明 + Q&A） |
| 本導入 | 4/3〜4/10 | 慣れ期間（新規タスクはLinear、既存タスクはBacklogのまま） |
| 本導入 | 4/10 | Backlog残課題の一括移行 |
| 本導入 | 4/13 | 全面Linear移行（Backlog新規起票停止） |
| 本導入 | 4/15 | 移行完了確認（Backlog未クローズ課題ゼロ） |
| 定着 | 4/13〜5/4 | 展開後フォローアップ・週次アンケート |
| 定着 | 5/4 | プロジェクトクローズ |
主要な数字をまとめるとこうです。
| 項目 | 結果 |
|---|---|
| プロジェクト全期間 | 2.5ヶ月（2/23〜5/4） |
| 全社移行までに要した期間 | 1.5ヶ月（2/23〜4/10） |
| 業務停止時間 | 0時間 |
移行のスピード感はかなり重視しました。
長引くほど、2つのツールの並行運用やワークフローの複雑化など、効率的な業務遂行に影響が出るので。
Phase0：なぜBacklogからLinearへ？
きっかけは、私がリードを務める「AI推進プロジェクト」の取り組みです。
「AI駆動開発」の仕組みを社内に展開する上で、タスク管理ツールが「AIネイティブ」であることの重要性に気がつきました。
- Backlog上でAIを呼び出して質問/相談をする
- Backlog上で1クリックで実装作業を委任する
- タスクの起票・更新・情報収集をAIに任せる
こういったことをBacklogで実現するのはハードルが高く、AIありきでワークフローや業務体験を最適化する上で、大きなボトルネックになっていました。
LinearとBacklogの比較
Linearの優位性は大きく3つあると考えました。
| 観点 | Backlog | Linear |
|---|---|---|
| GitHub連携 | 課題番号によるコミット連携が中心 | PR・Issue・ブランチが双方向で同期、Issueステータスの自動遷移、Linear上でレビュー完結 |
| AIエージェント連携 | WebhookやAPI経由で個別実装が必要 | Devin・Claude CodeのMCP/インテグレーションがネイティブ対応 |
| UI/UX | 標準的 | 表示/応答速度が速い、モダンな画面構成と操作体験、Issue検索がラク、豊富なショートカットキー |
費用対効果の評価
Linearの導入により、タスク管理ツールのコストが1.7万円→10万円に増加します。（弊社の場合）
それでも移行することに利があると定量的に説明できます。
根拠は「Linear導入による業務効率向上」です。
月当たりのコスト増は約8.3万円、これを従業員数で割ると2,300円。
つまり、Linearの導入によって従業員1名あたり月に2,300円分の工数削減ができればコスト回収が可能です。
2,300円というと月給40万円の人の時給と大体同じ額ですから、既述のLinearの優位性を持って十分に達成できると説明できます。
また、工数削減はその数値が大きいほど「従業員の業務体験の向上」に繋がります。
Linearを使えば、課題の起票/更新、プロジェクト進捗管理、パフォーマンス分析などの地味で煩雑な作業はAIに委任できます。
人間はより生産的でクリエイティブな作業に集中できます。
Phase 1: 試験導入で「小さく始める」設計の判断ポイント
ツール移行で最も避けたいのは「全社一斉で入れて、合わなかった」という最悪パターン。だから試験導入を必ず挟みました。ここでの判断ポイントは「誰を・どれだけの期間・何を測るか」の3点です。
試験対象3チームの選び方
うちが試験対象に選んだのは、ラッコキーワード（KW）・インフラ（INF）・ラッコID（ID）の3チーム。選定基準は次の3軸でした。
| 軸 | 狙い | 今回の選定理由 |
|---|---|---|
| 規模の多様性 | 小〜中規模で代表性を確保 | 3〜10人の異なる規模をカバー |
| 業務性質の多様性 | サービス開発／インフラ／プラットフォームで偏らない | 3チームでこの3領域を網羅 |
| 協力度の高さ | 新ツールへの好奇心・フィードバック意欲がある | リーダーやメンバーが前向きだった |
ポイントは「たまたま空いているチーム」で選ばないこと。試験は本導入の縮図なので、本導入で当たる難所が試験中に出てこないと意味がありません。
試験期間2週間の意図
試験期間は2週間（3/9〜3/21）に切りました。短い、と思われるかもしれません。意図はこうです。
- 長すぎると「とりあえず使えてる」状態でダラダラ続いてしまう
- 2週間あれば、運用ルール・UI習熟・チーム内会話のすべてに最低1サイクルは回る
- 試験期間が長いほど、本導入の決断が先延ばしになる
結果として、2週間でGo判断に十分な材料が揃いました。
週次アンケートで何を測ったか
試験中に毎週とったアンケートでは、次の3軸を聞きました。
- 回せているか： Linearでタスク管理が業務として成立しているか
- 困っていないか： UI・ルール・運用で具体的な詰まりがないか
- 戻りたいか： もしBacklogに戻れと言われたら戻りたいか
機能面や効率面でLinearに優位性があることは自明でしたので、問題なく業務がまわり、オンボーディングコストが低く、Backlogよりも業務体験が良いことを確認できればGoに踏み切れます。
Phase 2: 試験運用2週間で本導入を決定
結果として試験開始から2週間で本導入Goを確定させました。
試験参加者および上層部の反応が非常に良く、計画を前倒しして本導入することに賛同いただきました。
3軸の評価結果
| 軸 | 判定基準 | 試験結果 |
|---|---|---|
| 運用が回るか | アンケートで「業務として成立している」回答が大多数 | 全員「成立」回答 |
| 重大なブロッカーがないか | UI・機能・連携で「これがないと無理」という障壁の有無 | ゼロ件 |
| メンバーの納得感 | 「Backlogに戻りたい」回答の有無 | ゼロ件 |
3軸とも閾値を越えていたら自動的にGo、というルールで関係者と事前合意しておきました。
明確な判断軸と基準を用意しておくとスムーズに決定しやすいです。
上層部から理解を得るために工夫したこと
関係者、特に上層部からの理解を得るために意識したことが二つあります。
- 試験に実際に参加してもらう
- 試験参加者の声をこまめに届ける
機能/効率の面でLinearに優位性があることは事前に共有済みでしたが、より納得感をもって本導入に賛同いただけるように、上層部の方にも試験参加者としてLinearを先行利用していただきました。
これにより、かなり速い段階でLinearの良さを関係者全員に知っていただくことができました。
Phase 3: 全社展開で「業務の混乱を避ける」設計のポイント
いよいよ全社全チームへLinearを導入します。
このフェーズでは「業務を止めない」ことを最優先にしました。
オンボーディング設計：動画事前配布 + 説明会 + Q&A自動化
「使い方がわからない」「画面の見方がわからない」
この状態を防ぐために、次のような取り組みを行いました。
- 本導入前に「触って慣れる期間」を設ける
- 操作説明動画の配布
- Q&Aボットの導入（Notebook LM）
- Slack上でサポートチャンネル作成/質問相談に回答
- 便利な使い方をサポートチャンネルでこまめに発信
操作説明動画で基本的な画面の見方や操作方法を解説し、Q&Aボットも用意したことで、困り事があっても各従業員が自己解決することができました。
サポートチャンネルでは、各自が発見した便利な使い方が頻繁に共有されています。
皆さんの協力のおかげで、私の負担は相当に軽減され、社内へのLinearの定着が劇的に早まった感覚があります。
※操作説明動画は全部で12本、Linearの公式Docよりわかりやすかったと思う
※ナレッジ共有で盛り上がるSlack
「移行期間」を挟む意図
4/3〜4/10の1週間は 「新規タスクはLinear、既存タスクはBacklogのまま」 という移行期間にしました。
4/3 説明会
│
│ ▼ 新規タスク
│ ├─ Linear で起票
│ │
│ ▼ 既存タスク
│ └─ Backlog で継続（クローズまで）
│
4/10 慣れ期間終了 → Backlogから一括移行
この期間の狙いは次の通りです。
- 新規だけLinearにすることで、操作を全員に強制的に経験させる（実際に触って欲しい）
- 既存タスクには触らないので、進行中の業務は止まらない
- メンバーがLinearで詰まる箇所をこの期間中に発見できる
ここで集めた質問・違和感はSlackのサポートチャンネルに集約し、運用ルールにフィードバックしました。
Backlog一括移行の日を切る判断
4/10、慣れ期間の最終日にBacklog残課題を一括でLinearに移行しました。判断ポイントは「移行の日を1日に切る」こと。
一括移行は私（プロジェクトリード）が一人で実行しました。Backlogの全プロジェクトから未完了Issueを抽出し、対応するLinear Teamに移行するスクリプトを事前に用意しておきました。
全面移行と移行完了確認
4/13（月）から全業務をLinearに切り替え、Backlogの新規起票を停止。
4/15（月）にはBacklog未クローズ課題ゼロを確認して、全面移行完了としました。
確認のステップ:
- 各サービスPMが、自チームのBacklog残課題を最終チェック
- 「これはもうクローズしてOK」「Linearに移行漏れがある」を全件分類
- 移行漏れはこの日のうちに対応し、Backlog未クローズゼロを担保
「完了確認の日を切る」ことで、ダラダラした残課題が後を引かないようにしました。
Phase 4: 定着フェーズで「人を置き去りにしない」フォローアップ
移行完了がゴールではありません。本当のゴールは「全員がLinearで仕事できる状態」です。ここでも明確な判断ポイントを置きました。
#linear-supportでの質問対応
専用Slackチャンネルを作り、Linearに関する質問・困りごとはすべてここに集約。回答する側のメンバー（私を含む数名）も同じチャンネルを見ていればいいので、対応コストが分散しません。
意外なほど質問は少なく、最終的に半数以上がオンボーディング（Q&Aボット、操作説明動画）の段階で吸収されていました。質問の山は説明会直後の数日でピークを迎え、1週間でほぼゼロになりました。
週次アンケートで定着度を測る
本導入後も週次アンケートは継続。次のような項目で「運用が回り続けているか」を可視化しました。
- 今週Linearで困った場面はあったか
- Backlogに戻りたいと感じる瞬間はあったか
- 運用ルールで曖昧と感じる部分はあるか
最初の1,2回目のアンケートでは、運用ルールの不備や、オンボーディングにつまづいている人を発見し、素早いフォローアップに繋げることができました。
3回目のアンケート（4/24実施）の時点でほぼ「困りごとなし」になり、定着フェーズの完了を判断する材料になりました。
想定通りだったこと / 想定外だったこと
今回のプロジェクトは全般的にGoodに進められました。
想定外とはいえネガティブな事項はありません。
想定通りだったこと
- 試験導入で「重大なブロッカー」は出ないだろう、という見立て
- 慣れ期間を挟めば、現場の操作習熟は座学を遥かに超えるという仮説
- 一括移行を1日に切れば混乱が抑えられるという設計
- AIエージェント連携が選定の最大の理由として効くこと
想定外だったこと
- Go判断を11日前倒しできた: 試験運用が想定以上に良好で、Goの根拠が早く揃った
- 質問の少なさ: Linearの直感的なUIで、操作上のフォローアップがほとんど不要だった
- AI連携運用が走り出すまでの早さ: 移行直後からDevinへのIssue委譲が始まった
同じ立場のPM/EMへ：移行を始める前に決めておくべき4つの判断
最後に、これから移行を始める方へ。プロジェクトを始める前に次の4つだけは決めておくと、後の判断が楽になります。
- 試験対象チームの選定基準（規模・業務性質・協力度の3軸を明文化）
- Go/NoGoの判定軸（運用が回るか・ブロッカー有無・戻りたい人がいるか）
- 「業務の混乱を避ける」ための切り方（慣れ期間・一括移行日・全面移行日を事前に決める）
- 定着の判定条件（週次アンケートで何を見て「定着済み」とするか）
これらはプロジェクト計画書を書く前に決まっているのが理想です。判断軸が事前にあると、各フェーズの意思決定が「迷う作業」ではなく「チェック作業」になります。
まとめ
Backlogから Linear への全社移行を 2.5 ヶ月で完遂しました。技術的には大した話ではなく、効いたのは「摩擦を生まない設計」を作る次の3点です。
- 小さく試す: 3チーム・2週間の試験で、Go判断材料を揃える
- 業務を止めない: 慣れ期間 + 一括移行日 + 全面移行日を事前に切る
- 誰も置き去りにしない: 動画事前配布 + 説明会 + 週次アンケート + 個別フォローアップ
ツールの良し悪しよりも、摩擦を生まない判断ポイントの設計が移行の成否を決めます。同じ場所に立っているPM/EMの方の助けになれば嬉しいです。
最後まで読んでいただき、ありがとうございました！
質問・自社事例の共有など、コメントやSNSでぜひ教えてください。
Discussion