Backlogの使い方｜課題の立て方から決める

「backlog 使い方」で検索する人の多くは、ボタンの押し方が分からなくて困っているわけではありません。課題を登録する画面は開けている。それでも手が止まるのは、この作業を1件の課題として立てるべきなのか、どのプロジェクトに置くべきなのか、種別に何を選ぶべきなのかが決まっていないからです。道具の操作は数分で覚えられますが、決め事のないまま使い始めたチームは、数週間で一覧が読めなくなります。この記事では、進行をとりまとめる立場の人が、課題の立て方という一点から運用全体を組み立て直せるように、プロジェクトの切り方、課題の種類とカテゴリー、担当と期限、状態の進め方を順に整理します。あわせて、プランごとの上限や2027年に予定されている料金改定など、運用の前提になる公式情報も確認します。

使い方でつまずいているのは操作ではなく決め事

進行管理の道具を入れたあと、チームで起きることはだいたい決まっています。最初の1週間は全員が課題を登録します。2週目に入ると、登録されるものと登録されないものが分かれ始めます。1か月後には、課題一覧に「処理中」のまま止まった項目が何十件も並び、誰もその一覧を進捗の根拠として信用しなくなります。ここまで来ると、朝会は結局チャットの履歴を遡って進めることになり、道具は記録置き場としてだけ生き残ります。

この崩れ方には共通の原因があります。課題を立てる基準がチームで共有されていないことです。ある人は「デザイン修正」という1行を課題にし、別の人は「トップページのファーストビューの画像を差し替える」という具体的な作業を課題にする。前者は誰がいつ終わらせたのか判定できず、いつまでも閉じられません。後者は完了の判定ができるので閉じられます。この2種類が同じ一覧に混ざった瞬間、一覧を上から順に見ても状況が分からなくなります。

もうひとつは、プロジェクトの切り方が最初に決まっていないことです。Backlogはスペースの下にプロジェクトを置き、プロジェクトの下に課題を置く構造になっています。プロジェクトの切り方を決めないまま走り出すと、課題は「とりあえずここに置いておく」場所に集まり、片方のプロジェクトだけが数百件に膨れます。あとから分割しようとすると、課題キーが変わることを気にして手が止まり、そのまま放置されます。

つまり、使い方の本題は画面の操作ではありません。次の4つを、チームで文章にして決めることです。

・プロジェクトをどの単位で切るか ・1件の課題をどのくらいの大きさにするか、件名と詳細に何を書くか ・種別とカテゴリーをそれぞれ何のために使うか ・状態を誰がいつ動かすか、完了は誰が押すか

この4つが決まっていれば、道具が変わっても運用は生き残ります。逆に、この4つが空白のままだと、どの道具に移っても同じ壊れ方をします。以下では、この順番で決め方を具体化していきます。

なお、画面上のボタンの位置やメニューの並びは版によって変わるため、この記事では「どこをクリックするか」ではなく「何を決めるか」を中心に書いています。実際の画面での操作手順は、公式のヘルプセンターで最新の案内を確認してください。

プロジェクトの切り方を最初に決める

課題の立て方を決める前に、その課題を置く箱を決める必要があります。プロジェクトの切り方は、あとから変えるのがいちばん面倒な部分なので、最初に時間をかける価値があります。

組織で切らず、終わりのある単位で切る

よくある失敗は、プロジェクトを部署名や担当チーム名で切ることです。「開発部」「マーケティング部」というプロジェクトを作ると、そこに入る課題には終わりがありません。部署は解散しないので、プロジェクトも永遠に閉じられず、課題は延々と積み上がります。半年後には、その部署の全員が過去1年分の課題一覧をスクロールして目的の項目を探すことになります。

代わりに、終わりが定義できる単位で切ります。「コーポレートサイトのリニューアル」「新料金プランのリリース」「2026年下期の採用」のように、完了条件が言葉にできるものです。終わりがあるということは、閉じられるということです。閉じたプロジェクトは一覧から消せるので、いま見るべき箱の数が増え続けません。

