Backlogの案件を移す｜途中の仕事を止めない進め方
「backlog プロジェクト 移行」を調べている人が抱えているのは、データの問題ではありません。動いている案件を抱えたまま、どうやって足場を組み替えるかという問題です。納期は待ってくれませんし、外注先も社内のメンバーも、切り替えの都合には付き合ってくれません。
結論を先に置きます。一斉に切り替えず、プロジェクト単位で順に移すのが現実的な答えです。そのうえで、移す順番と、切り替えの1日の作り方と、並行して動く期間の決めごとを先に固めておく。この3つが揃えば、仕事は止まりません。2027年1月の料金改定で期限がはっきりしたので、その日付との突き合わせ方も合わせて置きます。
一斉に切り替える方式が、たいてい失敗する理由
移行の計画で最初に出てくるのは、「◯月◯日から新しいほうに移ります」という一斉切り替えです。分かりやすく、説明もしやすい方式です。ところがこれは、途中の仕事を抱えているチームには合いません。
理由は3つあります。
第一に、全部のデータを同時に運ぶ必要が出ることです。動いている案件も、終わった案件も、社外が入っている案件も、同じ週末に運ぶことになります。量が一度に集中するため、作業は必ず遅れます。
第二に、問題が起きたときに戻せないことです。全部を切り替えたあとで「担当者の割り当てが全部おかしい」と分かった場合、戻す先がありません。旧環境には切り替え後の書き込みが入っていないからです。
第三に、現場が混乱する規模が大きすぎることです。切り替えの翌日、全員が同時に「どこに何があるか分からない」状態になります。とりまとめている人のところに質問が集中し、その日は他の仕事が進みません。
プロジェクト単位で移すと、何が変わるか
順に移す方式では、これらが分散します。1つのプロジェクトを移し、そこで起きた問題を直してから、次に進みます。2つ目、3つ目は同じ手順を繰り返すだけになり、速くなります。
もう1つの利点は、移さないという判断を途中で挟めることです。移してみたら思ったより手間がかかると分かった時点で、残りをどうするか考え直せます。一斉切り替えでは、この判断の機会がありません。
現場でよく聞くのは、最初の1つに時間をかけたおかげで、残りが想定の半分で終わったという話です。逆に、いきなり全部を運ぼうとして、途中で止まったまま2つの環境が並存し続けたという話も聞きます。並存が長引くのがいちばん悪い状態です。
移す前に、案件を3つに仕分ける
順番を決める前に、そもそも移す対象を絞ります。プロジェクトは3つに分かれます。
移すものは、いま動いていて、これから数か月は続く案件です。ここが本体です。
移さずに終わらせるものは、納期が近く、まもなく完了する案件です。旧環境で走り切って、終わったら記録として書き出します。
移さず閉じるものは、実質的に止まっている板です。試しに作ったもの、担当者が異動して動いていないもの、去年で終わったのに開いたままのもの。これらは移行の対象から外します。
この仕分けを最初にやるかどうかで、移行の総量が変わります。とりまとめている人からよく聞くのは、数えてみたら本当に動いているのは全体の3割だった、という話です。残りの7割を運ぼうとするから、移行が終わらなくなります。
仕分けの基準は、最後に課題が更新された日で足ります。3か月動いていない板は、たいてい止まっています。判断に迷ったら、その板の担当者に「まだ使いますか」と聞けば数分で決まります。
移す順番の決め方
順に移すと決めたら、次は順番です。ここで間違えると、いちばん大変なものを最初に持ってくることになります。
最初に移すのは、始まったばかりの案件
1つ目に選ぶのは、動いていて、かつ始まったばかりの案件です。理由は明快で、過去のやり取りが少ないからです。運ぶ課題の数が少なく、コメントも溜まっていません。
しかも、動いているので状態や担当者の問題が表に出ます。終わった案件で練習すると、全部が完了状態のまま並ぶだけで、実務の問題が見つかりません。
この1つ目で確かめることは4つあります。書き出したCSVがそのまま読めるか。取り込みの件数の上限に当たるか。担当者の割り当てが正しく入るか。間違えたときにまとめて取り消せるか。この4つが分かれば、以降の見積もりが立ちます。
4つ目は軽く見られがちですが、実務では効きます。列を1つずらしたまま数百件を取り込んだとき、1件ずつ消すことになると、そこで半日が消えます。確かめ方は簡単で、10件だけ取り込んで、その10件をまとめて消してみるだけです。
かかった時間も記録しておきます。1プロジェクトに要した時間が分かれば、対象のプロジェクト数を掛けて全体の日数が出ます。この数字があると、適用開始日までに間に合うかどうかを具体的に判断できます。
終盤の案件は、動かさない
逆に、絶対に最初に触らないのが、納期が目前の案件です。切り替えの混乱が、そのまま納期のリスクになります。
終盤の案件は、その案件が終わるまで旧環境に置いたままにします。終わったら、記録として書き出して保管する。移す必要はありません。この割り切りができると、移行の対象は目に見えて減ります。
判断の目安は、残りの期間です。1か月以内に終わるなら移さない、3か月以上続くなら移す。あいだの場合は、課題の件数で決めます。件数が少なければ移し、多ければ終わるまで待ちます。
社外が入っている案件は、後ろに回す
外注先や協力会社が入っているプロジェクトは、切り替えに相手の手間がかかります。招待を受けてもらい、使い方を覚えてもらい、書き込む場所を変えてもらう。こちらの都合だけでは進みません。
そのため、社内だけの案件で手順を固めてから、社外が入っているものに移ります。手順が固まっていれば、相手に渡す案内も1枚で済みます。逆に、手順が固まらないうちに社外を巻き込むと、変更のたびに連絡することになり、信用を落とします。
相手に渡す案内には、3つを書きます。いつから新しい場所を使うか、招待のメールがどこから届くか、困ったときに誰に連絡すればよいか。この3つがあれば、やり取りは1往復で済みます。逆に「新しいツールに移ります」とだけ伝えると、相手からの質問で数往復することになります。
移すときは、相手に見せる範囲を先に決めます。旧環境で「なんとなく全部見えている」状態のまま運用してきた場合、移行はその範囲を引き直す機会になります。社外の人を入れるときの線の引き方は、安全性の考え方のページに整理があります。
終わりのない板は、切り替え日を決めて移す
定例業務、保守、問い合わせ対応など、終わりのないプロジェクトがあります。これらは「案件が終わったら移す」という判断が使えません。
対処は、日付で区切ることです。ある日を境に、新しい依頼は新環境に立てる。旧環境の未完了分だけを手で移す。過去の完了分は移さず、書き出して保管する。この形なら、移す量は未完了分だけに絞られます。
未完了分の件数は、多くの場合数十件に収まります。数十件なら、CSVを使わずに手で立て直すほうが速いこともあります。件数を数えてから、どちらにするか決めます。
手で立て直す利点は、内容を見直せることです。半年前に立てたまま誰も触っていない依頼が混ざっていることがあり、運ぶ過程で気づけます。CSVで一括して運ぶと、この気づきは起きません。件数が少ないうちは、手を使うほうが結果的にきれいに終わります。
順番を一覧にして、共有しておく
順番が決まったら、プロジェクト名と切り替え予定日を並べた一覧を作り、関係者に共有します。作るのは1枚で足ります。
一覧があると、3つのことが同時に片づきます。1つ目は、担当者が自分の案件がいつ切り替わるかを把握できること。2つ目は、繁忙期と重なっている案件を事前に見つけられること。3つ目は、途中で担当が変わっても引き継げることです。
この一覧は、進めながら更新します。予定日がずれるのは普通のことで、ずれた事実が見えていれば問題になりません。見えないまま遅れると、いつまで並行するのかが分からなくなります。
切り替えの1日をどう設計するか
プロジェクトごとの切り替えは、1日で終わる設計にします。数日にまたがると、その間どちらに書けばよいか分からなくなります。
書き込みを止める日と、開く日を分ける
流れは3段階です。
前日までに、書き出しと整形を済ませます。この時点では、まだ旧環境で普通に仕事をしています。
当日の朝、旧環境への書き込みを止めます。この時点で書き出しをもう一度行い、前日からの差分を拾います。そのうえで取り込みを実行します。
当日の午後、新環境を開きます。担当者に見てもらい、自分の課題が入っているかを確認してもらいます。ここで漏れが見つかったら、その場で足します。
翌日から、新環境だけを使います。旧環境は読み取り専用として扱います。
この流れで重要なのは、朝に書き込みを止めることです。前日の夜に書き出して、当日も普通に仕事を続けると、その日に増えた分が落ちます。落ちた分は数件かもしれませんが、その数件が納期に関わる依頼だと大きな問題になります。止める時刻を決めて、前日のうちに全員に伝えておきます。
止める時間を短くしたいなら、切り替えは業務の少ない曜日に置きます。半日で終わる設計にしておけば、午前中だけ書き込みを止めれば済みます。
引き継ぐのは、未完了のものだけ
切り替えの日に運ぶのは、未完了の課題だけです。完了済みは運びません。運んだところで開かれず、取り込みの件数だけが増えます。
Backlogの一括登録では、一度に登録できる課題が最大250件と決まっています。他のサービスでも同様の上限があることが多く、未完了に絞れば1回で収まることがほとんどです。1回で収まると、当日の作業が短く済みます。
なお、課題の「状態」は取り込み時に指定できないことが多く、Backlogの一括登録でも公式ヘルプが「すべて『未対応』で登録されます」と明記しています。未完了だけを運ぶ場合、状態の種類は2つか3つなので、当日の午後に手で置き直しても数分で終わります。
当日の役割を、2人に分ける
切り替えの当日は、役割を2つに分けます。1人は取り込みの操作を行い、もう1人は質問に答えます。1人で両方をやると、操作の途中で声をかけられ、列を1つずらしたまま進めるといった事故が起きます。
質問に答える側が用意しておくものは3つです。旧番号と新番号の対応表、ファイルを置いた場所のURL、担当者の対応表。この3点があれば、当日の質問の大半は答えられます。
当日に来る質問も、だいたい決まっています。前の課題はどこにあるのか。ファイルはどこへ行ったのか。自分の担当のものが見当たらない。この3つです。先に1枚のメモにまとめて配っておくと、個別に答える回数が減ります。
添付ファイルの扱いを、当日までに決めておく
課題に付いた添付ファイルは、CSVの行の中には入りません。別に運ぶことになります。ここを当日に考え始めると、切り替えが1日で終わりません。
決めるのは1点です。移行先の課題に付け直すか、共有ドライブに置いてリンクだけ張るか。前者は元の形に近くなりますが、ファイル数だけ操作が要ります。後者は運ぶ量が減る代わりに、リンクを張る作業が生まれます。
動いている案件に限れば、添付の数はそれほど多くありません。仕様書や見積書のように何度も開くものは付け直し、確認のために一度だけ貼られた画面写真はまとめて共有ドライブに置く。この線引きを前日までに決めておけば、当日は迷いません。
並行して動く期間の決めごと
順に移す方式では、しばらくのあいだ2つの環境が並びます。ここでの決めごとが、成否を分けます。
二重に書かない
いちばん避けたいのが、両方に書く状態です。安全に見えますが、これをやると両方が不完全になり、どちらが正しいか分からなくなります。結局は人に聞くことになり、道具を使う意味が薄れます。
決めごとは1つで足ります。移したプロジェクトは新環境だけ、まだ移していないプロジェクトは旧環境だけ。プロジェクト単位で移す方式の利点はここにあります。境界がプロジェクトなので、迷う余地がありません。
どちらに書くかを、見た目で分かるようにする
決めごとを作っても、人は間違えます。仕掛けで防ぎます。
旧環境に残っているプロジェクトの名前に、移行済みかどうかの印を付けます。「【移行済み・書き込み禁止】」のように名前の先頭に付けておけば、開いた瞬間に分かります。説明を読ませるより、名前に書くほうが確実です。
移した先でも同じで、移行した案件には元のプロジェクト名を残しておきます。名前を変えると、探す人が迷います。名前をそろえる作業をしたい場合でも、移行の当日ではなく、落ち着いてから別の日にやります。
並行の期間に上限を置く
並行の期間は、長くても3か月を上限にします。それを超えると、どちらが正なのか分からなくなり、新しく入った人が両方を見ることになります。
期間を短くするには、移す対象を減らすのがいちばん効きます。全部のプロジェクトを移す前提だと期間は延びます。終盤の案件を移さない、完了済みを移さない、使われていない板は移さない。この3つを適用すると、対象は半分以下になることが多くあります。
並行の終わりも、日付で決めておきます。この日から旧環境は読み取り専用にする、と先に宣言しておけば、だらだらと延びません。宣言した日が来たら、残っている案件が終わっていなくても、そこで線を引きます。引けないほど残っているなら、そもそも移す対象の絞り込みが足りていません。
移す前に、板の形をもう一度決める
移行は、そのまま運ぶ作業だと思われがちです。ただ、そのまま運ぶと、旧環境で溜まった無駄もそのまま運ばれます。切り替えは、形を決め直せる数少ない機会です。
状態の段数を減らせないか確かめる
旧環境で状態を5段も6段も作っている場合、その段数が本当に要るかを確かめます。段が多いほど、動かす人が「いまどれか」を考える時間が増えます。考える時間が増えると、更新が後回しになります。
判断の材料は簡単です。過去3か月の課題を見て、実際に使われた状態がいくつあるかを数えます。作ったけれど誰も選んでいない状態は、移行のときに落とします。3段で回っているなら、移行先も3段で作ります。
必須にする欄を、1つ減らす
入力の手間を決めるのは、必須の欄の数です。担当者、期限、種別、優先度、カテゴリー。全部を必須にすると、課題を1件立てるのに考えることが5つになります。
移行の前に、必須の欄を1つ減らせないかを検討します。減らして困るかどうかは、その欄で絞り込んだ回数で判断できます。絞り込みに使っていない欄は、必須にする理由がありません。減らした結果として、移行のときに整える列も1つ減ります。
プロジェクトの名前をそろえる
長く使っていると、プロジェクトの名前の付け方がばらばらになります。年月が入っているもの、顧客名が入っているもの、略称だけのもの。移行のときにそろえておくと、一覧が読みやすくなります。
そろえ方は、頭に何を置くかを決めるだけで足ります。顧客名を先頭に置くか、案件の種類を先頭に置くか。並べたときに探しやすいほうを選びます。ここで決めた形は、移行後に新しく立てる板にも引き継がれます。
よくあるつまずきと、その避け方
実際に順に移していくと、決まった場所で引っかかります。先に知っておけば避けられます。
担当者がまだ招待されていない
課題を取り込んだのに、担当者が空欄になる。原因は、その人がまだ新環境に招待されていないことです。多くのサービスは、存在しない利用者を担当者として設定できません。
避け方は、取り込みの前日までに全員を招待しておくことです。招待だけ済ませておけば、当日は取り込みに集中できます。社外の人が入っている場合、招待を受けてもらえるまでに数日かかることがあるので、さらに前倒しします。
期限が入っていない課題が大量に出てくる
書き出したCSVを見ると、期限が空欄の課題が想像以上に多いことに気づきます。旧環境では見えていなかった問題が、移行のときに表に出ます。
ここで全部に期限を入れようとすると、移行が止まります。移行の作業と、運用の見直しは分けます。期限が空欄のまま運び、移行が終わってから担当者に順に埋めてもらう。移行の当日に決めごとを増やさない、というのが原則です。
課題の詳細に貼られたリンクが切れる
課題の本文やコメントには、別の課題へのリンクが書かれています。移行先ではURLが変わるため、これらは切れます。
動いている案件に限れば数は多くありません。取り込みのあとで、担当者に自分の課題を開いてもらい、切れたリンクがあれば直してもらう形が現実的です。全部をこちらで直そうとすると、そこだけで数日かかります。あわせて、旧番号と新番号の対応表を共有しておけば、切れたリンクに当たっても元をたどれます。
移行の途中で担当者が変わる
数か月かけて順に移すと、その間に異動や退職が起きます。移行の担当者が変わると、そこまでの決めごとが失われます。
避け方は、決めごとを1枚のメモに残すことです。移す順番、切り替えの手順、対応表の置き場所、まだ移していないプロジェクトの一覧。これを共有ドライブに置いておけば、引き継ぎが数分で済みます。頭の中だけに置くと、移行そのものが止まります。
プロジェクト数の上限が、移行の設計に効く
2027年1月からの新プランでは、プロジェクト数の上限が変わります。ここが移行の設計に直接影響します。
エコノミープランのプロジェクト数の上限は30で、現在のスタンダードプランの100から縮みます。ビジネスプランとプロフェッショナルプランは無制限です。
スタンダードプランを使っている組織のうち、ユーザー15名以下かつプロジェクト30以下であれば、エコノミーへ自動で移ります。16名以上または31プロジェクト以上の場合は自動移行の対象から外れ、ビジネス以上を自分で予約することになります。金額は16,000円から36,300円（いずれも税抜・月払い）へ、2倍を超えます。
つまり、プロジェクトを30以下に収められるかどうかが、年額で183,600円の差になります。移行の話をする前に、この数を確かめる価値があります。
数える前に、閉じられるものを閉じる
プロジェクトの数を数えると、たいてい想像より多く出ます。試しに作った板、終わった案件、担当者が異動して止まったままのもの。これらが残っています。
閉じられるものを閉じてから数え直すと、30を切ることがあります。ここで注意したいのが、アーカイブしたプロジェクトが上限にどう数えられるかです。扱いについては公式のFAQに記載があるため、最新の内容を確認したうえで数えるのが確実です。数え方を間違えると、予約するプランを間違えます。
なお、現行プラン内でのダウングレードには制限があり、公式FAQには「次の利用期間が2027年1月1日以降の場合は、現在のプランでのダウングレードはできません」と記載されています。プランを下げる方向で調整するなら、契約期間の切れ目を先に確認しておく必要があります。
日程を、改定の日付と突き合わせる
料金改定の告知は2026年6月17日に公開され、同日付で上場企業としての適時開示も出ています。日程は3つに分かれます。
現行プランの新規契約につきましては、2026年12月31日をもって受付を終了いたします 出典: ssl4.eir-parts.net
新しい3プランの開始は2027年1月1日です。既存の契約者に新料金が適用されるのは、2027年1月1日以降に到来する最初の契約更新日で、ヌーラボはこれを「適用開始日」と呼んでいます。この日はスペースごとに違い、契約管理者または管理者が「組織設定」の「プラン」画面で確認できます。トライアル中、プラン停止中、フリープランの場合は表示されません。
移行を進めるなら、この適用開始日から逆算します。順に移す方式では、1プロジェクトあたりの所要時間にプロジェクト数を掛けた日数が要ります。加えて、繁忙期を避ける必要があります。切り替えの日を納期の直前に置かない、という原則は動かせません。
日数が足りないと分かった場合、無理に間に合わせるより、いったん新プランを予約してから移行を続ける判断のほうが安全です。予約が必須になるのは、スタータープラン利用中、スタンダードプランでユーザー16名以上またはプロジェクト30超、スタンダードプランでNulab Pass契約中のいずれかです。公式のFAQは、予約が無い場合について「適用開始日以降にBacklogを利用できなくなる可能性があります」と明記しています。期限の目安は、銀行振込が適用開始日の64日前まで、クレジットカードが2日前までです。
移した先で案件が回るかは、板の形で決まる
プロジェクトを運びきることと、そこで仕事が回ることは別です。移した先で更新する人が数人に固定されれば、進捗の表はすぐ実態から離れます。現場では、埋める欄が多く、考える時間が要る作りだと、2週間ほどで更新が止まると言われています。
だから移行のときに見るべきは、機能の一覧より、板の形と入力の手間です。列がいくつあるか、必須の欄がいくつあるか、担当を決めるのに何回クリックするか。旧環境の項目をすべて再現すると、入力の手間もそのまま再現されます。
料金の作りも同じ方向で見ます。機能ごとに段が分かれていると、工程表や属性のために上のプランへ上げる相談が定期的に出ます。機能で絞らず、区切るのは人数とボードの数だけという作りであれば、その相談が起きません。料金の考え方は料金のページに、使える範囲はできることのページにまとまっています。
取り込みの口も確かめます。CSVを受け取れるか、1回あたりの件数の上限はいくつか、間違えたときに取り消せるか。自動での取り込みに対応する範囲がTrelloに限られる作りのサービスもあり、それ以外は表計算を経由することになります。運べる範囲はTrelloからの移行のページに記載があります。
そのうえで、移さない判断も同じ土俵に置きます。リポジトリを課題と同じ場所で使っているなら、課題番号とコミットの結び付きは移した先で作り直せません。Backlogは長く使われている製品で、2026年に入ってからも機能追加の告知が続き、提供終了の告知は出ていません。両者の課金の単位と上限の考え方の差は、Backlogとの比較のページで確かめられます。
今日のうちに終わる確認
移行の計画を立てる前に、次の5つを数えます。どれも短時間で終わります。
第一に、適用開始日を「組織設定」の「プラン」画面で確認します。移行の日程は、すべてここから逆算します。
第二に、プロジェクトの数です。閉じたつもりのものも含めて数え、閉じられるものを閉じてから数え直します。エコノミープランの上限は30です。
第三に、そのうち「いま動いている」プロジェクトがいくつかを数えます。これが実際に移す対象です。全体の3割から5割に収まることが多くあります。
第四に、動いているプロジェクトごとの未完了課題の件数です。合計が数百件なら、移行は現実的な作業量に収まります。数千件なら、対象をさらに絞る検討が要ります。
第五に、社外の人が入っているプロジェクトがいくつあるかです。ここは相手の手間がかかるため、日程に余裕を持たせます。
数えるときは、画面の数字をそのまま控えます。記憶で答えると、止まっている板や、招待だけして使っていない人が抜け落ちます。控えた数字は、その場で1枚の表にまとめておきます。社内に説明するとき、この表がそのまま資料になります。
あわせて確認しておきたいのが、リポジトリを課題と同じ場所で使っているかどうかです。Git / Subversionは公式の料金ページによれば全プランで利用でき、フリープランでも利用可と記載されています。課題番号とコミットを結び付けて運用しているなら、その結び付きは移した先で作り直せません。移行の判断そのものが変わる要素なので、日程を組む前に確かめておきます。
この5つが揃うと、1プロジェクトあたりの所要時間を掛けるだけで全体の日数が出ます。その日数と、適用開始日までの残り日数を並べて、間に合うかどうかを判断します。細かい条件で不明な点が残る場合は、よくある質問のページに運用まわりの疑問がまとまっています。
Q1. 動いている案件を止めずに移行できますか？
できます。ただし一斉切り替えではなく、プロジェクト単位で順に移す方式にします。移したプロジェクトは新環境だけ、まだ移していないプロジェクトは旧環境だけ、と決めれば、どちらに書くか迷う場面がなくなります。1プロジェクトごとに1日で切り替える設計にし、当日の朝に書き込みを止めて取り込み、午後に担当者へ確認してもらう流れが現実的です。
Q2. どのプロジェクトから移すのがよいですか？
始まったばかりで、いま動いている案件からです。過去のやり取りが少なく運ぶ量が小さいうえ、状態や担当者の問題が実際に表に出るため、手順を固めるのに向いています。逆に納期が目前の案件は動かしません。その案件が終わるまで旧環境に置き、終わったら記録として書き出して保管します。社外が入っている案件は手順が固まってから回します。
Q3. 完了した課題も移したほうがよいですか？
移さない前提で計画するほうが、現実的に終わります。切り替えの日に運ぶのは未完了の課題だけにし、完了済みは書き出して共有ドライブに置きます。Backlogの一括登録では一度に登録できる課題が最大250件と決まっており、未完了に絞れば1回で収まることがほとんどです。取り込みの回数が減ると、切り替え当日の作業時間も短くなります。
Q4. 旧環境と新環境を並行して使う期間はどのくらいですか？
長くても3か月を上限にします。それを超えると、どちらが正なのか分からなくなり、新しく入った人が両方を見ることになります。期間を短くするには移す対象を減らすのが最も効きます。終盤の案件を移さない、完了済みを移さない、使われていない板は移さない。この3つを適用すると、対象は半分以下になることが多くあります。
Q5. プロジェクト数は移行の判断にどう関わりますか？
2027年1月からのエコノミープランはプロジェクト数の上限が30で、現在のスタンダードプランの100から縮みます。31以上またはユーザー16名以上だとビジネスプランになり、16,000円から36,300円（いずれも税抜・月払い）へ2倍を超えます。閉じられる板を閉じて30以下に収まるかを確かめる価値があります。アーカイブ済みの扱いは公式FAQで最新の記載を確認してから数えます。