【Notion】Notionで申請フォームを部署ごとに分けたい時のDB設計

Notionを申請フォームとして活用している企業は多く、部署ごとに異なる申請項目や承認フローを設定したいケースがよくあります。しかし、すべての部署を1つのデータベースで管理しようとするとプロパティが乱立したり、複数のデータベースに分けると管理が煩雑になるという課題があります。本記事では、シングルデータベース方式とマルチデータベース方式の2つの設計パターンを比較し、それぞれのメリット・デメリットや具体的な実装手順を解説します。また、よくある失敗パターンや管理者に確認すべきポイントも紹介するため、自社の運用に最適な設計を選ぶ参考にしてください。

1. なぜ部署ごとに分ける必要があるのか

申請フォームを部署ごとに分ける理由は、主に以下の3点です。

• 申請項目の違い: 例えば、人事部は休暇申請・残業申請、経理部は経費精算・購入申請など、部署ごとに必要な入力フィールドが異なります。1つのデータベースにすべての項目を詰め込むと、不要なプロパティが増えてユーザーが混乱します。
• 承認フローが異なる: 承認者や承認順序が部署ごとに違う場合、データベースだけで制御するのは困難です。Notionの自動化機能やサードパーティツールと組み合わせる必要があります。
• 権限管理: 部署ごとに閲覧・編集権限を細かく設定したい場合、データベースを分ける方が簡単です。シングルデータベースでは行単位の権限設定ができないため、全員が見えてしまうリスクがあります。

2. シングルデータベース方式 vs マルチデータベース方式

最初に、2つの設計パターンを理解してください。以下の比較表を参考に、自社の規模や運用方針に合った方式を選びましょう。

項目	シングルデータベース方式	マルチデータベース方式
管理のしやすさ	1つのDBを管理するだけなので、全体の設定変更が容易。	複数DBの管理が必要。テンプレートの統一や更新作業が手間。
プロパティの複雑さ	全部署の項目を入れるとプロパティ数が増え、見づらい。	部署ごとに最適なプロパティのみ。シンプルで使いやすい。
権限設定	DB全体に対する権限のみ。行単位の制限は不可。	DBごとに権限設定可能。部署外のユーザーは見えない。
集計・分析	全部署のデータを横断的に集計しやすい。	集計のためには複数DBをまとめるビューやデータベース間リンクが必要。
テンプレートの活用	データベーステンプレートで部署用のビューを作成可能。	各DBに個別のテンプレートを設定。複製時に一貫性を保つ工夫が必要。
拡張性	新しい部署を追加するにはプロパティとテンプレートの修正が必要。	新しい部署用のDBを複製して作成するだけ。容易。

3. シングルデータベース方式の設計手順

3.1 プロパティ設計のポイント

シングルデータベースでは、すべての部署に共通するプロパティと、特定の部署だけに必要なプロパティを整理します。以下の手順で進めてください。

1. 各部署で必要となる申請項目をリストアップし、共通項目と固有項目に分類します。例えば、申請者名、申請日、ステータスは共通、プロジェクトコードは特定部署のみなどです。
2. 固有項目は「○○部署用フィールド」のようにプロパティ名に部署名を含めるか、セレクトプロパティの「部署」を使って条件付きで表示する方法を検討します。ただしNotion標準機能では条件付き表示はできないため、フォームビュー(データベースのフォーム機能)を部署ごとにテンプレート化するのが現実的です。
3. データベースの「フォームビュー」を部署ごとに作成し、各フォームに必要なプロパティのみ表示する設定をします。例えば、人事部用フォームでは「休暇種別」「残業時間」、経理部用フォームでは「経費区分」「領収書URL」といった具合です。
4. 「部署」セレクトプロパティを必ず作成し、申請時にユーザーが自身の部署を選択するルールにします。これにより、フィルターや集計が容易になります。
5. データベースのデフォルトビューを「部署ごとのグループ化」に設定し、各部署の申請がひと目でわかるようにします。

3.2 テンプレート機能の活用

シングルデータベース方式では、テンプレート機能を使って部署ごとのフォームビューを定義します。手順は以下の通りです。

1. データベースの「テンプレート」ボタン(+ New)から新しいテンプレートを作成します。
2. テンプレート内で、部署プロパティに特定の値を初期設定する(例:人事部なら「人事」)ようにします。
3. 各テンプレートに必要なプロパティのみを表示するように、フォームビューの設定でプロパティの表示・非表示を調整します。
4. テンプレート名を「人事部用申請フォーム」「経理部用申請フォーム」などわかりやすく付け、ユーザーが迷わないようにします。
5. 実際にテストユーザーに使ってもらい、不要なプロパティが表示されていないか確認します。

4. マルチデータベース方式の設計手順

4.1 データベースの複製とテンプレート化

マルチデータベース方式では、まず1つのベースとなるデータベースを完璧に設計し、それを複製して各部署用にカスタマイズするのが効率的です。

