タスク管理モジュールの開発設計書
新しい業務テーブルをServiceNowで作るとき、taskテーブルを継承するかどうかは最初に決める設計判断です。この記事は、その判断の思想を主題とする。Australiaの PDI では、taskを直接継承する子テーブルが63件存在し、共通のビジネスルール33件・固有フィールド71項目・ACL34件が最初から使える状態で用意されている。継承をどこまで使い、どこから自分で設計するかの境界を、判断基準とチェックリストの形で示します。汎用の作業依頼テーブルu_work_requestは、その実装例です。
検証環境：Australia PDI / OOTB / 2026-09-01 確認
本書に含む章
taskを継承で拡張する設計思想（なぜ継承か・拡張点の選び方）
継承時に必ず設計すること（辞書上書き・ACL・番号プレフィクス）
実装時に検討すること（チェックリスト）と禁止事項・アンチパターン
実装例：u_work_request（汎用作業依頼テーブル）の設計サンプル
主題はtask継承という拡張点をどう使うかの判断基準であり、u_work_requestは実装例です。task直接のACL・通知・SLA・Assignment Ruleはいずれも0件のため新規テーブル側で自作します。task層自体の変更は63テーブル全件に及ぶため、確認事項を第13章にまとめます。
設計書の章立て
章内容1〜2目的・前提条件3システム構成（6層の資産棚卸し）4OOTB実装設計（拡張点の選び方・実装チェックリスト）5〜8データ・画面・権限・処理設計9〜11通知・SLA・外部連携設計12移送設計13制約事項と禁止事項14〜15検証計画・用語定義
3章と4章が本書の中心である。6層の資産棚卸し（3章）と拡張点の選定基準・実装チェックリスト（4章）で判断を確定してから、5章以降をu_work_requestへの適用例として書く。継承する部分は「標準を継承する」と1行で記載する。
第1章：本書の目的と適用範囲
本書は、taskを直接継承する新規テーブルを設計する際の判断基準を定める。対象読者は設計担当者とレビュー責任者とし、運用の体制・役割は別途の運用設計書に委ねる。適用範囲は、taskという拡張点の使い方（継承の判断・必須設計・禁止事項）と、その判断を適用した実装例u_work_requestとする。個別プロセスの設計は対象外とする。
第2章：前提条件
項目内容対象バージョンAustraliaベースとする状態OOTB（プラグイン追加・カスタマイズなし）継承元テーブルtask（super_classが空の最上位クラス）新規テーブルu_work_request（taskを直接継承）作業タスクの子テーブル本設計では新設しない（第13章参照）
taskに関連するプラグインは13件あるが、いずれも周辺機能で、taskテーブル自体を有効・無効にするプラグインは無い。delivery_plan等サービスカタログ向けの数項目は継承フィールドに含まれるが、フォームに配置しないことで対応する。
第3章：システム構成
3-1. 設計方針
新規テーブルは、taskが提供する6層（データ・画面・権限・処理・期限と通知・設定値）の上に構築する
データ・画面・権限・処理の4層はtaskの継承分をそのまま使い、期限と通知の層は新規に定義する
3-2. 設計図
保存の流れに沿って層が重なる。画面層が入力を制御し、権限層が書き込みを判定し、処理層が補正と連鎖を行い、期限と通知の層が後続を動かす。taskは6層すべてに定義を持つが、量には大きな偏りがある。
3-3. 設計項目
6層の件数を、新規テーブル側の扱いと対応させて示す。
層taskの総数新規テーブル側での扱いデータ（フィールド）71全項目を継承する。固有項目は第5章の基準で追加画面（UIポリシー1・クライアントスクリプト5・UIアクション26）32標準を継承する。固有制御は第6章で追加権限（テーブルACL4・フィールドACL30）34read・write・createを新規追加（第7章）処理（ビジネスルール、有効のみ）33標準を継承する。固有処理は専用のorder帯へ期限と通知（通知1、SLA等は0）1通知・SLA・割り当てをすべて新規定義設定値（プロパティ）91一部を参照する。複製関連は新規定義
3-4. 詳細設計
件数は工数の見積もりに直結する。データ・画面・権限・処理の4層は継承で足りる部分が大半を占める。期限と通知の層はほぼ空（SLA・Assignment Rule・Escalation Rule・Data Lookupいずれも0件）である。したがって本設計では、この3点を新規テーブル側で一から定義する。
継承時に必ず設計すること
taskを継承すると自動で用意されるのは器と汎用ロジックだけで、値そのものは3か所で必ず自分で設計する。辞書上書きのclose_states等3属性（第5章）、read・write・createのACL（第7章）、記録番号のプレフィクス（第5章）である。この3点を欠くと、状態管理・権限判定・番号採番のいずれかが機能しない。
参考：ServiceNowのフィールド設定はどこに保存される？ sys_dictionaryを実機で読む … データ層の確認方法
第4章：OOTB実装設計
4-1. 設計方針
拡張点は、既存テーブルの流用・拡張、参照テーブルの追加、task継承、独自テーブルの5段階から選ぶ
u_work_requestは流用・拡張・参照テーブル単独では要件を満たせないと判定し、task継承（段階4）で設計する
4-2. 設計図
下の段階へ進むほど保守の負担が増える。独自テーブルはACL・通知・SLAを自作し、アップグレード時の再検証範囲も広い。
参照テーブルという選択肢
要件が「本体にフィールドを足す」ではなく「1件の依頼に複数件の付随データを持たせる」場合、テーブル継承よりも参照テーブルが向く。task_group・task_location・sysapproval_approverは、taskを継承せず参照項目1つで関連付けるテーブルで、本体の権限・状態管理を1つに保ったまま付随データだけを増やせる。詳細は第11章に記す。
4-3. 設計項目
要件に対する5つの実現手段を、保守負担とともに整理する。
段階実現手段保守の負担1. 既存テーブルの流用ticket等をそのまま使うなし2. 既存テーブルの拡張フィールドを追加する小。既存プロセスへの影響確認が必要3. 参照テーブルの追加参照項目1つで新テーブルを足す小〜中。本体の状態・権限に影響しない4. task継承での新規テーブルtaskを直接継承して新設する中。ACL・通知・SLAは自作するが継承分は使える5. 独自テーブルtaskを継承しない完全新規大。すべて自作する
実装時に検討すること
段階4（テーブル継承）を選んだ場合、実装に入る前に次を確認する。
項目確認すること・決め方継承階層の位置task直下かplanned_task系か。独立業務はtask直下を選ぶstateの扱い基底6値で表現できなければ辞書上書きで独自定義（第5章）共通BR33件との干渉orderが標準の帯と重ならないよう空いている帯に配置（第8章）フィールドACLの整合継承30件のitil・task_editorが不一致なら専用ロールを新設（第7章）SLA・割り当て・通知taskレベルは0件のため必要な分だけ新規定義（第9・10章）横断レポートへの影響task.listに行が並ぶため、集計対象に含めるか事前合意する
4-4. 詳細設計
採否の判断は次の形式で記録する。表1行で1つの判断を表す。
要件採用した方法理由社内の作業依頼を1テーブルで管理したいtask継承（段階4）。ticket流用（段階1）は不採用ticketは既に汎用チケットで、混在は分類・レポートを崩す承認・担当割当・横断集計を一から作りたくないtask継承（段階4）。独自テーブル（段階5）は不採用task固有71項目とtask参照98テーブルの横断性をそのまま使える依頼1件に複数件の付随データを持たせたい本体はtask継承＋参照テーブル併用状態・権限は1行で管理し、付随データだけを逃がす
項目の再利用性、ビジネスルールの再利用性、ACLの波及範囲（task直接はread・write・createとも0件）の3点で判断する。incidentもproblemもテーブル継承（段階4）を選ぶ。u_work_requestも、この前例に合わせる。
参考：自動割り当ての2つの仕組み（Assignment Rule / Data Lookup） … 標準で用意されている仕組みの例
この記事の有料部で得られるもの
有料部では、5章から15章までの記述サンプルを載せます。
第5〜8章 データ・画面・権限・処理設計：71項目の使う・使わない判定、辞書上書き、ACL・order帯の割り当て
第9〜12章 通知・SLA・外部連携・移送設計：taskが提供しない層をゼロから設計する
第13章 制約事項と禁止事項：task層を守るための禁止事項
第14章 検証計画：層別の確認項目
自社の要件を埋めれば、そのまま開発設計書として使える記述にしています。
💰 ここから先は有料エリア