ただし、終わりのない定常業務も現実には存在します。問い合わせ対応、保守、経理の月次処理などです。これらは無理に案件単位に切らず、「保守・問い合わせ」のような常設プロジェクトを1つ用意し、そのなかをカテゴリーとマイルストーンで区切るほうが扱いやすくなります。常設プロジェクトは、月ごとや四半期ごとのマイルストーンを置いて、区切りで一度締めるという運用にすると、一覧が無限に伸びるのを防げます。

プランごとのプロジェクト数の上限を前提に切る

プロジェクトを細かく切りたくなったとき、必ず確認しておくべきなのが上限です。Backlogは契約しているプランによってプロジェクト数の上限が決まっています。公式の料金ページによれば、スタータープランはプロジェクト数5、スタンダードプランは100、プレミアムプランとプラチナプランは無制限とされています。フリープランはプロジェクト数1、ユーザー数10、総容量100MBとヘルプセンターに記載があります（いずれも2026年9月2日時点の公式ページの記載）。

この上限は、切り方の設計に直接効いてきます。スタータープランで運用しているチームが、案件ごとにプロジェクトを切る方針を取ると、5件目の案件で行き詰まります。上限に達したときの選択肢は、古いプロジェクトを削除するか、プランを上げるか、切り方そのものを変えるかの3つです。削除は履歴を失うので現実的ではなく、結局は「1つのプロジェクトに全部入れる」という運用に戻り、最初の問題に戻ります。

だからこそ、切り方はプランと一緒に決めます。案件数が年に数件で、同時に走るのが2つか3つなら、案件単位で切って問題ありません。同時に十数件が走る受託の現場なら、案件単位で切ることを前提にプロジェクト数の余裕があるプランを検討するか、顧客単位でプロジェクトを切って案件はマイルストーンで区切る、という設計に変えます。

切りすぎたときに起きること

逆に、プロジェクトを細かく切りすぎたチームにも典型的な症状があります。課題を登録するときに「これはどのプロジェクトだっけ」と迷う時間が生まれ、登録そのものが億劫になります。さらに、プロジェクトをまたいだ一覧が見えにくくなり、「今週、自分が担当している全部の作業」を把握するのに複数のプロジェクトを行き来することになります。

ひとつの目安として、日常的に開くプロジェクトが1人あたり5個を超えたら切りすぎを疑う価値があります。切り分けの基準は、関わる人が大きく違うか、完了時期が大きく違うか、この2つです。どちらも同じなら、同じプロジェクトのなかでカテゴリーやマイルストーンを使って区切るほうが、日々の負担は小さくなります。

課題の粒度をそろえる

プロジェクトの箱が決まったら、次はそこに入れる1件の大きさをそろえます。粒度がそろっていない一覧は、件数を数えても意味がなくなるため、進捗の把握ができません。

1件は「1人が終わらせられる作業」にする

粒度の基準として実用的なのは、「1人の担当者が、他人を待たずに終わらせられる作業か」という問いです。この条件を満たしていれば、担当者は自分の判断で着手でき、終わったら自分で閉じられます。誰かの確認を待たないと終わらない作業は、確認そのものを別の課題にするか、確認者を担当にした課題を後ろに置きます。

作業時間の目安を決めておくのも有効です。2時間から3日程度で終わるくらいを標準にすると、一覧の見通しが良くなります。1週間を超えそうな課題は、途中の状態が「処理中」のまま長く止まり、進んでいるのか止まっているのか外から分からなくなります。逆に15分で終わる作業を1件ずつ課題にすると、登録の手間のほうが大きくなり、誰も登録しなくなります。

大きすぎる作業は、親課題と子課題に分けます。Backlogには親子課題の機能があり、料金ページの記載ではフリープランでは利用できないとされていますが、有料プランでは大きな作業を分割して管理できます。分割の基準は、担当者が変わるところ、成果物が変わるところ、この2つで切ると自然な単位になります。

件名の書き方をチームで決める

件名は一覧に並ぶ唯一の情報です。ここが揃っていないと、一覧をスクロールしても内容が頭に入りません。決めるべきは、次の3点です。

・動詞で終えるか、体言で終えるか ・対象をどこまで書くか ・記号をどう使うか

実務でいちばん読みやすいのは、「対象＋どうするか」を1行で書く形です。「トップページのファーストビュー画像を差し替える」「請求書テンプレートに振込先を追記する」のように、読んだだけで完了条件が分かる書き方です。「デザイン修正」「請求書の件」のような名詞だけの件名は、書いた本人以外に伝わりません。

