Backlog「孫課題」の便利な活用方法、活用時の注意点

2026年08月27日 09時00分更新

文● 大塚昭彦／TECH.ASCII.jp

提供: ヌーラボ

どう使うのが便利？現役Backlogユーザーにアイデアを聞きました

　それでは、この孫課題機能はどんなときに使うのが便利でしょうか。まずは筆者自身が、ASCII.jp編集部の業務をサンプルに考えてみました。

　孫課題の利用が適していると思うのは、イベント開催時（前述した例ですね）やYouTube生放送／映像収録などのタスク管理です。こうしたタスクには、準備段階から本番当日まで多くのメンバー（5人以上のイメージ）が関わり、多数の細かなタスクを並行して進める必要があるからです。

　親課題と子課題だけだと、細かなタスクを個々のメンバーに割り当てるのがやや面倒ですが、孫課題があればそれができます。「子課題まではプロジェクトリーダーが作るが、孫課題はタスクの担当メンバーが自由に作ってよい」といったルールにすれば、必要に応じてメンバー側でも課題を追加することができ、リーダーもメンバーも楽に運用ができそうです。

　一方で、孫課題まで使う必要はないかな？という用途もあります。たとえば、記事制作のタスク管理です。このタスクは関わる人数が少なく（1～3人程度）、並行して進むタスクも少ないので、親子課題、もしくは親課題のみ（階層化しない）で十分管理できます。むしろ、孫課題までタスクを分割しすぎると、管理が複雑になって面倒そうです。

セミナー開催のタスク（前述した例）を親／子／孫課題で整理。ちなみにガントチャートを「親課題」でグルーピングすると、親／子／孫のツリーをたたむことができて、より見やすくなる

アイデア：“失敗事例”の記録をタスクにひも付けて残す

　孫課題はほかにもさまざまな活用法がありそうです。現役Backlogユーザーの皆さんにも、ユースケースのアイデアを聞いてみました。

北海道ガスエンジニアリングソリューション部の峠幸寛さん。Backlog歴は5年です（写真は「Backlog World 2025」の登壇風景）

　北海道ガスの峠幸寛さんは、契約中の顧客へ新たに実施したい施策や提案のアイデアをBacklogで管理しています。ここでは親子課題を利用し、プロジェクトの概要や目的を「親課題」、具体的な施策や提案を「子課題」と整理して、子課題の中で実施の検討を行います。

　これまで、基本的にはこの親子分類で回ってきたものの、子課題で実施が確定した施策を、個々の物件（契約顧客）に適用したかどうか管理したい場合もあります。その場合、子課題の中でチェックリストを設けて管理しているため、各物件への適用状況は、子課題の詳細画面を開かないと進捗が見えません。

　そこで、このチェックリストを孫課題として切り出し、進捗の見える化に使いたいとのこと。「孫課題を使うことで、どの物件まで完了しているのかを課題一覧から確認できる構成を実現できそうなので、楽しみです」（峠さん）。

　もうひとつの活用アイデアは、孫課題にプロジェクトの実行結果、特に「うまくいかなかった」結果を書き残す、というものです。

　「うまくいったことは親課題／子課題に残しつつ、うまくいかなかったことを、その理由を含めて孫課題に残すことで、自社におけるアンチパターン（失敗事例）を取り出しやすくしたい。その抽出においては、Backlog AIアシスタントが使えると思います」（峠さん）

　親／子／孫という課題どうしの関係にとらわれず、実行したプロジェクトにまつわる詳しい情報を残すために孫課題を使う、というアイデアは面白いですね。

アイデア：他のツールに分散していた情報をBacklogに統合する

Fusic 技術コミュニティ統括室室長兼シニアエバンジェリストの清家史郎さん。Backlog利用歴は11年目だそうです（写真は「Backlog World 2024」の登壇風景）

　Fusicの清家史郎さんは現在、受託した業務システム開発のプロジェクト管理にBacklogを活用しています。このプロジェクトは大規模なもので、開発には複数のパートナー企業が参加しています。

　「これから作る機能の一覧をBacklogに集め、お客様とパートナー会社が同じ画面を見ながら、スクラム開発を進めています」（清家さん）

　ここでは、Backlogに独自の「課題の種別」を用意して、情報とタスクを管理しています。最上位である“大きな機能のかたまり（Epic）”、それを個々の機能まで分割した“機能（Story）”、そして実際に機能を開発する“実装タスク”の3階層です。

　ただし、これまでの親子課題は2階層だったため、3階層すべては収まりませんでした。そこで、Epic（親課題）－Story（子課題）はBacklog上で管理し、実装タスクは別途、Backlogの外にあるGitリポジトリで管理しています。「開発の進み具合を知るには、2つの場所を行き来することになります」（清家さん）。

　今回、Backlogに孫課題が追加されることで、3階層がすべてBacklogで管理できることになります。「孫課題があれば、日々の開発では孫を、スプリントの区切りではStoryを、全体を見渡すときは Epicを見るというように、同じツリーの深さを変えるだけで済みます」（清家さん）。

　またこれまで、Backlogに記録を残したい作業は、Epic－Storyのツリーとは別のツリー（親課題）を用意して、その子課題としてぶら下げるしかありませんでした。これも、孫課題としてEpic－Storyのツリーの配下に置くことができます。

　「同様に、技術的負債が生じた場合も、現在はEpicの直下に置いていますが、本来はどのStoryの実装で生まれたかをはっきりさせたいところです。孫課題としてStoryの下に置くことができれば、技術的負債が生まれた場所も、解消できていない課題も、ツリーの形で分かりやすく整理できます」（清家さん）

　社内のエンジニアだけでなく、社外の顧客企業やパートナー企業が見ても分かりやすい形での情報整理を進めるうえで、孫課題が大いに活躍しそうです。

注意点：孫課題の位置づけや使い方のルールをチーム内で統一すること

　孫課題を使ううえでの注意点としては、プロジェクトチーム内であらかじめ「親／子／孫課題の粒度、位置づけの意識合わせを行う」ことが挙げられます。

　チームメンバーの間で「どんな場合に孫課題を使うのか／使わないのか」という意識合わせをしておかないと、孫課題があまり使われなかったり、その反対に、ばらばらの目的で孫課題が作られて混乱したりすることになりかねません。管理者が簡単なルールを作って、「こういうケースでは孫課題を使ってください」と呼びかけるのがよいでしょう。

　子課題を孫課題に分割するかどうかの基本的な判断基準は、「担当者や進行スケジュールが異なるタスクが含まれるかどうか」だと思います（これは親課題／子課題の判断基準と同じです）。

　複数の担当者が並行してタスク（子課題）に取り組む、あるいは進行スケジュールが並行して進むタスクであれば、孫課題に分割すると便利です。その反対に、1人の担当者で完結するタスク、進行スケジュールを個別に管理しなくてよい（並行して動かない）タスクであれば、分割せず子課題のまま扱うほうが混乱は少ないはずです。

　なお、タスクを細分化して進捗を確認するうえでは「チェックリスト」も便利です。1人の担当者で完結する子課題であれば、孫課題を作るのではなく、複数のタスクをチェックリストで管理するのが手軽で良いと思います。