Notion と Slack でタスク管理を回す｜連携の範囲と、窓の分け方

Notion と Slack を並行して使っていると、タスク管理の置き場所で迷いが出てきます。会話は Slack で進み、決まったことは Notion に書く。この形自体は多くのチームが取っている流れですが、実際に運用すると、Slack のメッセージを Notion に写す手間と、2つの画面を行き来する手間の2つが残ります。ここでは、公式の連携でどこまで自動化できるのか、有料プランが要る範囲はどこかを整理したうえで、2つの画面を1日じゅう開くときの置き方まで踏み込みます。

会話とタスクが分かれている状態が、そもそもの前提

Slack はメッセージが時系列で流れる作りで、Notion はページとデータベースが構造として残る作りです。役割が違うため、どちらか一方に寄せる解き方はうまくいきません。Slack にタスクを書けば流れて消え、Notion だけで会話をすれば反応が遅くなります。

流れるほうの性質は、プランの条件にも表れています。Slack のフリープランは90日間のメッセージ履歴と、連携できるアプリが最大10個までという線引きです。

90 日間のメッセージ履歴 / 最大で 10 個のアプリ 出典: slack.com

つまり、無料の範囲で使っている場合、3か月より前のやり取りは検索で出てきません。決まったことを Notion 側に残す運用は、好みの問題ではなく、履歴が消える前提への対処でもあります。ここを押さえると、連携をどこまで作り込むかの判断がしやすくなります。

公式の連携でできることは、大きく3方向

Notion のヘルプでは、Slack との連携の中身が具体的に案内されています。方向は3つです。

1つ目が、Slack のメッセージを Notion のデータベースへ送る動きです。対応が必要になったメッセージや、新しく出たアイデアを、その場で Notion のページとして作れます。スラッシュコマンドを打つか、メッセージの右横に出るオプションから選ぶ形で、送り先のデータベースを検索して指定します。データベースの既存のプロパティに合わせて、作るページに情報を足すこともできます。

2つ目が、Slack から Notion のタスクを作る動きです。タスク名、担当者、ステータス、期限、説明を Slack 側の画面で入力し、Notion のプロジェクトへ送ります。会話の流れを切らずにタスクが立つため、書き写す工程が消えます。

3つ目が、逆向きの通知です。Notion 側で何かが起きたときに Slack へ知らせます。自分のページにコメントが付いたとき、参加しているコメントのスレッドに追記があったとき、データベースのプロパティが変わったとき、ページへのアクセスを求められたときなどが対象です。

ここで押さえておきたい制約が1つあります。メッセージから Notion へ送るスラッシュコマンドは、Slack のチャンネルの階層でのみ動き、スレッドの中では動きません。議論がスレッドに潜ったあとで「これをタスクにしよう」となったときに、その場からは送れないということです。運用の設計では、この1点が効いてきます。

通知の自動化は、有料プランの範囲に入る

連携を作り込む前に確認しておきたいのが、どこから有料になるかです。Notion のヘルプは、Slack へ通知を送るオートメーションについてはっきり書いています。

備考： この機能は有料プランでのみご利用いただけます。 出典: notion.com

対象は、ボタン、データベースのボタン、データベースのオートメーションから特定の Slack チャンネルへ通知を送る作りです。たとえば「ステータスが完了に変わったら、そのチャンネルに知らせる」といった動きは、ここに含まれます。無料の範囲で使う場合は、Slack から Notion へ送る方向を中心に組み立て、逆向きの自動通知は個人宛の通知設定で代用することになります。

なお、Slack のフリープランではデータが1年後に削除される案内も出ています。連携で作った記録が Slack 側に残っている前提の運用にすると、期間が過ぎたところで参照できなくなります。恒久的に残したいものは Notion 側に置く、という切り分けが素直です。

タスクの正をどちらに置くかを、先に決める

連携の設定より先に決めておきたいのが、タスクの正がどちらにあるかです。ここが曖昧なまま両方に書ける状態にすると、同じ作業が2か所に立ち、どちらが最新か分からなくなります。

現実的な線引きは、期限と担当が付くものは Notion のデータベースに置き、その場で終わる依頼は Slack のメッセージのままにする、という形です。判断の基準を「明日以降も覚えておく必要があるか」に置くと、迷いが減ります。明日も覚えておく必要があるなら Notion へ送る。今日の午後に片付くなら Slack のままでよい。この1行を決めておくだけで、連携の使いどころがはっきりします。

もう1つ、ステータスの種類を増やしすぎないことも効きます。着手前、進行中、完了の3つで回るチームが、承認待ちや保留を足した結果、どこに置けばよいか分からない項目が溜まる例は珍しくありません。ステータスは、Slack で口頭に近い速度で更新できる粒度に保つほうが続きます。

そして、誰が動かすかを決めます。担当者本人が Notion のステータスを動かすのか、進行役がまとめて動かすのか。ここが決まっていないと、連携で通知が飛ぶようになったあとに、通知だけが増えて実態が変わらないという状態になります。連携は手間を減らす仕掛けであって、運用の設計を肩代わりするものではありません。

通知をどこで受け取るかで、置き方が変わる

