タスク管理モジュールの運用手順書
Incident・Problem・Change・Requestなど、担当者が実際に触るのはtaskを継承した63の子テーブルです。プロセスは違っても、担当者がすることは一覧で自分の持ち物を見つけ、開いて編集し、終わったら閉じるという3つの操作に集約されます。この手順書は、その3つの操作をtask層の視点でまとめたものです。個々のプロセスの入力ルールは、各プロセスの手順書が正本になります。
検証環境：Australia PDI / OOTB / 2026-09-04 確認
この手順書が扱う内容
task継承テーブルを横断して一覧で見る方法（task.list）
レコードをフォームで開いて編集する方法
レコードをクローズする方法
横断監視に使える絞り込みクエリと、誤操作からの戻し方
この手順書が扱わない内容
新しいtask継承テーブルの設計・作成（本シリーズ第9巻「タスク管理モジュールの開発設計書」）
プロセスごとの必須項目・承認フロー（各プロセスの運用手順書が正本）
1. 本手順書の役割と前提
taskは、Incident・Problem・Change・Request・Demandなど63の子テーブルに共通のフィールド・ACL・Business Ruleを提供する基底テーブルです。63テーブルそれぞれの入力ルールは、各プロセスの運用手順書が正本になります。
本手順書は、その手前にある共通操作だけを対象にします。プロセスをまたいでタスクを一覧で見る、フォームで編集する、クローズするという3つの操作です。新しいtask継承テーブルの設計は対象外とし、本シリーズ第9巻「タスク管理モジュールの開発設計書」に委ねます。
複数プロセスを兼任する担当者やチームリーダーは、Incidentの手順書・Problemの手順書・Changeの手順書をそれぞれ開き直すより、まずtask層の共通操作を1つ覚えるほうが早く動けます。プロセスごとの細部は、担当する案件が出たときにその手順書を開けば足ります。
参考：taskテーブル：ITSM全プロセスの共通の親 … taskが担う役割全体の整理
対象操作：task.listでの横断閲覧／フォームでの編集／状態のクローズ
対象外操作：新しいtask継承テーブルの設計・作成
対象バージョン：Australia
想定読者：複数プロセスのタスクを日常的に扱う担当者
必要なロール：itilまたはtask_editorを含む業務ロール
2. 手順の全体像
手順1はtask.listを開いて横断的に眺めるだけの操作で、無料で読める範囲に置きます。手順2のフォーム編集と手順3のクローズ、そして横断監視クエリ集とリカバリ表は、有料エリアにまとめます。
手順1（閲覧）：【担当者】task.listで横断的にタスクを見る
task.listは、taskを継承する全テーブルの行を1つの一覧にまとめて表示する合成ビューです。Incidentの一覧・Change Taskの一覧のようにテーブルごとに開き直さなくても、担当者に関係する行を1画面で見渡せます。
STEP1（一覧を開く）：【担当者】task.listを開く
操作：ブラウザで/task_list.doを開く。または左側のナビゲータフィルタに「Task」と入力し、表示されたモジュールを開く。
開いた直後は、Number・Priority・State・Assigned to・Short description・Task typeの列が並びます。フィルタを1つ足すたびに、画面上部にAll > 条件1 > 条件2という形でパンくずが増える仕組みです。パンくずの各要素はクリックで外せるため、条件を1つずつ足したり戻したりしながら絞り込めます。
確認する項目
一覧の右上にActionsボタンとNewボタンがあり、通常のテーブル一覧と同じ操作ができること
パンくずに現在の絞り込み条件が表示されていること
STEP2（種別を見分ける）：【担当者】Task type列でプロセスを見分ける
操作：一覧のTask type列を見る。
Task type列には、そのレコードが実際に属するテーブル（sys_class_name）の表示名が入ります。上のスクリーンショットでは、Action・Change Requestという2種類が並んでいる状態です。絞り込む条件を変えると、Change Task・Improvement Initiative・Decision・Demandのように、まったく異なるプロセスの行も同じ列で見分けられます。
未割当のアクティブなタスク2,339件の内訳を見ると、上位はプロジェクトタスク427件と証明書関連フォローアップタスク334件です。次いで素のtask行58件・承認グループ29件が続き、ChangeとIncidentはそれぞれ8件・6件で全体の1%に届きません。Task type列を見ずに「未割当タスクが多い」とだけ捉えると、対応すべき部門を取り違えます。
確認する項目
同じ一覧の中に複数のTask typeが混在していること
対応が必要な部門を、Task type列で確認してから着手すること
STEP3（絞り込む）：【担当者】よく使う条件で絞り込む
操作：一覧右上の検索欄、または画面のフィルタ機能で条件を追加する。URLのsysparm_queryに条件を書いても同じ結果になる。
代表的な2パターンを実際に開いた結果です。
active=true^assigned_toISEMPTY（未割当のアクティブなタスク）は2,339件、active=true^due_dateISNOTEMPTY^due_date<javascript:gs.now()（期限超過のタスク）は138件でした。担当者ごとの絞り込みやグループごとの絞り込みも同じ考え方で組めます。具体的なクエリ一式は、この記事の有料部にまとめます。
よく使う条件は、フィルタ画面から名前を付けて保存できます。保存した条件の実体はsys_filterというテーブルです。
参考：一覧の検索欄で使える記号と絞り込みの書き方 … OR・NOT・ワイルドカードなどの書き方
参考：Save filterの実体は1テーブル（sys_filter） … 絞り込み条件を保存する仕組み
確認する項目
条件を足すたびに件数が変わり、パンくずに条件が積み上がること
よく使う条件は、都度URLを打たずに保存して呼び出せること
STEP4（範囲を知る）：【担当者】素のtask行はadminしか読めないと理解する
操作：特別な操作は不要。task.listに並ぶ行のうち、どの子テーブルにも分類されない行があることを知っておく。
task自身にはread・write・createのACLが1件もありません。あるのはreport_view（レポート作成用）とdeleteだけです。テーブルにACLが無いときの既定動作は、システムプロパティglide.sm.default_modeが決めます。本PDIでの値はdenyで、どの子テーブルにも分類されない素のtask行（本記事の確認時点で258件）は、実質adminロールでしか読めません。Incident・Change Taskのように子テーブルに分類された行は、その子テーブル自身のACLで判定されるため、この制約を受けません。
read権限が無いのにレポートだけは作れるという組み合わせは、一見ちぐはぐに見えます。ダッシュボードやレポートで横断集計だけを行い、一覧では素の行を極力見せない設計だと捉えると、この組み合わせに筋が通ります。
この構造の詳しい判定フローは、本シリーズ第3巻「タスク管理モジュールのロール」で扱っています。原因の切り分けに迷ったときは、次の2本も助けになります。
参考：ロールを付けたのに見えない理由：ACL（sys_security_acl） … ACLの条件と評価順の基本
参考：Access Analyzer：「見えない」の理由を層で切り分ける … 見えない原因をACL・ロール・フィールド権限のどの層かで切り分ける
確認する項目
一覧の行数が想定より少ないとき、対象がどの子テーブルに属するかを先に確認すること
素のtask行だけが例外的にadmin限定であり、子テーブルの行はそれぞれ別の基準で判定されること
この記事の有料部に含まれるもの
手順2・手順3の作業手順と、成果物としてまとめた横断監視クエリ集・リカバリ表を記載します。
手順2：レコードをフォームで開いて編集する2つのSTEP
手順3：状態をクローズ系へ変更し、結果を確認する3つのSTEP
成果物：横断監視に使えるクエリ集（用途・URL・該当件数の一覧）
成果物：誤操作から戻す簡易リカバリ表
分量は本文の後半およそ4,800字です。手順どおりに操作すれば、複数プロセスのタスクを自分の担当分だけに絞って編集・クローズできるようになります。
💰 ここから先は有料エリア
