Notionカンバンの作り方｜タスクが滞留しないボードビュー設計

Notionでカンバンを作ること自体は簡単です。

タスクDBを作る。ボードビューを追加する。ステータスでグループ化する。カードをドラッグして移動する。ここまでは、Notionの基本操作で作れます。

ただし、実務で問題になるのは、ボードの作り方ではありません。

問題になるのは、ボードを見ても仕事の詰まりが分からないことです。

よくある失敗は、次のような状態です。

• 「進行中」の列にカードが増え続ける
• レビュー待ちと作業中が同じ列に入っている
• 完了条件がないため、完了にしてよいか判断できない
• 担当者別の偏りが見えない
• 期限切れのカードがボード上で埋もれる
• 差し戻しが新規タスクのように扱われる
• 顧客待ちや社内判断待ちが「進行中」のまま放置される
• 週次会議で、すべてのカードを順番に読むだけになる

Notionカンバンは、カードを横に動かす画面ではなく、滞留、レビュー待ち、差し戻し、期限切れを見つけて、次の対応を決める業務ボードとして設計する 方が実務向けです。

この記事では、Notionでカンバンを作る方法を、ボードビューの基本、ステータス列、WIP、レビュー待ち、差し戻し、期限切れビュー、週次会議、外部ツール判断まで含めて整理します。

先に結論：Notionではボードビューでカンバンを作る

Notionでカンバンを作るなら、データベースのボードビューを使います。

Notion公式ヘルプでは、ボードビューはデータベースページを特定のプロパティでグループ化して表示できるビューとして説明されています。ステータス、担当者、優先度などでグループ化でき、フィルター、並べ替え、カード表示も調整できます。

Notion公式ヘルプ：ボードビュー

つまり、Notionのカンバンは独立した別機能ではありません。

同じタスクDBを、ステータス別に見せるビューです。

この考え方が重要です。

カンバン用に別のDBを作るのではなく、タスクDBを作り、その表示方法の1つとしてボードビューを作ります。

要素	Notionでの作り方
カード	タスクDBの1ページ
列	ステータスプロパティのグループ
担当者	ユーザープロパティ
期限	日付プロパティ
優先度	セレクトプロパティ
案件	プロジェクトDBとのリレーション
補足情報	カード内の本文、添付、コメント

最初に作るべきDBは、カンバンDBではなくタスクDBです。

Notionタスク管理の作り方

タスクDBが整っていれば、同じデータをテーブル、ボード、カレンダー、タイムラインで切り替えて見られます。

逆に、ボードから先に作ると、見た目は分かりやすいものの、担当者、期限、確認者、完了条件が後付けになりやすいです。

カンバンに向く業務と向かない業務

Notionカンバンは、すべての業務に向いているわけではありません。

向いているのは、状態が少なく、カード単位で進み具合を見たい業務です。

向いている業務	理由
小さな改善タスク	未着手、進行中、確認待ち、完了で流れを追いやすい
コンテンツ制作	企画、執筆、レビュー、公開の状態が明確
営業フォロー	見込み、提案中、確認待ち、失注、受注を視覚化しやすい
採用候補者管理	書類、面談、最終確認、内定などの状態管理に向く
問い合わせ対応の軽い管理	未対応、対応中、確認待ち、完了を見やすい

一方で、カンバンだけでは苦しくなる業務もあります。

向かない業務	理由
工程が日付中心の案件	タイムラインやガントの方が見やすい
依存関係が多い開発案件	チケット管理やBacklog、Jiraの方が強い
SLAや障害対応がある業務	優先度、期限、通知、履歴管理が重くなる
承認履歴が必要な業務	ワークフローやkintoneの方が安全
原価、請求、在庫と連動する業務	会計、ERP、案件管理システムと分けるべき

Notionカンバンは、流れを見える化するには便利です。

ただし、厳密な統制や監査を担うには弱いです。

工程表として使うなら、タイムラインビューやガントチャートの方が向く場面もあります。

Notionタスク管理をガントチャート化する方法

ステータス列の設計

Notionカンバンで最初に決めるのは、列です。

列は多すぎると使われません。

少なすぎると、詰まりが見えません。

おすすめは、次の6列です。

ステータス列	意味	更新する人
未着手	まだ作業していない	管理者、担当者
進行中	担当者が作業している	担当者
確認待ち	作業は終わり、確認者の判断待ち	担当者、確認者
差し戻し	確認者が修正を求めた	確認者、担当者
保留	顧客、素材、社内判断待ちで止まっている	担当者、管理者
完了	完了条件を満たし、確認済み	確認者

ここで重要なのは、「確認待ち」と「差し戻し」を分けることです。

