RedmineでWBSを作る手順と限界｜親子チケットで分解して工程表につなぐ
redmine wbs 作り方 で検索する人が本当に知りたいのは、たいてい2つです。1つは、Redmineの画面のどこを使えばWBSの形になるのか。もう1つは、作ったあとにそれが工程表として使えるのか、です。
Redmineには「WBS」という名前の画面はありません。そのため、機能の一覧を眺めても対応するものが見つからず、プラグインを探し始める人が多くなります。ただし実際には、プロジェクト、サブプロジェクト、親子のチケット、バージョン、そしてチケット同士の関連という標準の部品を組み合わせるだけで、WBSに相当する構造は作れます。
この記事では、成果物の洗い出しから始めて、分解、粒度の調整、担当と日付の設定、前後関係の登録、そしてガントチャートへの反映までを順に扱います。あわせて、標準の機能では届かない範囲がどこかを、公式の記載に沿って確かめます。読み終えたときに、自分の案件でどこまでRedmineで作り、どこから別の手段に頼るかを判断できる状態を目指します。
WBSは作業の分解であって、工程表そのものではない
最初に用語を整理しておきます。ここを混ぜたまま作り始めると、途中で目的を見失います。
WBSは Work Breakdown Structure の略で、成果物を上から順に分解して、実行できる大きさの作業まで落とし込んだ構造のことです。要点は、時間の話がまだ入っていないという点にあります。誰がいつやるか、どの順でやるかは、分解が終わってから決めます。
一方、工程表は時間軸の上に作業を並べたものです。ガントチャートはその表現の1つで、いつ始めていつ終わるかと、その前後関係を見せます。
この2つを分けておくと、Redmineでの作業も分かれます。分解は親子のチケットで表現し、時間軸は開始日と期日とバージョンで表現し、前後関係はチケットの関連で表現します。同じ画面の中で3つのことを同時にやろうとすると、必ずどこかが雑になります。
現場では、この順番が守られないまま作られたWBSをよく見かけます。日程が先に決まっていて、そこに作業を割り当てる形で作られたものです。分解が不十分なまま線だけが引かれているので、作業が始まってから抜けが見つかり、そのたびに線を引き直すことになります。分解を先に終わらせておくと、あとで日程が動いても構造は動きません。ここが分けておく最大の利点です。
Redmineのどの部品が、WBSのどの階層に対応するか
Redmineには階層を表現できる部品が3種類あります。それぞれ性質が違うので、対応を決めてから使い始めてください。
・プロジェクトとサブプロジェクト。最も大きな単位です。権限とメンバーの単位でもあるため、見せる相手が違うところで切るのが原則です ・親子のチケット。1つのチケットの下に子のチケットを並べる形で、実際の分解はここで表現します。階層は深く作れますが、実務では3階層までに収めると読みやすくなります ・バージョン。日付を設定できる区切りで、マイルストーンに相当します。工程表の上に大きな節目を置きたいときに使います
対応の例を挙げると、次のような形になります。
| WBSの階層 | Redmineの部品 | 例 |
|---|---|---|
| 案件全体 | プロジェクト | 新サービスの立ち上げ |
| 大分類 | 親のチケット、またはバージョン | 要件の整理、設計、制作、検収 |
| 中分類 | 親のチケット | 画面の設計、データの設計 |
| 作業 | 子のチケット | 一覧画面のワイヤーを引く |
サブプロジェクトを大分類に使う方法もありますが、おすすめしません。サブプロジェクトは権限とメンバーの単位なので、大分類ごとに分けると、メンバーの追加や権限の設定を分類の数だけ行うことになります。見せる相手が同じなら、1つのプロジェクトの中で親子のチケットに分けるほうが軽くなります。
もう1つ、トラッカーで階層を表現しようとする設計も見かけます。大分類のトラッカー、中分類のトラッカー、作業のトラッカーを作る形です。これも避けたほうが無難です。トラッカーはワークフローの遷移を定義する単位なので、階層のために増やすと、ステータスの設計が階層の数だけ複製されます。
手順1から3、成果物を書き出して分解する
ここから実際の作り方に入ります。全体は5つの手順に分かれます。
最初にやるのは、作業ではなく成果物を書き出すことです。何を作るのか、何を納めるのかを名詞で並べます。「設計する」ではなく「設計書」、「テストする」ではなく「テスト結果の報告」という書き方です。動詞で書き始めると、作業の数だけ思いつくままに並んで、抜けが見えなくなります。名詞で書くと、納めるものが揃っているかどうかで抜けを確認できます。
次に、その成果物を作るために必要な作業へ分解します。ここで初めて動詞が出てきます。1つの成果物につき、3つから7つ程度の作業に分けるのが目安です。2つしか出てこないなら分解が粗く、10を超えるなら粒度が細かすぎます。
3つめが粒度をそろえる作業です。ここを飛ばすと、あとで工程表が読めなくなります。目安は、1つの作業が2日から5日で終わる大きさです。この範囲に収めると、週に1度の更新で進捗が意味のある数字になります。
半日で終わる作業は、チケットにせずチェックリストとして親の説明欄に書きます。作業として登録すると、更新の手間が実際の作業時間を上回ります。逆に2週間かかる作業は、必ず分割してください。2週間動かない進捗は、遅れているのか順調なのかが判別できません。
粒度をそろえるときに使える判断の目安を挙げます。
・1人で完結するか。2人以上が関わるなら、たいてい分けられます ・終わったかどうかを他人が判定できるか。判定できないなら、成果物の定義が曖昧です ・途中で止まったときに、どこまで進んだかを説明できるか。説明できないなら大きすぎます
この3つを満たすまで分解すると、作業の数はおおむね案件の規模に比例して落ち着きます。1か月の案件なら20件から40件、3か月なら60件から120件が現実的な範囲です。これを大きく超えるなら、粒度が細かすぎるか、案件を分けるべき状態です。
手順4と5、日付と前後関係を入れて工程表につなぐ
分解が終わったら、時間の情報を入れます。
Redmineでは、チケットに開始日と期日を入れます。この2つが工程表の元になります。公式のWikiには次のように書かれています。
The gantt chart displays issues that have a start date and a due date or are assigned to a version with a date. 出典: redmine.org
つまり、開始日と期日の両方が入っているチケット、または日付を設定したバージョンに割り当てられているチケットが図に出ます。逆に言えば、期日だけ入れて開始日が空のチケットは、思った形では図に出ません。工程表が薄く見える原因の大半はここです。
親のチケットについては、子のチケットの日付から期間が算出されます。したがって親に日付を手入力する必要はありません。子の日付を動かせば親の帯も動きます。この仕組みがあるので、分解を親子で作っておくと、工程表が自動で階層の形になります。
バージョンには日付を設定できます。要件の確定、設計の完了、検収といった節目をバージョンとして作り、それぞれに日付を入れておくと、工程表の上に区切りが並びます。バージョンの名前は、開発の反復の番号でも、案件の工程の名前でも構いません。
最後が前後関係です。Redmineのチケットには複数の関連が用意されていて、そのうち工程に効くのが「先行する」と「後続する」の組み合わせです。公式には、この関連は順序を定義するもので、AがBの開始よりも何日前に完了している必要があるかを設定できると説明されています。Aの終了日を後ろにずらすと、Bの開始日と終了日も一緒に動きます。
ここで注意したいのは、関連を入れすぎないことです。すべての作業をつなぐと、1つ動かしただけで全体が組み替わり、意図しない日程になります。つなぐのは、遅れが本当に後工程へ波及する箇所だけにしてください。目安として、作業の数の2割から3割程度に関連が付いていれば、工程表として十分に機能します。
関連には他にも、関連する、重複する、ブロックする、複製元である、といった種類があります。工程の話ではなく、作業の性質を記録したいときに使い分けてください。ブロックするの関係は、閉じられるかどうかに影響します。BがAをブロックしている場合、Bが閉じられるまでAは閉じられません。
CSVで一括登録するときに、つまずきやすい点
作業の数が数十件を超えると、画面から1件ずつ作るのは現実的ではありません。Redmineは課題のCSVによる取り込みに対応しているので、表計算ソフトで一覧を作ってから流し込む方法が使えます。
進め方としては、まず表計算ソフトで次の列を用意します。
・件名。作業の名前です ・トラッカー。既定ではbug、feature、supportの3つが用意されています ・担当者。Redmineに登録されている名前と一致させる必要があります ・開始日と期日。書式を統一してください ・親のチケット。階層を作る場合に指定します
つまずきやすいのは階層の指定です。取り込みの時点では親のチケットの番号がまだ決まっていないため、親と子を同じ回で取り込もうとすると参照できません。親だけを先に取り込んで番号を確認し、そのあとで子を取り込む、という2回に分ける進め方が確実です。
もう1つが担当者の指定です。表記が1文字でも違うと割り当てられません。姓と名の間の空白が全角か半角かで落ちることがあるので、Redmine側の一覧から名前をコピーして使ってください。
取り込む前に、必ず試験用のプロジェクトを1つ作って、そこで数件だけ流してみてください。本番のプロジェクトにいきなり流すと、間違いに気づいたときに数十件のチケットを手で消すことになります。
前後関係の関連は、取り込みでは設定できません。取り込みのあとに画面から入れることになります。前述のとおり付けるのは2割から3割で足りるので、この手作業はそれほど重くなりません。
WBSを作る前に、抜けを見つけるための3つの問い
分解を始める前に確かめておくと、あとから作業を足す回数が減ります。作り直しがいちばん多く発生するのは、成果物の洗い出しが浅かったときです。
1つめの問いは、誰かに渡すものが何かです。案件の中では、自分たちが作るものだけでなく、相手に確認してもらうもの、承認をもらうもの、引き渡すものがあります。この受け渡しの回数だけ、待ち時間が発生します。待ち時間を作業として置いておかないと、工程表の上では前の作業が終わった翌日に次が始まる形になり、実際とずれます。
2つめの問いは、誰かから受け取るものが何かです。素材の支給、仕様の確定、他部署からの回答など、自分たちでは動かせない作業があります。これを工程表に載せておかないと、遅れの原因が記録に残りません。相手の作業として置き、担当を相手の窓口の名前にしておくと、進捗の確認のたびに自然と話題になります。
3つめの問いは、最後に何が起きるかです。検収、引き渡し、公開、報告といった終わりの手続きは、忘れられがちです。とくに公開のあとの見守りの期間や、初期の不具合への対応は、工程表に無いまま人が動くことになります。案件の終わりから逆算して置いておくと、次の案件の開始日を現実的に決められます。
この3つで洗い出した項目を、成果物の一覧に足してから分解に入ってください。分解のあとで足すと、階層の置き場所に迷って構造が崩れます。
3階層のWBSを、実際に組んでみる
手順だけでは形が見えにくいので、具体的な例で組み立ててみます。題材は、社内向けの申請システムを3か月で作り直す案件とします。関わるのは6人、うち工程表を引くのが1人という想定です。
最上位はプロジェクトです。ここでは「申請システムの刷新」という名前で1つ作ります。サブプロジェクトは作りません。関わる人が全員同じで、見せる範囲を分ける必要が無いためです。
次にバージョンを作ります。節目に相当するものを4つ置きます。要件の確定、設計の完了、開発の完了、検収の完了です。それぞれに日付を入れておくと、工程表の上に区切りが並びます。バージョンは後から日付を動かせるので、この時点では暫定の日付で構いません。
その下に、大分類の親チケットを置きます。要件、設計、開発、テスト、移行、の5つです。この5つには日付を入れません。子の日付から自動で算出されるためです。
さらにその下に、作業の子チケットを並べます。たとえば設計の下には、画面の一覧を作る、画面ごとのワイヤーを引く、データの構造を決める、権限の設計をする、レビューを受けて直す、という5件が入ります。それぞれに担当と、開始日と期日を入れます。
この構造で組むと、工程表を開いたときに、上から順に大分類の帯が並び、その下に作業の帯が並びます。大分類の帯は子の期間の合計として自動で伸び縮みするので、どこかの作業が遅れると、上の帯もそのまま伸びます。遅れが視覚的に上へ伝わるので、報告のときに説明が要りません。
前後関係は、この案件では4本だけ入れます。要件の確定が終わってから設計を始める、データの構造が決まってから開発を始める、開発が終わってからテストを始める、テストが終わってから移行を始める、の4本です。作業の数は全部で30件ほどになりますが、関連は4本で足ります。細かい作業どうしをつながなくても、大分類のあいだをつないでおけば、遅れの波及は追えます。
役割と権限を、WBSの構造と合わせる
WBSを作ったあと、意外と手戻りが出るのが権限の設定です。Redmineは役割を自分で定義して権限を設定できる作りなので、自由度が高いぶん、後から変えると影響範囲が読みにくくなります。
先に決めておきたいのは3点です。
1つめは、誰がチケットを作れるかです。全員が作れる設定にすると、WBSの構造の外に作業が生まれます。作れる人を絞ると、抜けが報告されず放置されます。実務では、全員が作れるようにしたうえで、親の指定を必須にしない代わりに、週に1度、親が付いていないチケットを一覧で確認する運用が扱いやすくなります。
2つめは、誰が日付を変えられるかです。工程表を引く人だけが日付を変えられる設定にすると、担当者は遅れを自分で反映できません。逆に全員が変えられると、工程表が知らないうちに動きます。折衷案としては、担当者は自分のチケットの日付を変えられるようにして、変更があったときに通知が飛ぶ設定にしておく形です。
3つめは、誰が親子の構造を変えられるかです。分解の構造そのものは、案件の途中で崩れると読めなくなります。ここは工程表を引く人に限定して構いません。
権限の設計は、案件が始まってからでは変えにくくなります。人が増えるたびに役割を割り当てる作業も発生するので、案件の種類ごとに標準の役割を決めておくと、2件目以降が楽になります。社外の協力会社が入る案件では、閲覧と自分のチケットの更新だけを許す役割を用意しておくと、毎回の設定が1操作で済みます。
作業時間の記録を乗せて、次の見積もりに使う
WBSを作る目的は、その案件を回すことだけではありません。次の案件を見積もるための材料を作ることでもあります。ここまで見据えて作ると、2件目以降の精度が上がります。
Redmineは作業時間の記録に対応していて、プロジェクト単位でもチケット単位でも入力できます。ユーザー、トラッカー、カテゴリ、活動の種類ごとに時間を集計する簡単なレポートも用意されています。
使い方としては、チケットに予定工数を入れておき、実際にかかった時間を各自が記録する形です。案件が終わったあとに、予定と実績の比を作業の種類ごとに出すと、次の見積もりの係数になります。たとえば画面のワイヤーを引く作業が、毎回予定の1.5倍かかっているなら、次からはその分を最初から積んでおけます。
ただし、時間の記録は運用の負担が最も大きい部分です。全員に毎日入力させると、たいてい2週間で止まります。始めるなら、次のどちらかに絞ってください。
・案件の中でいちばん見積もりを外している作業の種類だけ、時間を記録する ・週の終わりに、その週にかかったおおよその時間を作業の種類ごとにまとめて入れる
15分単位で正確に記録することに意味はありません。次の見積もりに使える粒度、つまり半日単位でおおよそ合っていれば十分です。精度を上げようとすると入力が止まり、入力が止まればデータが無くなります。粗くても続くほうが価値があります。
集計するときは、担当者ごとの数字を評価に使わないでください。使った瞬間に、記録される数字が実態から離れます。見るのは作業の種類ごとの傾向だけにとどめると、記録が正直なまま残ります。
標準の機能で届かない範囲は、3つある
ここまでの手順でWBSと工程表は作れます。そのうえで、標準の機能では届かない部分が3つあります。移行や併用を検討するかどうかは、この3つが自分の運用で致命的かどうかで決まります。
1つめは、図の上で直接組み替えられないことです。ガントチャートはチケットの日付から自動で描かれる図なので、線をつかんで動かすと日付が変わる、という操作は想定されていません。日程を変えるにはチケットの日付を直します。工程を引き直す作業が主業務になっている人には、この往復が負担になります。
2つめは、資源の平準化が自動では行われないことです。1人に同じ週の作業が5件割り当てられていても、Redmineは警告を出しません。誰がいつ何件抱えているかを見るには、担当者で絞ったクエリを保存して自分で確認する運用になります。人単位の負荷を図で見たい場合は、標準の画面には見当たりません。
3つめは、当初の計画を保存して実績と比べる仕組みが標準に見当たらないことです。日程を動かすと元の日付は上書きされるため、最初の計画から何日ずれたかを後から追うには、取り込みの前にCSVで控えを取っておくといった運用の工夫が要ります。
この3つのうち、1つめと3つめは公式のプラグインの一覧に対応するものが公開されている場合があります。導入する場合は、本体のバージョンに追従して更新されているかを先に確かめてください。プラグインは本体の内部の作りに依存するため、更新が止まっているものを入れると、本体のセキュリティ更新を当てられない状態になります。
作ったWBSを運用に載せるために決める3つのこと
WBSを作り終えたところで満足してしまい、1か月後には誰も更新していない、という結末は珍しくありません。運用に載せるために決めるべきことは3つです。
1つめは、更新の頻度と担当です。週に1度、決まった曜日に各担当が自分のチケットを更新する形がいちばん定着します。とりまとめる人が全員分を代わりに入力する形にすると、負担が1人に集まり、しかも進捗の精度が落ちます。入力する人が増えないと、進捗の表はすぐ嘘になります。
2つめは、作業を追加するときのルールです。実際に始まると、WBSに無かった作業が必ず出てきます。これを既存のチケットの説明欄に書き足すと、工程表に反映されません。新しいチケットとして追加し、適切な親の下に置く、というルールを最初に決めておいてください。
3つめは、終わったかどうかの判定です。進捗率を各自の感覚で入れると、8割で止まるチケットが増えます。判定できる形にするには、完了の条件をチケットの説明欄に1行で書いておくのが確実です。「レビューを受けて指摘が0件になったら完了」のように、他人が見ても分かる書き方にします。
加えて、案件が終わったあとにWBSを見直す時間を30分だけ取ってください。実際にはどこで分解が足りなかったか、どの作業が想定の何倍かかったかを振り返り、次の案件のひな型に反映します。これをやるかどうかで、3件目以降の精度がはっきり変わります。振り返りを飛ばすと、毎回ゼロから組み直すことになります。
この3つが決まっていれば、道具が何であっても運用は回ります。逆に決まっていなければ、どんなに高機能な道具を入れても同じ結果になります。
別の道具でWBSを作る場合に、何が変わるか
Redmineの標準機能で届かない部分が業務の中心にあるなら、別の道具を併用する選択肢が出てきます。判断の材料として、他のサービスの立ち位置を並べておきます。
板を横に並べる形の道具は、分解した作業を動かしながら見ることに向いています。Trelloの無料プランはワークスペースあたり10ボード、10コラボレーターまでで、カレンダーやタイムラインやテーブルのビューはPremium以上です。無料でどこまで使えるかはTrelloとの比較に整理があります。
自動化と外部連携の幅で選ぶなら、Asanaとの比較とmonday.comとの比較が判断材料になります。文書とデータベースを同じ場所に置き、WBSの表そのものを構造化して持ちたい場合はNotionとの比較が近い形です。
国内のサービスは前提が動いています。Backlogは2026年12月31日で現行プランの新規契約が終了し、2027年1月1日から新しい3つのプランに移ります。フリープランのユーザー上限は10名から5名になります。詳細はBacklogとの比較にあります。各サービスの料金と上限を横並びで見るなら比較の一覧にまとめてあります。
道具を足すときに見ておきたいのが、工程表を見るために上位プランへ移る必要があるかどうかです。ガントチャートやカレンダーの表示が上位に置かれている設計だと、進捗を見たいという理由だけで全員分の単価が上がります。機能で段階を分けず、区切るのが人数とボードの数だけという形なら、この移動が起きません。実際に何ができるのかはできることに、条件は料金に載っています。
道具を比べるときは、機能の一覧ではなく自分たちの条件から入ってください。工程表を触る人数、案件の長さ、社外の人が入るかどうか、社内の審査があるかどうかの4つを先に書き出すと、候補は2つか3つに絞れます。機能から入ると、どの道具にも足りない部分が見つかっていつまでも決まりません。
併用を決める場合の原則は1つで、同じ作業を2か所に書かないことです。分解の詳細と開発の記録はRedmineに残し、社外の人が見る進行だけを板に出す、という分け方が運用しやすくなります。移す場合の実際の手順はTrelloからの移行に書かれている形が参考になります。データの置き場所や権限の設計といった社内の審査で必ず聞かれる論点は安全性の考え方に、契約や運用の細かい疑問はよくある質問にまとまっています。
Q1. RedmineにWBSという名前の機能はありますか？
その名前の画面はありません。プロジェクトとサブプロジェクト、親子のチケット、バージョン、チケット同士の関連という標準の部品を組み合わせて作ります。分解は親子のチケットで表現し、節目はバージョンで置き、前後関係は関連で設定するのが基本の形です。標準で作れる範囲を確かめてから、足りない部分だけプラグインを検討してください。
Q2. 作業をどのくらいの大きさに分ければよいですか？
1つの作業が2日から5日で終わる大きさが目安です。半日で終わるものは親の説明欄にチェックリストとして書き、2週間かかるものは分割してください。判断の基準は、1人で完結するか、終わったかどうかを他人が判定できるか、途中で止まったときにどこまで進んだか説明できるか、の3つです。
Q3. ガントチャートに一部のチケットが出てきません。なぜですか？
公式には、開始日と期日の両方が入っているチケット、または日付を設定したバージョンに割り当てられているチケットが表示されると説明されています。期日だけ入れて開始日が空になっていると、思った形では出ません。まず日付の入力状況を確認してください。親のチケットは子の日付から期間が算出されるため、親に日付を手入力する必要はありません。
Q4. 前後関係はすべての作業に設定したほうがよいですか？
つなぎすぎると、1つ動かしただけで全体の日程が組み替わり、かえって読みにくくなります。設定するのは、遅れが本当に後工程へ波及する箇所だけで十分です。作業の数の2割から3割に関連が付いていれば、工程表として機能します。先行するの関係を使うと、前の作業の終了日を動かしたときに後ろの作業の日付も連動します。