Confluenceで進捗をどう見せるか｜報告のために作り直さない組み方
Confluenceで進捗をどう管理するか、という相談の中身は、たいてい同じ形をしています。文書は溜まっている。会議の記録も、仕様も、検討の経緯も、全部そこにある。それなのに、上に報告するときは毎回どこかで一覧を作り直している。この作り直しの時間が、とりまとめる立場の人の週次の負担になっています。
この記事は、その作り直しをやめるための組み方を並べます。結論を先に置くと、Confluenceは進捗を出すための仕掛けを複数持っていて、使い分けの基準さえ決まれば一覧は自動で埋まります。ただし、その仕掛けが動くための前提を先に整えておかないと、空の表ができるだけです。前提のほうが、仕掛けの操作より重要です。
報告のたびに作り直している状態を、まず名前で捉える
週に1回、報告の前に手が止まる。各ページを開いて、進み具合を読み取って、別のページに書き写す。この作業には名前が付いていないので、業務の負担として数えられていません。だから何年も続きます。
この作業が発生する理由は単純です。進捗の情報が、各ページの中に文章として書かれているからです。文章は人が読まないと意味が取れません。機械が集められるのは、決まった場所に決まった形で置かれた情報だけです。
つまり、作り直しをやめるために必要なのは新しい機能ではなく、各ページに「機械が読める形の欄」を作ることです。状態、担当、期日、次の確認日。この4つを文章の中ではなく決まった欄に置く。それだけで、集めてくる側の仕掛けが動くようになります。
とりまとめる人が最初にやるべき仕事は、この欄の設計です。項目を決め、名前を揃え、どのページにも同じ形で置く。ここが揃っていないと、後からどんな仕掛けを組んでも集まりません。名前が「状態」と「ステータス」に割れているだけで、片方が集まらなくなります。
現場でよく起きるのは、欄を作ったのに書き方が人によって違うという状態です。ある人は「進行中」と書き、別の人は「作業中」と書く。集計すると別々の項目として数えられます。欄を作るときに、入れてよい言葉を4つ程度に限定して、それをページの見本に書いておくと防げます。
進捗を出すための仕掛けは、大きく4つある
Confluenceで進捗を見せる方法は、使う道具ごとに性質が違います。整理すると次の4つです。
・各ページの決まった欄を集めて一覧にする仕掛け ・ページの中のチェックボックスを集める仕掛け ・Jiraの課題を条件で引いてきて並べる仕掛け ・データベースを作って、そこに行を溜める仕掛け
この4つは、情報がどこに置かれているかで使い分けます。1つ目は、案件ごとにページがあるチームに向きます。2つ目は、会議の記録の中に決まった宿題が書かれるチームに向きます。3つ目は、開発の課題管理が別にあるチームに向きます。4つ目は、ページを作るほどでもない細かい項目を並べたいチームに向きます。
どれを使うか決められないときは、いま情報がどこに書かれているかを見てください。ページの本文に書かれているなら1つ目、箇条書きのチェックとして書かれているなら2つ目、別の道具に入っているなら3つ目です。情報の置き場所を変えずに済む仕掛けを選ぶのが、いちばん定着します。
逆に、全部を1つの仕掛けに寄せようとすると失敗します。書く人が情報の置き場所を変えることになるからです。とりまとめる人は集めやすい形を望みますが、書く人は書きやすい形を望みます。集める側が書く側に合わせるのが原則です。
集める前に、ラベルを決める
4つの仕掛けのうち、最初の2つは共通してラベルに依存します。ここを設計せずに始めると、何も集まりません。
ラベルは、ページに付ける目印です。集めてくる側の仕掛けは、「このラベルが付いたページを集めてこい」という指示で動きます。だから、ラベルの名前が揃っていないと、対象から漏れます。
ラベルの設計で押さえるべき点は3つです。
・数を増やしすぎない。付ける人が迷う数になると、付けられなくなる ・用途ごとに接頭辞を揃える。案件なら同じ書き出しで始め、工程なら別の書き出しにする ・付け忘れを検出する手段を用意する。集まっていないページがあることに気づけないと、一覧は静かに嘘になる
3つ目が抜けやすいところです。一覧に出ていないページがあっても、見ている側には分かりません。表に並んでいる行だけを見て、それが全部だと思い込みます。ラベルを付け忘れた案件が1つあると、その案件だけが報告から消えます。
手当てとして実用的なのは、ページを作る入り口を1つにすることです。決まった見本からページを作る形にして、その見本にラベルをあらかじめ入れておく。手で付けるのをやめれば、付け忘れは起きません。
各ページの欄を集めて一覧にする
案件ごとにページがあるチームで最も効くのが、この仕掛けです。各ページの上部に決まった欄を置き、別のページでそれを集めて表にします。
Atlassianの公式資料には、この仕組みについて次のように書かれています。
The content properties and content properties report macro work together to enable you to show summary information from one page or live doc on another page or live doc. 出典: support.atlassian.com
同じ資料には、このマクロが以前はページプロパティレポートという名前だったことも書かれています。社内に古い手順書が残っているチームは注意が必要です。名前で検索しても見つからず、「機能が無くなった」と誤解される原因になります。挿入するときは、編集画面でスラッシュを打ってからマクロの名前を打つ形になります。
組み方の順番は次のとおりです。
・各ページの上部に、集めたい項目を並べた欄を置く ・そのページにラベルを付ける ・一覧を出したいページに、集めてくる側のマクロを置く ・対象のラベルを指定する
注意点が1つあります。集めてくる側のマクロが対象にするラベルは、集められる側のページに付いているラベルです。ここを取り違えて、一覧を出す側のページにラベルを付けてしまう例が非常に多く見られます。付ける先を間違えると、表は空のまま出ます。
複数の一覧を1枚のページに置きたい場合は、それぞれを見分けるための識別の指定ができます。公式資料には、特定の欄だけを対象にするか、すべてを対象にするかを選べると書かれています。1つのページで、案件の一覧と工程の一覧を分けて出したいときに使います。
欄に何を置くか、4項目の決め方
集めてくる仕掛けを組む前に、各ページに置く欄の中身を決めます。ここで項目を増やしすぎると、書く人が埋めなくなり、結局一覧が空になります。実務で機能するのは次の4項目です。
・状態。選べる言葉を最初から限定する。未着手、進行中、確認待ち、完了の4つで多くの現場は足りる ・担当。人の名前を入れる。役職や部署名を入れると、誰に聞けばよいか分からなくなる ・期日。日付の形で入れる。「今月末」のような書き方をすると並べ替えができない ・最終確認日。誰かが最後に中身を見た日。これが古いページは、状態の値も信用できない
4つ目を入れておくと、一覧の信用度が上がります。状態が「進行中」と書いてあっても、最終確認日が3か月前なら、その値は当てになりません。見る側が自分で判断できる材料を1列足すだけで、問い合わせの回数が減ります。
「進捗率」を入れたくなりますが、おすすめしません。数字で表そうとすると、書く人が毎回悩みます。40%なのか50%なのかは本人にも分からないので、適当な値が入ります。適当な値が並ぶ表は、見る側が信用しないので、結局口頭で確認することになります。4つの状態で段階を表すほうが、書く側も見る側も迷いません。
欄の見本は、ページを作る型の中に埋め込んでおいてください。手で作らせると、項目の順番が人によって変わり、集めた表の列がずれます。型から作る運用にしておけば、この事故は起きません。
見せる相手ごとに、一覧を分けてよい
一覧が1枚できると、そこに全部を詰め込みたくなります。ところが、見る相手によって知りたいことは違います。1枚で全員を満足させようとすると、列が増えて誰も読まなくなります。
分け方として実用的なのは、次の3枚です。
・全体の一覧。案件を全部並べる。とりまとめる人が使う ・遅れているものだけの一覧。期日を過ぎていて完了していないものを出す。報告に使う ・今週更新されていないものの一覧。最終確認日が古いものを出す。抜けを探すのに使う
一覧を何枚作っても、情報の置き場所が増えるわけではありません。集めてくる仕掛けは、元のページを見にいく窓にすぎないからです。だから枚数を増やしても、更新の手間は1ページ分のままです。
報告を受ける側に渡すのは、2枚目だけで足りることが多いです。全体の一覧を渡すと、量の多さに目が向いて、肝心の遅れが埋もれます。遅れているものだけを並べて、そこに補足を口頭で足すほうが、報告の時間は短くなります。
3枚目は、とりまとめる人が自分のために持つ一覧です。人に見せる必要はありません。毎週月曜にこれを開いて、更新が止まっているページの担当者に声をかける。この習慣があるかどうかで、一覧の信頼度は決まります。
絞り込みの条件を、あとから足せるようにしておく
一覧が出るようになると、次に来る要望は絞り込みです。今期の分だけ見たい、この部署の分だけ見たい、あの人が書いたものだけ見たい。
Confluenceには、この絞り込みのための問い合わせの書き方が用意されています。公式資料によると、集めてくる側のマクロでは次のような条件が使えます。ラベル、特定のページの下にあるもの、作成または編集した人、作成した人、名前が挙がっている人、直接の子ページ、対象のスペース。
実務では、ラベルと「特定のページの下にあるもの」の2つでほとんど足ります。案件のページを1つの親の下にまとめておけば、その親を指定するだけで対象が決まります。ラベルの付け忘れがあっても、親の下にあれば拾えるので、二重の網になります。
条件を組むときに気をつけたいのは、増やしすぎないことです。条件が4つ5つと重なると、なぜある案件が表に出ていないのかを説明できなくなります。出ていない理由が分からない表は、信用されません。条件は2つまでに抑えて、残りは目で見て判断するほうが結果的に速いことが多いです。
チェックボックスを集める仕掛けと、その制約
会議の記録の中に宿題を書く習慣があるチームでは、チェックボックスを集める仕掛けが効きます。本文の中に付けたチェックの項目を、スペース、ページ、担当者、ラベル、作成日などで絞って一覧にできます。
この仕掛けのよいところは、書く人の手間がまったく増えないことです。会議の記録を書くときに、いつもどおり宿題を箇条書きにして、担当者の名前を入れる。それだけで一覧に載ります。欄を作る必要も、ラベルを付ける必要も、場合によってはありません。
一方で、公式資料には明確な制約が書かれています。このマクロはライブドキュメントではまだ使えず、使うにはページに置くか、ライブドキュメントをページに変換する必要があると説明されています。新しい形式で文書を書き始めているチームは、ここで詰まる可能性があります。
もう1つの制約は、粒度です。チェックの項目は1行の短い文章なので、状態が「終わった」「終わっていない」の2つしかありません。進み具合を段階で表したい場合には向きません。会議の宿題のように、やったかやっていないかで足りるものに使うのが正解です。
使い分けの目安は明快です。案件の進み具合は欄を集める仕掛けで、会議の宿題はチェックを集める仕掛けで。この2つを混ぜると、どちらも中途半端になります。
会議の記録から、宿題だけを取り出す運用
チェックを集める仕掛けを活かすなら、会議の記録の書き方も少し揃えておくと効果が出ます。揃えるのは形式ではなく、書く場所です。
多くの会議の記録では、決まったことと、宿題と、参考の情報が地続きに書かれています。この状態だと、宿題がどこにあるかを人が読んで判断することになります。記録の末尾に「次にやること」の見出しを置いて、そこにだけチェックの項目を並べる。この決まりを作るだけで、集めたときの精度が上がります。
宿題の書き方にも目安があります。1行に1つ、担当者の名前を必ず入れ、期日を添える。「確認する」だけでは、誰が何を確認するのかが後から分かりません。3か月後にその行だけを見て意味が通るかどうかを基準にすると、書き方が安定します。
会議で出た宿題のうち、そのまま案件になるものは、宿題として残さずページを作るほうが確実です。チェックの項目は終わったかどうかしか表せないので、数週間かかる作業を入れると、ずっと未完了のまま並び続けます。並び続ける未完了は、見る人の目を素通りするようになります。
この切り分けを決めておくと、宿題の一覧は常に数十行に収まります。数十行なら会議の冒頭で全部読み上げられます。読み上げられる分量に保つことが、宿題を消化させるいちばん確実な方法です。
課題管理が別にある場合の出し方
開発の現場では、課題の管理が別の道具に入っていることがほとんどです。この場合、進捗の数字をConfluenceに書き写すのは二重管理になります。
Confluenceには、繋がっている課題管理の道具から条件で課題を引いてきて、ページ上に一覧として表示する仕掛けがあります。表示する項目は選べて、並び順も変えられます。件数だけを表示する形も選べるので、報告用のページに「未完了 12件」とだけ出す、といった使い方もできます。
この仕掛けを使うときのコツは、条件を課題管理の側で作ってから持ってくることです。ページの編集画面で条件を組み立てると、後から直すのが面倒になります。課題管理の側で保存した検索の条件を指すようにしておけば、条件を直すときに1か所を直せば済みます。
そして、この形にすると、Confluenceのページは進捗を保持しません。表示しているだけです。これは弱点ではなく利点です。書き写した数字は必ず古くなりますが、引いてくる形なら常に最新が出ます。報告のために作り直す作業は、ここで消えます。
ただし、繋がっていない場合は使えません。課題管理が社内の別の仕組みで動いている、表計算で管理している、といった場合は、この道は選べません。その場合は、次のデータベースを使う方法が現実的です。
ページを作るほどでもない項目は、データベースに溜める
Confluenceには、行と列で情報を溜める仕組みがあります。案件ごとにページを作るほどではないけれど、一覧で管理したい項目に向きます。
公式資料によると、作り方は複数あり、画面の作成ボタンから作る、スペースの一覧の横にある追加のボタンから作る、編集中にスラッシュを打って作る、といった経路が説明されています。なお、同じ資料には、この機能が特定の行政向けの環境では使えないという注記も書かれています。
データベースを使う利点は、項目の型を決められることです。文章の中に書かれた「9月末まで」は機械には日付として読めませんが、日付の型の列に入っていれば読めます。期限が近いものを上に出す、といった並べ替えができるようになります。
注意したいのは、これを進行の管理そのものに使い始めると、行が増え続けることです。文書の置き場の中に、更新頻度の高い表を置くことになります。毎日何度も状態が変わる情報を、文章を編集する画面で更新するのは無理があります。データベースは、月に数回動く程度の項目に向いていると考えたほうが安全です。
自動化に頼る前に、プランごとの上限を見る
進捗の管理を自動で回そうとすると、自動化の仕掛けを使いたくなります。しばらく更新されていないページの担当者に知らせる、期日が近いものを毎朝まとめて出す、といった使い方です。
日本語の公式料金ページには、2026年9月12日時点で、プランごとの自動化の上限が書かれています。Freeは1サブスクリプションあたり月50の自動化ステップ、Standardは1ユーザーあたり月間100、Premiumは1ユーザーあたり月250、Enterpriseは1ユーザーあたり月500です。
数え方がプランで変わる点に注意してください。Freeだけは環境全体で50という数え方で、人数が増えても枠は増えません。有料のプランは1人あたりの数え方なので、人数に比例して枠が増えます。無料の枠で進捗の通知を組もうとすると、思ったより早く止まります。
料金についても同じページに記載があります。Freeは0円で最大10ユーザーまで、Standardは1ユーザーあたり月額744円、Premiumは1ユーザーあたり月額1,432円と表示されています。これは月額で請求を受ける場合の金額で、年間の請求に切り替えると最大17%安くなる旨も同じ場所に記載があります。税をどう扱うかについてはページ上で確認できなかったので、請求の額は申し込みの画面で見てください。
誰が更新するかを決めないと、一覧は空を映す
ここまでの仕掛けは、どれも「各ページに情報が入っている」ことを前提にしています。入っていなければ、一覧は空か、古い値を並べます。
とりまとめる人が陥りやすいのは、仕掛けを組んだ時点で仕事が終わったと思うことです。実際には、そこからが本番です。各ページの欄を誰がいつ更新するのかを決めないと、1か月で一覧は嘘になります。
決めるべきことは3つです。
・誰が更新するか。案件のページなら、その案件の担当者 ・いつまでに更新するか。報告の前日までに ・更新されていないことに誰が気づくか。仕掛けで知らせるのか、人が見るのか
3つ目を仕掛けに任せられると、とりまとめる人の負担が大きく減ります。更新日が古いページを集める一覧を1枚作っておけば、毎週それを見るだけで抜けが分かります。催促の連絡を人が出すのではなく、状況が見える形にしておくほうが、人間関係の摩擦も小さくなります。
現場では、新しい運用を入れて2週間で誰も更新しなくなる、という話がよく出ます。逆に言えば、2週間続けば定着の見込みが立ちます。最初の2週間だけは、とりまとめる人が毎日見て、更新されていない欄を埋めに行く覚悟をしておくとよいでしょう。
一覧が信用されなくなる入口は、3つしかない
せっかく組んだ一覧が、半年後には誰も見なくなる。この現象には、決まった入口が3つあります。どれも技術の問題ではなく、運用の問題です。
1つ目は、抜けがあると分かった瞬間です。報告の場で「この案件が載っていません」と指摘されると、その表全体が信用を失います。載っていない理由がラベルの付け忘れだったとしても、見ている側にはそこまで分かりません。抜けを防ぐ手段を先に用意しておくことが、そのまま信用を守ることになります。
2つ目は、値が古いと分かった瞬間です。表では「進行中」なのに、実際には先月終わっていた。1度でもこれが起きると、次からは表を見る前に本人に確認する流れができます。確認する手間が増えるので、結局その表は使われなくなります。最終確認日の列が効くのはここです。古い値であることが見た目で分かれば、信用が一気に崩れることはありません。
3つ目は、一覧の作り方が特定の1人にしか分からないという状態です。組んだ人が異動や退職でいなくなると、直せる人がいなくなります。表の中身がおかしくなっても放置され、やがて誰も見なくなります。
3つ目への手当ては、仕掛けの脇に説明を書いておくことです。どのラベルを対象にしているか、どのページの下を見ているか、なぜその条件にしたか。3行でよいので、一覧のページに書いておいてください。後任がそれを読めば直せます。逆に、書いていないと、後任は仕掛けを消して手作業の表を作り直します。報告のための作り直しは、こうやって復活します。
とりまとめる立場の人が残すべきものは、きれいな一覧ではなく、その一覧が動いている理由の説明です。
文書の道具に進行を持たせる限界と、その線引き
ここまで組めば、報告のための作り直しはかなり消えます。それでも残る負担があるとすれば、更新の重さです。
文章を編集する画面で状態を変えるという行為は、進行の道具でカードを動かすのに比べて手数が多くなります。ページを開き、編集に入り、欄を直し、保存する。1日に何度も状態が変わる仕事では、この手数が積み重なって更新が止まります。
だから線引きが要ります。月に数回動く情報は文書の置き場に置いてよい。毎日動く情報は、別の場所に置いたほうが続く。この線を引けるかどうかで、運用の寿命が変わります。
ボード型のタスク管理は、毎日動く情報のほうを引き受ける道具です。できることに、どこまでを範囲にしているかが書かれています。正直に書いておくと、こちらには弱いところもあります。長い文章を大量に蓄える用途は範囲に入っておらず、リポジトリの機能もありません。連携や自動化の組み立ての深さでは、そこを主戦場にしている道具に届きません。表示できる言語は日本語だけです。文書の置き場そのものを置き換える候補としては、合いません。
費用の考え方も違います。料金には、機能の有無ではなく規模で区切る形が説明されています。機能で絞らず、区切るのは人数とボードの数だけという置き方なので、自動化のステップ数を気にしながら仕掛けを組む必要がありません。
進行の置き場を別に持つと決めた場合、候補ごとの違いは個別のページにまとまっています。カード型の代表的な道具との違いはTrelloとの比較、タスクの割り当てと期日の管理に強い道具との違いはAsanaとの比較、文書とデータベースを同居させる道具との違いはNotionとの比較にあります。文書と進行を1つに寄せるかどうかを迷っている人には、Notionとの比較が近い論点です。画面の作り込みが特徴の道具はmonday.comとの比較、課題管理と結び付けて使われてきた国内の道具はBacklogとの比較、国内発のカード型はJootoとの比較で、それぞれ違いが説明されています。候補を一度に並べたいときは比較の一覧が入り口になります。
移すときにかかる工数も、あらかじめ見ておくべき項目です。Trelloからの移行に取り込みの範囲がありますが、そのまま読み込めるのはTrelloに限られます。それ以外は、いったん書き出してから形を整えて入れ直すことになります。データを預かる際の方針は安全性の考え方、細かい運用上の疑問はよくある質問で確認できます。
Q1. 一覧を出すマクロを置いたのに、表が空のままです。
ラベルを付ける先を取り違えている可能性があります。集めてくる側のマクロが対象にするのは、集められる側のページに付いているラベルです。一覧を出すページにラベルを付けても集まりません。あわせて、各ページに決まった欄が置かれているかも確かめてください。
Q2. ページプロパティレポートという名前のマクロが見つかりません。
公式資料によると、このマクロはコンテンツプロパティレポートという名前に変わっています。古い手順書に旧称が残っていると見つからず、機能が無くなったと誤解されがちです。編集画面でスラッシュを打ち、新しい名前で探してください。
Q3. チェックボックスを集めるマクロが使えません。
公式資料には、このマクロはライブドキュメントではまだ使えないと書かれています。使うにはページに置くか、ライブドキュメントをページに変換する必要があります。また、集められるのは終わったか終わっていないかの2状態だけなので、進み具合を段階で見せたい用途には向きません。
Q4. 自動化で更新の催促を送りたいのですが、上限はありますか？
2026年9月12日時点の日本語の公式料金ページでは、Freeが1サブスクリプションあたり月50の自動化ステップ、Standardが1ユーザーあたり月間100、Premiumが月250、Enterpriseが月500と書かれています。Freeだけは環境全体での数え方なので、人数が増えても枠は増えません。