ポータルモジュールの開発設計書

検証環境：Australia PDI / OOTB / 2026-10-01 確認

本書は、Employee Center を使うポータルの開発設計書です。架空のモデル案件を1つ置き、ページの構成と公開、組織ごとの公開範囲、テーマの変更までを設計します。更新セットの移送順と表示不具合の診断も含め、設計は12件です。変更要求を受けたときは、第2章のマトリクスと付録Cから、変更対象・影響する権限・確かめる動作を引けます。各設計は同じ10項目で書き、標準仕様の各行には根拠の種類を付けました。

1. 目的・範囲・前提

この章で決めること：何の案件を想定した設計書で、どこまでが範囲で、設計書の記述をどう読むか。

想定する案件

この設計書のモデル案件は架空の設計例です。国内の事業会社（従業員1,200名、本社と3拠点）が、従業員からの問い合わせと申請の窓口を Employee Center に集約します。現在は部門ごとにメールと紙の申請書が混在しています。

• 構築と運用は情報システム部（5名）。うちポータル担当は2名

• コンテンツの提供は人事部・総務部（各1名が掲載担当）

• 対応時間は平日9:00〜18:00。時間外と休日は翌営業日に対応

• 掲載は、申請者（人事・総務）と公開する人（情報システム部）を分ける

• 公開範囲の対象は、全従業員、人事部・総務部、拠点（本社と大阪を含む4拠点）、管理職、外部委託・派遣（社内アカウントあり）

• 対象外はモバイル専用ポータル、社外（取引先）への公開、多言語対応

次の値は架空です。自社の案件では、読み替えてください。

• 従業員数・拠点数

• 掲載ページ数（約20）と配置数（約100）、同時利用者数（最大150）

• 掲載担当の人数と部門

• 公開後の確認までの時間（5分）と、切り分けの目標（受付から30分）

• 公開範囲の単位（モデル案件では部署・拠点・役職・雇用形態の4種類）

標準ポータル10種の外観は、第1巻のポータルモジュールの概要にあります。テーブル構成・ロール・プロパティの現在値は第2巻の「ポータルモジュールの設定」に、操作は第3巻の「ポータルモジュールの追加開発手順」に書きました。この巻は、それらを前提に「何を、どう決めるか」を扱います。運用の判断基準は第5巻の運用設計書へ渡します。

用語

本書では、次の語を1つの意味で使います。

• 一般の従業員：ポータルのロールを持たない従業員

• 確認用ユーザー：見え方を確かめるために用意する、ロールを持たないユーザー。A〜Eの5名を「組織ごとの公開範囲」で定義します

• 掲載担当：人事部・総務部で掲載を依頼する人

• ポータル担当：情報システム部で sp_admin を持ち、作成と公開を行う2名

• 公開範囲：User Criteria で決める、組織ごとに見せる範囲

• User Criteria：条件に合うユーザーを定義するレコード（user_criteria）

• ウィジェット：画面に表示する機能単位の定義（sp_widget）

• 配置：ページの列にウィジェットを置いたレコード（sp_instance）

• 公開：本番のページの Draft をオフにする操作

• 停止：公開したページの Draft をオンに戻す操作

• PDI：本書の標準仕様を確かめた Australia の Personal Developer Instance。冒頭の「検証環境」もこれを指します

• 開発環境／本番環境：モデル案件で使う2つの環境

設計項目の形式と表記

各設計は、次の10項目をこの順に書きます。該当する内容がない項目は「なし（理由：〜）」と書き、空欄にしません。

• 対象：設計が扱うテーブル・項目・レコード

• 目的：この設計で決めること

• 前提：設計を適用する前にそろっている条件

• 標準仕様：製品の標準の構成と挙動

• 設計内容：この案件で採用する決定

• 設計理由：その決定を採る理由

• 例外：決定が当てはまらない場合、制約、未決事項

• 完了条件：設計どおりに適用できたと判断する状態

• 確かめ方：試験の条件・合格基準・実施状態と、見直しの契機

• 記入例：モデル案件で設計を適用した後の期待値。付録Dにまとめます

標準仕様の各行の末尾には、根拠の種類を付けます。

• ［実測］：PDI で確かめた事実

• ［公式］：製品同梱の説明、または公式ドキュメントの記述

• ［未確認］：確かめていないこと

試験の状態は、PDI で条件どおりに実行して合格基準を満たしたものを［実施済み］、まだ実行していないものを［未実施］とします。

文体は、設計内容の文末を「とする」、完了条件と合格基準の文末を「こと」、図表を書き起こした箇条書きを体言止め、それ以外の説明を「です・ます」にそろえます。担当（ポータル担当）と関連資料（第2巻・第3巻・第5巻）は文書全体で共通とし、各設計に繰り返しません。試験の合否の判定者はポータル担当とし、結果は作業記録に、条件・日時・実施者・画像の保存先とともに記入します。図と表の画像は、同じ内容を直後に箇条書きでも書き出しています。

要件・設計・試験・未決事項・設計判断には、名前とIDを付け、本文では名前で呼びます。IDは、見出しと試験・判断・未決事項の項目名、第2章のマトリクス、第11章の一覧表、変更票、付録Cだけで使います。IDの接頭辞は、要件が RQ、設計が DS、試験が TS、未決事項が OI、設計判断が DC です。

2. 要件と設計の対応

この章で決めること：どの要件を、どの設計で満たすか。要件と設計の対応は、この章のマトリクスだけに書きます。

要件

• RQ-01 窓口の一本化：従業員は1つの画面から、問い合わせ・申請・ナレッジ検索ができる

• RQ-02 限定情報の非表示：組織ごとに限定した情報は、対象外の従業員に表示しない

• RQ-03 承認後の公開：掲載内容は、申請者と別の人が承認してから公開する

• RQ-04 切り分け：表示が崩れたとき、受付から30分以内に原因の分類を特定できる

• RQ-05 本番前の確認：本番に反映する前に、開発環境で表示を確認する

• RQ-06 更新後の確認：製品のメジャーアップグレード後、主要画面の表示を確認する

設計と要件の対応マトリクス

• DS-01 ポータル・ページ・配置の構成と命名：窓口の一本化

• DS-02 User Criteria の作成規則と公開範囲の保存場所：限定情報の非表示