記号の使い方も先に決めます。件名の先頭に角括弧で領域を入れる書き方は読みやすい一方で、カテゴリー機能と役割が重複します。カテゴリーを使うなら件名の記号は使わない、と決めたほうが、あとで一覧を絞り込むときに迷いません。

詳細欄に書くことを型にする

詳細欄が自由記述のままだと、書く人によって情報量が大きく変わります。テンプレートを決めておくと、書く側の負担も読む側の負担も減ります。最低限、次の3つがあれば足ります。

・なぜやるか（背景、依頼元、関連する会話の要約） ・完了の条件（何がどうなったら終わりか） ・分かっている制約（期日の理由、依存する作業、参照する資料の場所）

特に「完了の条件」は、状態を進めるときの判断材料になります。ここが書かれていない課題は、担当者が「終わった」と思っても、依頼者が「まだ終わっていない」と考えることが起こります。差し戻しが増えるチームは、たいていこの欄が空です。

課題の種別とカテゴリーを使い分ける

Backlogには、課題を分類する軸が複数あります。種別、カテゴリー、マイルストーン、優先度、そして有料プランで使える属性のカスタマイズです。これらを何のために使うかを決めずに全部埋めようとすると、登録が重くなって続きません。

種別は工程、カテゴリーは領域で使う

実務で機能しやすい割り当ては、種別を「作業の性質」に、カテゴリーを「対象の領域」に使うやり方です。

種別の例としては、タスク、バグ、要望、質問、調査といった分け方があります。これは、その課題をどう処理するかが変わる軸です。バグは再現手順が要りますし、要望はやるかどうかの判断が先に必要です。処理の仕方が違うものを分けておくと、一覧を種別で絞ったときに、そのまま作業の待ち行列として使えます。

カテゴリーの例としては、フロントエンド、サーバー、デザイン、原稿、営業資料といった分け方があります。これは、誰が見るべきかが変わる軸です。カテゴリーで絞り込めば、自分の領域の課題だけを取り出せます。

この2つを混ぜると破綻します。種別に「デザイン」と「バグ」が並んでいると、デザインのバグをどちらにすべきか毎回迷います。軸の意味を1文で書いてプロジェクトの説明欄に置いておくと、新しく入った人も同じ基準で選べます。

増やしすぎない目安を持つ

分類は増やすほど細かく絞れますが、増やすほど選ぶ時間が増えます。種別は5個前後、カテゴリーは10個前後を上限の目安にして、それを超えそうなら統合を検討するくらいがちょうど良い水準です。

判断の基準は、「その分類で一覧を絞り込む場面が実際にあるか」です。3か月使って一度も絞り込みに使われなかった分類は、登録者の手間を増やしているだけなので削ります。逆に、絞り込みたいのに該当する軸がないなら追加します。分類は運用しながら育てるもので、最初に完成させるものではありません。

なお、課題の項目そのものを増やしたい場合、公式の呼称では「属性のカスタマイズ」にあたります。料金ページの記載では、この機能はプレミアムプランとプラチナプランで利用可能とされ、スタータープランとスタンダードプランには記載がありません。同ページには「一部の課題の属性（開始日、予定時間、実績時間）はスタンダードプラン以上でご利用いただけます」という注記もあります。独自の項目を運用の前提に組み込む場合は、契約プランで使えるかを先に確認しておく必要があります。

親課題と子課題の使いどころ

親子課題は、大きな作業を分割するための仕組みです。使いどころは、「ひとつの成果物に対して複数人が別々の作業をする」場面です。たとえば「採用サイトの公開」を親にして、原稿、デザイン、実装、公開作業を子にすると、親の進み具合を子の消化状況で見られます。

一方で、親子を深くしすぎると全体像が見えなくなります。階層は2段までに抑え、それ以上に分けたくなったらプロジェクトかマイルストーンで区切るほうが、一覧としては読みやすくなります。公式ブログには、孫課題にあたる3階層の対応が2026年夏頃のリリース予定として挙げられていますが、階層を深くできることと、深くすべきことは別の問題です。

