ナレッジ管理モジュールの運用設計書

ナレッジ管理を回すには、誰が記事を書き、誰が公開を承認し、古くなった記事を誰が退役させるかを決める必要がある。ServiceNowはワークフロー状態とFlow Designerの公開・退役フローを最初から備えている。だが「どのKnowledge Baseに承認を挟むか」「フィードバックが来たら誰が直すか」「有効期限が切れかけた記事をどう見つけるか」までは決めてくれない。この記事は、Australia PDIの構成を前提とした運用設計書のサンプルである。章立てと記述の粒度は、そのまま自社の設計書に流用できる形にしている。

本書に含む章

• 運用設計書に必要な章立て

• ナレッジ運用の枠組み（KCS）とServiceNow実装の対応、対象者別のKB設計軸

• Knowledge Base単位のオーナー・投稿者・レビュアーという体制設計

• SLA定義が0件という前提での鮮度管理の設計

• 記事のフィードバックが対応タスクへ変わらない実態を踏まえた品質サイクル

• Knowledge Base単位の承認要否と可視性設定の運用ルール

設計の前提

• ロール8件は、投稿者・レビュアー・ナレッジ管理者の3層を想定した構成になっている

• 記事型・フィードバック・品質評価の仕組みは、業界で使われるKCSフレームワークとほぼ1対1で対応する

• Service PortalとAgent Workspaceは別々のプラグインとして実装されており、対象者に応じてKBを使い分けられる

• SLA定義（contract_sla）はcollection=kb_knowledgeで0件が標準であり、時間管理はSLA以外の設計に委ねられている

• Knowledge Base本体（kb_knowledge_base）と記事（kb_knowledge）で、可視性設定のフィールド構成が異なる

運用設計書の章立て

ServiceNow のモジュール運用設計書は、次の構成とする。

章内容1本書の目的と適用範囲2前提条件3運用体制4役割分担（RACI）5運用ルール6サービスレベル7エスカレーション8通知と報告9品質管理10会議体11教育と引き継ぎ12運用開始の準備13用語定義

開発設計書が「どう作るか」を定めるのに対し、運用設計書は「誰がどう回すか」を定める。両者で項目は重複させない。Publish・Retireボタンの個別の押下手順は運用手順書に、KBの承認要否をどう決めるかは本書に記載する。

第1章：本書の目的と適用範囲

本書は、ServiceNow のナレッジ管理モジュールを日常運用するための体制・役割・ルールを定める。

本書が対象とするのは、運用の責任者と各役割の担当者である。システムの設定値と実装方式は、別途の開発設計書で定める。

適用範囲は、記事の起票から公開・改版・廃止までの日常運用とする。Knowledge Base単位の承認要否の決め方は第5章に、フィードバックへの対応は第8章に記載する。

運用の目的は、必要な人が必要なときに正しい記事へたどり着ける状態を保つことにある。記事を増やすことよりも、公開後も内容が古びず指摘があれば直る仕組みを維持することが運用側の役割になる。この分担を前提として、以降の章を定める。

第2章：前提条件

2-1. ナレッジ運用のフレームワークとServiceNowの対応

ナレッジ管理の実装を評価するとき、その場だけの物差しで判断するより、業界で広く使われている型に照らすほうが再現性が高い。KCS（Knowledge-Centered Service）は、Consortium for Service Innovationが策定したサポート業務向けのナレッジ管理方法論である。記事の構造・役割段階・品質評価・利用者との対話ループについて、共通の語彙を提供する。ITILのナレッジ管理プラクティスも、知識の共有基盤を整える。既存記事の再利用によって解決までの時間を短縮することも、目的の1つに掲げる。KCSは、この目的を具体的な運用手順へ落とした方法論という位置づけになる。

Australia PDIのkb_knowledge基盤を確認すると、KCSの主要な要素に対応する実装が、記事型・フィードバック機能・品質評価のそれぞれに揃っている。