• DS-03 ページの公開状態：承認後の公開

• DS-04 テーマ・ヘッダー・ホームの指定：窓口の一本化、本番前の確認

• DS-05 標準の自動処理を使う範囲：窓口の一本化

• DS-06 ロールと権限境界：限定情報の非表示、承認後の公開

• DS-07 組織ごとの公開範囲：限定情報の非表示

• DS-08 カタログ・ナレッジ・タクソノミーの接続：窓口の一本化

• DS-09 表示不具合の診断：切り分け

• DS-10 性能とキャッシュ：窓口の一本化

• DS-11 更新セットの運用と移送順：本番前の確認

• DS-12 メジャーアップグレード後の回帰確認：更新後の確認

3. 設計方針

この章で決めること：標準のまま使うもの、設定で調整するもの、追加開発するもの。

方針は、標準で足りるものを標準のまま使い、足りない部分だけ設定で調整する順に決めます。追加開発は、この案件の要件には1件もありません。次の表に、論点ごとの区分を示します。

• ポータルの数（標準のまま）：Employee Center（esc）1つだけを使用

• テーマ（標準のまま）：標準テーマを使用。変更要望が出たら複製して調整

• 公開範囲（設定で調整）：カタログとナレッジの User Criteria で組織ごとに分割。ACL は追加なし

• ウィジェット（標準のまま）：製品提供のウィジェットは直接編集せず、複製して変更

• 自動処理（標準のまま）：ビジネスルール・ジョブは追加なし

• 切り分け（手順化）：診断の出力項目を固定。本番にコードは入れない方針

採用の理由

• 新しいポータルを作らないのは、Employee Center で窓口の一本化を満たせるためです。ポータルを増やすと、条件によって利用分析の設定とプロパティが自動で増え、管理するものが増えます

• User Criteria で分けるのは、カテゴリの Available for の効果を PDI で確かめ、公式ドキュメントもこの方式を説明しているためです

• 追加開発をしないのは、標準の自動処理が、ページ ID の整形・既定ポータルの一意性・予約語の禁止を担っているためです

却下した案

• sp_operator を採用する案：却下。保有者は0人で、実際にできる操作を ACL と照合しておらず、権限の範囲を設計に書けません

• ページ・配置単位で User Criteria を使う案：却下。PDI では登録先が見つかっていません

• 組織ごとに独自の ACL を追加する案：却下。追加の要否は、試験「直接アクセスと API」の結果で判断します

4. データ設計

この章で決めること：どのレコードを、どの粒度で、どう名付けて作るか。新しいテーブルは追加しない。

DS-01 ポータル・ページ・配置の構成と命名

対象：sp_portal・sp_page・sp_container・sp_row・sp_column・sp_instance

目的：どのポータルにページを作り、ページと配置をどう名付けるかを決めます。

前提：承認済みの掲載依頼があり、ページの表示名と、置くウィジェットの一覧が決まっています。

標準仕様

• ポータルは10種が標準で入っています。既定（default）が有効なのは Employee Center（esc）の1つだけです［実測］

• 画面は、ページ・コンテナ・行・列・配置の順に積み上がります。配置が「どの列にどのウィジェットを置くか」を持ちます［実測］

• ポータルの URL サフィックスには、予約語の portal と、CMS で使用中の名前を指定できません［実測］

• sp_config ポータルは、サフィックスの変更と削除が保存時に中止されます。それ以外の変更は妨げられません［実測］

ページ ID の整形規則は、「標準の自動処理を使う範囲」の標準仕様にまとめています。

設計内容

• 本番に新しいポータルを作らず、Employee Center（esc）にページを追加する

• ページ ID は、部署略称と内容を _ でつないだ英小文字とする。入力の時点で規則に合わせ、保存後の値が入力と同じであることを確かめる

• 1ページにつきコンテナは1つとし、配置は列ごとにウィジェット1つを基本とする

• 製品提供のウィジェットは、直接編集せず複製して変更する

• 検証用のポータルは開発環境にだけ作り、本番へ移送しない

設計理由

• 配置を1列1ウィジェットにすると、表示が崩れたとき、どの配置が原因かを診断出力の1行に対応づけられます

• ID を入力の時点で規則に合わせると、保存時の整形で値が変わらず、依頼書と更新セットに書いた ID が本番の ID と一致します

例外

• 検証用ポータルを開発環境に作ると、Usage Insights が有効で Engagement Messenger 用でない場合に、利用分析の設定1件とシステムプロパティ1件が自動で作られます。削除するときは、この2件も同時に消します

完了条件

• 保存後の ID が入力の規則と一致すること

• ページ構成（コンテナ・行・列・配置）が、ページのフォームの Page Content に表示されること

確かめ方

• TS-01 ホーム画面の表示［未実施］：人事所属の確認用ユーザーで /esc を開きます。合格基準は、ヘッダー・検索欄・Quick links が表示されること

• TS-02 ページIDの整形［実施済み］：ページ ID に空白と大文字を含む値を入力して保存します。合格基準は、小文字と _ に整形されること

• 見直しの契機：ページ数が想定の約20を大きく超えたとき、ID の規則を見直します

記入例：なし（理由：ページ ID の記入例は、付録D「ページの公開状態」に含めています）

DS-02 User Criteria の作成規則と公開範囲の保存場所

対象：user_criteria（User Criteria）と、カタログ・ナレッジに結ぶ M2M テーブル

目的：組織ごとの限定を、どのレコードで、どんな名前と条件で作り、人事異動にどう追従させるかを決めます。どの組織に何を見せるかの一覧は「組織ごとの公開範囲」に置きます。

前提：承認済みの依頼に、対象の組織（部署・拠点・役職・雇用形態）と、限定する対象（カテゴリ・商品・ナレッジベース・記事）の名称があります。

標準仕様

• User Criteria の条件項目は、user・group・role・department・company・location・script（advanced）・match_all です。役職と雇用形態の項目はありません［実測］

• カテゴリと商品の公開範囲は、Available for と Not available for の M2M（sc_category_user_criteria_mtom・sc_category_user_criteria_no_mtom・sc_cat_item_user_criteria_mtom・sc_cat_item_user_criteria_no_mtom）で結びます［実測］

