月曜の朝、新しい案件のNotionページが届いた。「タスクはここに入れてください」とリンクが貼ってある。ページを開くと、プロパティの設定が前の案件と微妙に違う。「担当者」の欄がどこにあるか、3分探してわからなかった。

結論：Notionはドキュメントを育てるツールとして傑出しているが、タスクの担当・期日・通知をチーム全員が追いかけなくても回る状態にするには、専用ツールとの組み合わせが現実的だ。

フリーランスのデザイナー・藤岡さんは、クライアントから「うちのNotionに入って作業してほしい」と頼まれることが増えた。最初の数週間は問題ない。仕様書もワイヤーフレームのコメントも全部同じ場所にある。ところが案件が2本・3本と増えると、どのタスクが自分に降ってきているのか、いつが期日なのかが見えにくくなる。メンションが来てもメールで届くかどうかわからない。担当が変わったことにその日の夜まで気づかなかった、という経験をした人は少なくない。

Notionは2016年のリリース当初からドキュメントツールとして設計されてきた。柔軟なブロック構造、ネストできるページ、リレーショナルなデータベース。これらはすべて「情報を構造化して保存する」ことへの最適化だ。Notion Projectsというタスク機能が追加されたのは2022年末のこと。後から乗せられた機能である以上、「タスクを誰かに届ける」という動作の設計は後回しになりやすい。

Notionのタスク機能で起きがちな3つの問題

プロパティ設計がチームの共有知になっていないと崩れる

Notionでタスクを扱うには、データベースにプロパティを設定する作業から始まる。担当者フィールド、期日フィールド、ステータスフィールド、優先度フィールド。これらを誰がどのように設計するかは、完全にチームに委ねられている。

問題は、その設計が属人化しやすいことだ。たとえばウェブ制作会社のABC商事では、もともとエンジニアの山田さんがNotionのテンプレートを設計した。ステータスは「未着手・進行中・レビュー待ち・完了」の4段階。ところが営業が新しいプロジェクトを作るとき、似たようなテンプレートをコピーして微妙に違うステータス名を設定してしまった。「確認中」「対応待ち」「クローズ」。気づけばワークスペースに4種類のステータス設計が混在し、誰のデータベースが正しいのかわからなくなった。

タスク管理ツールを選ぶときの判断軸を整理しておくと、こうした設計の属人化が起きにくいツールを最初から選べる。タスク管理専用のツールなら、ステータスの定義はシステム側が持っている。チームは設計を覚える必要がない。

通知が届かないとタスクは存在しないも同然

Notionでタスクを作成し、担当者をアサインしたとき、相手に何が届くか。Notionのアプリ内通知は飛ぶ。ただし、それをその人が見るかどうかはNotionを開いているかどうかにかかっている。

月3本の動画制作案件をこなすディレクターの高橋さんは、複数のクライアントから別々のNotionワークスペースに招待されている。それぞれのワークスペースの通知設定を個別に管理しなければならない。メールへの転送設定が漏れていたせいで、あるクライアントからのタスク変更に2日気づかなかったことがある。

SlackやChatWorkなどチームがすでに使っているコミュニケーションラインへの自動連携は、Notionの標準機能には含まれていない。Zapierなどで橋渡しすることは可能だが、それ自体がメンテナンスコストになる。Slackでタスク管理をしようとして失敗するパターンと同じ構造で、「会話の場所」と「タスクの場所」が分離していないと抜け漏れが起きやすい。

外部メンバーの招待コストが読みにくい

フリーランスや外部のクライアントをNotionに招待する場合、ゲストとして追加することになる。無料プランではゲスト数に上限があり、有料プランでも一定数を超えると追加費用が発生する。案件の数だけ外部メンバーが増え、案件が終わればアクセス権を削除して、また新しい外部メンバーを追加する。この繰り返しの中で費用がどう積み上がっていくかは、見積もりが難しい。

発注する側の企業にとっても、受注する側のフリーランスにとっても、「ゲスト招待の費用計算が複雑になってきた」という感覚は、チームの規模が10人を超えたあたりから顕在化しやすい。

Notionが本当に強い用途

ここまで書いてきたのはNotionへの否定ではない。Notionには他のツールが追いつけない領域がある。

仕様書の作成と更新がその筆頭だ。エンジニアが仕様書を書き、デザイナーがワイヤーフレームを埋め込み、ディレクターがミーティングメモをリンクさせる。テキスト・画像・テーブル・コードブロックが同一ページに共存できる柔軟性は、Notionの核心だ。

打ち合わせメモも強い。テンプレート機能を使えば、毎回の定例会議のフォーマットを統一し、過去の議事録を時系列で並べられる。「先月の定例で何を決めたか」を探すとき、Notionのページ検索は速い。

プロセスドキュメントやFAQ、オンボーディング資料の整備にも向いている。新しいフリーランスが入ったとき、「このNotionページを読んでください」で業務の流れを伝えられる構造を作るのに、Notionほど適したツールはほとんどない。

向き不向きを整理する

用途Notionタスク管理専用ツール
仕様書・ドキュメント作成強い不向き
会議メモ・議事録強い不向き
FAQ・ナレッジベース強い不向き
タスクの担当アサイン設定次第標準機能として強い
期日リマインダー通知弱い強い
外部ゲスト招待コスト費用が増える固定または無制限
Slack/ChatWork連携外部ツール必要標準統合あり
複数案件の横断把握ビュー設定が必要標準で見やすい

この表を見ると、Notionが弱いのは「タスクを誰かに届け、追いかけなくても期日が来たら動いてくれる」という動作の部分に集中していることがわかる。

「NotionでなんでもやろうとしてNotionが崩れた」というケース

Webマーケティングを請け負う5人のチームが、Notionをタスク管理のメインに据えた。クライアントのABC商事も同じワークスペースに招待し、タスクの進捗もすべてNotionのデータベースで追うことにした。

最初の1ヶ月は動いた。しかし2ヶ月目、チームに業務委託の藤岡さんが加わった。藤岡さんをゲストとして招待したが、プロパティの意味を理解するまでに2回説明が必要だった。3ヶ月目、別のクライアントが増え、同じワークスペースに2社のクライアントが混在することになった。どのタスクがどのクライアントの案件かを識別するフィールドを追加しようとしたが、既存のデータベース設計と衝突した。

半年後、チームはNotionを「仕様書と会議メモ専用」に絞り直し、タスクは別のツールに移した。担当者へのタスク通知がSlackに届くようになり、期日前日に自動リマインダーが来るようになった。藤岡さんは「ツールを開きに行かなくていいのが助かる」と言った。

ツールは役割分担で使う

Notionが悪いツールだというわけではない。Notionは「情報を構造化して保存する」という仕事において、現時点で最もよくできたツールのひとつだ。ただ、タスクをチームに「届け」、誰もが同じ絵を見ながら案件を前に進めるという仕事は、専用に設計されたツールの方が摩擦が少ない。NotionとPaqutを比較した場合の役割分担を見ると、それぞれが得意な領域をどう組み合わせるかがより具体的にわかる。

フリーランスや外部メンバーと仕事をする人にとって、「ゲスト招待が何人いても費用が変わらない」という構造は、チームの規模が流動的であるほど効いてくる。案件ごとにメンバーが入れ替わる仕事の現場では、費用設計のシンプルさがそのまま意思決定のスピードにつながる。

Notionで育てたドキュメントと、タスクの流れを止めない専用ツール。この役割分担を早めに決めたチームが、半年後も同じ設計で動いていることが多い。藤岡さんのような外部メンバーが「このチームは動きやすい」と感じる環境は、ツールの選び方ひとつで変わってくる。