KCSの要素ServiceNowの対応する仕組み実測根拠記事構造（Issue／Environment／Cause／Resolution）KCS Article記事型が持つ4フィールド（kb_issue／kb_environment／kb_cause／kb_resolution、いずれもhtml型）kb_template_kcs_articleの辞書定義Capture in the workflow（対応の場で記事化する）Incidentクローズ時にCommentsから下書きを自動生成するビジネスルール「Incident Create Knowledge」本シリーズ第8巻実測UFFAループ（Use it／Flag it／Fix it／Add it）利用実績kb_use、フィードバックのkb_feedback.flagged、Checkoutによる改版、kb_submissionとCreate Knowledge BRによる記事化本巻・第5巻・第8巻実測記事品質の採点（Article Quality Index）kb_knowledge.latest_aqiフィールドと、合格点を定めるglide.knowman.aqi_pass_score（既定70点）本シリーズ第4巻実測役割段階（候補者→投稿者→公開者→コーチ）本書が定める4層体制（投稿者→レビュアー→KBオーナー→ナレッジ管理者）とkb_uc_can_contribute_mtomによる段階的な投稿権限付与第3章（本巻設計）実測

本環境の記事型・フィードバック機能・品質評価は、KCSの主要な要素とほぼ1対1で対応する。したがって本設計は、体制や品質サイクルを独自に考案せず、KCSの役割段階とUFFAループを検証済みの基準として採用し、第3章の体制・第9章の品質サイクルをこの型に沿わせる。

KCS関連プラグイン（com.snc.knowledge_kcs_capabilities／com.snc.incident.knowledge）は、本環境ではいずれもInactiveである。記事型のテーブル定義や役割・フィードバックの仕組みは、プラグインを有効化しなくても動作する。プラグインが追加するのはKCSロール名などの付加的なメタデータにとどまり、本書が採用する型そのものは変わらない。

2-2. 誰をサポートするかで変わるナレッジの入口

ServiceNowは、ナレッジの入口を2系統で実装している。1つは利用者（一般社員）向けのService Portal・Employee Center、もう1つはヘルプデスク（担当者）向けのプラットフォーム画面・Agent Workspaceだ。com.snc.knowledge_serviceportal（Service Portal上のナレッジ機能）とcom.sn_component_workspace_knowledge（Agent Workspace上のナレッジ機能）は、別々のプラグインとして提供されている。本環境ではいずれもActiveになっている。担当者がIncidentなど作業中のレコードから記事を探す経路は、com.snc.knowledge3.graphql（Contextual Search向けGraphQLスキーマ、Active）が支える。Employee Center側にもsn_ex_sp_quick_linkからナレッジへの導線がある。

この2系統は、記事の書き方と公開範囲の設計に直接影響する。利用者向けの入口は、専門知識のない社員が自己解決を試みる場であり、平易な言葉遣いとFAQ・What Is型の記事が向く。ヘルプデスク向けの入口は、担当者がインシデント対応の途中で技術的な原因と再現手順を探す場であり、専門用語を許容したKCS Article・How To型の記事が向く。

kb_knowledge_base・kb_categoryの辞書には対象者を示すフィールドが無く、可視性もKB単位のUser Criteria任せの構造になっている。対象者の違いは、KBの分割そのもので表現するほかない。したがって本設計は、5-1で定めるKB分割基準の第一の軸に「対象者」を置き、既存の「承認要否」「利用者の範囲」の2軸をその下に配置する。

設計例（対象者別のKB設計）

項目利用者向け（セルフサービス）ヘルプデスク向け（内部ナレッジ）入口Service Portal・Employee Centerの検索プラットフォーム画面のナレッジホーム、Incident作業中のContextual Search文体専門用語を避けた平易な説明専門用語・再現手順を許容する技術的な記述記事型FAQ・What Is中心KCS Article・How To中心可視性全社員（KB単位のUser Criteriaで開く）itil等の担当者ロールに絞る効果自己解決による問い合わせ削減解決時間の短縮、回答の均質化

以下は、設計内容を具体化するための推奨例です。実際の組織名・グループ名・時間・閾値・通知先は、導入先の運用体制に合わせて確定してください。