• Not available for は Available for より優先します。両方に合うユーザーは、その商品にアクセスできません［公式］

• カテゴリの User Criteria は、配下の商品に自動では及びません。必要なら商品ごとに適用します［公式］

• 商品の制限は、Service Catalog の外でテーブル経由のアクセスには適用されません［公式］

• sc_cat_item の読み取り ACL は、スクリプトで canView() を呼びます［実測］

• 一般の従業員がテーブル経由で商品の何を見られるか［未確認］

• ナレッジベースは、Can Read・Cannot Read・Can Contribute・Cannot Contribute の4種類の M2M（kb_uc_*_mtom）で結びます［実測］

• User Criteria を結んでいないナレッジベースは、全員が読め、ロールを持つ全員が投稿できます。Can Read と Cannot Read の両方に合うと読めません。ナレッジ管理者は評価されません［公式］

• 標準の条件のユーザー属性を変更すると、カタログの公開範囲に即時反映されます。スクリプトとロールの条件は、セッションのキャッシュのため再ログインが要ります［公式］

• カテゴリの Available for に人事部を結ぶと、人事所属の一般の従業員には表示され、財務所属には「You do not have permission to see this category」と出ます［実測］

• Available for の行を削除すると、対象外だった財務所属にも表示されます［実測］

• 商品が0件のカテゴリは、管理者でも権限なしの表示になります［実測］

• 商品を作ると、sc_cat_item_category・sc_cat_item_catalog の結び付きが1件ずつ自動で作られます［実測］

• ページ・配置単位の User Criteria は、プラグインとプロパティを有効にすると適用できます［公式］

• PDI では、ページ・配置単位の User Criteria の登録先は見つかっていません［実測］

設計内容

• 部署と拠点は、ユーザーの属性（部署・場所）を条件とする。管理職と外部委託・派遣は、標準の条件項目に役職・雇用形態がないため、グループを条件とする

• 1つの User Criteria は、1つの意味（1部署、1拠点、1グループ）だけを持つ。組み合わせが必要なときだけ Match All をオンにする。例は「大阪の人事部だけ」で、部署に人事部、場所に大阪を入れて Match All をオンにする

• 名前は、許す側を「公開範囲：<対象>」、除外する側を「対象外：<対象>」とする。Not available for は除外にだけ使う

• カテゴリに User Criteria を結ぶときは、配下の商品すべてにも同じものを結ぶ

• ナレッジベースは、作成時に Can Read を設定する。全従業員向けの共通 FAQ のナレッジベースだけは、結ばない例外とする

• 公開範囲の取り下げは、結び付きの削除でなく、カテゴリと商品の無効化で行う

• 棚卸しの対象は、User Criteria の一覧（名前・条件・active・結び付きの件数）とする。条件が空のものと、どこにも結ばれていないものを見つける。周期は第5巻の運用設計書で決めるものとする

設計理由

• 部署・場所の属性は、人事上の異動がユーザー属性に反映された時点で、公開範囲に追従します。グループは付け替えが手作業になり、異動の反映漏れが出ます

• カテゴリの制限が商品に及ばないため、カテゴリと商品の両方に結びます。除外は Not available for の優先で確実に止まります

• スクリプトとロールの条件は、反映に再ログインが要るため使いません

• 結び付きの削除は公開範囲を広げる操作になるため、取り下げには無効化を使います

例外

• 新しいカテゴリを作ると、所属するカタログと、商品の sc_cat_item_category・sc_cat_item_catalog の結び付きも変更対象になります

• ページ・配置単位の User Criteria は採用しません。プラグインとプロパティは有効にしていません

• 未決事項：ページ・配置単位の部門限定が必要か。決める人は情報システム部の責任者で、要望が出たときに決めます

完了条件

• 確認用ユーザーA〜E（一般職2名・管理職1名・外部委託・派遣2名）で、各 User Criteria の見え方が「組織ごとの公開範囲」の一覧どおりであること

• User Criteria の一覧と結び付きの件数が、作業記録に残っていること

確かめ方

• TS-03 カテゴリの公開範囲［実施済み］：カテゴリの Available for に人事部の User Criteria を結びます。合格基準は、人事所属に表示され、財務所属に権限なしの表示が出ること

• TS-04 公開範囲の解除［実施済み］：Available for の行を外します。合格基準は、外したあと財務所属にも表示され、公開範囲を設定していないカテゴリが全員に表示されること

• TS-05 商品URLと検索での非表示［未実施］：対象外の確認用ユーザーで、限定した商品の URL を直接開き、ポータルの検索でも探します。合格基準は、どちらでも商品が表示されないこと

• TS-06 異動への追従［未実施］：確認用ユーザーの部署または場所を変更し、グループ基準のものはグループを付け替えます。合格基準は、見え方が変わり、変更から反映までの時点（即時か、再ログインのあとか）がカタログとナレッジで別々に記録されていること

• 見直しの契機：ユーザー属性の項目、または User Criteria の仕組みがメジャーアップグレードで変わったとき

記入例：付録D「User Criteria の作成規則と公開範囲の保存場所」に載せます。

5. 画面設計

この章で決めること：ページの公開状態、テーマ、ヘッダー、ホームページをどう決めるか。

DS-03 ページの公開状態

対象：sp_page（ページ1枚の定義）の Draft 項目

目的：承認前のページを一般の従業員に見せず、承認後に公開し、問題があれば停止する操作の順序を決めます。

前提：掲載担当から出された依頼が承認済みで、依頼番号、ページの表示名、置くウィジェットの一覧がそろっています。作業者はポータル担当です。

標準仕様

• sp_page には Public・Draft・Roles の3項目があります［実測］

• Draft の製品内の説明は「Draft pages are not visible to end users, but they will show for Service Portal admins」です（訳：下書きのページはエンドユーザーには見えず、Service Portal の管理者には表示される）。引用元：/sys_documentation_list.do?sysparm_query=name=sp_page^element=draft［公式］

• Draft をオンにしたページを管理者が開くと、ページ上端に赤字の「This page is in draft」が出て、ウィジェットも表示されます［実測］

• 同じページを人事所属の一般の従業員が開くと、「Sorry, the page you requested was not found.」の404ページが出ます［実測］