担当と期限を決める

課題が立っても、担当と期限が入っていなければ、それは一覧に並んだメモにすぎません。ここが運用のいちばん壊れやすい部分です。

担当は必ず1人にする

担当者を複数にできる仕組みを求める声はよく聞きますが、進行管理の観点では担当は1人にすべきです。2人にすると、どちらも「相手がやると思っていた」という状態が生まれます。複数人の作業が必要なら、それは課題を分けるべきサインです。

担当を決めるタイミングも決めておきます。登録した人が仮の担当を入れる運用にすると、担当欄が空の課題が生まれません。仮でも入っていれば、その人が「これは自分ではない」と判断して付け替えられます。空欄のまま置かれた課題は、誰の目にも入らないまま沈みます。

とりまとめる立場の人がやるべきことは、担当を割り振ることそのものよりも、担当が偏っていないかを見ることです。一覧を担当者で絞って件数を並べれば、1人に20件以上が集まっているといった偏りはすぐ見えます。偏りは、その人が止まった瞬間にチーム全体が止まるという意味なので、早めに割り直します。

開始日と期限日をどう入れるか

期限日は、外部との約束がある課題には必ず入れます。逆に、内部の都合しかない課題にまで全部期限を入れると、守られない期限が一覧に並び、期限という表示そのものが軽くなります。期限は「守られること」に意味があるので、入れる基準を絞ったほうが機能します。

開始日については、料金ページの注記のとおり、開始日を含む一部の属性はスタンダードプラン以上での利用とされています。開始日を入れられる環境なら、期限だけでなく着手予定も置いておくと、いつから手を付ける想定なのかが分かり、直前になって慌てる事態が減ります。

期限が動いたときの扱いも決めておきます。よくあるのは、期限を過ぎた課題をそのまま放置し、赤い表示だけが増えていく状態です。期限は約束であると同時に予定なので、変わったら動かします。動かすときに、なぜ動いたのかをコメントに1行残す運用にすると、あとから振り返ったときに遅れの原因が追えます。守らせるための期限ではなく、状況を映すための期限として扱うほうが、一覧は長く生き残ります。

予定時間と実績時間を入れるかどうか

予定時間と実績時間も、スタンダードプラン以上で使える属性として料金ページに記載されています。入力するかどうかは、その数字を何に使うかで決めます。見積の精度を上げたい、外部への請求根拠にしたいといった目的があるなら入れる価値があります。目的がないまま「入れておこう」で始めると、入力の負担だけが残り、数か月で誰も入れなくなります。

入れると決めたら、入力のタイミングも決めます。実績時間は、作業した日のうちに入れないと精度が落ちます。週末にまとめて思い出しながら入れた数字は、判断材料としては使えません。

状態の進め方をそろえる

課題の状態は、進捗の一覧そのものです。ここの意味がチームでずれていると、一覧は読めなくなります。

それぞれの状態の意味を文章にする

Backlogの標準的な状態には、未対応、処理中、処理済み、完了があります。この4つの言葉の意味を、チームの言葉で定義しておきます。

・未対応：まだ誰も手を付けていない。担当は決まっていても着手前 ・処理中：担当者がいま手を動かしている。今日明日で触る状態 ・処理済み：担当者の作業は終わり、依頼者の確認を待っている ・完了：依頼者が確認して、もう触らない

この定義でいちばん大事なのは、処理済みと完了を分けることです。作業者と確認者を分けておかないと、作業者が「終わった」と判断した時点で完了になり、確認漏れが発生します。処理済みで止まっている課題の一覧が、そのまま確認待ちの行列になります。

もうひとつ決めるべきは、処理中に置いていい件数です。1人が同時に処理中にできるのを3件までにするといった上限を置くと、手を広げすぎて全部が中途半端になる状態を防げます。処理中が10件並んでいる人は、実際には1件も進んでいないことがほとんどです。

完了を押すのは誰かを決める

完了を押す人を決めていないチームは非常に多く、その結果として処理済みの課題が数十件たまります。原則としては、その課題を作った人、つまり依頼者が押します。依頼者が社外なら、社内の窓口担当が代理で押します。

