Notionでガントチャートを組む｜日付と依存関係の決め方
「notion ガントチャート」で検索する人の多くは、タイムラインの出し方そのものを知りたいわけではありません。出し方は公式ヘルプに数行で書かれていて、迷う余地がほとんどないからです。詰まるのはその手前と、その後です。手前では、どのデータベースにどんな形で日付を持たせるかが決まっていません。後では、線は引けたのにチームの誰も日付を直さず、1週間で表が実態からずれていきます。
この記事では、Notionで工程表を組むときに実際に時間を取られる場所を、公式ヘルプと料金ページで確認できる範囲の事実に絞って整理します。扱うのは、日付プロパティの持たせ方、依存関係をどこまで引くか、ビューをどう切るか、そして人数が増えたときに効いてくる料金と権限の線です。5人から数十人のチームで進行をとりまとめている人が、いまの詰まりがどこにあるのかを見極めて、次に何を変えるかを決められる状態を目指します。
先に立場をはっきりさせておきます。Notionは工程表の道具として弱いわけではありません。むしろ逆で、同じ情報の集合を、目的に応じて何通りにも見せ替えられるという設計が、工程表と相性の良い部分です。公式ガイドにも「Notion gives you the flexibility to visualize the same information set in different ways.」と書かれています。問題は、その自由度が「決めなければならないことの多さ」と裏表になっている点にあります。決める順番を間違えると、あとから全タスクを触り直すことになります。
工程表を「別ファイル」で持ち続けたときに何が起きるか
進行をとりまとめている人の手元には、たいてい2種類のものがあります。ひとつはタスクの一覧で、もうひとつは工程表です。この2つが別々のファイルに分かれている状態が、いちばんよくある出発点です。タスクはチャットや表計算やチケット管理の中にあり、工程表だけが別の表計算ファイルとして存在しています。
この持ち方は、最初のうちは何も困りません。困り始めるのは、担当者がタスク側の日付を動かしたときです。タスク側では期日が3日後ろにずれているのに、工程表の棒は古い位置のまま残ります。工程表を直すのは、たいてい進行をとりまとめている1人です。その人が線を引き直している間、他のメンバーは古い表を見ているか、そもそも表を開かなくなっています。工程表を引いている人からは、この二重管理で疲弊したという話をよく聞きます。
ここで起きているのは、単なる更新漏れではありません。2つの場所に同じ日付が存在していること自体が原因です。日付の置き場所が2つある限り、どちらかは必ず古くなります。工程表の道具を選ぶときにまず確かめるべきなのは、線の見た目の美しさではなく、その線が「タスクの日付そのもの」を描いているのか、それとも「タスクの日付を書き写した別のデータ」を描いているのかという点です。
Notionのタイムラインは前者です。タイムラインは独立した工程表ファイルではなく、データベースの表示形式のひとつとして定義されています。同じデータベースのテーブルビューで日付を直せば、タイムラインの棒はそのまま動きます。逆に言えば、タイムラインの棒をドラッグして動かせば、タスクの日付プロパティが書き換わります。二重管理が構造的に発生しないという意味で、この設計は工程表の悩みの半分を最初から消してくれます。
残りの半分は消えません。日付を誰が入れるのか、入っていないタスクをどう扱うのか、遅れをどう表すのか。これらはツールが決めてくれることではなく、チームで決めることです。ここを決めないままタイムラインだけ出すと、線は引けているのに中身が空という状態になります。
Notionのタイムラインはデータベースの見せ方のひとつ
公式ヘルプは、タイムラインを次のように説明しています。
Notionのタイムラインは、タスクとスケジュールを把握できるデータベースで、時間や日、週、月、年など、時系列でプロジェクトを表示できます 出典: notion.com
つまり、時間軸の目盛りを時間・日・週・月・年で切り替えられる表示形式です。工程表というと日単位の棒を思い浮かべがちですが、四半期の計画を見るときは月単位、当週の割り振りを見るときは日単位、と目盛りを変えて同じデータを見られます。ここは表計算で作った工程表との明確な違いです。表計算では、日単位で作った表を月単位で見たければ、列の作り直しが必要になります。
作り方も公式ヘルプに手順が書かれています。新規ページから始める場合は、ページを作って「ここから始める」の三点リーダーからタイムラインを選びます。ページの途中に埋め込みたい場合は、任意のページで /Timeline view と入力してEnterを押します。すでにあるデータベースにタイムラインを足す場合は、データベース名または現在のビュー名の横にある「+」をクリックして、ドロップダウンからタイムラインを選びます。
そして、ここが本題です。公式ヘルプには、タイムラインの利用条件として、日付の範囲を持つ日付プロパティが必要である旨が記載されています。タイムラインを出す操作は数クリックで終わりますが、その数クリックが機能するかどうかは、日付プロパティの持ち方で決まります。この前提を知らずにタイムラインを選ぶと、棒が1本も出ない、あるいは点のようなものしか出ない画面に行き当たります。
標準テンプレートに最初から入っているもの
ゼロから組む前に、標準で配られるものを確認しておくと手間が減ります。公式のプロジェクト管理ガイドによれば、Notionに組み込みのプロジェクト管理テンプレートは3種類です。
「To-do list」は単一のデータベースで、シンプルなタスク管理向けとされています。単発の仕事や個人のタスク管理で、仕組みを最小限にしたい場合に適していると説明されています。「Projects & tasks」はチームのプロジェクト管理向けで、プロジェクトとタスクという2つの別々のデータベースを持ち、それらをリレーションで結びます。「Projects, tasks & sprints」はそこにもう1階層を足し、タスクを期間を区切ったスプリントに並べられる形で、エンジニアリングチームの課題追跡に向くとされています。
このうち「Projects & tasks」テンプレートには、最初から次のものが入っています。プロジェクトはタスクの親であり、ひとつのプロジェクトに多数のタスクがぶら下がる構造。プロジェクト側にはステータス、担当者、関連タスク、関連タスクの完了率といったプロパティ。タスク側には担当者、期日、ステータスのプロパティ。そして完了率のプロパティが、プロジェクトごとの完了タスク数を計算して進捗バーとして表示します。
ビューも初期状態でいくつか用意されています。プロジェクトデータベースには、計画中と進行中だけを残したカンバンの「Active」、自分がタグ付けされたものだけに絞る「Mine」、全件を表で見る「All」、そして「Timeline」があります。公式ガイドは Timeline ビューについて「Here, you'll see your projects arranged according to start and end date.」と説明し、開始日と終了日で並べることで負荷の重なりを見て、新しいプロジェクトを受けられる余力があるかを判断できるとしています。タスクデータベース側には、親プロジェクトごとに分ける「By project」、自分の担当だけに絞る「Mine」、担当者ごとに並べる「People」が入っています。
つまり、工程表の骨組みは配られています。テンプレートはNotionアプリのサイドバーの「Templates」から呼び出します。公式ガイドには「The Projects and tasks template is only available in the Notion app」と書かれているため、ブラウザではなくアプリ側から探すことになります。
どのプランから使えるのかは公開資料で確認できない
ここは正確に書きます。タイムラインビューが有料プランからしか使えないという情報を目にすることがありますが、公式ヘルプ記事「タイムラインビュー」には、プランを限定する注記が見当たりません。料金ページの比較表「プランと機能」にも「タイムラインビュー」という行そのものが存在しません。データベース関連の行は「サブタスクと依存関係」「カスタムプロパティとフィルタリング」「チャート」「フォーム」「ダッシュボード」の5つで、タイムラインは項目として立っていません。
したがって、タイムラインビューが有料プランからであるという記載は、公開資料では確認できませんでした。プランによる制限があるとは書かれていませんが、制限が無いと明記されてもいません。導入前提で人数分の予算を組むような場面では、この点は自分のワークスペースで実際に確かめるか、公式に問い合わせて確認するのが安全です。記事や比較表の記述を根拠に「有料が必要」と決め打ちしないほうがよい箇所です。
一方で、確認できる事実もあります。比較表の「サブタスクと依存関係」と「カスタムプロパティとフィルタリング」は、フリー、プラス、ビジネス、エンタープライズの4列すべてにチェックが付いています。フリープランのカードにも「サブタスク、依存関係、カスタムプロパティなどを含むデータベース」と書かれています。工程表に必要な部品のうち、依存関係とカスタムプロパティについては、無料プランの列にもチェックがある、というところまでは公開資料で確認できます。料金ページと比較表は2026年9月2日時点で確認したものです。プランの内容は変わるため、判断の直前に公式ページで見直してください。
日付プロパティの持たせ方で、あとの手間の大半が決まる
工程表を組むときに最初に決めるべきは、ビューではなくプロパティです。ここを決めずにタイムラインを開くと、あとから全タスクの日付を入れ直すことになります。
開始と終了をひとつの日付プロパティの範囲として持つ
Notionの日付プロパティは、単一の日付としても、開始と終了を持つ範囲としても使えます。工程表の棒は「いつからいつまで」を表すものなので、範囲を持つ形にする必要があります。公式ヘルプがタイムラインの利用条件として、日付の範囲を持つ日付プロパティに触れているのはこのためです。
ここで多くのチームが最初に迷うのが、「開始日」と「終了日」を別々のプロパティとして2つ作るか、ひとつの日付プロパティの中に範囲として持つか、という分かれ道です。表計算の癖で、つい2列に分けたくなります。しかしタイムラインの棒として描かせたいなら、ひとつのプロパティの中で開始と終了を持たせるほうが素直です。プロパティを2つに分けると、棒を描かせるために結局どちらかを主にするか、数式で組み直すことになります。
判断の目安はこうです。工程表として棒で見せたい日付は、範囲を持つひとつのプロパティにまとめます。それとは別に、契約上の締切や検収予定日のように、棒とは別軸で管理したい単一の日付は、別プロパティとして独立させます。工程の長さを表す日付と、動かせない外部の期日を、同じプロパティに混ぜないのが要点です。
予定と実績を分けて持つかどうかを最初に決める
工程表が実態からずれる最大の原因は、遅れの表現方法を決めていないことです。当初の予定が2週間だったタスクが、実際には3週間かかったとき、日付プロパティを上書きするのか、それとも予定と実績を別に持つのか。この2つは運用の重さが大きく違います。
上書きする方式は、プロパティが1つで済むぶん、入力が軽く、更新が続きやすくなります。ただし「当初はいつまでの予定だったか」が消えます。振り返りで遅れの傾向を見たいチームには向きません。
予定と実績を分ける方式は、日付プロパティを2つ持ち、タイムラインのビューを2つ作って重ねて見る形になります。遅れが可視化される代わりに、担当者が触るべき欄が倍になります。5人から数十人のチームで、進捗の入力をメンバーに任せる前提なら、入力欄が増えることの負荷は無視できません。現場では、入力する場所が増えるほど、更新される率が落ちると言われています。
決め方の目安は、その工程表を誰に見せるためのものかです。社内の割り振り調整が主な用途なら、上書き方式で十分です。発注元への報告や、あとで遅れの原因を分析する用途が入るなら、分けて持つ価値があります。どちらにするかを先に決めずに走り出すと、途中で方式を変えることになり、既存タスクを全件開き直すことになります。
日付が入っていないタスクの置き場所を決める
タイムラインで棒として描かれるのは、日付が入っているタスクだけです。日付が空のタスクは、工程表の上には現れません。これは仕様として当然なのですが、運用では見落としの温床になります。誰も日付を入れていないタスクが、工程表の上では存在しないことになるからです。
対策は簡単です。日付が空のタスクだけを集めたビューを、別に1つ作っておきます。テーブルビューでフィルタを「日付が空」に設定するだけです。週に一度、そのビューを開いて空欄を埋める時間を取る。この運用を入れておくと、工程表に載っていないタスクが積み上がる事故を防げます。とりまとめる立場の人がやるべきなのは、線を引き直すことではなく、この「載っていないタスク」を見つけて拾うことです。
期限だけがあるタスクをどう表示するか
締切だけが決まっていて、着手日が決まっていない仕事は多くあります。これを工程表に載せるとき、開始日を仮置きするかどうかが問題になります。
仮置きすると棒が引けますが、その仮の開始日を誰も直さないまま残ると、工程表が実態と違う長さを示すことになります。仮置きしないと工程表に出てきません。実務的には、着手日が決まっていないものは日付を範囲にせず、単一の期日として持ち、タイムライン上では点として並ぶことを許容する運用がやりやすいです。棒と点が混ざった見た目になりますが、「まだ着手日が決まっていない」という情報がそのまま画面に出ることには価値があります。すべてを綺麗な棒に揃えようとすると、揃えるための仮の数字が増えて、工程表の信頼が落ちます。
依存関係をどこまで引くか
工程表というと矢印で結ばれた依存関係を思い浮かべる人が多く、そこに手間が集中します。ここは「どこまでやるか」を決める話です。全部やる必要はありません。
依存関係は比較表の全列にチェックが付いている
まず事実確認です。料金ページの比較表「プランと機能」にある「サブタスクと依存関係」の行は、フリー、プラス、ビジネス、エンタープライズの4列すべてにチェックが付いています。フリープランのカードにも「サブタスク、依存関係、カスタムプロパティなどを含むデータベース」という記述があります。依存関係を使うために上位プランが必須である、という記載は料金ページの比較表には見当たりません。
依存を引く前に決めておくこと
依存関係を引く作業自体は難しくありません。難しいのは、引いたあとの運用です。前工程が3日ずれたとき、後工程を自動で動かすのか、手で動かすのか。自動で動かす前提で組むと、1本ずれるたびに下流が全部動き、担当者の予定が勝手に変わります。手で動かす前提にすると、依存の線は「参考情報」になり、実際の日付とは別に管理されることになります。
現実的な落としどころは、依存を引く対象を絞ることです。工程全体に矢印を張り巡らせるのではなく、「ここが遅れたら確実に全体が遅れる」という数本だけに絞ります。多くのプロジェクトで、本当に他を止める工程は3本から5本程度です。デザインの確定、外部からの素材の受領、検収の日程。こうした「他人が握っている待ち」だけを依存として明示し、社内で融通が利く工程は依存を引かない。この割り切りをすると、工程表の維持コストが一気に下がります。
依存を引かずに済ませる作り方
依存関係を引かずに済ませる手もあります。プロジェクトとタスクを親子で持つ構造を使い、プロジェクト側のタイムラインで大きな塊の重なりを見て、タスク側は担当者ごとの並びで見る、という分け方です。公式ガイドが Timeline ビューの説明で、開始日と終了日で並べることで負荷の重なりを見て新しいプロジェクトを受ける余力を判断できると書いているのは、まさにこの使い方です。
塊同士の前後関係は、人間が見れば分かります。矢印を引かなくても、棒が並んでいれば「これが終わらないと次が始まらない」ことは読み取れます。矢印の価値は、それを機械に伝えて自動で押し出させるところにあります。自動で押し出させる運用をしないなら、矢印を引く手間に見合う効果は出ません。とりまとめる人が毎週見て判断するタイプのチームでは、依存を引かない選択のほうが続きます。
ビューの作り方
工程表を「作る」作業の実体は、ビューを何枚作るかを決める作業です。ここでの判断が、チームが工程表を見に来るかどうかを決めます。
プロジェクトの層とタスクの層を分ける
標準テンプレートが2つのデータベースに分かれているのには理由があります。プロジェクトとタスクを同じ層で扱うと、工程表の棒が数百本になり、誰も読めなくなるからです。
公式ガイドはこの構造を「Projects are the parent of tasks」と説明し、ひとつのプロジェクトが多数のタスクを持つが、各タスクは単一のプロジェクトにのみ関連づくべきだとしています。工程表として外に見せるのはプロジェクト層です。棒の本数が数十本に収まり、全体像として読めます。タスク層のタイムラインは、担当者が自分の仕事の並びを確認するために使います。
この2層を1枚の画面に混ぜないことが要点です。混ぜると、経営層に見せる工程表と、担当者が使う作業リストが同じ画面になり、どちらの用途にも中途半端になります。
表示単位と期間の切り替えを前提に設計する
タイムラインは時間・日・週・月・年で目盛りを切り替えられます。この切り替えがあることを前提にすると、ビューの枚数を減らせます。「今週の詳細版」と「四半期の俯瞰版」を別のビューとして作らなくても、同じビューの目盛りを変えるだけで両方が見られるからです。
ただし、目盛りの設定はビューごとに保持されます。チーム全員が同じビューを共有している場合、誰かが目盛りを変えると他の人の画面も変わります。これを避けたい場合は、俯瞰用と詳細用でビューを分けます。ビューを分けるコストは低いので、見る人が固定されている場面ではむしろ分けたほうが揉めません。
見る人ごとにビューを分ける
標準テンプレートに「Mine」ビューが最初から入っているのは、この考え方の表れです。公式ガイドは「Mine」について、自分がタグ付けされているプロジェクトを動的に絞り込むビューだと説明しています。タスク側にも同じ「Mine」があり、担当者ごとに並べる「People」ビューがあります。
進行をとりまとめる立場で作るべきビューは、少なくとも次の4枚です。全体の俯瞰、自分の担当分、日付が空のもの、そして期限が近いもの。この4枚を最初に作っておくと、あとから増やす必要が減ります。公式ガイドも「In both databases, you can create any new views that you and your team would find helpful.」として、ビューの追加は利用者側の作業だと明示しています。
フィルタとグループ分けの決め方
ビューを増やすときに効くのが、フィルタとグループ分けです。フィルタは「何を見せないか」、グループ分けは「何で束ねるか」を決めます。
工程表で使う束ね方は、実務上ほぼ3種類に収まります。担当者で束ねる（誰が詰まっているかが見える）、プロジェクトや親の単位で束ねる（塊ごとの前後が見える）、ステータスで束ねる（止まっているものが見える）。この3つ以外の束ね方を試すより、この3つのビューを整えて運用に乗せるほうが効果があります。
フィルタで気をつけるのは、完了したタスクを消しすぎないことです。完了分を全部隠すと、工程表が「これから」だけの表になり、遅れがどこで発生したのかが見えなくなります。俯瞰用のビューでは完了分も残し、作業用のビューでは隠す、という使い分けが実務的です。
工程表が嘘にならないための更新の設計
道具の話をここまで書いてきましたが、工程表が機能するかどうかを最終的に決めるのは、更新が続くかどうかです。入力する人が増えないと、進捗の表はすぐ嘘になります。
更新が止まる原因は、たいてい3つのどれかです。ひとつは、入力する場所が普段の作業場所から離れていること。工程表を見るためだけに別のツールを開かなければならないなら、更新されません。ふたつめは、入力する欄が多すぎること。ステータス、進捗率、実績日、コメントと4つ埋めさせようとすると、埋まりません。みっつめは、更新しても誰も見ていないと担当者が感じていることです。
この3つに対する打ち手は、道具の機能ではなく運用の設計です。入力の場所を、タスクが実際に動く場所と一致させる。担当者に埋めさせる欄を2つまでに絞る。そして、とりまとめる人が週に一度その画面を開いて、そこで判断していることを見せる。この3つが揃うと、工程表は生きたまま残ります。
Notionの構造は、このうち1つめについては有利です。工程表がタスクデータベースの見せ方のひとつである以上、担当者がタスクを開いて日付を直せば、そのまま工程表に反映されるからです。工程表を更新するという別作業が存在しません。逆に不利になりやすいのは2つめです。プロパティを自由に足せるため、気づくと入力欄が10個になっていることがあります。プロパティの追加について公式ガイドは、オプションのメニューからプロパティを開いて新規追加する手順を案内していますが、追加が簡単であることは、増やしすぎる危険と裏表です。プロパティを足すときは、それを誰が毎回埋めるのかを先に決めてください。
人数が増えたときに効いてくる線
5人で始めた運用が20人になると、料金と権限の設計が問題として立ち上がってきます。ここは公式に確認できる範囲の事実を整理しておきます。以下はすべて2026年9月2日時点で公式ページを確認した内容です。
課金はワークスペースのメンバー数
公式ヘルプは「Notionの請求モデルは、ワークスペース内のメンバー数に基づいています。」と明記しています。ワークスペース内の各メンバーに1シートが割り当てられ、そのシート数に基づいて請求される仕組みです。料金表の単位表記も「メンバー/月」となっています。
JPY表示の金額は、年払いでフリーが￥0、プラスが￥1,650、ビジネスが￥3,150、エンタープライズはカスタム料金です。月払いに切り替えると、プラスが￥2,000、ビジネスが￥3,800になります。いずれも「メンバー/月」の単位です。年払いの割引については「年間プランで最大20%お得に」と表示されています。
税の扱いには注意が必要です。各有料プランのカード下部には「日本の消費税（該当する場合）」という注記が出ますが、表示価格が税抜か税込かを明示する文言は、料金ページおよびヘルプの請求関連記事では確認できませんでした。読み取れるのは、該当する場合に日本の消費税が加算されるということまでです。予算を組むときは、この注記を前提に見積もるか、公式に確認するのが確実です。
メンバーを増やしたときの請求も、月払いと年払いで挙動が違います。月払いでは、通常の月次請求で翌月分が請求されると同時に、前の請求サイクル中に追加されたメンバーの日割り分が遡って加算されます。年払いでは、翌月の同じ暦日に、年払いの残余期間に応じて計算された新規メンバーごとの利用料が請求されます。逆にメンバーを外した場合は「請求額の減額は次回の請求サイクルから適用され、サイクル途中の日割り計算は行われません。」と明記されています。
ゲストはメンバーとは別枠
外部の協力者に工程表を見せたい場面は多くあります。公式ヘルプは、ゲストを「Guests are individuals external to your company or organization who you invite into your workspace on a page-by-page basis.」と定義しています。ワークスペース全体へのアクセスは与えられず、ページ単位での招待になります。
料金ページの比較表にある「外部ゲスト制限」は、フリーが10、プラス、ビジネス、エンタープライズはいずれも「無制限のゲスト」です。課金対象はメンバーであり、ゲストはこの別枠で管理される仕組みになっています。ただし、有料プランでゲストが完全に無課金であることを直接述べた文言は、公開資料では確認できませんでした。確認できるのは、課金対象がメンバーである旨と、ゲストが別枠の上限で管理される旨までです。
実務で気をつけるのは、招待の操作でうっかりメンバーとして追加してしまうことです。公式ヘルプは、招待をクリックする前にメールアドレスにカーソルを合わせてゲストとして追加されていることを確認するよう案内し、メンバーへのアップグレードを尋ねられた際は「今はスキップ」を選ぶよう説明しています。人数課金の道具では、この一手間が毎月の請求に直結します。
フリープランで複数人になるとブロック数の上限が効く
無料で試すときに知っておくべき制限があります。公式ヘルプ「ブロックの使用状況を理解する」の表によれば、無料プランでワークスペースオーナーが1名のみの場合、ブロックは無制限です。しかし2名以上になると「ワークスペースごとに1,000ブロック」となり、それ以上コンテンツを作り続けるには有料プランへのアップグレードが必要になると書かれています。英語版ヘルプにも「Workspaces with more than one member will be able to use up to 1,000 blocks in that workspace.」と同趣旨の記述があります。
厄介なのはカウントの仕方です。公式ヘルプは「サインアップ後にワークスペースで作成されたコンテンツの量に基づいてブロックをカウントします。ブロックを削除したり、ゴミ箱を空にしたりしても、ブロック数は減りません。」と明記しています。作って消してを繰り返す試行錯誤も、そのまま上限に近づきます。チームで工程表を試作する段階では、この1,000という数字を頭に置いておく必要があります。
その他、フリープランではファイルのアップロードが最大5MB、ページの履歴が7日、チャートが1という上限があります。ページ履歴はプラスで30日、ビジネスで90日、エンタープライズで無制限です。工程表の日付を誰かが誤って一括で書き換えたときに、どこまで遡って戻せるかを決めるのがこの履歴期間です。人数の多いチームで工程表を共有するなら、無視できない項目です。
権限とダッシュボードの線
比較表を見ると、権限まわりには明確な線があります。「チームスペース（オープン、クローズド）」と「権限グループ」はフリーを含む4列すべてにチェックがありますが、「チームスペース（プライベート）」「チームスペースの高度なアクセス権設定」「データベース権限の詳細設定」は、ビジネスとエンタープライズのみです。「ダッシュボード」も同様に、ビジネスとエンタープライズのみチェックが付いています。
工程表の文脈で効いてくるのは「データベース権限の詳細設定」です。工程表のデータベースは見せたいが、日付を勝手に動かされたくない、という要求はよく出ます。細かい権限制御が必要になる規模になると、プランの線に当たることになります。この線をいつ超えるかは、人数よりも、外部の協力者や別部署がどれだけ工程表に触るかで決まります。
なお「SAMLシングルサインオン（SSO）」はビジネスとエンタープライズ、「監査ログ」「ワークスペースアナリティクス」「ドメイン管理」などはエンタープライズのみです。日本国内でのデータ保存が選べるデータレジデンシーも、公式ヘルプによればエンタープライズプランの顧客が対象で、既定では米国に保存されると明記されています。データの置き場所に要件があるチームは、この点を先に確認しておく必要があります。道具ごとの安全性の考え方を横に並べて見たい場合は、安全性の考え方に、保管や権限まわりの整理があります。
持ち出しと乗り換えの前提
工程表を組む前に、その工程表を後で外に持ち出せるかを確認しておくと、判断が軽くなります。持ち出せる前提があると、試すことのリスクが下がるからです。
公式ヘルプによれば、書き出しに対応している形式はPDF、HTML、Markdown、CSVの4つです。料金ページの比較表には「ワークスペース全体のエクスポート（HTML、Markdown、CSV）」という行があり、フリーを含む4列すべてにチェックが付いています。一方、「ワークスペース全体のエクスポート（PDF）」の行は、ビジネスとエンタープライズのみです。PDFの「サブページを含める」オプションについても、ビジネスまたはエンタープライズで利用可能と説明されています。
ワークスペース全体の書き出しには時間の制約があります。公式ヘルプは「エクスポートの処理には、ワークスペースのサイズによっては最大30時間かかる場合があります。」と書き、ダウンロードリンクの有効期限を7日間としています。また、書き出しは「デスクトップまたはWebでのみ実施できます。」とされ、エクスポートしたコンテンツを再アップロードしてもワークスペースを即座に再現することはできない旨も明記されています。工程表のデータを他所へ移す場合、CSVで日付とステータスを抜き出して組み直すのが現実的な線になります。
取り込み側は、プレーンテキスト、テキストとマークダウン、Microsoft Word、CSV、HTML、PDF、ZIPに対応しています。他ツールからは「Confluence、Asana、Evernote、Trelloなど、さまざまなアプリからのデータインポートにも対応しています。」とされ、Confluence、Asana、Monday.comには個別ページが用意されています。なお取り込み機能はデスクトップとWebで利用でき、モバイルではまだ利用できないと書かれています。
組み替えの自由度と、板型の道具の使い分け
ここまで見てきた通り、Notionで工程表を組む作業は「機能が足りるか」の問題ではありません。ほとんどが「どう決めるか」の問題です。日付の持ち方、依存の範囲、ビューの枚数、プロパティの数。決められるということは、決めなければならないということでもあります。
この自由度が価値になるチームと、負担になるチームがあります。分かれ目は、工程表以外にどれだけのものを同じ場所で扱いたいかです。議事録、仕様、ナレッジ、案件のメモ。これらを工程表と地続きで持ちたいなら、Notionのままがいい場合が多くなります。ページとデータベースが同じ体系の中にある道具は多くありません。工程表だけを切り出して別の道具に移すと、タスクから仕様へのリンクが切れます。
逆に、扱いたいのが進行そのものだけで、組み立てに時間をかけたくないなら、板型の道具のほうが早く立ち上がります。列を作ってカードを並べるだけで、その日から使えるからです。板型の道具でどこまでできるかはできることに整理があります。ボードと期日、担当、進み具合の管理といった、進行に必要な部分に絞ってまとめたページです。
料金の考え方も違いが出ます。人数課金は分かりやすい一方で、たまにしか見ない人の分まで積み上がります。板型の道具の中には、機能で絞らず、区切るのは人数とボードの数だけという引き方をするものもあります。上位プランでないと権限設定が使えない、といった機能の線を引かない考え方です。どちらが安いかは人数と使い方によるので、料金で自分のチームの人数を当てはめて確かめるのが早いです。
正直に書いておくと、板型の道具には板型の弱点があります。ページとデータベースが一体になった情報の器としては使えません。リポジトリの機能もありませんし、自動化や外部連携の広さでは、その領域を主戦場にしている道具に及びません。画面が日本語のみという制約もあります。自動で取り込めるのはTrelloからのデータだけで、他のツールからの移行は手作業が入ります。Trelloを使っているならTrelloからの移行に取り込みの流れがまとまっています。
比較ページから見えてくる、工程表で詰まる場所
道具ごとの比較ページを横に並べて読むと、工程表まわりで人が詰まる場所には、道具を問わない共通の型があることが見えてきます。
ひとつめは、工程表とタスクが別の場所にある型です。この型で詰まっているチームは、道具を替えても直りません。直るのは、工程表がタスクの日付そのものを描く構造に変わったときだけです。Notionのタイムラインはこの構造を持っています。詳しい違いはNotionとの比較で、ページとデータベースを組み立てる道具と、板に進行をまとめる道具の設計の違いとして整理しています。
ふたつめは、カードは並んでいるが期間が見えない型です。板だけで進行を回していると、いつからいつまでという幅が持てず、負荷の重なりが見えません。板型の道具を使っているチームからよく出る困りごとで、Trelloとの比較では、板の運用でどこまで進行が見えるのか、どこから足りなくなるのかを扱っています。
みっつめは、機能は足りているが料金の線でチームが分断される型です。特定の機能を使うために上位プランが必要になり、全員分は払えないので一部の人だけが上位プランになる。すると工程表を見られる人と見られない人ができ、結局スクリーンショットで共有することになります。Asanaとの比較とmonday.comとの比較では、プランごとの機能の線がどこに引かれているかを扱っています。
よっつめは、道具が国内の商習慣に合っているかという型です。工程表の粒度や、発注元への報告の形は、国内の開発現場に固有の作法があります。Backlogとの比較とJootoとの比較は、国内で使われている道具との違いを扱っています。道具ごとの位置づけをまとめて見たい場合は比較の一覧から辿れます。
これらの型に共通しているのは、詰まりの原因が機能の有無ではなく、「決めていないこと」と「線の引かれ方」にあるという点です。Notionで工程表を組むかどうかを判断するときも、確かめるべきは機能表ではありません。日付をひとつのプロパティの範囲として持てるか、依存を絞って引けるか、見る人ごとのビューを作れるか、そしてチームの人数でプランの線を越えるか。この4つに答えられれば、判断はつきます。導入前によく出る疑問はよくある質問にまとめてあるので、細かい前提の確認はそちらが早いです。
最後にもう一度書いておきます。タイムラインビューがどのプランから使えるかについては、公開資料では確認できませんでした。ヘルプ記事にも料金ページの比較表にも該当する記載が見当たらないためです。これは「制限が無い」という意味でも「有料が必要」という意味でもありません。人数分の予算に関わる判断をするなら、自分のワークスペースで実際に確かめるか、公式に問い合わせて確認してください。工程表の道具選びで最も避けたいのは、確かめられていない前提の上に運用を組んでしまうことです。
Q1. Notionのタイムラインビューは無料プランでも使えますか？
公式ヘルプ「タイムラインビュー」にも料金ページの比較表にも、タイムラインのプラン制限を示す記載は見当たらず、公開資料では確認できませんでした。ただし比較表の「サブタスクと依存関係」「カスタムプロパティとフィルタリング」はフリーを含む全プランにチェックが付いています。予算に関わる判断をする場合は、自分のワークスペースで実際に確かめるのが確実です。
Q2. タイムラインに棒が表示されないのはなぜですか？
公式ヘルプは、タイムラインの利用条件として日付の範囲を持つ日付プロパティが必要である旨を記載しています。開始日と終了日を別々のプロパティとして持っていると、棒として描かれません。ひとつの日付プロパティの中で開始と終了を範囲として持たせてください。日付が空のタスクも表示されないため、空欄だけを集めたビューを別に作っておくと見落としを防げます。
Q3. Notionの料金はいくらですか？
2026年9月2日時点のJPY表示の金額は、年払いでフリーが￥0、プラスが￥1,650、ビジネスが￥3,150、エンタープライズはカスタム料金です。月払いではプラスが￥2,000、ビジネスが￥3,800です。単位はいずれも「メンバー/月」で、課金はワークスペースのメンバー数に基づきます。表示価格が税抜か税込かを明示する文言は確認できず、「日本の消費税（該当する場合）」という注記のみが表示されます。
Q4. 無料プランのままチームで工程表を運用できますか？
公式ヘルプによれば、無料プランでワークスペースオーナーが1名のみならブロックは無制限ですが、2名以上になるとワークスペースごとに1,000ブロックが上限となり、それ以上作るには有料プランへのアップグレードが必要になります。削除やゴミ箱を空にしてもブロック数は減らないと明記されているため、試作を繰り返す段階から上限に近づきます。少人数の短期運用なら可能ですが、継続的な運用では上限を前提に計画してください。