• Draft をオフにすると、同じ従業員にも表示されます［実測］

• ページを複数のポータルのホームに指定している場合、Draft の値は両方に効きます。Draft はポータルでなくページ単位の設定です［実測］

• ページ一覧の既定の列には Draft が含まれません。値はフォームで見ます［実測］

• 開発環境で Draft オンのままのページを送ったとき、本番の公開済みページが下書きに戻るか［未確認］

設計内容

• ページは必ず Draft オンで作成し、開発環境で配置まで終える

• 移送は Draft オンのまま行う。本番で承認済みの依頼番号を確かめてから、本番のページの Draft をオフにする操作を公開とする

• 公開後5分以内に、確認用ユーザーでページを開き、表示を確かめる

• 表示が期待と異なる場合は、Draft をオンに戻して停止する。停止はレコードの削除でなく Draft のオンで行う

• 本番で公開したら、開発環境の同じページも Draft をオフにそろえる

• Public はオフとする（標準の初期値のまま使う）

設計理由

• Draft オンのページは、一般の従業員のページ表示で404になります。承認前の内容を、この経路では見せずに済みます

• 承認の確認と公開の操作を同じ時点に置く運用規則にします。承認状態と Draft を結び付ける仕組みは設けません。仕組みで強制したい場合は、追加開発として別に設計します

• 停止がオンへの切り替えで済むため、削除と違って元の内容が残り、再公開もオフにするだけで済みます

例外

• Draft オンのページは、一般の従業員の視点では確認できません。一般の従業員での確認は公開後になるため、公開後5分以内の確認と停止の手順を組にしています

• 管理者の画面では下書きの内容が見えるため、管理者の表示だけで公開済みと判断しません

• 開発環境の Draft が本番の公開状態に影響するかは、試験「移送後の表示一致」で確かめます

• Public をオフにしたときの未ログインでのアクセスは試験していません。モデル案件は社外への公開を対象外としているため、Public はオフのまま運用します

• 未決事項：sp_admin だけで本番の公開操作ができるか、掲載担当に公開を許すか。決める人はポータル担当と情報システム部の責任者で、期限は本番移行の2週間前です

完了条件

• 公開後の Draft がオフで、確認用ユーザーが期待のウィジェットを見られること

• 承認済みの依頼番号、公開した日時と作業者、確認用ユーザーの表示を撮った画像が、作業記録に残っていること

確かめ方

• TS-07 Draft の表示［実施済み］：Draft のオンとオフを切り替え、一般の従業員と管理者で開きます。合格基準は、オンのとき一般の従業員は404・管理者は赤字付きで表示され、オフのとき一般の従業員にも表示されること

• TS-08 sp_admin だけでの公開操作［未実施］：開発環境で sp_admin だけを付与したユーザーで、ページの Draft を切り替えます。合格基準は、公開と停止の両方を保存できること

• 見直しの契機：メジャーアップグレードで Draft の表示や404の出し方が変わったとき

記入例：付録D「ページの公開状態」に載せます。

DS-04 テーマ・ヘッダー・ホームの指定

対象：sp_theme・sp_header_footer と、sp_portal の theme・homepage

目的：見た目と最初の画面をどの単位で決め、変更をどう確かめてから本番へ入れるかを決めます。

前提：見た目の変更要求があり、承認済みです。変更のない間は、この設計に従う作業はありません。

標準仕様

• テーマとホームページは、sp_portal の項目でポータルごとに1つずつ指定します［実測］

• Employee Center は、テーマに EC Theme、ホームページに ec_home を指定しています［実測］

• ヘッダー・フッターはテーマの側で指定します［実測］

• ヘッダーの背景色などは、テーマの CSS 変数（例：$navbar-inverse-bg）で決まります。Stock Header を使うテスト用テーマで確かめました［実測］

• テーマの変更は、そのテーマを使っているポータルにだけ及びます。テーマAを変更するとテーマAのポータルのヘッダーが変わり、テーマBのポータルは旧色のままでした［実測］

• 変更後9秒で反映を確認しました（1回の観測。最短時間ではありません）［実測］

• EC Theme の変数名と変更前の値［未確認］

• 複製した自社テーマを Employee Center に指定したときの表示［未確認］

設計内容

• 当面は標準の EC Theme と ec_home を、変更せずに使う

• 色などの変更要求が出たら、開発環境で標準テーマを複製して自社テーマを作り、変更は複製側だけで行う

• 開発環境に検証ポータルを作って自社テーマを指定し、複製直後の表示と変更後の表示を確かめる。Employee Center の theme は、この時点では変更しない

• 確認後、自社テーマを更新セットで本番へ移送し、本番で Employee Center の theme を自社テーマに切り替える。sp_portal の更新も更新セットで運ぶ。切り戻しは、theme を EC Theme に戻す操作とする

• sp_header_footer のレコードと、テーマが参照するヘッダー・フッター、ホームページ（ec_home）は変更しない

設計理由

• テーマの変更は使っているポータルにだけ及ぶため、自社テーマを検証ポータルに指定すれば、Employee Center に影響を出さずに確かめられます

• 標準の EC Theme を変更せずに残すと、切り戻しは theme を EC Theme に戻す1回の操作で済みます

• ヘッダー・フッターとホームページを変えないことで、変更の範囲をテーマの CSS 変数に限り、切り戻しの対象を1つにします

例外

• 自社テーマを Employee Center に指定したときの表示崩れは、まだ確かめていません。試験「自社テーマ指定時の表示」で、変更前の自社テーマを指定した状態から確かめます

• EC Theme の変数名と変更前の値は、作業前に確認して控えます

完了条件

• 検証ポータルで変更後の色が表示され、別テーマのポータルが変わっていないこと

• 本番へ移送後、同じ画面を撮って開発環境の画像と比べた記録があること

確かめ方

• TS-09 テーマ変更の範囲［実施済み］：検証ポータルのテーマの CSS 変数を変更します（PDI ではテスト用テーマで実施）。合格基準は、そのテーマのポータルのヘッダーが新しい色になり、別テーマのポータルが変わらないこと

• TS-10 自社テーマ指定時の表示［未実施］：複製直後の自社テーマを、開発環境の検証ポータルに指定します。合格基準は、EC Theme を指定したときと同じ表示になること