週に一度、処理済みの一覧を上から見て、確認して完了に落とす時間を15分だけ取る。これだけで一覧の信頼度は大きく変わります。とりまとめる立場の人が定例で確保すべき時間があるとすれば、新しい課題を立てる時間ではなく、この確認の時間です。

状態を追加できるかはプランによる

標準の4つで足りない場合、状態そのものを追加したくなります。ヘルプセンターの記載によれば、フリープランでは「状態の追加・変更」は利用できないとされています。有料プランで状態を追加する場合も、増やしすぎには注意が必要です。状態が8個並ぶと、どこに動かすべきか毎回考えることになり、更新されなくなります。

追加を検討する価値があるのは、「待ち」を明示したいときです。先方の返答待ち、素材の到着待ちといった、こちらの手が動かせない状態を分けておくと、処理中の件数が実態に合います。追加するとしても、標準の4つに1つか2つ足すくらいにとどめるのが現実的です。

課題をまとめて扱うときに知っておくこと

課題の立て方が決まったら、既存の一覧をどう持ち込み、どう外に出すかも運用の前提になります。ここは公式ヘルプに具体的な条件が書かれているので、着手前に確認しておくと手戻りが減ります。

一括登録の条件

すでにスプレッドシートで管理している一覧がある場合、機能名としては「一括登録」でCSVファイルからまとめて登録できます。公式ヘルプに書かれている条件のうち、設計に影響するものは次のとおりです。

・一括登録用のCSVは専用テンプレートをダウンロードして使う必要があり、課題検索結果一覧の出力機能で出したCSVでは一括登録できない ・CSVは2行目から入力する（1行目は登録処理に必要な情報のため削除しない） ・入力できる項目は、件名（必須）、詳細、種別、担当者、開始日、期限日、予定時間、実働時間、カテゴリー、発生バージョン、マイルストーン、優先度、親課題 ・日付はハイフン区切り（例 2025-07-31）で、複数値はカンマ区切り ・課題の「状態」は入力できず、すべて「未対応」で登録される ・一度に一括登録できる課題は最大250件

実務で効いてくるのは、状態が入力できない点です。すでに半分終わっている案件をそのまま持ち込むと、全件が未対応として並びます。持ち込む前に、終わっている分は入れない、あるいは入れたあとで状態を手で直す時間を見込む、という判断が必要になります。件数が多い場合、250件ずつに分けて登録する段取りも先に組んでおきます。

カスタム属性を登録している場合はCSVにその項目が追加され、必須のカスタム属性はCSVへの入力が必須になる旨もヘルプに記載されています。属性を先に設計してから一括登録に進む順番のほうが、やり直しが少なくなります。

なお、Googleスプレッドシートを使った一括登録の案内も公式に用意されています。CSVによる一括登録との違いとして、Googleスプレッドシートでは孫課題を登録できない旨が公式ヘルプに書かれています。

書き出しの条件

外に出すほうも条件があります。公式ヘルプによれば、課題の検索結果はCSV形式やExcel形式で出力でき、課題とコメントをダウンロードできます。ここで注意したいのが、課題のコメントの取得上限数が200件とされている点です。議論の長い課題では、すべてのコメントが出力されるとは限りません。

Excel形式はセルが含むことができる合計文字数の制限を受けるため、文字数が大きい場合はCSV形式が推奨されると案内されています。詳細やコメントが長い運用をしているなら、最初からCSVを選ぶほうが安全です。

スペース全体をまとめて出したい場合は、有料オプションとして「スペースデータのバックアップ」が50,000円（税抜、別途消費税）で案内されています。課題やWikiなどのデータをCSV形式ファイルにし、共有ファイルや添付ファイルと一緒にGoogleドライブで提供するサービスです。ヘルプには注意点として、バックアップしたデータはBacklogにインポートできない旨が明記されています。

Gitについては、保管されているGitリポジトリをすべてgit cloneする方法が案内されており、Subversionについても専用のヘルプに手順があります。開発の履歴を持っているチームは、この経路を把握しておくと安心です。

工程表を見たいときのプラン条件

課題の一覧が整うと、次に見たくなるのが工程表です。ガントチャートがどのプランから使えるかは、運用の設計に直結します。

