📒
Notionで実装する構造化した業務フロー設計

2025/12/05に公開
 1. はじめにこんにちは。株式会社タイミーでエンジニアリングマネージャー（EM）をしている三宅です。 この記事は Timee Advent Calendar 2025 の5日目の記事です。
今年もアドベントカレンダーの季節がやってきました。2025年も残すところあとわずかですね。エンジニアリング組織の1年を振り返る良い機会です。
私は普段、EMとしてピープルマネジメントや組織運営に携わっていますが、その中で一定の時間を割いているのが「業務フローの設計」です。開発プロセス、採用フロー、オンボーディング、インシデント対応……組織が拡大すればするほど、これらのプロセスをいかに円滑に、かつ属人化せずに回すかが組織の出力（アウトカム）を左右します。
本日は、私がこれらの業務フロー設計において、社内で利用しているNotionをどのように活用しているかについてお話しします。単なるドキュメントツールとしてではなく、データベース（DB）機能やオートメーション機能を駆使してより強い業務フローを構築する手法について、その背景にある設計思想から共有できればと思います。

 2. 業務フローが「定着しない」という課題EMとして新しいプロセスやルールを導入した際、多くの人が直面するのが「設計したフローが組織に定着しない」という課題です。
社内ドキュメントに綺麗なフロー図を描き、詳細な手順書を残し、会議等で周知をしたとしても、数ヶ月後には以下のような状況に陥ることが少なくありません。
伝達の不十分さと認識のズレ
「手順書を読みましたが、解釈が違っていました」「そのルールは知っていましたが、自分のチームには適用されないと思っていました」といった認識の齟齬。

個人の能力への依存
几帳面なリーダーがいるチームはしっかり運用されているが、そうでないチームでは形骸化している。あるいは、特定の「詳しい人」がいないとプロセスが回らない。

慣習化の発生
「この手順は以前と異なるから」と現場判断で省略されたり、独自のローカルルールが継ぎ足されたりして、組織全体としてのデータの整合性が取れない。

これらの原因を考えると、「人間の意志力や記憶力に依存した運用」をしていることに尽きます。「ドキュメントを読んで、正しく理解し、その通りに実行する」という行為は、忙しい開発現場においては非常に高い認知コストを要求します。
そのため、業務フローを定着させるためには「気をつける」のではなく、「高度に構造化された仕組み」を提供する必要があると考えています。

 3. 業務フローを構成する要素とNotion具体的な手法に入る前に、そもそも「業務フロー」とは何かを再定義してみます。
私は、業務フローとは「取り扱う情報に対し、『いつ（When）』『どこで（Where）』『誰が（Who）』責任を持つかを管理し、状態を遷移させること」だと考えています。
情報（What）: タスク、仕様書、インシデントレポートとそれらを構成するプリミティブな要素。
接点（Where/When）: 定例会議、朝会、チャット上のやり取りなど、情報の確認や更新が行われる場。
責任（Who）: その情報のボールを誰が持っているか。
従来のドキュメントでは、これらが静的なテキストとして記述されているだけでした。しかし、Notionはリレーショナルデータベースの機能を持つため、これらの要素をアプリケーションのようにマッピングして実装することが可能です。

 Notionにおけるマッピングの考え方「情報」 = データベース (DB)とプロパティ
タスクやプロジェクトそのもの。DBのプロパティによって構造化されたデータとして扱います。

「接点（会議体）」 = DBのテンプレート / ページの内容
情報の更新が行われる「場」です。定例会議の議事録ページなどがこれに当たります。

「責任・状態」 = プロパティの一部
ステータス（ToDo/Doing/Done）や担当者によって、現在の情報の持ち主と状態を表現します。

このように捉え直すことで、組織の業務フローを単純なドキュメントではなく、もう位置段深ぼった構造化された機能を提供することが可能です。

 4. 構造化とUXを提供する具体的な手法Notionを使った業務フローの構造化手法としてインシデントに対する対応フローを例として取り上げ紹介したいと思います。

 前提となる構造インシデント対応に対する業務フローでは例えば
インシデント (Alert/Incident)
インシデントそのものの情報を集約します。

振り返り (Postmortem)
インシデントで何が起きたかを分析し、その結果を集約します。

原因 (Problem)
振り返りで分析して明らかになったインシデントの原因を集約します。

再発防止 (Action Item)
インシデントから導き出された原因から再発防止とその進行状況について集約します。

というような要素をそれぞれ分解してそれぞれDB化することが考えられます。



インシデント対応における業務構造化の関係性

 4.1. DBとプロパティによる情報の「構造化」まず行うべきは、業務で扱う情報の「型」を定義することです。DBのプロパティは入力する情報を制約することができるため、フリーフォームで入力するときよりも観点の入力確度や漏れを防ぐことができます。

例えばインシデント対応について、プロパティでマイルストーンを埋めることによって入力する情報を固定のフォーマットで入力することができます。