• 見直しの契機：メジャーアップグレード後に、テーマの CSS 変数が残っているかを確かめます

記入例：付録D「テーマ・ヘッダー・ホームの指定」に載せます。

6. ロジック設計

この章で決めること：標準の自動処理のうち、この案件が前提とするものと、追加しないこと。

DS-05 標準の自動処理を使う範囲

対象：sp_ で始まるテーブルを対象とする、標準のビジネスルールとスケジュールジョブ

目的：標準の自動処理に何を任せ、何を追加しないかを決めます。

前提：追加開発の要望が出たときは、この設計で、標準の自動処理で足りるかを先に確かめます。

標準仕様

sp_ で始まるテーブルを対象とする有効なビジネスルールは36件あります［実測］。本書の設計が前提とするものは次の5件です。

• Unique Default on Insert / Update（sp_portal・after・100）：default が true になると、自分以外の default を false にします。既定のポータルは常に1つになります［実測］

• Page ID（sp_page・before・99・ID が空でないとき）：ID を小文字にし、英数字と _ 以外を _ に置き換え、連続した _ を1つにまとめ、末尾の _ を除きます［実測］

• Page Title（sp_page・before・100・title が空のとき）：title に ID を入れます［実測］

• Container Name / Set Name（sp_page・sp_container・before・100）：コンテナ名を「ページの title（なければ ID） - Container <order>」に設定します。ページの title や ID を変えると、配下のコンテナ名も更新します［実測］

• Create Analytics Settings for New Portal（sp_portal・after・200）：Usage Insights が有効で Engagement Messenger 用でないポータルに、利用分析の設定を作ります［実測］

スケジュールジョブは次の3件です。

• Portal Analyzer：有効・定期実行［実測］

• Populate Suggestions to avoid Cold Start - Portals：無効・手動実行［実測］

• Advanced Portal Navigation : Delete invalid records：有効・毎日［実測］

設計内容

• ビジネスルール・フロー・スケジュールジョブを追加しない

• 標準のスケジュールジョブの有効・無効は変更しない。Populate Suggestions は無効のままとする

• ページの追加では、Page ID・Page Title・Container Name の標準の動作に任せ、手作業で整形しない

設計理由

• この案件の要件は、標準の自動処理で満たせます。追加するコードは、保守と移送の対象を増やします

• ID とコンテナ名の付け方を標準の動作にそろえると、ページごとの付け方の差が出ません

例外：なし（理由：この設計は自動処理を追加しない決定で、標準の自動処理を止める操作を含まないためです）

完了条件

• ページの保存後に、ID が整形され、title とコンテナ名が自動で設定されていること

確かめ方

• TS-11 名前の自動設定［未実施］：title を空にしてページを保存し、続けて title を入力して保存します。合格基準は、1回目の保存で title に ID が入ってコンテナ名が「<title> - Container <order>」になり、2回目の保存でコンテナ名が新しい title に変わること

• ID の整形は、「ポータル・ページ・配置の構成と命名」の試験「ページIDの整形」で確かめています

• 見直しの契機：メジャーアップグレード後に、ルールの件数と有効状態が変わっていないかを確かめます

記入例：なし（理由：記入する設定値がないためです）

7. 権限設計

この章で決めること：誰にどのロールを付与するか、組織ごとの公開範囲をどの層で制御するか、画面の出し分けを権限の制御とどう区別するか。

DS-06 ロールと権限境界

対象：ポータル専用のロールと、ページ・配置の Roles 項目

目的：誰が下書きを見られ、誰が公開でき、公開できない人は何ができるかを決めます。

前提：ロールの付与は承認済みの依頼にもとづきます。付与・剥奪の承認者と棚卸しの周期は、第5巻の運用設計書で決めます。

標準仕様

ポータル専用のロールは次の6つです［実測］。sp_ で始まるのは sp_admin と sp_operator の2つです。

• sp_admin：ポータルの管理（Can manage the Service Portal）。ポータル担当に付与

• sp_operator：管理者権限なしで、低コードでポータルを調整・管理する。付与の対象外

• portal_analytics_viewer：Web 分析を閲覧する。付与の対象外

• portal_analytics_admin：製品内の説明なし。公式ドキュメントでは Usage Insights の設定を作成するロール。付与の対象外

• portal_notification_pref_admin：通知の受信者の対応表（sys_recipient_user_mapping）を設定する。付与の対象外

• sn_ex_emp_fd.portal_stats_manager：製品内の説明なし（Employee Center の統計）。付与の対象外

sp_admin は次の7つのロールを含みます［実測］。公式ドキュメント「Service Portal roles」が sp_admin の包含ロールとして挙げるのは、このうち4つです［公式］。本書は PDI の包含を前提にします。

• 公式ドキュメントの一覧に載っている：taxonomy_admin、announcement_admin、search_application_admin、evam_admin

• 公式ドキュメントの一覧に載っていない：service_status_subscriber、log_debugger、notification_provider_admin

そのほかの標準仕様は次のとおりです。

• 配置の Roles に実在しないロール名を入れると、管理者には人事からのお知らせのカードが見えたまま、一般の従業員にはそのウィジェットだけが空白になります。エラーは出ません［実測］

• sp_operator で実際にできる操作（ACL との照合）［未確認］

• sp_admin だけでページの Draft を切り替えられるか［未確認］

• ページの Draft がオン：一般の従業員は404ページ、管理者は赤字付きで表示

• 配置の Roles に合わない従業員：そのウィジェットだけが空白で、エラー表示なし

• カテゴリの Available for の対象外の従業員：権限なしの表示

• 3つの判定をすべて通過：表示

設計内容

役割ごとのロールは、次の表のとおりとする。

• 掲載担当（人事・総務 各1名）：ポータルのロールなし。役割は掲載の依頼。sp_admin は付与の対象外

• ポータル担当（情報システム部 2名）：sp_admin を付与。役割は開発環境での作成と、本番での公開操作（Draft の切り替え）。sp_operator は付与の対象外

• 一般の従業員：ロールなし。役割は公開済みページの閲覧。下書きは閲覧の対象外

• 確認用ユーザー（A〜Eの5名）：ロールなし。役割は公開範囲と表示の確認。常設のロールは付与の対象外