公式の料金ページの記載では、ガントチャートはスタータープランには無く、スタンダードプランで利用可能（表示範囲は6か月分）、プレミアムプランとプラチナプランでも利用可能とされています。フリープランでは利用できないとヘルプセンターに記載があります。

つまり、工程表を前提に運用を組むなら、スタンダードプラン以上が出発点になります。ここを知らずにフリープランやスタータープランで始めて、あとから「工程表が出せない」と気づくと、運用設計をやり直すことになります。逆に、工程表を必要としないチームであれば、課題一覧とマイルストーンだけで十分に回ります。工程表が必要かどうかは、外部に対して線表で説明する場面があるかで判断すると、迷いが減ります。

工程表を使う場合の注意は、線を引くこと自体が目的になりやすい点です。線を引くには開始日と期限日が要るので、全課題に日付を入れることになります。日付が動くたびに引き直す運用は負担が大きく、途中で更新が止まります。線表に載せるのは、外に説明する必要のある大きな単位だけにして、日々の作業は課題一覧で見る。この二段構えにすると、更新が続きます。

料金とプラン改定を運用の前提に入れる

課題の立て方を決めるうえで、プランの制約は無視できません。ここは2026年9月2日時点の公式ページに書かれている内容を、そのまま確認しておきます。

現行プランの料金

公式の料金ページには「価格は全て税抜表示です。別途消費税がかかります。」と明記されています。以下はすべて税抜の表記です。

プラン	月払い（月額）	年払い（月額換算）	ユーザー数	プロジェクト数	ストレージ
スターター	￥2,700	￥2,565	30	5	1GB
スタンダード	￥16,000	￥15,200	無制限	100	30GB
プレミアム	￥27,000	￥25,650	無制限	無制限	100GB
プラチナ	￥75,000	￥71,250	無制限	無制限	300GB

年払いは月払いに比べて5%オフと料金ページに記載されています。ユーザー数が無制限とされているプランには「安定した運用を維持するため、最大10,000人までを推奨」の注記があります。

課金の軸についても公式に説明があります。

プランと料金ページの料金は登録したスペース1つ分の金額です。スペースにプロジェクトやユーザーを追加されるごとに追加料金が発生することはありません。 出典: support-ja.backlog.com

つまりスペース単位の定額制であり、人が増えるたびに単価が積み上がる形ではありません。人数が読みにくいチームにとっては、費用が跳ねにくいという意味を持ちます。ただし、プランごとのユーザー数・プロジェクト数の上限は別途あるので、そこが実質的な区切りになります。

支払い方法については、銀行振込とクレジットカードのいずれかで、銀行振込は3か月分・6か月分・12か月分のいずれかの一括払い、クレジットカードは1か月分・12か月分のいずれかの一括払いと案内されています。振込手数料は利用者負担です。初期費用はかからず、料金ページに書かれている金額のみと明記されています。納品書や発注書など特別な書類への対応が必須の場合は1回10,000円（税抜）とされ、契約期間中に解約した場合の返金対応はないと書かれています。無料トライアルはどのプランも30日間です。

2027年1月からのプラン改定

料金ページには「※2027年1月1日からプランが変わります。」の注記があり、公式ブログとヘルプで内容が案内されています。運用を長く続ける前提なら、ここは先に見ておく価値があります。

・2026年12月31日で現在のプランでの新規契約が終了し、現行4プランは2026年12月31日まで提供 ・2027年1月1日から新しいプラン体系と料金の提供開始 ・既存契約への適用は、2027年1月1日以降の最初の契約更新日から。スペースごとに異なる

新プランは、現行の4プランが3プラン（エコノミー／ビジネス／プロフェッショナル）に統合される構成です。税抜の月払い料金は、エコノミーが¥21,000／月、ビジネスが¥36,300／月、プロフェッショナルが¥100,000／月と案内されています。年払いは月払いに比べて5%オフで、それぞれ¥19,950／月、¥34,485／月、¥95,000／月です。

上限についてもヘルプに記載があります。新しいフリープランはユーザー数5（現在の10から変更）、プロジェクト数1、ストレージ100MB。エコノミーはユーザー数15、プロジェクト数30（現スタンダードの100から変更）、ストレージ30GB。ビジネスとプロフェッショナルはユーザー数・プロジェクト数が無制限で、ストレージはそれぞれ100GB、300GBとされています。現在のスタータープランに対応する新プランは無く、比較表の該当欄は「ー」となっています。

