Notionのタスク管理テンプレート｜配られた形をどこまで直すか
「notion タスク管理 テンプレート」で調べる人の多くは、ゼロから組み立てる気ではありません。すでに用意されている形を呼び出して、そのまま使えるなら使いたいと考えています。ところが実際に呼び出してみると、これは自分たちの進め方に合っているのか、どこまで手を入れてよいのかが分からず、そこで手が止まります。この記事では、標準で配られるテンプレートに何が最初から入っているのかを公式の記述どおりに整理したうえで、自分たちに合わせて直すべきところと、触らないほうがよいところを分けます。
テンプレートで始める人が増えている背景
進行の管理を任された人が最初にぶつかるのは、道具選びではなく「形をどう決めるか」です。ステータスをいくつ置くのか、誰を担当者に立てるのか、期日はいつを指すのか。この設計は本来なら業務の棚卸しから始めるものですが、実務では新しい案件が動き出す前日に決めなければならないことが珍しくありません。組み込みのテンプレートが選ばれているのは、この「決める前に動き出さなければならない」という状況に対する答えとして機能しているからです。
同時に、テンプレートから始めた運用が数か月で放置される話も、現場ではよく聞きます。原因は道具の性能ではなく、配られた形と自分たちの進め方のずれを埋めないまま走り出したことにあります。ずれが小さいうちは、担当者が頭の中で補正して使えます。ところが人が増え、途中から入ってきた人が同じ画面を見たとき、その補正は引き継がれません。ステータスの「進行中」が着手済みを指すのか作業中を指すのかで、報告の粒度が人によって変わります。表の数字が実態と食い違いはじめ、やがて誰も更新しなくなります。
もうひとつの背景として、道具の選定基準が変わってきたことがあります。以前は「何ができるか」で比べられていた領域が、いまは「入力する人が続けられるか」で比べられるようになりました。配られた形をどこまで直すかは、機能の多さではなく、入力する人の手数で決まります。とりまとめる側にとって便利な項目を足すほど、入力する側の手数は増えます。手数が増えれば入力は滞り、滞れば表は嘘になります。テンプレートを直すかどうかの判断は、この一点に集約されます。
だからこそ、最初にやるべきことは「何を足すか」を考えることではありません。配られた形に何がすでに入っているかを正確に把握することです。入っているものを知らないまま似た項目を足してしまうと、同じ情報を二か所で管理することになり、そこから食い違いが始まります。
標準で配られるテンプレートは3種類
公式のプロジェクト管理ガイドでは、組み込みのプロジェクト管理テンプレートが3種類あると説明されています。どれを選んでも、あとからプロパティを足してカスタマイズできることも同じガイドに明記されています。
There are three built-in project management templates in Notion, each with a designated use case in mind. Regardless of which one you start with, you'll be able to customize it by adding more properties later on. 出典: notion.com
呼び出し方についても、Projects and tasks のテンプレートはアプリでのみ利用でき、サイドバーの Templates から始めると案内されています。まずどれを選ぶかで、その後に直す量が大きく変わります。
To-do list
単一のデータベースで簡単なタスク管理を行うためのテンプレートです。公式の説明では、タスクを作成し、整理し、追跡できるものとされ、単発のプロジェクトや個人のタスク管理で、仕組みをできるだけ最小限に保ちたい場合に最適だと書かれています。
「最小限に保ちたい場合」という前提が明記されている点が重要です。チーム全体の進行を預かる立場で、複数の案件が並行して動いている状況では、この形はいずれ足りなくなります。案件をまたいでタスクが並ぶため、どの案件がどこまで進んだかを見るには、タグやフィルタを自分で足していくことになります。逆に、扱っている案件が実質1つで、参加者が数人という状況であれば、これ以上の構造は入力の手数を増やすだけです。
判断の目安は、案件の単位で進捗を報告する必要があるかどうかです。報告の相手が「あの件はどうなっているか」と案件名で尋ねてくるなら、次の形を選んだほうが直す量は少なくなります。
Projects & tasks
チームのプロジェクト管理に向いたテンプレートとして説明されています。公式の記述では、これらのデータベースによってタスクをプロジェクトごとに整理し、チーム全体の進捗を追跡できるとされ、プロジェクトとタスクは別々でありながら関連づけられた2つのデータベースであると明記されています。それぞれのデータベースに異なる情報を記録し、互いにリンクできるという説明も添えられています。
5人から数十人のチームで進行をとりまとめる立場であれば、まず検討するのはこの形です。案件そのものを表す入れ物と、その中で動く作業を表す入れ物が分かれているため、「案件の一覧を見る画面」と「自分の作業を見る画面」を同じデータから作れます。とりまとめる人と手を動かす人で見たいものが違うという、チーム運用でいちばん起きやすい要求のずれに、構造として答えている形です。
Projects, tasks & sprints
公式の説明では、このテンプレートを選ぶとプロジェクトとタスクにもうひとつ層が加わり、タスクを期間で区切ったスプリントにまとめられるとされています。エンジニアリングチームのプロジェクト管理や課題追跡に最適だという位置づけも明記されています。
期間で区切って計画と振り返りを回す進め方が定着しているチームであれば、この形が最初から合います。一方で、その進め方をしていないチームが選ぶと、使われない層が1つ増えます。使われない項目は空欄のまま残り、空欄が並ぶ画面は「この表は運用されていない」という印象を全員に与えます。進め方が先にあり、テンプレートは後です。順番を逆にしないことが、直す量を減らす最初の分かれ目になります。
最初から入っているものを正確に押さえる
Projects & tasks を選んだ場合、公式ガイドには何が最初から入っているかがはっきり書かれています。ここを正確に把握しておくと、「足したつもりが二重管理だった」という失敗を避けられます。
2つのデータベースとリレーション
構造については、プロジェクトがタスクの親であると説明されています。1つのプロジェクトは多数のタスクを持てるが、各タスクは単一のプロジェクトにのみ関連づけるべきであるとされ、タスクはプロジェクトを完了させるための踏み石として考えられると書かれています。
この「タスクは1つのプロジェクトにだけ紐づける」という前提は、あとから効いてきます。1つの作業が複数の案件にまたがるように見える場面は実務でしばしば出ますが、そこで紐づけ先を増やす方向に直すと、完了率の計算がどの案件のものなのか分からなくなります。またがって見える作業は、案件ごとに分けて登録するか、そもそも案件の切り方を見直すほうが、表は素直に保てます。
ステータス、担当者、期日
プロジェクト側のプロパティとしては、ステータス、担当者、関連するタスク、関連タスクの完了率が挙げられています。タスク側のプロパティとしては、担当者、期日、ステータスが挙げられています。
つまり、進行の管理でまず必要になる3点は、最初から用意されています。ここに気づかず「担当者欄を作ろう」「期限の列を足そう」と手を動かしてしまうと、似た列が2つ並びます。似た列が2つあると、入力する人はどちらに書けばよいか毎回迷い、迷いは入力漏れに変わります。
完了率のプログレスバー
進捗の測り方についても明記があります。プロジェクトの進捗は完了したタスクによって測られ、完了プロパティがプロジェクトごとの完了タスク数を計算し、その割合をプログレスバーとして表示するという説明です。
この設計は、進捗を人の感覚から切り離します。「だいたい7割です」という自己申告ではなく、タスクの完了数から自動で出る値になります。とりまとめる側にとってはここが最も大きい価値で、同時にいちばん壊しやすい部分でもあります。タスクの粒度がばらばらだと、この数字は意味を持ちません。1日で終わる作業と2週間かかる作業が同じ1件として数えられるためです。完了率を信用したいなら、直すべきなのは計算式ではなく、タスクの切り方のほうです。
複数のビュー
プロジェクトのデータベースには、最初から複数のビューが入っていると説明されています。「Active」ビューは Planning または In progress とマークされていないプロジェクトをすべて隠し、動いている案件に集中できるようにするもの。「Mine」ビューは自分がタグづけされているプロジェクトを動的に絞り込むもの。「All」のテーブルレイアウトはデータベース内のすべてを表示するもの。そして「Timeline」ビューでは、開始日と終了日にしたがってプロジェクトが並び、約束事の重なりを見ることで負荷が均されているかを確認し、新しい案件を受けられる余力を判断できると書かれています。
タスクのデータベース側にも、最初からビューが用意されています。「By project」ビューはタスクの一覧を関連するプロジェクトごとに分割するもの。「Mine」はデータベースを絞り込んで自分に割り当てられたタスクだけを表示するもの。「People」ビューは各メンバーのやることリストを管理者が見るのに理想的だと説明されています。
同じ情報を違う切り口で見られることが、複数ビューの本質です。公式の説明でも、同じ情報の集合をさまざまな方法で可視化できる柔軟性があるとされ、1人に割り当てられたタスクの一覧でも、親プロジェクトごとにまとめたタスクでも、今後7日以内に期限を迎えるものでも、その時々で重要なものに集中するための文脈的なビューを作れると書かれています。
権限の初期状態
見落とされやすいのが権限の初期値です。公式ガイドには、Projects & Tasks をチームスペースに追加すると、そのチームスペースにいる全員がそれらのデータベースにアクセスできるようになると書かれています。これにより、チーム全体が何をすべきかを把握でき、進捗をデータベースに記録する役割を主体的に担えるという説明が続きます。
つまり初期状態は「全員が見える」です。進行の管理では、この状態が出発点として合理的です。見えないものは更新されないからです。細かく絞りたくなるのは、外部の協力者が入ってきたときや、金額や評価に関わる情報を同じ場所で扱いはじめたときですが、その判断は運用が回りはじめてからで間に合います。
自分たちに合わせて直すべきところ
公式ガイドは、直すことを前提にした書かれ方をしています。両方のデータベースで、自分とチームにとって役立つ新しいビューを作れると明記され、プロパティの追加手順もオプションのメニューからプロパティを開いて新規プロパティを選ぶ形で案内されています。すぐに使えるプロジェクトとタスクのテンプレートから始めて、自分の働き方にいちばん合う、完全にカスタマイズされた仕組みを作れるという説明もあります。そのうえで、直す優先順位には明確な差があります。
ステータスの言葉を自分たちの言葉に置き換える
いちばん先に直すべきなのはステータスです。配られた段階は汎用の言葉で書かれているため、そのままだと解釈が人によって割れます。制作の工程を持つチームなら「確認待ち」と「修正中」が分かれている必要がありますし、外部への納品がある業務なら「先方確認中」という、自分たちでは動かせない状態を表す段階が要ります。
置き換えるときの基準は、その段階にいるとき次に動く人が誰かが一意に決まるかどうかです。「進行中」は誰が動くか分かりません。「先方確認中」なら、こちらは待つと分かります。段階の数は増やしすぎないことです。段階が多いほど、入力する人は「いまどれか」を毎回考えることになり、その一瞬の迷いが更新をやめる理由になります。実務で回りやすいのは4段階から6段階の範囲で、それを超えるなら、そのうちのいくつかは別のプロパティに分けたほうが素直です。
案件の性質を表すプロパティを足す
次に足す価値があるのは、案件を分類するためのプロパティです。取引先、案件の種別、優先度、担当部署といったものが該当します。これらは絞り込みの軸になるため、足しておくと後からビューを増やしやすくなります。
ただし、足す前に確認することがあります。その項目で絞り込んだ画面を、実際に誰が何のために見るのかです。見る人が思い浮かばない項目は、入力の手数だけが増えて誰も使いません。優先度は特にその傾向が強く、全案件が「高」で埋まって機能しなくなる例がよく挙がります。優先度を入れるなら、上位に置ける件数を先に決めておくほうが実用に耐えます。
見る人ごとのビューを用意する
ビューの追加は、直す作業の中でいちばん費用対効果が高い部分です。プロパティを足すのは入力する人の手数を増やしますが、ビューを足しても入力の手数は変わりません。同じデータを別の並べ方で見せるだけだからです。
用意しておきたいのは、週次の打ち合わせでそのまま画面に映せるビューです。今週が期限のものだけを集める、遅れているものだけを集める、自分の担当だけを集める。この3つがあると、打ち合わせのために資料を別途作る作業が消えます。とりまとめる人の負担で最も大きいのは入力ではなく、集まった情報を報告用に作り直す時間です。ビューはそこを直接削ります。
触らないほうがよいところ
直す価値が高い部分がある一方で、手を入れると後から効いてくる場所もあります。
プロジェクトとタスクの結びつき
タスクは1つのプロジェクトにのみ関連づけるという前提は、崩さないほうが無難です。ここを多対多に広げると、完了率がどの案件の値なのか説明できなくなり、進捗の自動計算という最大の利点が失われます。複数案件にまたがる作業がある場合は、案件ごとにタスクを分けるか、共通作業を独立した案件として立てるほうが、あとから見て意味が通ります。
完了率の出どころ
完了率は完了タスク数から計算されると明記されています。この計算元を、進捗率の手入力に置き換えたくなる場面があります。「タスクは3件しかないが、そのうち1件が全体の8割を占める」といった状況です。
置き換えたくなったときは、計算式ではなくタスクの切り方を見直すほうが先です。8割を占めるタスクは、そもそも1件で扱う大きさを超えています。手入力の進捗率は、入力した人の主観がそのまま数字になるため、集計しても意味を持ちません。自動で出る数字を手入力に置き換えた瞬間、その表は報告のための作業になります。
最初から入っているビューを消さない
使わないビューがあっても、消すより残しておくほうが安全です。あとから人が増えたとき、その人が最初に開くのは自分に割り当てられたものを見るビューです。標準で用意されている「Mine」や「People」にあたる画面は、新しく入った人の入口として働きます。
使わないと判断するのは、3か月ほど運用してからで遅くありません。運用の初期に画面を減らしすぎると、途中参加した人が自分の居場所を見つけられず、そのまま更新に参加しなくなります。
人数が増えたときに条件が変わる部分
配られた形をどこまで直すかとは別に、人数が増えたときに前提が変わる部分があります。公式の料金ページとヘルプに書かれている範囲で整理します。以下は2026年9月2日時点で公開ページを確認した内容で、プランや金額は変わりうるため、判断の前に必ず公式のページで最新を確かめてください。
課金の軸は人数です。公式ヘルプには、請求モデルはワークスペース内のメンバー数に基づいており、ワークスペース内の各メンバーに1シートが割り当てられると明記されています。ゲストはこれとは別の扱いで、ページ単位でアクセスを渡す仕組みとして説明されています。
フリープランで押さえておきたいのは、ブロック数の考え方です。公式ヘルプの表では、無料プランでワークスペースオーナーが1名のみの場合は無制限、2名以上の場合はワークスペースごとに1,000ブロックで、その後もコンテンツを作り続けるには有料プランへのアップグレードが必要だとされています。カウントの仕方についても、サインアップ後にワークスペースで作成されたコンテンツの量に基づいてカウントし、ブロックを削除したりゴミ箱を空にしたりしても数は減らないと書かれています。
そのほか、フリープランの列に数値が入っている項目としては、ファイルのアップロードが最大5MB、ページの履歴が7日、外部ゲスト制限が10、チャートが1となっています。ページの履歴はプラスが30日、ビジネスが90日、エンタープライズが無制限と示されています。ダッシュボードの行はビジネスとエンタープライズにのみチェックが付いており、フリーとプラスの列は空欄です。一方で、サブタスクと依存関係、カスタムプロパティとフィルタリングは4つのプランすべてにチェックが付いています。
料金は、JPY表示の金額で、年払いがプラス￥1,650、ビジネス￥3,150、月払いがプラス￥2,000、ビジネス￥3,800で、いずれも単位表記は「メンバー/月」です。フリーは￥0、エンタープライズはカスタム料金と表示されます。年払いについては「年間プランで最大20%お得に」という表示があります。税については、各有料プランのカード下部に「日本の消費税（該当する場合）」と表示されます。表示価格が税抜か税込かを明示する文言は、料金ページおよび請求関連のヘルプでは確認できませんでした。
なお、タイムラインビューが有料プランからであるという記載は、ヘルプ記事にも料金ページの比較表にも見当たりませんでした。制限があるとは書かれていませんが、無いと明記されているわけでもないため、断定は避けるべき部分です。実際に確かめるなら、公式の料金ページの表記と、自分のワークスペースの画面を突き合わせるのが確実です。
出入り口を先に確かめておく
道具の形を直しはじめる前に、確かめておくと安心できるのが、データの出入り口です。公式ヘルプでは、書き出しの形式として PDF、HTML、Markdown、CSV が案内されています。料金ページの比較表では、ワークスペース全体のエクスポート（HTML、Markdown、CSV）の行が4つのプランすべてにチェックが付いており、ワークスペース全体のエクスポート（PDF）の行はビジネスとエンタープライズのみにチェックが付いています。
ワークスペース全体の書き出しについては、ダウンロードリンクの有効期限が7日間であること、ワークスペースのサイズによっては処理に最大30時間かかる場合があること、デスクトップまたはWebでのみ実施できることが明記されています。また、書き出したコンテンツを再アップロードしても、ワークスペースを即座に再現することはできないという注意も添えられています。データベースのフォームビューは現時点では書き出せず、テーブルビューから質問と回答を書き出す方法が案内されています。
取り込み側については、プレーンテキスト、テキストとマークダウン、Microsoft Word、CSV、HTML、PDF、ZIP が対応形式として列挙され、Confluence、Asana、Evernote、Trello など、さまざまなアプリからのデータインポートにも対応していると説明されています。取り込みはデスクトップとWebで利用でき、モバイルではまだ利用できないと明記されています。
出入り口を先に見ておく理由は、乗り換えを前提にするためではありません。書き出せる形が分かっていれば、どこまで作り込んでよいかの上限が見えるからです。書き出しても意味が保てない作り込みは、その道具の中でしか価値を持ちません。それが悪いわけではありませんが、把握したうえで選ぶのと、知らずに積み上げるのとでは、数年後の身動きの取りやすさが変わります。
板の形からもう一度考えるという選択肢
ここまでを踏まえたうえで、進行の管理を別の角度から考える余地もあります。テンプレートを直す作業は、突き詰めると「自分たちの進め方を、データベースの構造として書き下ろす」ことです。この作業に向いているチームと、向いていないチームがあります。
向いているのは、進め方がすでに言葉になっているチームです。工程の名前が決まっていて、どの段階で誰が動くかが共有されているなら、それを構造に落とすだけで済みます。向いていないのは、進め方をこれから決めるチームです。決まっていないものを構造にすると、構造のほうが先に固まり、あとから業務のほうを構造に合わせることになります。
後者の場合、板に付箋を貼るような、もっと単純な形から始めたほうが定着することがあります。列が工程を表し、カードが案件を表す形であれば、構造を決める作業がほとんど要りません。列の名前を変えるだけで進め方の変更に追随できます。構造で管理するか、並びで管理するか。この違いが、道具の向き不向きの大半を決めます。
道具ごとの考え方の違いは、比較の形で見ると輪郭がはっきりします。板と付箋の形で広く使われているものについてはTrelloとの比較で、担当と期日を軸に業務の流れを組み立てる考え方についてはAsanaとの比較で、それぞれ何を得意として何を利用者側の作業として残しているかを整理しています。今回扱った、文書とデータベースを同じ場所で扱う考え方についてはNotionとの比較にまとめてあり、テンプレートを直す前提の運用がどういう性質を持つのかを、板型の考え方と並べて確認できます。
案件の数が増え、見せ方を細かく作り込みたくなったときの選択肢としてはmonday.comとの比較が参考になります。国内の開発案件で課題管理と併せて使われることが多いものについてはBacklogとの比較、日本語で完結する板型のものについてはJootoとの比較で扱っています。どれか1つに絞る前に横並びで見たい場合は比較の一覧から辿れます。
判断の軸として持っておきたいこと
配られた形を直すかどうかで迷ったとき、最後に立ち返る基準は3つです。
1つ目は、入力する人の手数が増えないか。とりまとめる側が欲しい情報を足すたび、手を動かす人の入力は1項目ずつ増えます。増やした項目が、入力する人にも見返りを返すかどうかを確認してください。見返りとは、その項目があることで自分の作業が探しやすくなる、催促が減る、といったものです。見返りのない項目は必ず空欄になります。
2つ目は、自動で出る数字を手入力に置き換えていないか。完了率のように計算で出るものを主観の入力に変えると、集計した瞬間に意味を失います。数字が実態と合わないと感じたら、計算式ではなく、元になっているタスクの粒度を疑うのが先です。
3つ目は、途中から入ってきた人が自力で使いはじめられるか。運用が壊れるのは、たいてい人の入れ替わりのタイミングです。最初に開く画面が用意されていて、そこに自分の担当だけが並んでいれば、説明なしで参加できます。逆に、全案件が並ぶ表しか無いと、新しい人はどこを見ればよいか分からず、既存の誰かが口頭で補うことになります。その補いは記録に残らないため、次の人にも同じ説明が必要になります。
道具に何ができるかを調べる時間は、実はそれほど長く要りません。標準機能の範囲は公開されている資料で確かめられますし、迷いやすい点はよくある質問の形でまとめられていることが多いものです。板型の道具に何が備わっているかはできることで確認でき、いま板と付箋の形で運用しているものを持ち出したい場合の手順はTrelloからの移行に整理されています。社外の協力者を含めて共有するときに気をつける点は安全性の考え方で扱っています。
時間をかけるべきなのは、自分たちの進め方を言葉にする作業のほうです。工程の名前、次に動く人が変わる境目、報告したい単位。この3つが言葉になっていれば、どの道具を選んでも、配られたテンプレートのどこを直せばよいかは自然に決まります。逆にここが曖昧なままだと、どれだけ高機能な道具を選んでも、直す手が止まり続けます。テンプレートは進め方を代わりに決めてくれる仕組みではなく、決まった進め方を最短で形にするための足場です。
Q1. 標準で配られるテンプレートには何が最初から入っていますか？
公式ガイドによれば、プロジェクトとタスクという2つの関連したデータベース、両者を結ぶリレーション、ステータスや担当者や期日のプロパティ、完了タスク数から割合を出すプログレスバー、そしてカンバンやテーブルやTimelineなどの複数のビューが最初から入っています。ビューやプロパティの追加は利用者側の作業になります。
Q2. テンプレートのどこから直せばよいですか？
まずステータスの言葉を自分たちの工程名に置き換えるのが効果的です。基準は、その段階にいるとき次に動く人が一意に決まるかどうかです。次に、絞り込みの軸になる取引先や案件種別を足します。ビューの追加は入力の手数を増やさないため、優先度が高い直し方です。
Q3. 触らないほうがよい部分はどこですか？
タスクを1つのプロジェクトにだけ紐づける構造と、完了タスク数から算出される完了率です。ここを崩すと進捗の自動計算が意味を失います。数字が実態と合わないときは計算方法ではなくタスクの粒度を見直してください。最初から入っているビューも、運用が落ち着くまでは消さないほうが安全です。
Q4. 無料のままチームで使い続けられますか？
公式ヘルプでは、無料プランでオーナーが1名のみなら無制限、2名以上の場合はワークスペースごとに1,000ブロックまでと説明されています。ブロックは削除しても数が減らないと明記されています。ファイルは最大5MB、ページ履歴は7日、外部ゲストは10という数値も公開されています。人数課金のため、参加者が増える前に条件を確認してください。