Notionで案件管理を回す仕組み|小規模チームの実践テンプレート

案件が増えてくると、「どの案件が今どういう状態か」をスプレッドシートやチャットの記憶で管理するのは限界が来ます。Notionのデータベースを使えば、案件の受注から納品・請求までを1つの画面で見渡せる仕組みが作れます。この記事では、実際に当社(動画制作・SNS運用の制作会社)の現場で運用している構成をそのまま公開しながら、小規模チームがNotionで案件管理を回すためのデータベース設計と運用ルールを解説します。

なぜ案件管理にNotionなのか

案件管理の選択肢は大きく3つあります。スプレッドシート、専用のプロジェクト管理ツール(Backlog、Asanaなど)、そしてNotionです。

スプレッドシートは手軽ですが、案件ごとの詳細メモや関連資料が別の場所に散らばりがちで、「この案件の経緯どこだっけ」と探す時間が増えていきます。専用ツールは高機能な反面、営業段階のリード管理や請求管理まで含めるとツールを横断することになり、小規模チームには過剰です。

Notionが優れているのは、データベース(一覧管理)とドキュメント(詳細メモ)が同じページに同居できることです。案件一覧の1行を開けば、その案件の要件メモ・議事録・素材リンクがすべてそこにある。この「1案件=1ページ」の構造が、少人数で複数案件を並行して回すときに一番効きます。

さらに後述しますが、Notion APIを使えば締切通知や請求書発行などの自動化にもつなげられます。「最初は手動で始めて、育てながら自動化していける」拡張性も、専用ツールにはない利点です。

案件管理データベースの設計

当社では、1つの巨大なデータベースに詰め込むのではなく、「案件管理DB」「タスク管理DB」「クライアント管理DB」の3層構成にしています。

案件管理DB — 「〇〇社会社紹介動画」のような受注単位。金額・納期・ステータスを持つ、経営視点の管理単位
タスク管理DB — 「初稿編集」「MA作業」のような作業単位。案件DBにリレーションでぶら下がる
クライアント管理DB — 会社情報・担当者・契約条件。複数案件をまたいで参照される

最初は案件DB1つで始めたのですが、運用するうちに「案件の進捗」と「今日誰が何をやるか」は粒度が違いすぎて1つのDBでは混ざることがわかりました。案件は月単位で動き、タスクは日単位で動きます。この2つを分けてリレーションでつないだことで、経営者は案件DBだけ、制作メンバーはタスクDBだけを見ればよくなり、それぞれの画面がシンプルになりました。

最低限必要なプロパティ

案件管理DBに最初から入れておくべきプロパティは、実運用の経験上この7つです。

プロパティ	型	用途
案件名	タイトル	「クライアント名+案件内容」で命名
クライアント	リレーション	クライアント管理DBと紐付け
ステータス	セレクト	後述。設計の肝
種別	セレクト	動画制作/SNS運用/Web制作など
金額	数値	受注金額。ロールアップで月次売上を集計
納期	日付	締切通知の自動化にも使う
担当	ユーザー	社内の主担当

ポイントは「種別」を最初から入れておくことです。動画制作とSNS運用ではリードタイムも工程もまったく違うため、種別で絞り込めるだけでビューの使い勝手が大きく変わります。後述する締切アラートの出し分けにも使います。

ステータスの設計が9割

案件管理DBがうまく回るかどうかは、ステータスの設計でほぼ決まります。当社は次の流れで運用しています。

リード → 受注 → 進行中 → 納品 → 請求 → 完了

設計のコツは2つあります。

1つ目は、営業段階(リード)から入れておくこと。受注してから登録する運用にすると、見積もり中の案件が管理から漏れて、フォロー忘れが起きます。リードの段階で登録し、受注したらステータスを進めるだけにしておけば、営業パイプラインと制作進行が1つのDBで見渡せます。

2つ目は、「納品」と「完了」を分けること。納品して気が抜けた頃に請求書の送り忘れが起きるのが小規模チームの定番の事故です。「請求」ステータスを納品と完了の間に挟むことで、「納品したのにまだ請求ステータスに残っている案件」が月末に一目でわかります。

ステータス管理を導入する前は、納品した安心感からそのまま請求ステータスへの更新を忘れ、請求すべき月がずれ込んでしまうことがありました。「納品」と「請求」を同じ感覚で扱っていたため、気づいたときには翌月になっていた、ということも一度や二度ではありません。「納品」と「請求」を別のステータスとして明確に分けてからは、請求前の案件が一覧上ですぐに浮かび上がるようになり、請求月のずれや請求漏れ自体が起きなくなりました。

クライアントDBとのリレーション

クライアント情報を案件DBのテキスト欄に直接書くと、案件が増えるたびに同じ情報を何度も書くことになり、表記ゆれも起きます。クライアント管理DBを分けてリレーションでつなぐと、クライアントのページを開くだけで「この会社の過去案件・進行中案件」が全部並ぶようになります。