あわせて、次のとおりとする。

• 配置の Roles は原則として空とする。使う場合は、実在するロール名だけを入れる

• 掲載担当にページの公開を許す要望が出た場合は、ロールの付与で解決せず、承認後の公開（申請者と公開者の分離）を変える設計変更として扱う。sp_admin の包含ロール7つと sp_operator の ACL を確かめてから決める

設計理由

• 掲載の申請者と公開する人を分けるため、掲載担当に公開できるロールを渡しません

• sp_operator は保有者が0人で、実際にできる操作を ACL と照合していないため、権限の範囲を設計に書けません

• 配置の Roles に実在しない値が入ると、エラーなしでウィジェットだけが消えるため、原則として空にします

• 分析・通知設定・統計のロールは、この案件の要件に対応する機能がないため付与しません

例外

• sp_admin だけで本番の公開操作ができるかは、ACL との照合が済んでいません。試験「sp_admin だけでの公開操作」の結果で、公開手順とロールの付与を確定します

• 未決事項：sp_admin だけで本番の公開操作ができるか、掲載担当に公開を許すか（「ページの公開状態」と同じ未決事項）

完了条件

• 役割ごとのロールの付与状況が、上の表と一致していること

確かめ方

• TS-12 掲載担当の操作制限［未実施］：ロールを持たない掲載担当のユーザーで、ページの編集と Draft の切り替えを試みます。合格基準は、どちらも行えないこと

• sp_admin だけでの公開操作は、「ページの公開状態」の試験「sp_admin だけでの公開操作」で確かめます

• 見直しの契機：担当者の異動、および sp_admin の包含ロールが変わったとき

記入例：付録D「ロールと権限境界」に載せます。

DS-07 組織ごとの公開範囲

対象：ポータル・カタログ・ナレッジ・ACL の4つの層で制御する、組織ごとの公開範囲

目的：全従業員、人事部・総務部、拠点、管理職、外部委託・派遣のそれぞれに何を見せ、見せない相手をどの層で止めるかを決めます。User Criteria の作り方は「User Criteria の作成規則と公開範囲の保存場所」、ロールは「ロールと権限境界」を正本とします。

前提：承認済みの依頼に、対象の組織と、見せる内容の分類があります。試験には、次の確認用ユーザーを使います。

• 確認用ユーザーA：人事部・本社・一般職・社員

• 確認用ユーザーB：総務部・大阪・一般職・社員

• 確認用ユーザーC：財務部・本社・管理職・社員

• 確認用ユーザーD：人事部所属・本社・外部委託・派遣（社内アカウントあり）

• 確認用ユーザーE：総務部所属・大阪・外部委託・派遣（社内アカウントあり）

標準仕様

• ポータルの層では、ページの Draft と配置の Roles で出し分けられます［実測］

• ページ・配置への User Criteria は、プラグインとプロパティの有効化が前提です［公式］

• sc_cat_item・kb_knowledge・kb_knowledge_base の読み取り ACL は、canView・canReadArticle・canReadKnowledgeBase を呼んでいます［実測］

• 呼び出し先の実装と、一般の従業員が一覧や API で取得できる範囲［未確認］

• カタログの User Criteria Diagnostics は、ACL を診断しません［公式］

カタログとナレッジの層の User Criteria の効き方は、「User Criteria の作成規則と公開範囲の保存場所」の標準仕様のとおりです。

設計内容

組織ごとの見え方は、次の図のとおりとする。

起点は確認用ユーザーA〜E、緑は見える、赤は見えない、青の札は制御する層

• 全従業員共通の申請・FAQ：A〜E全員に表示。公開範囲なし

• 人事部内部の申請・ナレッジ：Aに表示、B・C・D・Eに非表示。公開範囲：人事部と対象外：外部委託・派遣（カタログは Available for・Not available for、ナレッジは Can Read・Cannot Read）

• 総務部内部の申請・ナレッジ：Bに表示、A・C・D・Eに非表示。公開範囲：総務部と対象外：外部委託・派遣（Eは総務部所属でも非表示）

• 大阪拠点の設備申請・お知らせ：B・Eに表示、A・C・Dに非表示。公開範囲：大阪拠点。設備は現場の外部委託・派遣も使うため、除外なし

• 管理職の申請・評価制度の手引き：Cに表示、A・B・D・Eに非表示。公開範囲：管理職と対象外：外部委託・派遣

• 社員限定の共通申請：A〜Cに表示、D・Eに非表示。対象外：外部委託・派遣をカタログだけに結び付け。理由は、この行の対象が申請だけで、社員限定にするナレッジがモデル案件にないこと

止める層は、次の図のとおりとする。

起点は確認用ユーザーA〜E、緑は組織で絞らない層、橙は組織ごとに絞る層、灰色は追加しない層

• ポータル・ページの層：組織では絞らず、A〜E全員が通過（ロールなし・公開済みページ）

• カタログのカテゴリの層：Available for と Not available for で停止。人事部内部の例では、Available for に合わない B・C と、Not available for に合う D・E が停止

• カタログの商品・ナレッジの記事の層：カテゴリと同じ条件を結び付け。社員限定の申請では D・E がここで停止

• ACL の層：追加なし。試験「直接アクセスと API」で対象外のレコードが取得できたときに検討

行ごとの結び方は、次のとおりとする。

• 人事部・総務部の内部の申請は、カテゴリと配下の商品の両方に Available for を結ぶ。内部の運用メモは部ごとのナレッジベースに置き、Can Read を結ぶ。Can Contribute は各部の掲載担当のグループだけに結ぶ

• 大阪拠点の設備申請（会議室・駐車場）は、場所を条件にした User Criteria をカテゴリと商品に結ぶ。お知らせは拠点別のナレッジベースの記事とし、Can Read に公開範囲：大阪拠点を結ぶ。ポータルのお知らせ機能の User Criteria は、プラグインが有効でないため採用しない

• 管理職の申請（部下のアカウント申請など）は、カテゴリと商品に結ぶ。評価制度の手引きは管理職用ナレッジベースに置き、Can Read に公開範囲：管理職、Can Contribute に人事部の掲載担当グループを結ぶ