1つのKBが両方の対象者を兼ねる場合もある。IT向けKBはApproval設定で全社員に開かれており、利用者からの単純な問い合わせとヘルプデスクの技術的な調査を両方受ける可能性がある。この場合はKBを分けず、カテゴリ単位で対象者を区別し、記事テンプレートを対象者ごとに使い分ける。

本番導入前には、Service Portal経由の閲覧とAgent Workspace経由の閲覧を、利用実績（kb_use）またはアクセスログで区別できるか確認する。本環境ではkb_useが0件のため、この検証は未実施である。

対象者の軸は、以降の章でも判断基準として使う。第5章のKB分割基準・記入基準、第9章のKPI、第11章の教育に反映する。

2-3. 製品が想定している役割分担

ロール8件の構成をもとに、体制を次のとおり定める。

層役割対応するロール投稿者記事の作成・編集・レビュー依頼を担うknowledgeレビュアー・承認者Approval設定のKBで公開可否を判断するknowledge系ロール保持者（KBオーナーが兼務することが多い）ナレッジ管理者KB全体の設定・可視性・テンプレ方針を運用するknowledge_admin・knowledge_managerview_as担当他ユーザー視点での見え方を確認するknowledge_view_as

knowledge_managerの権限範囲は、製品の説明に従う。

（訳: ナレッジベースを管理し、knowledge_adminの承認を得て新規ナレッジベースを申請できる）

引用元: /sys_user_role_list.do?sysparm_query=nameLIKEknowledge

Incident・Problemのitilロールはknowledge系ロールを一切自動継承しない。投稿・レビューの権限は、担当者へ個別に付与する前提で体制を組む。一方、継続的な改善管理の改善コーディネーター役割はknowledgeロールを自動的に含む構成になっており、改善提案の記録とナレッジ執筆の権限が製品側で結び付けられている。ロールの包含関係と、User Criteriaによる可視性の二層構造は、本シリーズ第3巻「ロール」で確認済みの内容を土台にする。

• 参考：ServiceNowのCIMはIncidentやProblemとどうつながる？ … 改善提案からナレッジ執筆権限が結び付く経路はここで確認する

2-4. SLAが無い前提での鮮度管理

contract_slaをcollection=kb_knowledgeで絞ると0件になる。ナレッジ管理にはOOTBのSLA定義が存在しない。

SLA定義を追加しない前提を維持する。記事は完成後も内容が古びていくという性質を持ち、期限を機械的に計測する対象は「対応時間」ではなく「内容の鮮度」になる。SLAではなくvalid_to（有効期限）を軸にした鮮度管理を、本書の時間管理の中心に据える。

valid_toは53記事全件に値が設定されているが、47記事は既定値の2100-01-01のままで、事実上の無期限になっている。個別の期限が入っているのは6記事だけである。この差を体制設計にどう反映するかは、第6章で決める。

• 参考：レガシーWorkflow（wf_workflow）とFlowの違い … 公開・退役フローの移行状況を確認する材料

2-5. 通知の宛先方針

有効な通知4件を確認すると、承認完了・却下・有効期限接近・記事共有の4場面に限られる。本設計もこの4件を土台に据え、追加の固定宛先は置かない。

レビュー依頼が発生した時点（承認レコードが作られた時点）の通知が、製品の標準機能として存在しない前提で運用を組む。4件のイベント名はいずれも承認完了・却下・期限接近・記事共有のいずれかに対応しており、レビュー依頼そのものを通知するイベントは無い。この抜けをどう埋めるかは第8章で決める。

• 参考：メール通知が飛ぶまでの4段階（Notification） … 通知が届かないときはここから追う

• 参考：承認は1人1レコード（sysapproval_approver） … レビュー依頼が生成する承認レコードの構造

第3章：運用体制

3-1. 基本方針

1. Knowledge Base単位にオーナーを1名置き、KBの品質と可視性設定に責任を持たせる

2. 投稿者はknowledgeロールを持つ担当者から、KBオーナーが指名する

3. レビュアーはApproval設定のKBだけに置き、Instant設定のKBには置かない

4. ナレッジ管理者は全KB横断で可視性・テンプレ・鮮度の運用ルールを統括する