リピートのご相談をいただいたときに、過去案件の金額・納期・やり取りの経緯を数秒で確認できるのは、営業対応の質に直結します。2回目以降の取引があるビジネスなら、クライアントDBの分離は最初からやっておくべきです。

ビューの使い分け

Notionデータベースの強みは、同じデータを目的別の「ビュー」で切り替えられることです。当社では3つのビューを役割分担させています。

ボードビュー:進行状況の把握

ステータスごとに案件カードが並ぶカンバン形式のビューです。週次の定例ミーティングはこのビューを映しながら、「進行中」の列を左から順に確認していくだけで進みます。カードの動きが2週間止まっている案件は何かが詰まっているサインなので、そこだけ深掘りします。

カレンダービュー:納期管理

納期プロパティを軸にしたカレンダー表示です。月の後半に納品が集中していないか、動画案件の撮影日と編集期間が重なっていないか、といった「負荷の偏り」を見るのに使います。新規案件の納期を決めるときも、このビューを見ながら回答すれば無理のないスケジュールが提示できます。

テーブルビュー:金額・請求管理

金額と請求ステータスを列に出した一覧表示です。月末はこのビューをステータス「請求」でフィルタして、請求書の発行漏れがないかを確認します。金額列の合計(サム)を表示しておけば、月次の売上見込みもこの画面でそのまま把握できます。

運用を定着させるためのルール

仕組みを作っても、更新されないデータベースはすぐに信用を失い、誰も見なくなります。当社で定着に効いたルールは3つです。

更新のタイミングを「打ち合わせ直後」に固定する。 「あとでまとめて更新」は必ず溜まります。クライアントとの打ち合わせやチャットで動きがあったら、その場でステータスとメモを更新する。1件30秒で終わる作業を先送りしないことがすべてです。
週1回、全案件を上から見る時間を作る。 毎週決まった曜日にボードビューを全部眺めて、実態とズレているカードを直します。これをやると「DBを見れば正しい状態がわかる」という信頼が保たれます。
入力項目を増やしすぎない。 プロパティが15個も20個もあると、入力が億劫になって更新が止まります。迷ったら「そのプロパティで絞り込みや集計をするか?」で判断し、しないなら本文メモに書けば十分です。

さらに効率化するなら:APIとの連携

手動運用が安定してきたら、Notion APIを使った自動化で「人が思い出す仕事」を減らしていけます。当社で最初に自動化したのは締切通知です。

仕組みはシンプルで、Google Apps Script(GAS)が毎朝9時に案件管理DBをNotion API経由で照会し、納期が近い未完了案件をSlackに通知します。

納期が14日以内の「完了」以外の案件をNotion APIで取得
残り日数に応じて段階的にアラート(1週間前 🟠 → 3日前 🔴 → 前日・当日 🚨)
種別が「動画制作」の案件だけは2週間前 🟡 から通知を開始(制作リードタイムが長いため)
案件名・クライアント・納期・ステータスを整形してSlackチャンネルに投稿

GASのトリガー機能で毎日9時に実行しているだけなので、サーバー費用はゼロです。ポイントは「動画は2週間前から、それ以外は1週間前から」という種別ごとの出し分けで、これはプロパティに「種別」を持たせてあるからこそできる芸当です。

朝Slackを開けば納期が迫っている案件が全部並んでいる状態になるので、「納期を思い出す」という仕事自体がなくなりました。

この通知を作る前は、Slack上のやり取りだけで「対応済み」と思い込んでいたタスクが、実はNotion側では未完了のまま残っている、ということがありました。会話が流れていく中で完了した気になってしまい、ステータスの更新自体を忘れてしまっていたのです。人の記憶や会話の流れに頼るのではなく、システム側から機械的に未完了案件を拾い上げてSlackに知らせる仕組みにしたことで、こうした取りこぼしがなくなりました。

締切通知の次は、ステータスが「請求」になったらMFクラウドで請求書の下書きを作る、といった連携にも広げられます。管理表を「見るためのデータ」から「業務を動かすデータ」に育てていけるのが、Notionを案件管理の中心に置く一番の理由です。

まとめ

Notionでの案件管理は、次の順番で作ると失敗しにくいです。

案件管理DBを作り、7つの基本プロパティとステータス(リード→受注→進行中→納品→請求→完了)を設計する
クライアント管理DB・タスク管理DBを分離し、リレーションでつなぐ
ボード・カレンダー・テーブルの3ビューを役割分担させる
「打ち合わせ直後に更新」「週1で全案件レビュー」を習慣にする
運用が安定したら、締切通知などAPIでの自動化に進む

最初から完璧な設計を目指す必要はありません。まず案件DB1つとステータス設計から始めて、実際の運用で困った順に育てていく——それがNotionという道具に一番合った進め方です。