• 画面の出し分けを、権限の制御とみなさない。公開範囲は、関係のない人に見せない配慮として扱う

• 人事異動には部署・拠点の属性基準で追従する。管理職と外部委託・派遣のグループは、異動と雇用形態の変更の手続きで付け替える

• 棚卸しは、User Criteria の一覧と結び付きを、上の見え方の図と突き合わせて行う。周期は第5巻の運用設計書で決めるものとする

設計理由

• 外部委託・派遣の除外を Not available for で結ぶのは、除外が優先され、人事部所属のD・総務部所属のEも確実に止まるためです

• 管理職をグループで条件にするのは、管理職が役職で決まり、User Criteria の標準の条件項目に役職がないためです

• ACL を追加しないのは、User Criteria が表示の対象を決め、標準の読み取り ACL が User Criteria に関わる関数を呼んでいるためです

例外

• ページ・配置の User Criteria とポータルのお知らせの User Criteria は、採用していません。必要になったときは、プラグインとシステムプロパティを確かめてから設計を追加します

• 個人情報と機密性の高い内容は、試験「直接アクセスと API」の結果が出るまで、公開範囲だけで守りません

• 未決事項：個人情報・機密情報を公開範囲で守るか。試験「直接アクセスと API」の結果を見て、情報システム部の責任者が本番移行の2週間前までに決めます

完了条件

• 確認用ユーザーA〜Eの表示が、上の見え方の図と一致すること

• 表示の画像と User Criteria の一覧が、作業記録に残っていること

確かめ方

試験は、確認用ユーザーA〜Eで画面を開き、見える人と見えない人の両方を確かめます。

• TS-13 共通と社員限定の申請［未実施］：合格基準は、共通のカテゴリ・商品がA〜Eに見え、社員限定のカテゴリ・商品がA〜Cに見えてD・Eに見えないこと。見える人は申請を送信でき、見えない人は申請を開始できないこと

• TS-14 人事部内部［未実施］：合格基準は、人事の商品・ナレッジ記事・検索結果がAに見え、B・C・D・Eに見えないこと。Dは人事部所属でも見えないこと

• TS-15 総務部内部［未実施］：合格基準は、総務の商品・ナレッジ記事・検索結果がBに見え、A・C・D・Eに見えないこと。Eは総務部所属でも見えないこと

• TS-16 大阪拠点［未実施］：合格基準は、大阪の設備申請と拠点ナレッジの記事がB・Eに見え、A・C・Dに見えないこと

• TS-17 管理職［未実施］：合格基準は、管理職の申請と評価制度の手引きがCに見え、A・B・D・Eに見えないこと

• TS-18 直接アクセスと API［未実施］：対象外の確認用ユーザーで、商品の詳細 URL・検索結果・一覧と API を使います。合格基準は、限定した商品とナレッジ記事を取得できないこと。取得できた場合は、追加の ACL を検討します

• 見直しの契機：組織の追加・統廃合、および User Criteria の評価方式の変更があったとき

記入例：付録D「組織ごとの公開範囲」に載せます。

8. 連携設計

この章で決めること：カタログ・ナレッジ・タクソノミーを、ポータルにどう接続するか。外部システムとの連携は対象外とする。

DS-08 カタログ・ナレッジ・タクソノミーの接続

対象：sp_portal の sc_catalog_page・kb_knowledge_page と、m2m_sp_portal_taxonomy

目的：Employee Center から、カタログ・ナレッジ・トピックをどの接続で出すかを決めます。

前提：カタログ・ナレッジ・トピックに新しい分類が要るときは、承認済みの依頼にその名称があります。

標準仕様

• Employee Center は、sc_catalog_page に esc_sc_category、kb_knowledge_page に esc_knowledge_home を指定しています［実測］

• Service Portal（sp）と Service Workspace Portal（swp）は、sc_catalog と M2M（m2m_sp_portal_catalog）でカタログを参照します。Employee Center には、この M2M の行がありません［実測］

• ナレッジベースを結ぶ M2M（m2m_sp_portal_knowledge_base）の行は Service Portal の2件だけで、Employee Center の行はありません［実測］

• タクソノミー（Employee）は、Employee Center と Mobile Employee Service Portal が参照しています。トピックは Employee 配下に階層で持ちます［実測］

• Employee Center では、カテゴリをたどっても目的の項目に届かないことがあり、検索のほうが確実に届きます［実測］

• Employee Center が参照するナレッジベースの選び方［未確認］

設計内容

• カタログ・ナレッジ・タクソノミーは、Employee Center の標準の接続のまま使い、接続のレコードを追加しない

• 人事・総務の項目は、既存のカテゴリとトピックの配下に置く。新しい分類が要る場合は、ポータル担当が依頼を受けて作る

• 一般の従業員への案内は、ホームの検索欄を第一の導線とし、カテゴリは補助とする

• 外部システムとの REST 連携・インポートは行わない

• Employee Center：sc_catalog_page は esc_sc_category、kb_knowledge_page は esc_knowledge_home、タクソノミーは Employee を参照する。接続のレコードは追加しない

• sp と swp：sc_catalog と m2m_sp_portal_catalog で Service Catalog を参照する。ナレッジベースの M2M（m2m_sp_portal_knowledge_base）は Service Portal の2件

設計理由

• Employee Center には、カタログとナレッジのページが標準で指定されており、窓口の一本化に必要な導線がそろっています。接続のレコードを追加すると、移送と回帰確認の対象が増えます

• 検索欄を第一の導線にするのは、カテゴリをたどっても目的の項目に届かないことがあり、検索のほうが確実に届くためです

例外

• Employee Center が参照するナレッジベースの選び方は、M2M の行がないため特定できていません

• 未決事項：Employee Center が参照するナレッジベースの選び方。決める人はポータル担当で、期限は本番移行の2週間前です。決まるまで、ナレッジの掲載範囲を確定できません

完了条件

• 人事所属の確認用ユーザーが、ホームの検索欄から、カタログの商品とナレッジの記事を1件ずつ見つけられること

確かめ方

• TS-19 検索からの到達［未実施］：人事所属の確認用ユーザーで、ホームの検索欄に商品名と記事の題名を入れます。合格基準は、商品と記事が検索結果に1件ずつ出て、開けること