1. 共通部分のみを含む「マスターデータベース」を作成します。この時点では部署固有のプロパティは入れません。
2. マスターデータベースを複製し、部署ごとに不要なプロパティを削除、必要なプロパティを追加します。例えば、経理部用DBには「支払先」、総務部用DBには「備品カテゴリ」など。
3. 各DBの権限設定を行います。ワークスペースのメンバー設定で、特定の部署のメンバーだけに編集権限を与え、他の部署は閲覧不可にします。
4. 全社で集計が必要な場合は、リレーションとロールアップを使って、各部署のデータを集約する「集計用データベース」を作成します。この集計DBからは参照のみ可能にし、直接編集はさせないようにします。
5. 各部署の申請フォームをページとして、各部署のDB上に作成します。ユーザーは自分の部署のDBだけを見ればよいため、迷いが減ります。

4.2 承認フローの統合(別ツールとの連携)

マルチデータベース方式では、承認プロセスをどう統一するかが課題です。Notionの自動化機能(例:ステータスが変更されたら通知)を使うか、外部ツール(Zapier、Make)と連携することを検討します。管理者に確認すべきポイントとして、以下の内容をまとめておきます。

• 各部署ごとに承認者リストを共有データベースで管理し、リレーションで紐付ける方法。
• Notionの「ボタン」プロパティ(データベースボタン)を使って、複数のアクションを1クリックで実行するワークフロー。
• サードパーティツールを使う場合のコストと導入期間。管理者にツールの利用可否を確認してください。

5. よくある失敗パターンとその対策

5.1 プロパティの乱立

シングルデータベース方式で、全部署の項目をそのままプロパティに追加すると、カラム数が30～40を超えることがあります。これによりフォームが非常に見づらくなり、入力ミスが増えます。対策として、必要最低限のプロパティに絞り、残りはテキストプロパティにJSONでまとめるなどの工夫が必要です。ただし、JSONでは集計が難しいため、本当に必要な項目だけを厳選しましょう。

5.2 テンプレートの更新漏れ

マルチデータベース方式では、各DBのテンプレートを個別に管理するため、共通項目を変更する際に全DBのテンプレートを手動で更新する必要があります。この作業を忘れると、部署間でフォームの項目が不一致になります。対策として、マスターデータベースでテンプレートの変更を一括適用するスクリプト(Notion API)を検討するか、定期的な監査を実施します。

5.3 権限設定のミス

シングルデータベース方式では、全メンバーがすべての行を閲覧できてしまうため、人事部の給与情報が他部署に見えるリスクがあります。対策として、機密情報は別データベースに切り出すか、閲覧権限をグループで制限できるNotionのプラン(Enterprise)を検討します。マルチデータベース方式でも、間違って親データベースから子データベースへのリンクを許可すると、権限が漏れることがあるので注意してください。

6. 管理者に確認すべきこと

設計を始める前に、ワークスペース管理者と以下の点を必ず話し合ってください。

• ワークスペースプラン: マルチデータベース方式ではデータベース数が増えるため、プランの制限(例:無料プランでは1000行まで)に抵触しないか確認します。
• 承認フロー自動化の可否: Notionの自動化機能だけでは複雑な承認が難しい場合、外部サービス(Zapier等)の導入許可を得てください。
• 既存データベースとの統合: すでに他のデータベースとリンクしている場合は、影響範囲を洗い出します。
• 監査ログの必要性: 申請履歴を追跡する必要がある場合は、Notionのアクティビティログを活用するか、別途ログ用DBを用意します。

7. よくある質問(FAQ)

Q1. 後から部署を追加したい場合、どうすればよいですか?

シングルデータベース方式の場合は、セレクトプロパティに新しい部署を追加し、テンプレートを新規作成します。マルチデータベース方式の場合は、既存のデータベースを複製して、部署名と権限を変更するだけです。両方式とも、既存データに影響を与えずに追加可能です。

Q2. データの集計をしたいのですが、どの方式が向いていますか?

全部署のデータを横断的に集計したい場合は、シングルデータベース方式が圧倒的に有利です。マルチデータベース方式でも、リレーションを使って集計用DBを作成できますが、設定が複雑になるため、集計が最優先ならシングルDBを選びましょう。

Q3. プロパティの数が多くなりすぎて困っています。良い対策はありますか?

プロパティを減らすために、共通項目と固有項目を明確に分け、固有項目はテキストプロパティ1つにJSON形式でまとめる方法もあります。ただしJSONではフィルタや集計ができなくなるため、本当に必要な項目だけプロパティ化し、残りはテキストの自由記述欄にするのも手です。

まとめ

Notionで申請フォームを部署ごとに分けるDB設計には、シングルデータベース方式とマルチデータベース方式の2つがあります。シングルデータベース方式は管理と集計が容易な反面、プロパティが乱立しやすく権限設定に注意が必要です。マルチデータベース方式は権限管理がしやすく拡張性に優れますが、テンプレートの統一や集計に工夫が求められます。自社の運用規模やセキュリティ要件、集計の必要性を考慮して最適な方式を選択してください。また、必ずバックアップを取った上でテスト環境で試し、ユーザーのフィードバックを得ながら改善すると、より実用的なフォームになります。

🧩

Notionトラブル完全解決データベース 共有、権限、データベース、Notion AI、インポートで止まる問題を横断的に確認できます。