ポータルモジュールの運用設計書
Employee Center を使うポータルの運用設計書です。架空のモデル案件について、表示不具合や掲載の依頼を誰が受け、誰が実行・確認・承認し、何をもって終えるかを、運用ルール15件で定めています。
検証環境：Australia PDI / OOTB / 2026-10-01 確認
この設計書で決めること
実行・確認・承認の分担と、同じ人が兼ねてはいけない組み合わせ
掲載・公開範囲・カタログ・特権の変更を、誰が申請し、誰が承認するか
表示不具合を、何分以内に誰へ渡し、停止か切り戻しかを誰が決めるか
本番への反映、パッチとメジャーアップグレード後の確認、月次の運用管理
値を自社用に置き換えるときの記入例・記入様式・値の決め方
組織・人数・時間・期限は、すべて架空のモデル案件から決めた値です。Australia PDI で確かめたのは、操作の結果と画面の挙動だけです。PDI の件数やロールの保有人数から、体制や期限は決めていません。
第1章から5.3（テーマ等の変更）までは無料で読めます。パッチとメジャーアップグレードの受け入れ以降（更新後の確認、運用管理、机上演習、各一覧、付録の記入例・記入様式・値の決め方）は有料部です。
1. はじめに
この章で決めること：何を、どの環境で、どの体制と分担で運用するか。
1.1 目的と対象範囲
この設計書の目的は、ポータルを従業員が使い続けられる状態に保つための判断を、障害の前に決めておくことです。第2章の6つの業務要件を、運用の側から満たすことを到達条件にします。
対象環境：本番インスタンスのポータルと、本番へ反映する前の開発環境。開発用のインスタンスは設けず、開発環境で開発と確認を兼ねる
対象のポータル：Employee Center（/esc）が主。/sp のホームも定点確認と重大度の判定の対象に含める
関連システム：人事システム（異動・入退社の反映元。管理は人事部）、情報システム部の連絡先台帳、ServiceNow の問い合わせ窓口（製品側の不具合と復元の照会先）
対象外：モバイル専用ポータル、社外（取引先）への公開、多言語対応、MID Server を使う連携
1.2 読み方・用語・文体
用語（第4巻の開発設計書と共通）
一般の従業員：ロールを持たない従業員
確認用ユーザー：表示の確認のために用意した、ロールを持たないテスト用のアカウント。公開範囲の区分ごとに、対象内と対象外を1名ずつ用意する
管理者：admin ロールを持つユーザー
ウィジェット：画面に表示する機能単位の定義（sp_widget）。ページの列にウィジェットを置いたレコードを「配置」と呼ぶ
公開範囲：誰にコンテンツを見せるかの指定。User Criteria（対象の利用者を条件で決めるレコード）で作る。モデル案件の5つの分け方を「公開範囲の区分」と呼ぶ
下書き（Draft）：ページの Draft 項目を有効にした状態
掲載：案内・ページ・ウィジェットを Employee Center に載せること
開発環境：モデル案件の、本番へ反映する前の環境（第4巻と同じ呼び方）。この記事で実機の確認に使った Australia PDI は「PDI」と書いて区別する
実行担当・確認担当：ポータル担当2名の、その日の役割。窓口当番表に日ごとに書く
受付：窓口当番が報告や依頼を受けた時刻
営業時間：平日9:00〜18:00。1営業日は9営業時間として数える。期限は営業時間の経過で数え、18:00を過ぎた分は翌営業日の9:00から数え直す
依頼票・障害記録・作業記録：依頼、表示不具合、作業ごとの記録。書式は付録
文体
決定事項（運用ルールの各項目と箇条書き）は常体で言い切ります。説明の文は「です・ます」で書きます。
識別子
要件は RQ、運用ルールは OR、確かめ方は TS、未決事項は OI、判断の記録は DC で始まるIDを持ちます。本文では名前で呼び、IDは見出し・対応表・分担表・一覧・付録でだけ使います。
根拠と確認の表示
製品の挙動を書いた行には、次のラベルを付けます。
［実測］PDI で操作して確かめた
［公式］製品同梱の説明か公式ドキュメントにある
［未確認］確かめていない
確かめ方には、状態を［実施済み］［未実施］で付けます。机上演習は、この記事の第7章で実際に行ったものだけを［実施済み（机上）］とします。
表と図は画像で載せ、すべて直後に同じ内容を文字で書き出しています。
1.3 モデル案件
国内の事業会社（従業員1,200名、本社と3拠点）が、従業員からの問い合わせと申請の窓口を Employee Center に集約した想定です。現在は部門ごとにメールと紙の申請書が混在しています。
構築と運用：情報システム部（5名）。うちポータル担当は2名
コンテンツ提供：人事部・総務部（各1名が掲載担当）
対応時間：平日9:00〜18:00。時間外と休日は翌営業日対応
公開の統制：掲載の申請者と承認者を分ける。人事・総務が申請し、情報システム部が承認して公開する
掲載ページ約20、配置約100、同時利用者は最大150
1.4 運用コンセプト
運用の方針は3つの考え方で組み立てます。
標準を使う：標準のポータル（Employee Center）・標準のウィジェット・標準のテーマを使う。追加開発は第4巻の設計が認めたものに限る。その代わり、製品の更新が表示に与える影響を「更新後の確認」で毎回確かめる
判断は人が行う：表示不具合の分類は診断スクリプトの出力で補助し、判断と承認は人が行う。表示不具合の自動通知には頼らない
月次で見直す：月次報告で期限の遵守率と切り戻しの件数を見て、期限と担当を見直す
運用の基準は、モデル案件の業務要件から決めます。PDI の件数や保有人数は、基準の根拠にしません。
1.5 運用体制と役割
モデル案件の役割は5つです。
掲載担当：人事部1名、総務部1名。依頼票を起票する。ポータルの設定は変更しない
ポータル担当：情報システム部の2名。日ごとに実行担当と確認担当に分かれる
窓口当番：情報システム部のうち、ポータル担当以外の3名が1日1名の輪番で受け持つ
情報システム部の責任者：1名。承認と、重大度の確定と、終了の承認を担う
代行者：責任者が窓口当番の3名から事前に1名指名する（1.8）
窓口当番が行う作業は、次の範囲に限ります。設定の変更、ロールとグループの変更、原因の分類は行いません。
報告と依頼の受付、聞き取り、暫定の重大度の判定
責任者とポータル担当への連絡、障害記録と作業記録の記入
使い方の問い合わせへの回答
確認用ユーザーでの表示の確認（読み取りだけ）
一覧の読み取りによる照合（公開範囲と特権の棚卸し）
窓口当番表には、日ごとの窓口当番1名、ポータル担当の実行担当と確認担当、代行者と代行期間を書きます。責任者が毎月25日までに翌月分を確定します。
掲載担当 → 窓口当番：依頼と連絡
窓口当番 → ポータル担当：引継ぎ（障害記録か依頼票で渡す）
窓口当番 → 責任者：重大度1だけは直接電話する
ポータル担当 → 責任者：承認の依頼と報告
ポータル担当 → ServiceNow 社：製品側の疑いがあり、責任者が承認したときだけ問い合わせる
責任者 → 代行者：不在のときに承認と判断を任せる
1.6 実行・確認・承認の分担
運用ルールごとに、実行・確認・承認を担う人を次の表で決めます。運用ルールの「責任者」の項目は、この表と同じ内容を書きます。
OR-01 掲載の承認：実行＝実行担当（公開）／確認＝窓口当番（公開後の表示）／承認＝確認担当
OR-02 公開範囲の付与と変更：実行＝実行担当／確認＝確認担当／承認＝責任者
OR-03 掲載の取り下げ：実行＝実行担当／確認＝確認担当／承認＝責任者（誤掲載は事後、それ以外は事前）
OR-04 公開範囲の区分の変更：実行＝実行担当／確認＝確認担当／承認＝責任者
OR-05 異動・入退社への対応：実行＝実行担当（グループの付け替え）、窓口当番（通知の照合）／確認＝確認担当／承認＝責任者
OR-06 公開範囲の定期棚卸し：実行＝窓口当番1名（照合）／確認＝確認担当／承認＝責任者
OR-07 カタログの表示切替と承認ルートの変更：実行＝実行担当／確認＝確認担当／承認＝責任者
OR-08 特権の付与と棚卸し：実行＝付与・剥奪はポータル担当のうち対象者本人でない1名、棚卸しは窓口当番1名／確認＝付与・剥奪は窓口当番1名、棚卸しはなし（照合そのものが確認のため）／承認＝責任者
OR-09 表示不具合の受付と分類：実行＝窓口当番（受付）、実行担当（分類）／確認＝なし（分類は設定を変えないため）／承認＝責任者（停止・切り戻し・調査継続の決定）
OR-10 公開範囲の誤りへの対応：実行＝実行担当／確認＝確認担当／承認＝責任者（取り下げは事後、再掲載は事前）
OR-11 復旧と切り戻し：実行＝実行担当／確認＝確認担当／承認＝責任者
OR-12 ベンダーへの問い合わせ：実行＝実行担当（起票）／確認＝確認担当（起票内容）／承認＝責任者
OR-13 本番への反映：実行＝実行担当／確認＝確認担当（その変更の掲載を確認担当が承認した場合は、窓口当番）／承認＝責任者（終了の承認を含む）
OR-14 更新後の確認：実行＝確認担当（5画面の確認）／確認＝なし（設定を変えないため）／承認＝責任者
OR-15 記録の保存と復旧：実行＝実行担当（記録の保存と照会の起票）／確認＝なし（照会は設定を変えないため）／承認＝責任者
同じ案件で兼ねてはいけない組み合わせ
申請と承認
実行と確認
実行または確認と、承認（代行者を含む）
特権の付与・剥奪で、対象者本人による実行と確認
棚卸しで、特権の保有者本人や、その設定の実行者による照合
掲載の承認と、その掲載を含む本番への反映は、同じ案件として扱います。兼ねるしかない日は、作業を延期します。延期できないのは、誤掲載の取り下げと重大度1の停止だけです。この2つは実行担当が単独で先に行い、確認は窓口当番、承認は責任者が事後に行います。
相談先と報告先
掲載の承認：相談＝責任者（機密を含む掲載だけ）／報告＝掲載担当
公開範囲の付与と変更、公開範囲の区分の変更：相談＝所有部門の掲載担当（管理職向けと人事・総務向けは人事部の掲載担当）／報告＝窓口当番
掲載の取り下げ、カタログの表示切替と承認ルートの変更：相談＝所有部門の掲載担当／報告＝窓口当番
異動・入退社への対応：報告＝人事部
公開範囲の定期棚卸し、特権の付与と棚卸し：報告＝掲載担当
表示不具合の受付と分類、公開範囲の誤りへの対応：相談＝掲載担当／報告＝報告者
復旧と切り戻し、本番への反映、更新後の確認：報告＝掲載担当と窓口当番
ベンダーへの問い合わせ、記録の保存と復旧：相談＝窓口当番／報告＝掲載担当
1.7 窓口と連絡先
窓口：情報システム部の問い合わせ窓口（メールと内線）。受付時間は平日9:00〜18:00
窓口当番表：責任者が毎月25日までに翌月分を確定する。3名の順番は月ごとに入れ替える
連絡先の正本：情報システム部の連絡先台帳。この設計書へ電話番号を転記しない。台帳の所在と更新者（責任者）は、第3巻の「開発作業の記録と引継ぎの記入」の引継ぎ書に書く
1.8 代行
責任者は、窓口当番の3名から代行者を事前に1名指名し、代行期間と一緒に窓口当番表に書きます。代行者が担う役割は2つです。
責任者が不在の日：掲載の承認（承認者と実行者を分けられない日）、公開範囲の付与と変更、掲載の取り下げ、カタログの表示切替と承認ルートの変更、本番への反映の承認。全重大度の判断と終了の承認。特権の付与・剥奪の承認は、責任者の不在が2営業日を超える場合に限る
ポータル担当の1名が不在の日：本番への反映と、公開範囲の付与と変更の確認担当
代行者は、同じ案件で実行・確認と承認を兼ねません。責任者とポータル担当1名が同じ日に不在で、代行者が承認と確認の両方を担うことになる案件は延期します。代行者がその日の窓口当番で、窓口当番の確認作業と承認が重なる場合は、確認を別の窓口当番に替えます。替えられない場合も、延期の扱いです。
ポータル担当の1名が不在の日に、残る1名が1人で行ってよいのは、表示不具合の分類（読み取りだけ）と定点確認です。誤掲載の取り下げと重大度1の停止も、1.6の例外のとおり単独で先に行い、確認は窓口当番、承認は責任者が事後に行います。
1.9 インスタンス運用方針
環境の使い分け
本番：従業員が使うポータル。従業員の氏名・所属などの個人情報を持つ。ここでの作業は、承認を受けた本番への反映と、取り下げ・切り戻しに限る
開発環境：開発と確認を兼ねる。確認は確認用ユーザーとテスト用の掲載で行い、本番の従業員の個人情報を使わない
下書きの確認体制
［公式］下書きのページはエンドユーザーには見えず、Service Portal の管理者にだけ表示される（sp_page の Draft 項目の製品同梱の説明）
［実測］PDI で、管理者が下書きのページを開くと、上端に赤字の「This page is in draft」が出てウィジェットも表示された
［未確認］sp_admin だけを持つユーザーで、下書きのページが表示されるか
下書きの表示確認は、管理者で行うこととします。一般の従業員の視点での確認は、確認用ユーザーで行います。
アクセス制御
sp_admin（Can manage the Service Portal）を持つ人は、ポータルの設定を変更できるため特権として扱います。付与と剥奪は「特権の付与と棚卸し」で決めます。
未決：ポータル管理画面に、接続元の IP 制限と多要素認証を求めるか。全社の認証基盤の方針で決まるため、責任者と認証基盤の担当者が決めます（未決事項の一覧は第8章）。
未決：ポータル担当に持たせる操作権限。ロール・グループを変更するためのロール、下書きの確認に使う管理者のアカウントと保有者、sp_admin だけで本番の公開操作（Draft の切り替え）ができるかを、責任者が決めます。第4巻の試験「sp_admin だけでの公開操作」は未実施です。
1.10 運用の開始と引継ぎの条件
運用を開始する条件は、次の3つがすべてそろうことです。
ポータル担当の2名が、第3巻の「下書きページを作り、部品を置いて公開する」と「表示不具合の切り分けと復旧」を、開発環境でそれぞれ1回ずつ実行し終えている
窓口当番表が1か月先まで確定している（実行担当・確認担当・代行者を含む）
第8章の未決事項の一覧が全件決定済みで、操作権限の確定に必要な第4巻の試験が終わっている
担当者が交代するときは、旧担当が第3巻の「開発作業の記録と引継ぎの記入」の書式で引継ぎ書を書きます。新担当は「表示不具合の受付と分類」の初動を開発環境で1回通してから引き継ぎます。引継ぎの完了を認めるのは責任者で、期限は交代日の前日です。
2. 要件と運用ルールの対応
この章で決めること：どの要件を、どの運用ルールで満たすか。運用ルールをどの書式で書くか。
2.1 業務要件
要件は6つです。第3巻の追加開発手順、第4巻の開発設計書、この巻が同じ要件を共有します。
RQ-01 窓口の一本化：従業員は1つの画面から、問い合わせ・申請・ナレッジ検索ができる
RQ-02 限定情報の非表示：組織ごとに限定した情報は、対象外の従業員に表示しない
RQ-03 承認後の公開：掲載内容は、申請者と別の人が承認してから公開する
RQ-04 切り分け：表示が崩れたとき、受付から30分以内に原因の分類を特定できる
RQ-05 本番前の確認：本番に反映する前に、開発環境で表示を確認する
RQ-06 更新後の確認：製品のメジャーアップグレード後、主要画面の表示を確認する
2.2 対応表
要件と運用ルールの対応は、この表だけに書きます。各運用ルールの本文には書きません。
OR-01 掲載の承認：RQ-03
OR-02 公開範囲の付与と変更：RQ-02
OR-03 掲載の取り下げ：RQ-03
OR-04 公開範囲の区分の変更：RQ-02
OR-05 異動・入退社への対応：RQ-02
OR-06 公開範囲の定期棚卸し：RQ-02
OR-07 カタログの表示切替と承認ルートの変更：RQ-01、RQ-02
OR-08 特権の付与と棚卸し：RQ-03（公開できる人を絞り、承認を経ない公開を防ぐ）
OR-09 表示不具合の受付と分類：RQ-04
OR-10 公開範囲の誤りへの対応：RQ-02、RQ-04
OR-11 復旧と切り戻し：RQ-04
OR-12 ベンダーへの問い合わせ：RQ-04
OR-13 本番への反映：RQ-05
OR-14 更新後の確認：RQ-01、RQ-06
OR-15 記録の保存と復旧：対応する要件なし（すべての運用ルールの証跡を保存する横断の決まりのため）
2.3 運用ルールの書式
運用ルールは、1つの判断を1つの節で完結させます。見出しにIDと名前を置き、冒頭に対象を1〜2文で書いたあと、次の8項目をこの順で書きます。該当がない項目は「なし（理由：〜）」と書き、空欄にしません。
条件：開始する条件と、そろっていなければならない情報
判断：どの場合にどうするか。実行しない場合の条件
責任者：実行・確認・承認（1.6の分担表と同じ）
期限：営業時間の経過で数える
証跡：残すものと記録先
例外：実行しない・保留する場合と、その引継ぎ先
見直しの契機
確かめ方：確かめる条件、合格基準、状態
製品の挙動に依存するルールは、項目の前に「前提となる製品の挙動」を根拠ラベル付きで置きます。
2.4 OR-01 掲載の承認（見本）
Employee Center に新しい案内・ページ・ウィジェットを載せる依頼を、誰がどの条件で承認するかを定めます。操作は第3巻の「下書きページを作り、部品を置いて公開する」です。既存の掲載を止める場合は「掲載の取り下げ」、公開範囲を指定する場合は「公開範囲の付与と変更」で扱います。
前提となる製品の挙動
［実測］ページのフォームには Public・Draft・Roles の3項目がある
［実測］ページ一覧の既定の列に Draft は含まれない。値はフォームで見る
［公式］ページ・カテゴリ・ナレッジなどへの公開範囲は、User Criteria で決められる
公開範囲は User Criteria で作り、ページの Roles は原則として空にします（第4巻の設計）。
項目
条件：掲載担当が依頼票を起票したときに始める。依頼票に次の4点がそろわない場合は受け付けず差し戻す
掲載内容の本文（または添付）
掲載先（ページ・カテゴリ）
公開範囲（全従業員か、公開範囲の区分か）
掲載期間（開始日と終了日）
判断：承認者は、4点がそろい、公開範囲の区分の指定があれば「公開範囲の付与と変更」の承認が済んでいることを確かめて承認する。ページのフォームでは次の3点を見る。個人情報・給与・人事評価を含む掲載は、責任者に相談し、第4巻の直接アクセスの試験が済むまで承認しない
①ID が依頼票の掲載先と一致する
②Draft が公開前は有効である
③Roles が空である。公開範囲は Roles でなく、User Criteria の結び付きで確かめる
責任者：申請は掲載担当。承認は確認担当（その日に公開を実行しない方のポータル担当）。公開の実行は実行担当。公開後の表示確認は窓口当番が確認用ユーザーで行う
期限：受付から2営業日以内に可否を返す。期限内に判断できないときは、承認者がその日のうちに申請者へ連絡し、責任者が承認する。公開後5分以内に、窓口当番が確認用ユーザーで表示を確かめる（本番への反映の30分以内の再確認とは別に行う）
証跡：依頼票の状態「承認済み」、承認者名、承認日時。依頼票IDを第3巻の作業記録に転記する
例外：ポータル担当の1名が不在で承認者と実行者を分けられない日は、責任者が承認する。責任者も不在の日は代行者が承認する。その代行者が同じ案件で窓口当番の表示確認を担う場合は、確認を別の窓口当番に替える。替えられなければ延期する。差し戻しには理由を依頼票のコメントに書く。本番への反映日は「本番への反映」に従う
見直しの契機：月次報告で承認の期限遵守率が90%を下回る月が2か月続いたとき。掲載担当が増減したとき
確かめ方：TS-01 承認から公開までの通し確認。条件：依頼票1件を起票し、確認担当が承認し、実行担当が Draft を外し、窓口当番が確認用ユーザーで表示を見る。合格基準：承認者と公開の実行者が別の人として記録され、公開後5分以内に確認用ユーザーの画面に表示される。［未実施］
①ID：依頼票の掲載先と照合する
②Draft：公開前は有効になっていることを確かめる
③Roles：空であることを確かめる。公開範囲はここでは決めない
記入例は付録Aにあります。
3. 運用サービス設計
この章で決めること：運用チームが何を提供し、いつ受け付け、どの水準で返すか。
3.1 サービスメニュー
ポータル運用チーム（ポータル担当2名と窓口当番3名）が提供するサービスは次のとおりです。受付は、情報システム部の窓口（メールと内線）に一本化します。
掲載の依頼：新しい案内・ページ・ウィジェットの掲載。依頼できるのは人事部・総務部の掲載担当。受付から2営業日以内に可否を返す
公開範囲の付与・変更の依頼：受付から2営業日以内に可否と反映日を返す
掲載の取り下げの依頼：誤掲載は受付から30分以内。期間終了は終了日の翌営業日12:00まで
公開範囲の区分の変更の依頼：区分の新設・変更・削除。受付から2営業日以内に可否と反映日を返す
カタログの表示切替・承認者の変更の依頼：受付から2営業日以内に可否と反映日を返す
本番への反映の依頼：依頼できるのは掲載担当とポータル担当。窓口当番が受け付け、受付から1営業日以内に反映日か延期の理由を返す
表示不具合の受付：全従業員が対象。期限は重大度ごとに決まる（4.8の表）
使い方の問い合わせ：ポータルの探し方・申請の出し方。窓口当番が1営業日以内に回答する
掲載状況の一覧の提供：部門の掲載担当が、自部門の掲載ページと公開範囲の一覧を依頼できる。公開範囲の定期棚卸しで作る一覧を使い、依頼から3営業日以内に確認担当が渡す
サービスの対象外は、1.1の対象外のとおりです。
3.2 対応時間
受付時間は平日9:00〜18:00です。時間外と休日は翌営業日の対応とし、期限は営業時間の経過で数えます。時間外に重大度1の報告を受けた場合の扱いは、4.11の時間外の暫定の扱いにまとめています。
3.3 運用項目の一覧
運用の作業を、定常・依頼・障害対応・保守の4つに分けます。
定常（毎週）：定点確認。毎週月曜の11:00までに確認担当が行う。確認用ユーザーで5画面（Employee Center のホーム・カタログ・ナレッジ・プロファイルと、/sp のホーム）と、部門限定の掲載ページ1つを開く。記録先は作業記録。手順は第3巻の「メジャーアップグレード後の確認」の画面を使う
定常（毎月）：月次報告。毎月第3営業日に確認担当が責任者へ送る
定常（四半期）：特権の棚卸しと、公開範囲の定期棚卸し
依頼：掲載の承認、公開範囲の付与と変更、掲載の取り下げ、公開範囲の区分の変更、異動・入退社への対応、カタログの表示切替と承認ルートの変更
障害対応：表示不具合の受付と分類、公開範囲の誤りへの対応、復旧と切り戻し、ベンダーへの問い合わせ
保守：本番への反映、更新後の確認、記録の保存と復旧
3.4 サービスレベルと計画停止の通知
表示不具合のサービスレベルは、4.8の「重大度と対応期限」の表で定めます。それ以外のサービスレベルは次のとおりです。
掲載の承認：受付から2営業日以内に可否を返す
本番への反映の依頼：受付から1営業日以内に反映日か延期の理由を返す
復元：任意時点への復元は約束しない（「記録の保存と復旧」）
計画停止の事前通知
本番のポータルが使えなくなる計画作業は、停止予定日の5営業日前までに、責任者が従業員へ告知します。告知はポータルのお知らせと、情報システム部の全社メールの2か所で行います。
対象：ServiceNow 側の計画メンテナンス、メジャーアップグレード、停止を伴う自社の反映
ServiceNow が通知する計画メンテナンスの日程：窓口当番が受け取り、同日中に責任者へ回す。5営業日前に間に合わない通知は、受け取った当日に告知する
対象外：停止を伴わない本番への反映。停止を伴うと分かった反映は、この通知の対象にする
4. 業務運用
この章で決めること：掲載・公開範囲・カタログ・特権・問い合わせ・表示不具合を、誰が、どの条件で、いつまでに処理するか。
4.1 掲載から公開範囲の変更までの流れ
掲載の承認は第2章の見本で決めています。この節では、承認のあとに続く公開範囲の付与と、掲載の取り下げを決めます。
掲載担当が依頼票を起票する
確認担当が「掲載の承認」の条件で承認する。差し戻した依頼は、掲載担当が直して出し直す
実行担当が本番で Draft を外して公開する
窓口当番が確認用ユーザーで公開後の表示を確かめる
公開後の公開範囲の変更と異動への対応は、実行担当が行い、責任者が承認する
表示不具合が報告されたら、4.9の流れへ移る
OR-02 公開範囲の付与と変更
部門限定の公開の依頼を受けたときのルールです。公開範囲は、User Criteria をカテゴリと商品、ナレッジベースに結んで作ります。操作は第3巻の「公開範囲を設定し、表示を確認して、解除する」です。
前提となる製品の挙動
［実測］PDI の /sp で、カテゴリに User Criteria を結ぶと、対象外の確認用ユーザーには「You do not have permission to see this category」と表示され、結び付きを外すと再び見えた
［実測］商品が1件も無いカテゴリは、管理者にも同じメッセージが出る
［公式］商品の制限は、Service Catalog の外でテーブル経由のアクセスには適用されない
画面の出し分けはデータの保護とは別の仕組みのため、機密を含む掲載には例外の項目で条件を付けます。
項目
条件：掲載担当が依頼票に、対象にする部門と対象外にする部門を書いていること。条件を特定できない依頼は受け付けない
判断：確認用ユーザー2名（対象内1名、対象外1名）を用意できる場合に実行する。用意できない場合は実行しない。確認するカテゴリには商品を1件以上入れておく
責任者：実行＝実行担当／確認＝確認担当／承認＝責任者
期限：受付から2営業日以内に可否と反映日を回答する。反映は承認済みの反映枠（本番への反映の曜日と時間）で行う
証跡：実行前後の確認用ユーザー2名の画面と、依頼票ID
例外：機密を含む掲載は、第4巻の直接アクセスの試験（商品詳細のURLと検索結果）が済むまで公開しない。ACL は追加しない（第4巻の判断）。直接アクセスで見えた場合は、第4巻の設計の見直しとして責任者へ回す
見直しの契機：公開範囲の区分を新設したとき。第4巻の直接アクセスの試験の結果が出たとき
確かめ方：
TS-02 /sp のカテゴリでの効き方。条件：カテゴリに User Criteria を結び、対象内と対象外の確認用ユーザーで開く。合格基準：対象外にだけ権限なしのメッセージが出て、結び付きを外すと見える。［実施済み］
TS-03 商品詳細のURL・検索結果・/esc での効き方（モデル案件の区分）。条件：モデル案件の5区分で、商品詳細のURLを直接開き、検索し、/esc から開く。合格基準：対象外の確認用ユーザーにどの経路でも表示されない。［未実施］。PDI の追補の確認（第3巻）では、商品とカテゴリの両方に条件を結んだ商品は直接URL・Table API でも条件どおりで、カテゴリだけに条件を結んだ商品は一般の従業員でも直接URL・API で開けた［実測］
①：「You do not have permission to see this category」の表示。対象外の確認用ユーザーにこれが出て、対象内には出ないことが完了の判断基準
同じメッセージは、商品が1件も無いカテゴリでは管理者にも出る。表示だけで公開範囲の不具合と決めず、商品の件数も確かめる
OR-03 掲載の取り下げ
掲載内容を止めるときのルールです。取り下げは、削除でなく下書き（Draft の有効化）で行います。操作は第3巻の「部品の差し替えと公開停止」です。
前提となる製品の挙動
［実測］PDI で Draft を有効にすると、一般の従業員には「Sorry, the page you requested was not found」の404ページが出て、管理者には赤字付きで表示された。Draft を外すと元に戻った
［実測］ページを複数のポータルのホームに指定している場合、Draft の値は両方に効く。Draft はポータルでなくページ単位の設定である
項目
条件：掲載期間の終了、内容の誤り、申請者からの取り下げ依頼のいずれか
判断：誤掲載（個人情報・機密情報の掲載、内容の誤り）は、承認を待たず実行担当が先に取り下げる。期間終了と申請者の依頼による取り下げは、責任者の承認後に実行する。取り下げの前に、そのページを使っているポータルを依頼票に書き出す
責任者：実行＝実行担当／確認＝確認担当／承認＝責任者（誤掲載は事後承認、それ以外は事前承認）
期限：誤掲載は受付から30分以内に取り下げ、事後承認は取り下げた営業日の18:00まで。期間終了は終了日の翌営業日12:00まで
証跡：取り下げの前後の Draft の値、取り下げた日時、依頼票ID、使っているポータルの一覧
例外：削除は取り下げの手段にしない。削除する場合は、責任者の承認と削除前の値の記録を条件にする（「記録の保存と復旧」）。確認担当が不在で誤掲載を取り下げた場合は、窓口当番が確認用ユーザーで確認する
見直しの契機：メジャーアップグレードで、下書きの表示や404の出し方が変わったとき
確かめ方：TS-04 下書きによる取り下げと復帰。条件：ページの Draft を有効にし、一般の従業員と管理者で開き、Draft を外して再び開く。合格基準：一般の従業員に404、管理者に赤字付きの表示が出て、Draft を外すと元に戻る。［実施済み］
①：「Sorry, the page you requested was not found」の表示。一般の従業員にこれが出れば、取り下げが効いている
4.2 掲載と公開範囲の完了の判定
掲載と公開範囲の作業は、「画面で見えた」だけで完了にしません。依頼票の内容と照合できる形で終わりを決めます。
掲載：依頼票の掲載先・公開範囲・掲載期間の3点が、フォームの値と一致していること
公開範囲：対象内の確認用ユーザーの画面に表示され、対象外の確認用ユーザーの画面に表示されないこと
取り下げ：一般の従業員の画面で404ページが出て、管理者の画面にだけ赤字付きで表示されること
4.3 公開範囲の区分の管理
モデル案件の公開範囲は、次の5区分です。
全従業員（1,200名）：共通の問い合わせ・申請・FAQ
人事部・総務部：部門内だけの申請とナレッジ
拠点（本社と3拠点）：拠点限定のお知らせと設備の申請
管理職：管理職だけが使う申請と、評価制度の手引きなどのナレッジ
外部委託・派遣（社内アカウントあり）：申請できるものを限定し、人事・管理職向けの情報は見せない
区分の条件の作り方は第4巻で決めています。この巻で使う前提は次のとおりです。
［実測］User Criteria の条件項目は、ユーザー・グループ・ロール・部署・会社・拠点・スクリプトで、役職と雇用形態の項目は無い
部署と拠点は、ユーザーの属性を条件にする（第4巻の設計）。属性が変われば判定も変わる前提で、追従そのものは第4巻の試験「異動への追従」で確かめる［未確認］
管理職と外部委託・派遣は、グループを条件にする。異動と雇用形態の変更のたびに、グループの付け替えが要る
［公式］対象外の指定（Not available for）は、対象の指定（Available for）より優先する
画面の出し分けとデータの保護は別に扱う。ACL は追加せず、機密を含む掲載は第4巻の直接アクセスの試験が済むまで公開しない（第4巻の判断）
OR-04 公開範囲の区分の変更
公開範囲の区分の新設・変更・削除を承認するルールです。
条件：依頼票に、対象のコンテンツ、見せる区分、見せない区分、変更の理由が書かれていること
判断：区分の変更は、情報の所有部門の掲載担当が申請し、責任者が承認する。管理職向けと人事・総務向けの区分は、人事部の掲載担当が内容を確認する。外部委託・派遣の区分を広げる依頼は、承認の前に責任者が契約の範囲と照らす。区分を広げる変更は、対象外の指定が残っていないかを承認の前に責任者が確かめる（対象外の指定が優先するため）
責任者：実行＝実行担当／確認＝確認担当／承認＝責任者
期限：受付から2営業日以内に可否と反映日を回答する。反映は承認済みの反映枠（本番への反映の曜日と時間）で行う
証跡：依頼票ID、変更前後の対象の一覧、確認用ユーザーの画面（区分ごとに対象内と対象外を1名ずつ）
例外：区分ごとの確認用ユーザーを用意できない場合は実行せず、確認用ユーザーの作成を先に依頼する
見直しの契機：組織変更で区分の数が変わったとき
確かめ方：TS-05 区分の変更の照合。条件：区分を1つ変更し、区分ごとの確認用ユーザーで見え方を確かめる。合格基準：変更した区分の対象内に表示され、対象外に表示されない。他の区分の見え方が変わらない。［未実施］
OR-05 異動・入退社への対応
人事部が異動・入社・退社・派遣契約の終了を確定したときのルールです。
条件：人事部から、異動（部署・拠点・役職の変更）、入社、退社、派遣契約の開始・終了の通知が届いたとき
判断：部署と拠点の区分は、人事システムの属性の更新で判定が変わる前提とし、作業しない。窓口当番が通知ごとに、変更後の所属（管理職か、外部委託・派遣か）を決め、現在の管理職グループ・外部委託・派遣グループとの差分を照合する。実行担当が差分のとおりグループへの追加と削除を行う。ユーザーを直接指定した User Criteria は、期限と必要性を照合し、不要なら解除する
責任者：実行＝実行担当（追加・削除・解除）、窓口当番（照合）／確認＝確認担当／承認＝責任者
期限：異動・退社・派遣終了は、その日の営業時間内に付け替え・解除する。入社と派遣の開始は、利用開始日の前営業日までに設定する
証跡：通知の写し、照合の結果、付け替え・解除した対象
例外：人事システムの反映が遅れ、部署・拠点の属性が更新されていない場合は、人事部へ反映を依頼し、反映を確かめるまで障害記録で追う
見直しの契機：人事システムの連携方式が変わったとき。区分の条件を変えたとき
確かめ方：TS-06 異動時の付け替え。条件：開発環境で確認用ユーザーの部署と管理職グループを変える。合格基準：部署の区分は条件を変えずに見え方が追従し、管理職の区分は付け替えの後にだけ見え方が変わる。［未実施］
User Criteria は、異動のたびに作り直しません。直接指定を使うのは、期間の決まった例外（派遣の一時利用など）に限ります。
OR-06 公開範囲の定期棚卸し
公開範囲の設定が、区分の表どおりになっているかを定期に照合するルールです。手順は第3巻の「閲覧範囲の棚卸しと、異動・組織変更後の確認」です。
条件：四半期ごと（各四半期の初月の第2営業日まで）。メジャーアップグレードの後と、組織変更の後は臨時で実施する
判断：User Criteria の一覧、カテゴリと商品の公開範囲、ナレッジベースの Can read を、区分の表と照合する。表にない指定、無効になった条件、直接指定の残りを差分として責任者へ報告する
責任者：実行＝窓口当番1名（照合）／確認＝確認担当／承認＝責任者
期限：差分の報告は実施から2営業日以内。是正は報告から5営業日以内
証跡：棚卸しの日付、照合した一覧、差分と是正の記録
例外：対象外に広く見えている指定が見つかった場合は、棚卸しの是正でなく「公開範囲の誤りへの対応」へ移す
見直しの契機：差分が2四半期続けて見つかったとき
確かめ方：TS-07 棚卸しの照合。条件：開発環境で区分の表にない指定を1件作り、棚卸しを行う。合格基準：その指定が差分として報告される。［未実施］
照合は、設定の実行者が自分の設定を確かめないように、ポータル担当以外の窓口当番が行います。
4.4 カタログの表示切替と承認ルート
カタログ（商品とカテゴリ）は、従業員が申請を出す画面です。カテゴリと商品の表示は公開範囲で切り替えます。商品ごとの承認者は、申請を承認する人を決める設定です。
OR-07 カタログの表示切替と承認ルートの変更
カテゴリや商品の表示・非表示の切替と、商品の承認者の変更を扱うルールです。操作は第3巻の「カタログのカテゴリと商品へ閲覧範囲を設定する」です。
条件：所有部門の掲載担当が依頼票に、対象のカテゴリか商品、切替の内容（表示・非表示・公開範囲）、期間を書いていること。承認者を変える場合は、新旧の承認者名と、変更の理由（旧承認者の異動・退職・長期不在のいずれか）も書く
判断：表示の切替は、確認用ユーザー2名（対象内・対象外）を用意できる場合に実行する。承認者の変更は、新しい承認者がその商品の申請を承認できる権限を持つことを、確認担当が確かめてから実行する。確かめられない場合は差し戻す。カテゴリと商品は削除せず、無効化して非表示にする（第4巻の設計）
責任者：実行＝実行担当／確認＝確認担当／承認＝責任者。承認者の変更は、所有部門の部長の了承を依頼票に残す
期限：受付から2営業日以内に可否と反映日を回答する。反映は承認済みの反映枠で行う。承認者の不在で申請が滞る場合は、不在期間の開始日の前営業日までに、代理の承認者を期間つきで設定する
証跡：変更前後の表示の状態と承認者、確認用ユーザーの画面、依頼票ID
例外：商品の誤り（価格・説明・承認者の誤り、個人情報の掲載）が報告された場合は、承認を待たず実行担当が先に無効化し、責任者が無効化した営業日の18:00までに事後承認する。時間外に報告された場合は、4.11の時間外の暫定の扱いに従う。終了は、確認用ユーザーの画面で商品が表示されないことを確かめ、責任者が承認した時点とする
見直しの契機：所有部門の承認者が異動したとき。カタログのカテゴリ構成を変えたとき
確かめ方：
カテゴリの表示切替は、TS-02（/sp のカテゴリでの効き方）の結果を使う
TS-08 承認ルートの変更。条件：開発環境で商品の承認者を変え、申請を1件出す。合格基準：新しい承認者に承認が届き、旧承認者に届かない。［未実施］
4.5 特権の管理
OR-08 特権の付与と棚卸し
sp_admin の付与・剥奪と、保有者の棚卸しのルールです。
前提となる製品の挙動
［実測］sp_admin は7つのロールを含む：taxonomy_admin、announcement_admin、service_status_subscriber、search_application_admin、log_debugger、evam_admin、notification_provider_admin
［実測］設定画面用の sp_config ポータルは、標準のビジネスルールにより、削除とURLサフィックスの変更が保存時に中止される
項目
条件：sp_admin の付与は、ポータル担当の2名に限る。それ以外の付与の依頼は、責任者が可否を判断する。ロールとグループを変更する権限も、ポータル担当の2名だけに持たせる。この権限に使うロールは、操作権限の未決事項で決める
判断：付与の前に、含まれる7つのロールが業務に必要かを責任者が確かめる。棚卸しでは、sp_admin の保有者と、ユーザー管理の権限の保有者の両方を照合する
責任者：実行＝付与・剥奪はポータル担当のうち対象者本人でない1名、棚卸しは窓口当番1名／確認＝付与・剥奪は窓口当番1名（保有者一覧を照合）、棚卸しはなし（理由：照合そのものが確認で、結果を責任者が承認するため）／承認＝責任者
期限：異動・退職の日の営業時間内に剥奪する。棚卸しは各四半期の初月の第2営業日までに行う
証跡：承認済みの付与台帳（対象者・権限・有効期間・承認者）、保有者の一覧、確認日
例外：責任者の不在が2営業日を超え、代行者が承認する場合、確認は代行者でない窓口当番が行う。sp_config の削除やURLサフィックスの変更の依頼は、保存時に中止される仕様のため、受けた時点で依頼者へ伝えて差し戻す
見直しの契機：メジャーアップグレードで sp_admin の包含ロールが変わったとき。ポータル担当が交代したとき
確かめ方：TS-09 特権の棚卸し。条件：sp_admin と、ロール・グループを変更する権限の保有者一覧を、窓口当番1名が承認済みの付与台帳（対象者・権限・有効期間・承認者）と照合する。合格基準：両方の権限の全保有者が付与台帳と一致する。［未実施］
PDI の sp_admin の保有者は20名でしたが、デモ環境の値で、モデル案件の人数の根拠にしていません。
4.6 問い合わせ対応
窓口当番は、従業員からの問い合わせを、次の3つに分けて受けます。
使い方の問い合わせ（探し方・申請の出し方）：窓口当番が受付から1営業日以内に回答する。回答できないものはポータル担当へ引き継ぐ
表示不具合の疑い（画面が開かない・ウィジェットが出ない）：「表示不具合の受付と分類」へ移す。使い方の問い合わせとして閉じない
掲載や機能の要望：掲載は依頼票を案内する。新しい機能の要望は、ポータル担当が依頼票に書き写し、第4巻の設計の見直しとして責任者へ回す
問い合わせの記録は、受付日時・問い合わせ者・内容・回答日時を作業記録に残します。1営業日以内に回答できない場合は、窓口当番がその日のうちに見込みを連絡します。
4.7 表示不具合の検知
表示不具合の検知は、自動の通知に頼りません。
［実測］標準のスケジュールジョブ Portal Analyzer は、存在して有効になっている
［未確認］Portal Analyzer の実際の稼働状況、表示不具合を通知するものか、出力の見方
検知の手段は次の3つです。
報告：従業員または掲載担当から窓口へ届く連絡。受付は窓口当番
定点確認：毎週月曜の11:00までに、確認用ユーザーで5画面と部門限定の掲載ページ1つを開く
更新後の確認：パッチとメジャーアップグレードの後に行う
管理者の画面だけで判断しない
［実測］PDI で配置の Roles に存在しないロール名を入れると、一般の従業員の画面は本文が空白でエラー表示もなく、管理者の画面には同じウィジェットが表示された
表示不具合の確認は、必ず確認用ユーザーで同じ画面を開いて行います。管理者の画面で表示が正常でも、報告を取り下げません。
1枚目（一般の従業員）：①の範囲にウィジェットが出ず、エラーも出ない
2枚目（管理者）：同じページに人事からのお知らせのカードが表示される
監視できない範囲の代替確認
利用者が見ている画面は、報告がない限り確かめられない：週次の定点確認で補う。週の途中の不具合は、報告が検知の手段になる
時間外の不具合：翌営業日9:00に窓口当番が、前日18:00以降の報告を最初に受ける
公開範囲の効き方は画面ごとに異なる可能性がある：定点確認に部門限定の掲載ページを1つ含め、対象内と対象外の確認用ユーザーで見る
4.8 重大度と対応期限
窓口当番が報告を受けた時点で暫定の重大度を判定し、分類の後に責任者が確定します。
重大度1：情報の露出（対象外の従業員に部門限定の情報が表示された、個人情報の誤掲載）。または主要画面が開かない（全従業員か複数拠点で /esc か /sp のホームが開かない）
重大度2：特定のページ・ウィジェット・部門で表示されない。検索やカタログの導線が使えない
重大度3：見た目の崩れ、一部の画像が出ないなど、業務に支障がないもの
重大度ごとの期限は、次の表だけで定めます。
重大度1（情報の露出）：連絡・引継ぎ＝受付から15分以内に、窓口当番が実行担当と責任者へ電話／分類・判断＝分類は受付から30分以内（取り下げと並行）、判断は分類後15分以内／停止・復旧＝受付から30分以内に取り下げる（分類を待たない）。事後承認は取り下げた営業日の18:00まで。再掲載の判断は翌営業日12:00まで
重大度1（主要画面が開かない）：連絡・引継ぎ＝受付から15分以内に電話／分類・判断＝分類は受付から30分以内、判断は分類後15分以内／停止・復旧＝受付から4営業時間以内に、公開停止か切り戻しで影響を止める
重大度2：連絡・引継ぎ＝受付から15分以内に障害記録で実行担当へ／分類・判断＝分類は受付から30分以内、判断は分類後15分以内／停止・復旧＝受付から1営業日以内に復旧する
重大度3：連絡・引継ぎ＝受付から15分以内に障害記録で引き継ぐ／分類・判断＝分類は受付から30分以内、判断は分類後15分以内／停止・復旧＝着手は受付から2営業日以内、復旧は着手から3営業日以内。期限内に直せない場合は、実行担当が責任者へ理由と見込みを報告する
共通の終了規則は次のとおりです。
終了の承認は責任者が行う。条件は、報告者と同じ部門・権限の確認用ユーザーの画面で、報告された症状が消えていること
責任者が不在の場合は、代行者が全重大度の判断と終了の承認を行う。反映後に見つかった障害も同じ扱いとする
緊急の切り戻し（重大度1と2）は、本番への反映の曜日と時間の制限を受けない
例：重大度2を火曜11:00に受け付けた場合、引継ぎは11:15、分類は11:30、判断は11:45、復旧は水曜11:00が期限
4.9 表示不具合の受付から終了まで
窓口当番が報告を受け、報告者の画面（どの画面、誰の権限、いつから）を聞き取り、暫定の重大度を判定する
情報の露出なら、実行担当がすぐ取り下げる（分類を待たない）
実行担当が、4つの区分（ページ・配置・公開範囲・テーマ）で分類する
責任者が重大度を確定し、停止・切り戻し・調査継続のどれかを決める
実行担当が復旧か切り戻しを行い、確認担当が確認用ユーザーで確かめる
復旧せず製品側の疑いがあれば、ServiceNow 社へ問い合わせる
責任者が終了を承認し、障害記録を閉じる
OR-09 表示不具合の受付と分類
表示不具合の報告を受けてから、原因の区分を特定するまでのルールです。手順は第3巻の「表示不具合の切り分けと復旧」です。
前提となる製品の挙動
［実測］配置の Roles が不一致のとき、一般の従業員の画面は本文が空白になり、エラーは出ない
［実測］ページが下書きのとき、一般の従業員の画面は404になる
［実測］商品が1件も無いカテゴリは、管理者にも権限なしのメッセージが出る
［実測］テーマの変更は、そのテーマを使うポータルにだけ効く
項目
条件：従業員・掲載担当・窓口への連絡で、ポータルの表示に関する報告を受けたとき。定点確認や更新後の確認でポータル担当が見つけた場合は、発見時刻を受付時刻として障害記録を作り、窓口当番へ通知する
判断：窓口当番が報告者の画面を聞き取り、暫定の重大度を判定する。実行担当が、次の4つの区分で確認項目を順に見て、1つの区分に分類する
ページ：ページの Draft・Public・Roles
配置：配置の widget・active・order・Roles（変更前の記録と比べる）
公開範囲：User Criteria の active、診断機能でのユーザーの可否、カテゴリ配下の商品の件数
テーマ：テーマの CSS 変数と更新日時
責任者：実行＝窓口当番（受付）、実行担当（分類）／確認＝なし（理由：分類は設定を変えない読み取りの作業で、結果を責任者の決定で確かめるため）／承認＝責任者（停止・切り戻し・調査継続の決定）
期限：4.8の「重大度と対応期限」の表のとおり
証跡：受付日時、報告者、暫定の重大度、確認した画面、分類の結果、責任者の決定と日時を障害記録に残す（書式は付録B）
例外：4つの区分のどれにも当てはまらない場合は、「その他」として責任者へ渡し、「ベンダーへの問い合わせ」の条件を確かめる
見直しの契機：「その他」の分類が月に2件以上出たとき。第4巻の診断情報の設計が変わったとき
確かめ方：
TS-10 ページと配置の区分の分類。条件：配置の Roles を誤らせた症状と、ページを下書きにした症状を作り、診断の出力から分類する。合格基準：それぞれ「配置」「ページ」に分類され、変更前の値へ戻すと表示が復旧する。［実施済み］
TS-11 公開範囲とテーマの区分の分類。条件：商品0件のカテゴリと、テーマの値の変更で症状を作る。合格基準：それぞれ「公開範囲」「テーマ」に分類される。［未実施］
TS-12 机上演習「火曜11:00、別拠点からカタログが空白」。条件：このシナリオを運用ルールだけで追う。合格基準：受付・分類・判断・終了の担当と時刻が1つに決まる。［実施済み（机上）］（結果は第7章）
TS-13 机上演習「月曜の定点確認で /sp のホームが開かない」。条件：このシナリオを運用ルールだけで追う。合格基準：発見から終了までの担当・時刻・重大度が1つに決まる。［実施済み（机上）］（結果は第7章）
OR-10 公開範囲の誤りへの対応
対象外の従業員に部門限定の情報が表示された報告の扱いです。
条件：対象外の従業員の画面、またはその写しを報告者が提示できること。提示できない場合も、受付時点では重大度1として扱う
判断：実行担当が、分類の完了を待たず該当コンテンツを先に取り下げる。取り下げは、ページはページの下書き、配置は第3巻の「部品の差し替えと公開停止」、カテゴリと商品は無効化で行う（第4巻の設計）。公開範囲の修正は取り下げた後に行う。取り下げの後、次の順に照合し、どこで漏れたかを障害記録に書く。是正は同じ区分の全体に適用する
「公開範囲の区分の変更」の承認記録（変更の承認漏れ）
「異動・入退社への対応」の記録（付け替えの漏れ、直接指定の残り）
「公開範囲の定期棚卸し」の記録（表にない指定）
「掲載の承認」と「公開範囲の付与と変更」の承認記録（公開範囲の指定そのものの誤り）
責任者：実行＝実行担当／確認＝確認担当／承認＝責任者（取り下げは事後承認、原因の判断と再掲載は事前承認）
期限：受付から30分以内に取り下げる。事後承認は取り下げた営業日の18:00まで。再掲載の判断は翌営業日12:00まで
証跡：表示された画面、報告者、取り下げの日時、公開範囲の変更前後の値、照合の結果
例外：再現できなかった場合の重大度の引き下げは、責任者が照合の結果を見て決める。再掲載の前には、対象内・対象外の確認用ユーザーで、直接URLと検索結果も見る
見直しの契機：同じ区分で2回目の露出が起きたとき
確かめ方：TS-14 机上演習「水曜15:00、人事の限定お知らせが他部門に見える」。条件：このシナリオを運用ルールだけで追う。合格基準：取り下げ・事後承認・再掲載の判断・終了の担当と時刻が1つに決まる。［実施済み（机上）］（結果は第7章）
終了は、対象外の確認用ユーザーで、画面・直接URL・検索のどれからも閲覧できないことを確かめ、露出した範囲と必要な連絡の完了を責任者が確認した時点です。
OR-11 復旧と切り戻し
原因となった設定を、変更前の値へ戻すときのルールです。
前提となる製品の挙動
［実測］PDI で、あるテーマの色を変えると、そのテーマを使うポータルだけが変わり、別のテーマのポータルは旧色のままだった。保存から9秒後に反映を確認した（1回の観測。最短時間ではない）
項目
条件：診断の結果、原因となった設定の変更前の値が作業記録にあること
判断：変更前の値が記録されている場合に限り、実行担当が変更前の値へ戻す。テーマの切り戻しは、そのテーマを使うポータルすべてを確認の対象にする
責任者：実行＝実行担当／確認＝確認担当／承認＝責任者
期限：重大度1・2は責任者の決定から30分以内（反映の曜日と時間の制限を受けない）。重大度3は、復旧期限内の反映枠の開始から30分以内
証跡：戻した値、戻した日時、確認用ユーザーの画面
例外：変更前の値の記録がない場合は戻さず、責任者へ引き継ぐ。責任者は「ベンダーへの問い合わせ」の条件を確かめる
見直しの契機：記録がなく戻せなかった事例が出たとき
確かめ方：
TS-15 変更前の値へ戻す復旧。条件：配置の Roles とページの Draft を変更前の値へ戻す。合格基準：確認用ユーザーの画面で症状が消える。［実施済み］
TS-16 テーマの変更の影響範囲。条件：テーマを使うポータルと別のテーマのポータルを開く。合格基準：変更したテーマのポータルだけが変わる。［実施済み］
TS-17 机上演習「金曜17:30、テーマ変更後のヘッダー崩れ、責任者は出張中」。条件：このシナリオを運用ルールだけで追う。合格基準：代行者の範囲と、着手・切り戻し・終了の担当と時刻が1つに決まる。［実施済み（机上）］（結果は第7章）
完了は、確認用ユーザーの画面で報告された症状が消えたことで認めます。
4.10 ベンダーへの問い合わせの基準
ServiceNow の問い合わせ窓口（Now Support）へ起票するのは、自社の判断で解決できないときです。起票の基準がないと、自社の設定の誤りを調べる前に問い合わせるか、逆に製品側の不具合を長く抱えることになります。
OR-12 ベンダーへの問い合わせ
条件：次の3点がそろっていること。そろわない間は起票せず、分類を続ける
診断で、原因が自社の設定でなく製品側にあると疑われる
変更前の値へ戻しても症状が再現する
再現の手順と発生時刻がある
判断：責任者が起票を決める。起票の内容は、症状・再現の手順・影響範囲（重大度）・直近に反映した更新セットの名前・製品のバージョンの5点
責任者：実行＝実行担当（起票）／確認＝確認担当（起票内容の5点）／承認＝責任者
期限：起票の決定から2営業時間以内。重大度1は30分以内。回答を待つ間も、取り下げと切り戻しの暫定対応は止めない
証跡：問い合わせ番号、起票日時、送った内容、回答の内容と日時
例外：重大度1で3点がそろうのを待てない場合は、責任者の判断で先に起票する。ベンダーの回答にもとづく恒久対応は「本番への反映」として扱う。復元の可否の照会は「記録の保存と復旧」で扱う
見直しの契機：起票から回答までの期間が、重大度1で2営業日を超えたとき
確かめ方：TS-18 起票内容の照合。条件：開発環境の症状1件で起票内容を作成し、確認担当が5点を照合する。合格基準：5点がそろい、更新セットの名前が作業記録と一致する。［未実施］
4.11 時間外の暫定の扱い
未決：時間外と休日に重大度1（情報の露出・主要画面が開かない）が報告されたときの最初の連絡先。責任者と人事部・総務部の各部長が決めます（未決事項の一覧は第8章）。
決めるときの既定案は次のとおりです。運用開始までに、この案を採るか、休日の連絡体制を設けるかを決めます。
時間外の報告は、翌営業日の9:00に窓口当番が最初に受ける
重大度1は9:15までに実行担当と責任者へ連絡する
情報の露出と商品の誤りは、9:30までに実行担当が取り下げ・非表示にする（例：20:00に商品の誤りが報告された場合も同じ）
責任者は取り下げた営業日の18:00までに事後承認する
機密に当たる掲載の反映は、営業日の10:00〜12:00に限る（公開した当日のうちに取り下げられるようにするため）
確かめ方：TS-19 机上演習「土曜に個人情報の誤掲載」。条件：既定案だけで追う。合格基準：受付・取り下げ・事後承認・終了の担当と時刻が1つに決まり、露出が続く時間が分かる。［実施済み（机上）］（結果は第7章）
5. 保守運用
この章で決めること：自社の変更を本番に入れる条件と、製品の更新を受け入れる手順。
5.1 保守運用の一覧
自社の変更の反映：「本番への反映」。更新セットの命名と移送は5.2
テーマ・ウィジェット・ページの変更：「本番への反映」に従う。追加の条件は5.3
パッチとメジャーアップグレード：準備は5.4、更新後の確認は「更新後の確認」
記録の保存と復旧：「記録の保存と復旧」
5.2 更新セットの命名と移送
自社の変更は、更新セットに記録して本番へ移します。
命名：1要件につき更新セットを1つ作り、名前は ポータル_<要件のID>_<内容>_<日付> とする（第4巻の設計。例：ポータル_RQ-02_新任者案内_20261104）。依頼票には、対応する要件IDと更新セット名を記録する
命名の確認：責任者が反映を承認するときに行う
検証用の作業：先頭を TEST_ にした別の更新セットで行い、本番へは移送しない
［実測］PDI で、レコードを作成してから削除しても、更新セットへの記録は残った。作成前と削除後の件数は一致したが、更新セットの記録は1201件から1207件に増えた
［未確認］更新セットの移送そのもの（単一のインスタンスでは確かめられない）
OR-13 本番への反映
開発環境で作った変更を、本番へ入れるときのルールです。
条件：次がすべてそろっていること
開発環境で実行担当が作成し、確認者（作成者・承認者と別の人）が確認用ユーザー2名の画面で表示を確かめた証跡がある。証跡には確認者名を残す
本番側の変更対象について、変更前の値を作業記録に控えている
反映する更新セットに、検証用に作ったテスト用のレコードが含まれていない
実行担当と別の確認者を確保できる（ポータル担当の1名が不在なら代行者が確認担当になる。その変更の掲載を確認担当が承認している場合は、窓口当番が確認する）
判断：責任者が、証跡と更新セットの内容を見て承認する。更新セットで移らない可能性のあるもの（データ、プラグインの有効化、プロパティの値）は、第4巻の移送の設計の一覧と照合してから承認する
責任者：実行＝実行担当／確認＝確認担当（その変更の掲載を確認担当が承認した場合は、窓口当番）／承認＝責任者（終了の承認を含む）
期限：反映は火曜から木曜の10:00〜16:00に限る。定例は水曜、臨時は火曜か木曜。反映後30分以内に、確認担当が開発環境で確かめた期待値と照合する
証跡：承認者、確認者、反映した更新セットの名前、再確認の画面、終了の承認
例外：確認担当を確保できない日、または代行者が承認と確認を兼ねることになる日は延期する。再確認で不一致が出たときや、反映後に重大度1の報告を受けたときは、責任者（不在なら代行者）が切り戻しを判断し、「復旧と切り戻し」に従って変更前の値へ戻す
見直しの契機：切り戻しが月に2件以上出たとき
確かめ方：
TS-20 更新セットへの記録。条件：レコードを作成して削除する。合格基準：件数は元に戻り、更新セットの記録は残る。［実施済み］
TS-21 移送から本番での公開までの通し確認。条件：開発環境から本番へ移送し、Draft を外して公開する。合格基準：反映後30分以内の再確認で期待値と一致する。［未実施］
TS-22 机上演習「ポータル担当1名が休暇の日に本番反映を依頼」。条件：このシナリオを運用ルールだけで追う。合格基準：実行・確認・承認が別の人に決まるか、延期が決まる。［実施済み（机上）］（結果は第7章）
実行担当が開発環境で作成し、確認者が確認用ユーザー2名で表示を確かめる
実行担当が本番側の変更前の値を作業記録に控える
責任者が証跡と更新セットを見て承認する
実行担当が火曜から木曜の10:00〜16:00に移送する
確認者が反映後30分以内に再確認する
一致すれば責任者が終了を承認し、作業記録を閉じる。不一致なら責任者が切り戻しを判断する
反映日を火曜から木曜の日中に限るのは、時間外の対応が翌営業日になるためです。月曜と金曜は、問題が出た場合に当日中に対応する時間が足りません。
5.3 テーマ等の変更
テーマ・ウィジェット・ページレイアウトの変更も、更新セットに記録して「本番への反映」で反映します。テーマの変更は、そのテーマを使うすべてのポータルに効くため、依頼票に影響するポータルを書き出します。切り戻しの確認範囲も同じポータルです。
色やロゴだけを変える変更は、掲載の承認を求めず、責任者の承認で反映します。反映日の制限は「本番への反映」に従います。
💰 ここから先は有料エリア