プロパティの設定例
これにより、入力される情報は強制的に構造化されます。構造化されたデータは、後からフィルタリングしたり、並び替えたり、Notion関数を利用すれば集計したりすることができます。いわば、組織内で扱う情報にスキーマを定義する作業です。

 4.2. リレーションによる「関係性と遷移」の表現業務フローにおいて情報は孤立していません。「インシデント」があり、それに紐づく「振り返り」があり、さらに「再発防止」があるというように、情報は階層構造や依存関係を持ちます。
Notionであればリレーション機能（Relation）を使うことで、これを表現できます。

リレーション機能はDBのプロパティで依存関係をもたせるDBを選択することで利用できます。

また、リレーションでは紐づけるページの数を1ページもしくは複数で選択できるため、1:多というような関係性についても整理可能です。
1:1 の関係: 親となるインシデントと、その振り返り。
1:多 の関係: 1つの振り返りと、そこに含まれる複数の要因。

といったように関連性ごとに紐づいていて良い情報を制御できます。
リレーションを活用すると、例えば「振り返り」のページを開いただけで、関連する「再発防止一覧」が自動的に表示されるビューを作れます。これにより、ユーザーはあちこちのページを探し回る必要がなくなり、情報の遷移がスムーズになります。


DBのリレーションの設定例

 4.3. テンプレートによる「入力内容の固定」と思考コストの削減「何をどう書くか」を個人の裁量に委ねると、情報の粒度はバラバラになります。ここで威力を発揮するのがDBのテンプレート機能です。
例えば「インシデント報告書」のDBを作る際、テンプレートとしてあらかじめ以下の見出しを用意しておきます。
発生事象（事実のみ記載）
影響範囲
金額
対象者
範囲

暫定対応
時系列

さらに、各項目の下にコールアウト等で「※ここでは推測を書かず、ログに基づいた事実を書いてください」といった説明書き（プレースホルダー的なテキスト）を入れておきます。



コールアウトと説明
これにより、書く人は「構成をどうしようか」と迷う時間がなくなります（思考コストの削減）。また、読み手にとっても常に同じフォーマットで情報が入ってくるため、認知負荷を下げることができます。

 4.4. ボタンとSlack連携による「フローの起点と循環」最後に、これらを動かす起点となるのが「ボタン機能」と「Slack連携」です。

 ボタンによるUXの提供複雑なリレーション設定やテンプレートの適用をユーザーに任せると認知負荷の増大やフローの迷いを生むためあまり良い状態にはなりません。ここでボタン機能を利用することで一連の動作を自動化することができるため、有効なツールとして利用できます。

例えば、「インシデントのページ作成」というボタンを一つ配置し、それを押すと以下の処理が一括で行われるようにします。
新しいインシデントのページを作成する。
日付とタイトルを自動設定する。
ステータスを「進行中」にする。
適切なテンプレートを適用する。
Slackにページの作成を通知する。
これにより、業務フローの起点が「ボタンを押す」という単純なアクションに落とし込まれます。裏側の複雑な仕組みを知らなくても、誰でも同じ品質でフローを開始できます。


ボタンによる業務フローの起点整備の例

 Slack連携によるリマインドフローが停滞するのは、「忘れていた」時です。Notionのオートメーション機能やSlack連携を使うことで、状態に応じた通知を飛ばせます。
例えば下記のようなケースで有効です。
ステータスが『レビュー待ち』になったら、レビュワーにSlack通知を送る。
ページ内のボタンが押下された際にSlackに通知する。
これにより、Notionを見に行かなくても、業務フローがプッシュ型でユーザーに働きかけるようになります。

 5. まとめ今回は、Notionを活用した業務フローの構造化について解説しました。
上記にも記載しましたが、業務フローの構造化は組織としてのアウトプットを最大化します。高度な構造化の上に効率的な組織運営が行われると考えています。
DBとプロパティで、情報の「型」を作る。
リレーションで、情報の「文脈」を繋ぐ。
テンプレートで、思考の「コスト」を下げる。
ボタンと連携で、行動の「トリガー」を引く。
これらは組織というシステムに対する構造化です。Notionを利用することで、簡易的に組織の業務プロセスを一段深くフローとして落とし込むことが可能です。
ぜひ皆さんも、Notionを武器に自走する組織のフローを設計してみてください！

 6. 株式会社タイミーでは仲間を募集中です！最後に宣伝をさせてください。 株式会社タイミーでは「一人ひとりの時間を豊かに」というビジョンのもと、プロダクト開発だけでなく、開発組織そのもののアップデートにも熱量を持って取り組んでいます。
今回紹介したような、組織の課題を仕組みやエンジニアリングで解決することに興味がある方、急成長する組織の土台作りに携わりたい方を募集しています。 エンジニア、エンジニアリングマネージャー、プロダクトマネージャーなど、全方位で積極採用中です！
少しでも興味を持っていただけたら、ぜひカジュアルにお話ししましょう。

https://product-recruit.timee.co.jp/

カジュアル面談は↓↓↓↓↓↓↓から！

https://product-recruit.timee.co.jp/casual

明日のアドベントカレンダーもお楽しみに！