実務では、担当者が終わったタスクと、確認者が承認したタスクは違います。

担当者が終わっただけなら、まだ完了ではありません。

確認者が見るべき状態なので、「確認待ち」に置きます。

修正が必要なら、「差し戻し」に戻します。

状態	ボード上の扱い
担当者が作業中	進行中
担当者が作業を終えた	確認待ち
確認者が修正を依頼した	差し戻し
外部回答待ちで動けない	保留
確認者が完了条件を満たしたと判断した	完了

カンバンの完了は、カードが右端に移動したことではなく、完了条件を確認者が満たしたと判断した状態にする のが安全です。

列名は、チーム内で意味が揃う名前にします。

「対応中」「作業中」「進行中」が混在すると、カードの位置を見ても判断できません。

WIPと滞留の見つけ方

カンバンで見るべきなのは、カード数です。

特に見るべきなのは、進行中と確認待ちのカード数です。

WIPは、Work In Progressの略で、同時進行中の作業量を意味します。

Notionに厳密なWIP制限機能があるわけではありません。

それでも、ボードの列ごとのカード数を見るだけで、詰まりはかなり見つけられます。

見る列	問題の兆候	対応
進行中	担当者が抱えすぎている	新規着手を止める、担当を分ける
確認待ち	確認者側で詰まっている	確認日を決める、確認者を増やす
差し戻し	品質基準や依頼内容が曖昧	完了条件を見直す
保留	外部回答や社内判断が止まっている	解除条件と次回確認日を入れる
未着手	優先度が曖昧	今週着手するものを絞る

Notion公式ヘルプでは、ボードの各列にはカード数などの計算を表示できると説明されています。

この列ごとの件数は、カンバン運用ではかなり重要です。

たとえば、進行中が15件、確認待ちが12件あるなら、新しいカードを増やす前に、滞留を解消した方がよいです。

ルール	例
進行中は担当者1人あたり3件まで	4件目に着手する前に既存カードを進める
確認待ちは2営業日以内に見る	2日を超えたら確認者へ依頼する
保留は次回確認日を必ず入れる	期限なしの保留を作らない
差し戻しは理由を必ず残す	同じ修正が繰り返されないようにする

WIP制限を厳密にシステム化しなくても、チームで見る数字を決めるだけで効果があります。

大事なのは、カードが増えたときに「忙しいですね」で終わらせないことです。

カードが増えている列には、必ず原因があります。

担当者別・期限切れビューを併設する

Notionカンバンだけで、すべてを見る必要はありません。

むしろ、ボードビューだけで運用しようとすると、期限や担当者の偏りを見落とします。

同じタスクDBに、次のビューを併設します。

ビュー	表示形式	目的
カンバン	ボード	ステータス別の流れを見る
担当者別	ボードまたはテーブル	特定担当者への偏りを見る
期限切れ	テーブル	期限超過のカードだけを見る
今週期限	カレンダーまたはテーブル	今週動かすカードを見る
確認待ち	テーブル	確認者が見るカードを絞る
保留一覧	テーブル	判断待ち、外部待ちを拾う

Notionのボードビューは、ステータスだけでなく担当者や優先度でもグループ化できます。

ただし、1つのボードで全部を見ようとしない方がよいです。

ステータス別カンバンは、流れを見るためのビューです。

担当者別ビューは、負荷を見るためのビューです。

期限切れビューは、事故を拾うためのビューです。

見たいこと	おすすめビュー
今どこで止まっているか	ステータス別カンバン
誰に偏っているか	担当者別ボード
期限を過ぎているもの	期限切れテーブル
今週確認すべきもの	確認待ちテーブル
優先度が高いもの	優先度別ビュー

見た目の分かりやすさだけなら、ボードが強いです。

漏れを防ぐなら、テーブルとフィルターが強いです。

この2つを併用すると、Notionカンバンはかなり実務で使いやすくなります。

レビュー待ちと差し戻しを分ける

Notionカンバンで多い失敗は、「レビュー待ち」が見えないことです。

進行中のカードが多いように見えても、実際には担当者の作業ではなく、確認者のレビュー待ちで止まっていることがあります。

この状態を放置すると、担当者の問題なのか、確認者の問題なのか分かりません。

そのため、レビュー待ちを独立した列にします。

列	誰が動かすか	次の状態
進行中	担当者	確認待ち
確認待ち	確認者	完了、または差し戻し
差し戻し	担当者	確認待ち
保留	管理者、外部相手	進行中、または中止

差し戻しには、理由を残します。

理由がない差し戻しは、同じ問題を繰り返します。

最低限、次のプロパティを持たせます。