そのほかの変更として、新しいフリープランとエコノミープランで2段階認証の必須化が×から◯に変わり、Nulab Passの契約が◯から×に変わる旨、適用開始日以降は銀行振込が12か月（年払い）のみになる旨がヘルプに記載されています。銀行振込の3か月・6か月を利用中の場合、適用開始日から自動的に年払いに変更されます。登録済みのデータは新しいプランでも引き続き利用でき、移行作業は不要と案内されています。

機能面では、Backlog AIアシスタントの継続改善、孫課題（3階層）が2026年夏頃、プロジェクト横断のガントチャートが2026年秋頃のリリース予定として公式ブログに挙げられています。ガントチャートの6か月以上の期間の表示とプロジェクト横断の表示は、新プランではビジネスとプロフェッショナルでのみ利用できる機能として案内されています。

金額や条件は今後も改定される可能性があるため、契約の判断をするときは必ず公式の料金ページで最新の記載を確認してください。

会話の置き場所をどう決めるか

課題の立て方と並んで、進行が崩れやすいのが会話の置き場所です。仕様の相談がチャットで進み、決まったことが課題に残らないと、あとから経緯を追えなくなります。

Backlogの料金ページの機能比較表には、課題ごとのコメントが全プランで「あり」と記載されています。課題に紐づく会話はここに残せます。一方で、Backlog本体の機能としての「チャット」については、料金ページの機能一覧に項目が見当たりません。同表のサポート欄にあるAIチャットボットは、サポート窓口の項目として掲載されているものです。

ヌーラボはビジネスチャットツール「Typetalk」を提供していましたが、2023年11月14日付でサービス終了が告知されています。2023年11月15日に無料トライアルとフリープランの新規申し込みを停止、2024年12月1日にプラン更新を停止、2025年12月1日にサービス終了、2025年12月31日にバックアップも含めてデータをすべて削除という日程が案内され、同記事には「今後はヌーラボのサービスに、多様な外部サービスを連携させながら」「ビジネスチャットツールの開発は終了しますが」と書かれています。

この事実からチームが受け取るべき結論はひとつです。日常の雑談や即時のやり取りは別のチャットツールで行い、決まったことは課題のコメントに残す、という役割分担を明文化しておくことです。ここを曖昧にすると、判断の根拠がチャットの流れのなかに沈み、半年後に「なぜこの仕様になったのか」を誰も説明できなくなります。運用の決め事としては、次の1行で足ります。決まったことは課題に、迷っていることはチャットに。

決め事を一枚に落とすという考え方

ここまで挙げてきた決め事は、どの道具を使っていても必要になるものです。プロジェクトの切り方、課題の粒度、種別とカテゴリーの役割、担当と期限、状態の意味。これらが文章になっていれば、道具の乗り換えは移行作業でしかなくなります。逆に、決め事がないまま道具だけ替えると、同じ壊れ方を新しい画面で繰り返します。

そのうえで、道具の側にも向き不向きがあります。課題の属性を細かく設計して、工程表や工数の集計まで一貫して管理したい現場では、機能の層が厚いほうが有利です。開発の履歴とタスクを同じ場所に置きたいなら、リポジトリを持っている道具のほうが手数が減ります。ここはBacklogが得意としている領域で、Git / Subversionはフリープランを含む全プランで利用可能と公式に記載されています。この使い方が中心なら、乗り換える理由はほとんどありません。

一方で、5人から数十人のチームで、やることの並びと担当と締切が見えていれば足りる、という現場もあります。属性を細かく設計するより、全員が毎日開いて動かしてくれることのほうが重要な場合です。この場合に効くのは、機能の多さではなく、覚えることの少なさです。課題を1枚のカードにして、板の上を左から右へ動かすだけ。決め事は「どの列に置くか」「誰の名前を貼るか」「いつまでか」の3つに絞る。この形にすると、入力する人が増え、一覧が実態に追いつきます。

