Notionのタスク管理で複数プロジェクトを回す設計と作り方
Notionでタスク管理を始めた人が最初につまずくのは、案件が2本目、3本目と増えたときです。1本目は快適に回っていたのに、案件ごとにページを作り始めた途端、今日どれから手を付けるのかが分からなくなる。原因は使い方ではなく設計にあり、直す場所もはっきりしています。この記事では、複数の案件を同時に回すための構造を、公式ヘルプに書かれている仕組みをもとに順に組み立てていきます。
複数案件で崩れるのは「案件ごとに一覧が分かれている」状態
まず、何が起きているのかをはっきりさせます。案件が増えたときに困る状態は、たいてい次のどれかです。
・案件ごとにページを作り、それぞれの中にタスクの一覧を置いている ・案件ごとにデータベースを作っている ・1つの一覧に全部入れているが、案件を区別する情報が入っていない
上の2つに共通する問題は、自分の今日のタスクを見る手段が無いことです。案件Aのページを開き、案件Bのページを開き、案件Cのページを開いて、頭の中で足し算する。これを毎朝やると、案件が5本になった時点で続きません。実際には全部を開かなくなり、声の大きい案件だけが進みます。
3つ目の問題は、絞り込めないことです。一覧に全部入っているのは正しい方向ですが、案件の名前がタスクのタイトルに書かれているだけだと、機械的に分けられません。「A社サイト_原稿作成」というタイトルの付け方をしていると、表記が揺れた瞬間に絞り込みから漏れます。
正しい形は決まっています。**タスクは1つのデータベースにまとめ、案件は独立した情報として持たせる。**この形にすると、案件ごとに見ることも、案件をまたいで見ることも、同じデータから両方できるようになります。案件ごとにデータベースを分けると、後者ができません。
案件ごとにページを作ること自体は問題ありません。問題なのは、そのページの中にタスクの一覧を直接置くことです。案件のページには、その案件のタスクだけを絞り込んで表示すればよい。元のデータは1か所にあって、案件のページはその一部を切り出して見せている、という関係にします。この形なら、案件のページを開いても、全体の一覧を開いても、同じデータを見ていることになります。
この設計はNotionが公式に配っているテンプレートと同じ考え方です。次にその中身を見ます。
標準で配られるテンプレートの構造を先に押さえる
自分で一から組む前に、公式のテンプレートがどういう構造になっているかを確認しておくと遠回りが減ります。
公式のガイドによれば、標準のプロジェクト管理テンプレートは3種類です。単一のデータベースで簡単なタスク管理をする「To-do list」、プロジェクトとタスクの2つのデータベースを持ちそれらを結び付ける「Projects & tasks」、さらに期間で区切ったスプリントの層を加える「Projects, tasks & sprints」。テンプレートはNotionのアプリのサイドバーにあるテンプレートから呼び出す、と案内されています。
複数案件を回すなら2つ目が該当します。この形の要点は公式ガイドに明記されています。
・プロジェクトはタスクの親であること。1つのプロジェクトは多くのタスクを持てるが、各タスクは1つのプロジェクトにだけ関連付けるべきであること ・プロジェクト側のプロパティとして、ステータス、担当者、関連するタスク、関連タスクの完了率が用意されていること ・タスク側のプロパティとして、担当者、期日、ステータスが用意されていること ・完了率のプロパティが、プロジェクトごとの完了したタスクの数を計算して、割合をプログレスバーとして表示すること
もう1つ、最初から用意されているビューも参考になります。プロジェクト側には、計画中と進行中だけを表示するカンバンのビュー、自分が関係するものだけを表示するビュー、すべてを表示する表のビュー、開始日と終了日で並べた時間軸のビューが入っています。タスク側には、関連するプロジェクトごとに分けるビュー、自分に割り当てられたものだけを表示するビュー、担当者ごとに並べるビューが入っています。
**このビューの構成そのものが、複数案件を回すための答えになっています。**案件ごとの見え方と、人ごとの見え方と、自分だけの見え方を、同じデータから切り替える。自分で組む場合も、この3つは最初に作っておく価値があります。
なお、権限の初期状態についても記載があります。プロジェクトとタスクをチームスペースに追加すると、そのチームスペースの全員がそれらのデータベースにアクセスできる、と説明されています。誰が何をすべきかを全員が見られる状態から始まる設計です。
タスクと案件をリレーションで結ぶ
自分で組む場合の中心になるのが、リレーションのプロパティです。タスクのデータベースに案件を指す列を1つ足します。
公式ヘルプによれば、リレーションは異なるデータベースにあるアイテム同士の関係性を表現するためのもので、活用例としてタスク一覧とプロジェクト一覧を関連付けるとプロジェクトとタスクの相関関係が明確になることが挙げられています。手順は、タスクのデータベースに新しいプロパティを追加し、種類としてリレーションを選び、接続先として案件のデータベースを選ぶ、という流れです。
ここで決めることが2つあります。
1つ目が、双方向にするかどうかです。
リレーションは、デフォルトでは一方向で作成されます。しかし、リレーション対象のデータベースにも簡単に対応するリレーションプロパティを作成することができます。 出典: notion.com
案件の側から「この案件にぶら下がっているタスク」を見たいなら、双方向にします。「関連データベース名に表示」のトグルを入れて、対応するプロパティに名前を付けます。双方向にしておくと、片方で追加した内容がもう片方にも反映されると説明されています。複数案件を回す設計では、案件のページを開いたときにタスクが並んでいてほしいので、双方向にしておくのが実用的です。
2つ目が、選べるページの数です。公式ヘルプには、リレーションに含められるページの数を1ページか無制限かで制限できると書かれています。タスクは1つの案件にだけ紐づけるべきだと公式ガイドが示しているので、タスク側のリレーションは1ページに制限しておくのが安全です。制限しておくと、1つのタスクを複数の案件に紐づけてしまう事故が防げます。集計が二重に効かなくなるという副次的な効果もあります。
ロールアップで案件の進み具合を数字にする
リレーションを張っただけでは、案件がどれだけ進んでいるかは見えません。ここでロールアップを使います。
公式ヘルプの説明によれば、ロールアップはリレーションに基づいてデータを集計する仕組みです。設定するのは、集計の対象になるリレーションのプロパティ、関連付けられたページのうちどのプロパティを集計するか、適用する計算、数値の書式、小数点の位置です。
複数案件の管理でよく使う計算は次のとおりです。
・すべてカウント。その案件に紐づくタスクの総数が出る ・値の数をカウント。選んだプロパティが空でないものの数が出る。完了日を入れる運用なら完了した件数になる ・未入力以外の割合。空でないものの割合が出る。進捗の目安として使える
公式ガイドが説明している標準テンプレートの完了率も、この考え方でプロジェクトごとの完了したタスク数を計算し、割合をプログレスバーとして表示しています。自分で組む場合も同じ形を作れます。
注意点が1つあります。公式ヘルプには、ロールアップは数値を出力する場合にのみ並べ替えることができる、という備考が付いています。「タスクが多い案件から順に並べたい」なら、件数を数える種類のロールアップにする必要があります。関連ページをそのまま並べる種類では並べ替えの対象になりません。
ロールアップは案件の側だけでなく、担当者の側にも使えます。人のデータベースを別に持っているなら、その人に紐づくタスクの件数を集計して、抱えている量を数字で出せます。人のデータベースを作るほどではないなら、タスクの一覧を担当者でグループ化すれば、各グループの件数がそのまま同じ情報になります。
もう1つ実務的な話をすると、進捗を割合で出すことには落とし穴があります。タスクの粒度が案件ごとに違うと、割合の意味も変わります。100個の細かいタスクに割った案件は序盤から数字が伸び、5個の大きなタスクに割った案件は最後まで数字が動きません。数字が並んでいると比べたくなりますが、案件をまたいで進捗の割合を比べるのは意味がないと割り切ってください。比べるべきは期日と残っているタスクの中身です。
案件をまたいで見るビューを作る
構造ができたら、見る形を用意します。複数案件を回すうえで実際に効くのは、次の4つです。
・**自分の今日のもの。**担当者が自分で、期日が今日以前のタスクだけを絞る。朝いちばんに開くのはこのビュー ・**今週の全体。**期日が今週のタスクを、案件ごとにグループ化して表示する。案件の重なりが見える ・**案件ごと。**案件でグループ化して、ステータスの列に分ける。案件の担当者に見せる用 ・**人ごと。**担当者でグループ化して、その人が今どれだけ抱えているかを見る。負荷の偏りを見つける用
この4つに加えて、月に1度だけ開くビューを1つ作っておくと、先の見通しが立ちます。案件の開始日と終了日で時間軸に並べた表示です。翌月に3つの案件の締切が重なっていることが、この画面でしか見えない場合があります。日々の運用では使いませんが、人の配置を考えるときに要ります。
4つ目が、複数案件を回すときに最も効きます。案件単位で見ていると、同じ人が3つの案件で同時に締切を持っている状態が見えません。人でグループ化した瞬間に、その偏りが表面化します。
ビューを作るときの注意を2つ挙げます。1つは、絞り込みや並べ替えを設定するときに、自分だけに適用するのか全員に適用するのかを意識することです。公式ヘルプには、データベースビューの全員に適用したい場合は全員に保存を選択でき、自分だけに適用したい場合は選択しないよう案内されています。共有するビューと個人用のビューを分けておくと、他の人の画面を勝手に変えてしまう事故が防げます。
もう1つは、ビューの名前です。「ボード」「テーブル2」のような名前が並ぶと、どれを開けばよいのか誰にもわかりません。開く理由が名前から読める状態にしておいてください。
サブグループを使うと、案件と状態を同時に表現できます。ステータスで列を分けたうえで、案件ごとにさらに区切る形です。公式ヘルプには、ボードでは2階層目のグループであるサブグループを追加でき、ステータス別のグループをさらに優先度別にサブグループ化できると説明されています。案件が3本程度なら見やすくなりますが、それ以上になると縦に長くなって読めなくなるので、案件数で使い分けてください。
案件が終わったタスクを残すかどうかも決めておきます。完了したものが一覧に残り続けると、件数が増えて表示が重くなります。ステータスで絞り込んで表示から外す運用にするか、案件が終わった時点でまとめて別の場所へ移す運用にするか、どちらかに寄せます。
案件の情報をどこまでプロパティにするか
構造を組み始めると、何をプロパティにして何を本文に書くかで迷います。ここを決めておかないと、後から絞り込みたくなったときに全部を手直しすることになります。
判断の基準は単純です。絞り込みたいもの、並べ替えたいもの、集計したいものはプロパティにする。読むだけのものは本文でよい。「取引先の担当者名」で絞り込む場面が無いなら、本文に書いておけば足ります。「案件の種類」で絞り込んで見たいなら、セレクトのプロパティにします。
複数案件を回す前提で、最低限そろえておきたいプロパティは次のとおりです。
・案件。リレーション。1ページに制限しておく ・担当者。人のプロパティ。テキストで名前を書くと絞り込みが表記に左右される ・期日。日付のプロパティ。着手日と締切日を分けたいなら2つ持たせる ・ステータス。セレクトかステータス。列に使うので、選択肢は5つ以内に抑える ・種別。設計、制作、確認といった作業の種類。人ごとの負荷を見るときに効く
これ以上を最初から作る必要はありません。プロパティは後から足せます。逆に、使われないプロパティが並んでいると、入力する人が「どこまで埋めればよいのか」で迷い、入力そのものが止まります。10個以上のプロパティが並んだデータベースは、たいてい半分が空欄のまま放置されています。
案件側のデータベースにも、同じ考え方が当てはまります。案件名、状態、開始と終了の日付、担当者、そしてタスクとのリレーション。この5つがあれば、時間軸のビューも案件一覧も作れます。契約金額や請求のタイミングを持たせるかどうかは、その情報を見る人が誰かで決めてください。全員が見えるデータベースに金額を入れると、権限の設計が一段複雑になります。
情報を取り出せる形にしておく
複数案件を長く回すつもりなら、いつでもデータを取り出せる状態かどうかも見ておく価値があります。案件は増え続けるので、後から移すときの手間は年々大きくなります。
公式ヘルプによれば、書き出しに対応している形式はPDF、HTML、Markdown、CSVの4つです。プランによる差もあり、比較表の「ワークスペース全体のエクスポート（HTML、Markdown、CSV）」はフリーを含む4つのプランすべてにチェックが付いていますが、PDFでのワークスペース全体の書き出しはビジネスとエンタープライズのみにチェックが付いています。
ワークスペース全体の書き出しには条件も書かれています。ダウンロード用のリンクが記載されたメールが届き、そのリンクの有効期限は7日間であること。処理にはワークスペースの大きさによって最大で30時間かかる場合があること。デスクトップまたはWebでのみ実施できること。そして、書き出した内容を再びアップロードしてもワークスペースを即座に再現することはできないこと。
最後の点が重要です。書き出せることと、戻せることは別です。データベースの構造やリレーションの関係は、CSVに書き出した時点で失われます。移すときは、構造を作り直したうえでデータを流し込む作業になります。案件が50本を超えてから移すのは現実的ではないので、構造に不安があるなら早い段階で確かめておくのが安全です。
取り込みについては、公式ヘルプに対応形式としてテキスト、Markdown、Word、CSV、HTML、PDF、ZIPが列挙されています。他のツールからの取り込みも案内されており、個別のページが用意されているものとしてConfluence、Asana、monday.comが挙げられています。移ってくる側の経路は用意されていますが、出ていく側の経路は自分で組むことになる、という構図は押さえておいてください。
人数と無料の範囲を先に確認しておく
複数案件を回すということは、たいてい関わる人も増えるということです。ここで料金の条件が効いてきます。
公式の料金ページに書かれている内容を、2026年9月時点の記載として整理します。プランは4つで、日本語表記はフリー、プラス、ビジネス、エンタープライズです。日本円表示では、年払いの場合にプラスが1メンバーあたり月額1,650円、ビジネスが3,150円と記載されています。月払いではプラスが2,000円、ビジネスが3,800円です。有料プランのカードの下部には「日本の消費税（該当する場合）」という注記が表示されます。表示価格が税抜か税込かを明示する文言は、公開資料では確認できませんでした。
無料のフリープランで押さえておくべき点は3つです。
・ページとブロックについて、比較表には個人の利用は無制限、メンバーが2名以上の場合は制限あり、と書かれている ・ページの履歴は7日と記載されている ・外部ゲストの制限は10と記載されている。プラス以降は無制限のゲストとなっている
3つ目が、複数案件を回すときに直接効きます。案件ごとに取引先の担当者を招くと、案件が5本あって1件につき2人なら、それだけで10人に届きます。
もう1つ、ダッシュボードについては、料金ページの比較表でビジネスとエンタープライズのみにチェックが付いていると確認できます。案件を横断して数字を並べる画面が要る場合、この行は見ておく価値があります。なお、時間軸の表示については、ヘルプ記事にも料金ページの比較表にもプランを限定する記載が見当たりませんでした。機能が無いという意味ではなく、制限の記載が公開資料では確認できなかったという意味です。
案件が増えたときに最初に壊れる場所
構造を整えていても、案件の数が一定を超えると別の問題が出ます。壊れる順番はだいたい決まっているので、先に知っておくと手が打てます。
最初に壊れるのは、案件ごとの状態の更新です。タスクは日々動くので更新されますが、案件そのものの状態、たとえば「進行中」「先方確認待ち」「保留」といった段階は、誰かが意識して直さないと止まったままになります。案件が10本を超えると、全部の状態を正しく保つのは1人の作業では追いつきません。週に1度、案件の一覧だけを上から見て状態を直す時間を取ってください。10分で終わります。
次に壊れるのは、期日の意味です。案件が少ないうちは全員が背景を知っているので、期日が多少ずれていても問題になりません。案件が増えると、背景を知らない人が期日だけを見て動くようになります。この段階で「実際にはこの日付は目安です」という暗黙の了解があると、判断が狂います。期日は守るものだけを入れて、目安は別のプロパティにするか本文に書く、という切り分けが要ります。
3番目に壊れるのが、保留になった案件の扱いです。動いていない案件が一覧に混ざっていると、全体の件数が実態より多く見えます。担当者から見ると自分の抱えている案件が多く見えるので、心理的な負荷にもなります。保留の案件は絞り込みで表示から外すか、別の場所へ移すかを決めておきます。
最後に壊れるのは、案件の終わり方です。終わった案件をいつ、誰が、どう片付けるかを決めていないと、一覧に完了済みが積み上がります。終了の手順を1行決めておくだけで防げます。「状態を完了にして、タスクを閉じて、振り返りを1行書く」で十分です。
設計が属人化する問題をどう扱うか
複数案件の構造を組み上げた後に出てくる、最も現実的な問題がこれです。組んだ人以外が直せない状態になります。
リレーション、ロールアップ、複数のビュー、フィルターの組み合わせ。動いているうちは快適ですが、案件の種類が増えたときに構造を足す必要が出てきます。そのとき、組んだ本人がいないと誰も触れません。現場では、組んだ人が異動した時点で構造が凍結し、以後は誰も直せないまま運用だけが続く、という展開がよく聞かれます。
この問題が表面化するのは、たいてい急ぎのときです。新しい案件が入って、いまの構造では扱えない項目が必要になった。そのとき組んだ人がつかまらないと、暫定でテキストに書いておく対応になります。暫定の対応が2件、3件と溜まると、構造とデータの間にずれが生じます。ずれた状態のデータは、後から絞り込めません。
対策は3つあります。
1つ目が、構造の説明をデータベースの説明欄に書いておくことです。「タスクは1つの案件にだけ紐づける」「進捗の割合は完了したタスクの数から計算している」といった前提を1行ずつ書いておく。設定は開かないと見えませんが、説明は目に入ります。
2つ目が、構造を触れる人を2人以上にしておくことです。1人だと必ず止まります。触れる人を増やすには、その人に一度いっしょに作ってもらうのが早い。
3つ目が、そもそも組みすぎないことです。ロールアップを何段も重ね、数式を組み、自動化を足していくと、便利さと引き換えに理解できる人が減ります。機能で絞らず、区切るのは人数とボードの数だけという考え方の道具は、この点で性格が違います。組む余地が小さいぶん、誰でも同じように使えます。自由に組める道具と、組まなくても使える道具のどちらが自分たちに合うかは、チームの人数と入れ替わりの多さで変わります。
置き場所を見直す判断と、その前に見るところ
構造を整えても解決しないことがあります。担当者が入力しない、という問題です。とりまとめる人が全員から聞き取って入力している状態なら、道具の構造をどれだけ整えても、聞き取りの手間は減りません。
判断の軸はここです。**担当者が自分でタスクの状態を動かしているか。**動いていないなら、原因は構造ではなく、入力の敷居か、その人にとって開く理由が無いことのどちらかです。自由に組める道具では、開いたときに何をすればよいのかが人によって違うので、この敷居が高くなりがちです。その兼ね合いはNotionとの比較に整理しています。
カードを列で動かす形の道具との違いはTrelloとの比較にまとめてあります。無料の範囲がワークスペースあたりのボード数と人数で区切られている点にも触れています。タスクの割り当てと期日の運用を中心にした作りとの差はAsanaとの比較を参照してください。ボードの数と席数で無料の範囲が決まる形についてはmonday.comとの比較で扱っています。
国産のサービスで課題管理を軸にした作りとの相性はBacklogとの比較にあります。プランの改定が告知されている点も確認できます。一般提供の終了が告知されているサービスを使っているならJootoとの比較に移行先を選ぶ観点をまとめています。どこから見るか決めていないなら比較の一覧から近い条件のものを開くのが早い。
移す前に確かめる点は4つです。1つ目が、いまのデータを持ち込めるかどうか。取り込みの範囲はTrelloからの移行に書かれている内容が目安になります。自動で取り込める相手は限られていて、それ以外は手作業になります。2つ目が費用の区切り方で、条件は料金に載っています。何ができるのかを機能単位で見たいならできることにまとめてあります。3つ目が社外の人の入れ方、4つ目が権限とデータの扱いで、考え方は安全性の考え方に整理しています。導入前によく出る疑問はよくある質問にまとめてあります。
最後に。複数案件を回す設計の核心は、タスクを1つの場所に集めて、案件を独立した情報として持たせることです。この形さえ守っていれば、道具が変わっても持ち出せます。逆に、案件ごとに構造を分けてしまうと、移すときにも案件の数だけ手作業が発生します。設計を決めるのは、道具を選ぶより先です。
Q1. 案件ごとにデータベースを分けるべきですか？
分けないほうが扱いやすくなります。タスクは1つのデータベースにまとめ、案件はリレーションのプロパティとして持たせる形が基本です。公式ガイドの標準テンプレートも、プロジェクトとタスクを別のデータベースにして両者を関連付ける構造になっています。この形にすると、案件ごとに見ることも案件をまたいで見ることも同じデータからできます。
Q2. 1つのタスクを複数の案件に紐づけてもよいですか？
公式ガイドには、1つのプロジェクトは多くのタスクを持てるが、各タスクは1つのプロジェクトにだけ関連付けるべきだと書かれています。リレーションのプロパティは、含められるページの数を1ページか無制限かで制限できるので、タスク側は1ページに制限しておくと事故が防げます。集計が二重に効く問題も避けられます。
Q3. 案件ごとの進捗を数字で出すにはどうしますか？
リレーションを張ったうえで、ロールアップのプロパティを追加します。関連するタスクの件数を数える計算を選べば、完了した数や割合を出せます。ただし公式ヘルプには、ロールアップは数値を出力する場合にのみ並べ替えられるという備考があるので、並べ替えたいなら件数を数える設定にしてください。
Q4. 複数案件を無料プランのまま回せますか？
人数と取引先の数によります。公式の料金ページでは、フリープランの外部ゲスト制限は10と記載されており、ページとブロックについてもメンバーが2名以上の場合は制限があると書かれています。案件が5本あって1件につき社外の担当者が2人なら、ゲストだけで上限に届きます。招く相手の人数を先に数えてから判断してください。