プロパティ	型	用途
完了条件	テキスト	何を満たせば完了か
確認者	ユーザー	誰が完了判定するか
差し戻し理由	テキスト	なぜ戻したか
次回確認日	日付	次に確認する日
関連プロジェクト	リレーション	どの案件に影響するか

Notionプロジェクト管理の作り方

レビュー待ちと差し戻しを分けると、週次会議で見るべきカードが絞られます。

進行中が多いのか。

確認者が詰まっているのか。

差し戻しが多く、完了条件が曖昧なのか。

この切り分けができるだけで、カンバンは「見える化」から「改善」に近づきます。

週次会議での使い方

Notionカンバンは、毎日全員で眺めるだけでは効果が弱いです。

週次会議で、例外から見るようにします。

おすすめの順番は次の通りです。

順番	見るもの	決めること
1	期限切れビュー	期限変更、担当変更、スコープ調整
2	確認待ち列	誰がいつ確認するか
3	差し戻し列	完了条件や依頼内容を直すか
4	保留列	解除条件、次回確認日、継続判断
5	進行中列	WIPが多すぎないか
6	今週期限	今週必ず進めるカードを絞る

順調なカードを1件ずつ読む必要はありません。

会議で見るべきなのは、流れていないカードです。

カンバン会議では、全部のカードを報告するより、期限切れ、確認待ち、差し戻し、保留だけを見て、次の移動条件を決める 方が効果があります。

会議で決めたことは、カードに残します。

決めること	Notionで残す場所
期限変更	期限プロパティ
担当変更	担当者プロパティ
確認予定	次回確認日
差し戻し理由	差し戻し理由
スコープ変更	関連プロジェクト、議事録
完了条件の変更	完了条件

カンバンを見て話すだけではなく、会議中にプロパティを更新します。

更新されないボードは、次の週には信用されなくなります。

完了列を倉庫にしない

カンバンを運用していると、完了列が増え続けます。

完了カードが増えること自体は悪くありません。

ただし、完了列が大きくなりすぎると、ボード全体が見づらくなります。

Notion公式ヘルプでは、完了列が増えてきた場合は列を非表示にし、完了したカードを非表示グループに入れる運用が紹介されています。

実務では、次のように整理します。

方法	向いている場面
完了列を非表示にする	ボードを軽く見たい
完了日を入れる	後から実績を振り返りたい
月別の完了ビューを作る	月次報告に使いたい
プロジェクトごとに完了を集計する	進捗率や案件報告に使いたい

完了したカードを消す必要はありません。

ただし、作業中のカードを見る画面に、過去の完了カードを大量に置く必要もありません。

進捗率を使いたい場合は、完了カードをタスクDBに残したまま、ロールアップや数式で集計します。

Notion進捗率の出し方

TrelloやBacklogへ移す判断

Notionカンバンは便利ですが、専用ツールの代わりにならない場面があります。

次の状態になったら、Notionだけで粘らない方がよいです。

状態	検討する移行先
バグ、リリース、開発チケットが中心	GitHub Issues、Jira、Backlog
顧客対応の期限やSLAがある	ヘルプデスク、CRM、kintone
承認履歴や監査ログが必要	ワークフロー、kintone
外部パートナーが頻繁に更新する	Trello、Backlog、顧客ポータル
工数、請求、原価と連動する	案件管理、会計、ERP

Notionを捨てる必要はありません。

Notionには、案件概要、議事録、決定事項、軽いタスク一覧を残し、厳密なチケット管理や顧客対応は専用ツールへ分ける設計もあります。

カンバンが便利だからといって、すべての業務をボードに押し込む必要はありません。

Notionで扱うべきなのは、チームが同じ画面を見て、次に動かすカードを決められる範囲です。

まとめ

Notionでカンバンを作るなら、ボードビューを使います。

ただし、カンバン用の別DBを作るのではなく、タスクDBの表示形式としてボードビューを作る方が安全です。

列は、未着手、進行中、確認待ち、差し戻し、保留、完了くらいに絞ります。

特に、確認待ちと差し戻しは分けます。ここを分けないと、誰が止めているのか分かりません。

進行中や確認待ちのカード数を見れば、WIPや滞留を把握できます。

ボードだけで足りないところは、担当者別ビュー、期限切れビュー、確認待ちビュー、保留一覧で補います。

週次会議では、全部のカードを読むのではなく、期限切れ、確認待ち、差し戻し、保留だけを見て、次の移動条件を決めます。

Notionカンバンの目的は、カードをきれいに並べることではありません。

止まっている仕事を早く見つけ、誰がいつ次の状態へ動かすかを決めることです。