Backlogの課題管理実務ガイド：種別・ステータスからドキュメント・ガントチャートまでをつなぐ運用設計

ツールを選んだ後に、機能をどうつなぐかが残る

当サイトの「プロジェクト管理ツール比較」では、Backlogを「予測型で工程表を軸に管理し、関係者が多く、日本語での運用と問い合わせを重視する組織」向けの有力な選択肢として整理した。だが実際にBacklogを選んだ後、PMが向き合うのは機能一覧の理解ではなく、課題・ドキュメント・ガントチャートという3つの機能をどう組み合わせて1つの進捗管理の流れに仕立てるかという設計である。

この3つは別々の画面で操作するため、設計せずに使い始めると、課題は積み上がるが誰が何に取り組んでいるか分からない、文書には古い仕様書が置き去りにされる、ガントチャートは作った日から更新されない、といった状態に陥りやすい。この記事は、Backlog公式ヘルプセンターとBacklogブログの一次情報に基づき、3つの機能をつなぐ設計手順を示す。Jiraのボード運用実務ガイドと同じく、ツールを選んだ後の「使いこなす」段階を扱う。

この記事の編集基準

本記事にアフィリエイトリンク・紹介料・掲載料は一切ない。機能や仕様の記述は、Backlog公式ヘルプセンター（support-ja.backlog.com）およびBacklogブログ（backlog.com/ja/blog）で確認できた範囲に限定している。

3機能の役割分担を先に決める

課題・ドキュメント・ガントチャートは別の画面だが、元になるデータは同じ「課題」である。課題に何を入力するかが、ドキュメントの参照先とガントチャートの見え方の両方を決める。

課題を作る前に決める3つの属性：種別・優先度・状態

Backlogで課題を追加する際に必須となる入力項目は、件名・種別・優先度の3つである。件名以外の2つは、あらかじめ設計しておかないと現場ごとに使い方がばらつく。

優先度は「高」「中」「低」の3段階が既定で用意されている。「高」は最も緊急度の高い課題、「低」は時間のあるときに対応する課題という位置づけで、これ自体に複雑な設計は要らない。

設計の余地が大きいのは種別と状態である。種別は作業の性質による分類で、種別ごとに課題のテンプレートを設定できる。状態は「未対応」→「処理中」→「処理済み」→「完了」という4段階の既定フローで進捗を表す。この4段階をチームがどう使うか（たとえば「処理済み」はレビュー待ち、「完了」はレビュー通過後、といった定義）を先に合意しておくことが、後述のガントチャートを機能させる前提になる。

種別・カテゴリー・マイルストーンという3つの分類軸

課題を大量に扱うようになると、種別だけでは絞り込みが効かなくなる。Backlogには種別に加えて、内容によって分類するカテゴリーと、時期・フェーズによって分類するマイルストーンが用意されている。

カテゴリーは「何についての課題か」、マイルストーンは「いつまでに終わらせる課題か」を表す軸である。マイルストーンにはプロジェクトの節目（リリース・検収など）を登録し、課題を紐づけることで、フェーズ単位の進捗を追える。種別・カテゴリー・マイルストーンを組み合わせて絞り込むと、大量の課題からも狙った切り口ですぐに一覧を作れる。

この3軸を後から追加すると、既存の課題への再設定作業が発生する。プロジェクト開始時点で、少なくともマイルストーン（フェーズの単位）とカテゴリー（成果物や機能の単位）は先に設計しておくべきである。

親子課題で、大きな課題を分割する

1つの課題が大きすぎると、状態が長期間「処理中」のまま止まり、進捗が見えなくなる。Backlogは課題を親子関係で分割する機能を持ち、子課題は親課題に紐づく形で個別に状態・担当者・期限を持てる。

親子課題を有効にしたプロジェクトでは、ガントチャート上でも親課題ごとに子課題をグルーピングして表示できる（プロジェクトのガントチャートのグルーピング設定で「親課題」を選択する）。工程表の行数が多くなりすぎる場合、この設定でWBSの階層とガントチャートの見た目を合わせられる。

ドキュメントとWiki：2026年7月の変更を踏まえた置き場所の設計

仕様書・議事録・運用ルールといった文書情報の置き場所は、2026年に大きな変更があった。Backlogは2025年12月1日にドキュメント機能を正式リリースし、既存のWikiページを一括でドキュメントへ移行する「ドキュメント移行機能」も同時期から順次提供を始め、2026年1月中に全組織で利用可能になった。

続いて2026年7月14日（火）以降、新たにBacklogの利用を開始するスペースではWiki機能自体が提供されなくなり、ナレッジ管理はドキュメント機能が前提になった。既存スペース内で新しく作るプロジェクトでも、Wiki機能の初期設定はオフになる（プロジェクト設定で個別にオンへ戻すことは可能）。すでにWikiを使っている既存のプロジェクトは、この変更の影響を受けず、そのまま使い続けられる。

この経緯から、置き場所の判断は次のように整理できる。2026年7月14日以降に新規で始めるプロジェクトは、ドキュメント機能を前提に文書を置く。すでにWikiで運用している既存プロジェクトは、無理に移行せずそのまま使うか、ドキュメント移行機能で一括移行するかを選べる。移行を実行すると、そのプロジェクトではWikiへの新規追加・編集ができなくなり、移行済みのページは「Wiki移行データ」フォルダにまとめられたドキュメントとして残る。

Wiki側で運用を続ける場合の整理術も押さえておく。ページ名をスラッシュ（/）で区切ると、その区切りがそのままツリー表示の階層になる。ページ名の先頭に[タグ名]を入れるとタグが付き、タグ単位での検索ができる。ページ数が増えるプロジェクトほど、階層とタグの設計を先に決めておく価値がある。

ガントチャートで工程表に落とす：プラン要件と表示条件

ガントチャートはフリープランとスタータープランでは使えず、スタンダードプラン以上が対象になる。工程表による管理を前提にBacklogを選ぶ場合、実質的な入口はスタンダードプラン以上になる点は選定段階で確認しておく必要がある（プラン別の価格は「プロジェクト管理ツール比較」にまとめている）。

課題をガントチャートに表示させるには、その課題に開始日・期限日・マイルストーン・完了日（自動設定）のいずれかが設定されている必要がある。件名・種別・優先度だけを入力してガントチャートを開いても、日付情報のない課題は表示されない。工程表として運用するなら、着手が決まった課題には開始日と期限日を入力する運用ルールを、課題作成時のルールとして決めておく。

新しいガントチャート（β版）では、表示する課題を種別・カテゴリー・マイルストーン・担当者で絞り込める。ブロック5で設計した分類軸は、ここで「今週見るべき課題だけを絞り込む」という形で効いてくる。エクスポートにも制限があり、Excel形式でのダウンロードは一度に6か月分の期間までという条件がある。工程表の考え方そのもの（依存関係やクリティカルパス）は「ガントチャートの作り方」を参照してほしい。

3つの機能を1つの運用につなぐ手順

ここまでを、プロジェクト開始時に踏む順序として並べ直す。