• 見直しの契機：メジャーアップグレード後と、新しい分類を作った後

記入例：なし（理由：接続のレコードを追加せず、記入する設定値がないためです）

9. 非機能

この章で決めること：表示不具合を切り分ける情報と、性能・キャッシュの扱い。

DS-09 表示不具合の診断

対象：診断の出力項目と、切り分けの分類

目的：表示が崩れたとき、何を見れば原因の分類を決められるかを定めます。

前提：症状の連絡があり、対象のページ ID と、症状が出る従業員が分かっています。

標準仕様

• 症状A（ウィジェットが出ない）：配置の Roles が一般の従業員に合わないとき、一般の従業員の画面はヘッダーだけで本文が空白になり、エラーは出ません。管理者は同じページでウィジェットが見えます［実測］

• 症状B（ページが見えない）：ページの Draft がオンのとき、一般の従業員は404ページになります。管理者には赤字付きで表示されます［実測］

• ページの draft・public・roles、配置の widget・active・order・roles、User Criteria の active、テーマの css_variables と更新日時は、読み取りだけでまとめて出力できます［実測］

• カタログには User Criteria Diagnostics、ナレッジにはユーザーアクセスの診断機能があり、選んだユーザーの可否を確かめられます［公式］

• 公開範囲の診断機能の出力の形［未確認］

設計内容

診断の出力を次の4区分に固定し、区分ごとに分類を1つ対応させる。

• 区分1 ページ（draft・public・roles）→ 分類「ページ」：draft がオンなら、Draft をオフにして復旧する

• 区分2 配置（widget・active・order・roles）→ 分類「配置」：roles が空でなければ、変更前の値（空）へ戻す。widget・active・order は変更前の記録と比べ、違えば戻す。権限で止まる項目は roles だけとする

• 区分3 公開範囲（User Criteria の active と、診断機能でのユーザーの可否）→ 分類「公開範囲」：「組織ごとの公開範囲」の見え方と食い違えば、結び付きを見え方の図に合わせる

• 区分4 テーマ（css_variables と更新日時）→ 分類「テーマ」：更新日時が症状の発生時刻と近ければ、変更前のテーマ値へ戻す

あわせて、次のとおりとする。

• 初動は、確認用ユーザーの表示と診断出力の2点をそろえて行い、管理者の画面だけで再現確認を終えない

• 診断は読み取りのみとし、変更は別の操作として、変更前の値を控えてから行う

• 目標は、症状の受付から30分以内に、4つの分類のどれかを特定することとする

設計理由

• 症状Aはエラー表示が出ないため、画面の表示からは原因をたどれません。区分ごとの出力が分類の根拠になります

• 区分と分類を1対1にすると、出力のどの区分が異常かで分類が決まり、担当者による判断の差が出ません

• 管理者の画面では症状A・Bとも本文が見えるため、確認用ユーザーの表示を初動に入れます

例外

• 4区分がすべて正常なのに症状が出る場合は、分類を決めません。症状の出る従業員・ページ ID・発生時刻を作業記録に残し、第5巻の運用設計書の判断に渡します

• 公開範囲の診断機能は PDI で実行していないため、区分3の出力の形は適用時に確かめます

完了条件

• 分類の結果、変更前の値、復旧後の確認用ユーザーの表示が、作業記録に残っていること

• 受付から分類の特定までの時間が記録されていること

確かめ方

• TS-20 症状A ウィジェットが出ない［実施済み］：配置の Roles を実在しない値にします。合格基準は、診断で「配置」と分類でき、Roles を空に戻して確認用ユーザーで再表示できること

• TS-21 症状B ページが見えない［実施済み］：ページを Draft オンにします。合格基準は、診断で「ページ」と分類でき、Draft をオフに戻して再表示できること

• TS-22 30分以内の分類［未実施］：開発環境で症状A・Bを起こし、ポータル担当が受付から分類までを行います。合格基準は、受付から30分以内に分類を特定できること

• 見直しの契機：区分の項目名がメジャーアップグレードで変わったとき

記入例：付録D「表示不具合の診断」に載せます。

DS-10 性能とキャッシュ

対象：glide.service_portal.* の検索応答とキャッシュの設定

目的：検索応答とキャッシュの設定を、変えるか既定のまま使うかを決めます。

前提：想定する利用は、同時利用者最大150、ページ約20、配置約100です（架空の値）。

標準仕様

• typeahead.min_length の既定は3です［実測］

• typeahead.wait_ms の既定は1000ミリ秒です［実測］

• 配置・お知らせ・User Criteria のキャッシュ（cache_enabled）は、いずれも既定で true です［実測］

• 値を変えたときの効果［未確認］

• 想定を超える利用者数での挙動［未確認］

設計内容

• 検索応答とキャッシュの設定は、既定値のまま使う

• 追加の非同期処理は作らない

• 性能の数値の合格基準は未決とし、決まった時点でこの設計の確かめ方に加える

設計理由

• 効果が確かめられていない設定を変えると、表示不具合の原因の切り分けが難しくなります

例外

• 未決事項：性能の合格基準（初期表示・検索応答の数値）。決める人は情報システム部の責任者で、期限は本番移行の2週間前です。決まるまで、性能の試験を実施できません

完了条件

• 検索応答とキャッシュのプロパティが、既定値のままであること

確かめ方

• TS-23 検索応答とキャッシュの既定値［未実施］：システムプロパティの一覧で、typeahead の2つの値と、配置・お知らせ・User Criteria のキャッシュの値を開きます。合格基準は、3・1000・true のままであること

• 見直しの契機：利用部門から検索の応答への指摘があったとき、typeahead の2つの値を見直します

記入例：なし（理由：既定値のまま使い、記入する設定値がないためです）

ここから先は有料部です。収録しているのは次の7つで、分量は約1万字です。

• 第10章 配布・移送設計（更新セットの運用と移送順、メジャーアップグレード後の回帰確認）

• 第11章 試験25件の実施状態の一覧

• 第12章 設計判断7件と未決事項6件の一覧

• 付録A 設計項目の記入様式と、モデル案件の値を自社の値に置き換える基準

• 付録B 変更票の書式と記入例

• 付録C 変更要求から設計・試験を引く表

• 付録D 設計ごとの記入例（6件）

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