この4層（投稿者・レビュアー・KBオーナー・ナレッジ管理者）は、KCSの役割段階（候補者→投稿者→公開者→コーチ）に対応させた構成である（2-1）。投稿者から始め、経験に応じてレビュアーやKBオーナーへ責任を広げる昇格の道筋を体制設計に組み込む。

3-2. 概要図

ナレッジ管理者が全社共通のルールを定め、KBオーナーがKBごとの投稿者・レビュアーを指名する。日々の記事作成と改版は投稿者が担う。

3-3. 設計項目

項目決定内容KBオーナーの人数KB1件につき1名kb_managersグループ未設定のまま個人運用を続けるか、グループへ切り替えるかをKBごとに判断する投稿者の任命KBオーナーが指名し、ナレッジ管理者がknowledgeロールを付与するレビュアーの任命Approval設定のKBのみ、KBオーナー自身が兼務するか別途指名するナレッジ管理者の人数1〜2名

3-4. 詳細設計

KBオーナーの人数

KB1件につき1名を専任とする。5件のKBには、それぞれ個人名のオーナーが登録済みである。KBの性質と利用者の広さが異なるため、オーナーを兼任させるより、KBごとに品質へ責任を持てる1名を置く。

kb_managersグループ

5件のKBすべてでkb_managers（管理グループ）が未設定であり、管理権限は個人のownerフィールドだけに依存している。オーナーが異動・退職すると、そのKBを管理できる人が一時的にいなくなる。記事数が2桁を超えるKBから優先して、kb_managersへ複数名のグループを設定する運用に切り替える。

投稿者の任命

KBオーナーが投稿候補者を選び、ナレッジ管理者がknowledgeロールを付与する。ロール付与を体制構築の起点にすると、指名だけで実際に投稿できない担当者が生まれる。指名とロール付与は同じタイミングで完了させる。

レビュアーの任命

Approval設定のKBだけにレビュアーを置く。Instant設定のKBにレビュアーを置いても、公開操作がレビューを経由しないため機能しない。レビュアーはKBオーナー自身が兼務してよく、別途指名する場合はナレッジ管理者へ届け出る。

ナレッジ管理者の人数

1〜2名とする。可視性設定・テンプレ方針・鮮度棚卸しという横断的な判断を担うため、KBオーナーより少人数に絞り、基準のばらつきを防ぐ。

記入例（体制の運用イメージ）

IT向けKBのオーナーには個人名（Bernard Laboy）が登録されており、公開承認もこのオーナー自身が担う。Known Error用KBのオーナーには「Problem Manager」という役割名のアカウントが登録されている。問題管理からの既知エラー登録という発生経路が、オーナー名にそのまま表れている実例である。KCS Knowledge Base（demo data）のオーナーには、KCSロールを持つ担当者（Arya Stark）が就いている。この3件は、KBの用途に応じてオーナーの性質が変わることを示す実例であり、本設計は「KBの用途に合わせてオーナーを選ぶ」という3-1の方針をそのまま採用する。

この記事の有料部に含まれるもの

4章以降に、運用設計書の記述サンプルを掲載する。

• 第4章 役割分担：RACI（13作業ぶん）と作業ごとの割り当ての意図

• 第5章 運用ルール：KB分割基準・記事テンプレートの使い分け・記入基準・可視性設計

• 第6章 サービスレベル：SLA非採用の判断と、valid_toによる鮮度管理の設計

• 第7章 エスカレーション：滞留を起点にした報告基準4つ

• 第8章 通知と報告：通知4件の実態と、フィードバックが対応タスクに変わらない実態への対応

• 第9章 品質管理：kb_use（利用実績）に依存しないKPI設計

• 第10章 会議体：4種類の会議の頻度・参加者・議題

• 第11章 教育と引き継ぎ：教育項目と引き継ぎの書式

• 第12章 運用開始の準備：確認項目14件と分野別の完了基準

分量は本文の後半およそ10,000字である。自社で変えるのは可視性設定の粒度・フィードバック対応の目標日数・KPIの目標値の3つ。それ以外は据え置きでも運用設計書として使える。

💰 ここから先は有料エリア