Notion と Slack を並行して使うとき、通知の経路は4つに分かれます。Slack のアプリからの通知、Notion のアプリからの通知、ブラウザのタブからの通知、そしてメールに届く通知です。何も整理しないままだと、同じ出来事が2回も3回も届きます。

ブラウザのタブに置いている場合、通知はブラウザというアプリからの通知として届くため、どのサービスのものかは中身を読むまで分かりません。独立した窓に出すと、通知は .app ごとに届き、macOS の通知設定の一覧にもサービス名で並びます。おやすみモードの対象に個別で入れたり外したりもできます。

実務では、即時に反応すべきものだけを画面の通知に残し、残りは1日に数回まとめて見る形にすると落ち着きます。Slack のメンションと、Notion の自分宛のコメントは画面の通知に残す。データベースのプロパティが変わった知らせは、Slack のチャンネルに集めて後で読む。この配分にすると、通知の数が半分以下に落ちます。

1日じゅう2つの画面を開くと、切り替えが積み上がる

連携を整えても残るのが、画面の行き来です。Slack で会話し、Notion で確認し、また Slack に戻る。1回あたりは数秒ですが、1日に何十回も繰り返せば無視できない量になります。

ブラウザのタブに両方を置いている場合、この行き来は最も手数がかかります。タブは開いた順に左から並び、数が増えるほど1つあたりの幅が縮みます。ある本数を超えるとタイトルの文字が消えてファビコンだけになり、Notion のタブと Slack のタブを目で探すことになります。さらに macOS の Command+Tab はアプリ単位で切り替わるため、ブラウザへ移動してからタブを選ぶという2段階を踏みます。

Slack には Mac 用のアプリがありますが、Notion 側もアプリを入れると、今度は Dock にアイコンが増えます。どちらも1日じゅう開くサービスなので、置き方を決めておかないと、タブの中とアプリの列の両方に散らばります。

窓をまとめるか、サービスごとに分けるか

置き方には2つの考え方があります。

1つは、複数のサービスを1つの窓にまとめる形です。サイトをアプリにする道具の中には、1つの .app の中に Notion と Slack を入れ、左側のサイドバーに並んだアイコンで切り替えられる作りのものがあります。タブを探す動作が消え、Command+Tab の列には1枠しか増えません。組み合わせは自由に決められるため、Slack と Notion のほかに、チケット管理やリポジトリを足して「この案件の窓」として運用する使い方ができます。

もう1つは、サービスごとにアイコンを分ける形です。Slack は通知を受け取るので独立させ、Notion は書く作業のときだけ開く、といった扱いの差を付けたい場合はこちらが向きます。アプリごとに通知の入り切りを設定できる道具であれば、Slack の窓だけ通知を残し、Notion の窓は切っておく調整もできます。

どちらを選ぶかは、切り替えの頻度で決めるのが実際的です。1つの案件の中で数分おきに行き来するなら、まとめたほうが速くなります。時間帯で作業が分かれている場合は、分けたほうが集中しやすくなります。この種の機能の範囲はできることにまとまっており、まとめられるサービスの一覧は対応サービス一覧で確認できます。

作る手順と、運用してから効いてくる条件

作成の流れそのものは長くありません。URL を入れ、アイコンを選び、作成を押すという3ステップで .app ができる作りのものが多く、実際の流れは使い方ガイドにまとまっています。300以上のプリセットから選ぶだけでアプリにできる作りであれば、Notion や Slack のように広く使われているサービスは URL の入力もアイコンの設定も要りません。

運用してから効いてくる条件が2つあります。1つはプロファイルの分離です。仕事用と個人用で別の Notion ワークスペースや別の Slack ワークスペースに入っている場合、同じブラウザで開くと切り替えメニューを経由することになり、書き込む先を取り違えます。.app ごとに独立したブラウザプロファイルが割り当てられる作りであれば、Cookie もログイン状態も窓ごとに分かれます。

もう1つが、ブラウザの更新への対処です。Chrome 系のブラウザを土台にして .app を作る方式には、ブラウザが更新されるたびに .app が参照する実体との版がずれ、アイコンが元に戻ったり起動しなくなったりする弱点があります。常駐の監視が更新を検知して同期し直す、起動時に版のズレを取り込み直すといった自己修復の仕組みを持つかどうかで、その後の手間が変わります。挙動の違いはよくある質問にも整理されています。

費用の面では、無料の範囲で3アプリまで作れて、有料版との機能差が作成数だけという作りのものもあります。その場合は Notion と Slack の2つ、あるいは両方をまとめた1つをまず作り、足りなければ有料へ進む順序が取れます。買い切りで3,980円という価格帯のものもあり、月額課金が増えるのを避けたい場合の選択肢になります。条件は料金で確認できます。

導入の順序としては、連携を先に、置き場所を後にするのが向いています。連携は書き写す手間を直接減らすため、効き目がその日のうちに分かります。置き場所は切り替えの回数に効くもので、数日たってから体感として表れます。両方を同時に変えると、どちらが効いたのかが分からなくなります。

まずは Slack から Notion へタスクを送る経路だけを作り、1週間そのまま回してみる。書き写す手間が消えた時点で、次に画面の置き方へ進む。この順序なら、連携と置き場所のどちらが効いたのかが分かれて見えます。