板型の道具を検討する場合、判断の材料として押さえておくべき点をまとめておきます。まず、どこまでできるかは事前に確認しておく必要があります。板とカードで進行をまとめる道具の機能範囲はできることにまとまっており、何ができて何ができないかを先に見ておくと、入れてから困る事態を避けられます。

料金の考え方も、課題の立て方に影響します。プロジェクト数で費用が変わる仕組みだと、切り方が費用に引きずられます。機能で絞らず、区切るのは人数とボードの数だけという考え方であれば、どの機能が使えるかを気にせずに運用を設計できます。詳しい区切り方は料金に記載があります。

いま使っている道具からの移り方も、決め手のひとつです。Trelloからの移行には、既存のボードをそのまま取り込む手順がまとまっています。ただし、自動で取り込めるのはTrelloだけである点は先に知っておくべきです。他の道具から移す場合は、書き出したCSVを見ながら手で並べ直す作業が発生します。データの扱いや保管の考え方については安全性の考え方に整理されています。

道具ごとの向き不向きを並べて見たい場合は、比較の一覧から個別のページに入れます。Backlogとの違いを直接確かめたいならBacklogとの比較に、課題の属性の設計思想や工程表の扱いの差がまとまっています。板型の道具どうしで迷っているならTrelloとの比較とJootoとの比較が近い比較になります。タスクの一覧と工程表を両方求めるならAsanaとの比較、文書とタスクを同じ場所に置きたいならNotionとの比較、複数の部署をまたいだ運用を想定しているならmonday.comとの比較が判断の材料になります。導入前によく出る疑問はよくある質問にまとまっています。

こうした板型の道具にも、認めておくべき制約があります。リポジトリ機能は無いので、コードの履歴と課題を同じ画面で追いたい現場には向きません。自動化と外部連携では勝負しない方針なので、他システムと細かく連動させたい要件がある場合は別の選択肢を検討することになります。画面は日本語のみなので、海外のメンバーが日常的に触る体制には合いません。これらに当てはまるなら、いま使っている道具を続けるほうが合理的です。

最後に、判断の順番を整理しておきます。道具を替えるかどうかを先に考えるのではなく、この記事で挙げた5つの決め事を文章にしてみてください。書けるなら、いまの道具のままで運用は立て直せます。書いてみて、「この決め事はいまの道具では表現できない」という項目が出てきたときが、道具を見直す時期です。多くのチームで実際に詰まるのは、機能が足りないことではなく、決め事がないまま画面だけが増えていることのほうです。

Q1. Backlogのフリープランでどこまで試せますか？

公式ヘルプセンターの記載では、フリープランはプロジェクト数1、ユーザー数10、ドキュメント数5、総容量100MBです。Git / Subversionとファイル共有は利用できますが、ガントチャート、親子課題、状態の追加・変更、属性のカスタマイズは利用できないと記載されています。運用の型を試すには十分ですが、工程表や独自項目を前提にした設計は確認できません（2026年9月2日時点）。

Q2. 課題の種別とカテゴリーはどう使い分ければよいですか？

種別は「作業の性質」、カテゴリーは「対象の領域」に割り当てると混乱しません。種別はタスク、バグ、要望、質問のように処理の仕方が変わる軸で、カテゴリーはデザイン、サーバー、原稿のように見るべき人が変わる軸です。両方に同じ意味の値を置くと、登録のたびに迷いが生まれます。種別は5個前後、カテゴリーは10個前後を上限の目安にしてください。

Q3. 既存のスプレッドシートの一覧を取り込めますか？

公式ヘルプによれば「一括登録」機能でCSVから登録できます。専用テンプレートを使う必要があり、課題検索結果の出力CSVでは一括登録できません。1行目は削除せず2行目から入力し、日付はハイフン区切りです。一度に登録できるのは最大250件で、状態は入力できずすべて「未対応」で登録される点に注意してください。

Q4. ガントチャートはどのプランから使えますか？

2026年9月2日時点の公式料金ページでは、スタータープランには記載がなく、スタンダードプランで6か月分の表示、プレミアムプランとプラチナプランでも利用可能とされています。フリープランでは利用できません。2027年1月からの新プランでは、6か月以上の期間の表示とプロジェクト横断の表示がビジネスとプロフェッショナルでのみ利用できる機能として案内されています。