XEROTTA

CUSTOM ITSM DEVELOPMENT / ITIL (VERSION 5)

必要な管理から、
貴社のITSMをつくる。

お客様の業務・体制・リスクに合わせた個社ITSM開発。
シンプルな受付から、複数部門・既存システムをつなぐ運用基盤まで、段階的に構築します。

採用する項目を見る ↓2つの開発事例を見る ↓情報確認日：2026年10月30日

FIT THE FRAMEWORK TO YOUR WORK

ITILを、現場で動く設計へ。

ITIL（Version 5）を参照し、どの目的を実現するために、誰が、どの情報を使い、何を判断するかを設計します。画面だけでなく、役割・手順・連携・効果測定までを一緒に整えます。

現行版：ITIL (Version 5)

2026年1月に公開された現行版です。ITIL 4から継続する考え方を活かしながら、製品とサービスのライフサイクル、利用者の体験、AIを含む運用の責任を踏まえて設計します。既存の手順を一律に廃止する前提にはしません。

ITILは参照する枠組みであり、このページは公式の必須機能一覧ではありません。ITILを参照した開発というだけで、製品の認証取得や一定の効果を保証するものではありません。

01

成果から決める

何を管理するかより先に、利用者が仕事を再開できる、必要な申請が完了する、といった目的を定義します。

02

運用の責任を決める

人、情報と技術、業務の流れ、委託先を合わせて確認。担当や情報の正本が曖昧な部分を整理します。

03

提供から改善までつなぐ

要件・設計・変更・提供・運用で得た情報を関連付けます。すべての依頼に同じ工程を強制しません。

04

小さく試して広げる

重要な業務から検証し、待ち時間や再発を測定。自動化やAIも、権限と確認手順を決めて追加します。

ADOPT / SIMPLIFY / EXTEND

何を採用し、どこをシンプルにするか。

以下は15の管理プラクティスを切り口にした、XEROTTAの実装例です。シンプル化では入力・重複記録・承認経路を絞り、責任者・必要な承認・権限・証跡は残します。専用機能を作らず、共通の台帳や既存システムで実現する選択も含みます。

サービスデスク

Service Desk

シンプル構成

受付フォームと共有キューを1つに集約。担当者と連絡履歴を見える化。

複雑な構成

会社・拠点・サービスごとの窓口、複数チャネル、担当グループと委託先への振り分け。

採用・簡略化の考え方

両構成で採用。小規模では入口を増やさず、責任者不明の依頼を防ぐ。

インシデント管理

Incident Management

シンプル構成

業務影響と緊急度から優先度を決め、復旧担当と次回連絡を記録。

複雑な構成

重大障害の指揮役、並行作業、影響サービス、関係者通知、復旧後レビューを統合。

採用・簡略化の考え方

両構成で採用。復旧を優先し、原因調査の完了を復旧報告の条件にしない。

サービス要求管理

Service Request Management

シンプル構成

機器貸出・アカウント申請など、頻出依頼のテンプレートと必要な承認だけを用意。

複雑な構成

サービスカタログ、条件分岐・並行承認、在庫・契約・ID基盤との連携で提供まで追跡。

採用・簡略化の考え方

両構成で採用。障害と通常申請を分け、すべての依頼に同じ承認を課さない。

問題管理

Problem Management

シンプル構成

再発・重大事象を改善台帳に登録。原因・暫定回避策・担当・期限を残す。

複雑な構成

関連インシデントを束ね、原因仮説、既知のエラー、恒久対策と変更を追跡。

採用・簡略化の考え方

小規模では専用の複雑な画面を後回しにできるが、再発を放置しない仕組みは残す。

監視とイベント管理

Monitoring & Event Management

シンプル構成

既存監視の重要通知だけを受付につなぎ、初期は担当者が確認して登録。

複雑な構成

監視イベントを収集し、重複抑制、サービスとの関連付け、当番通知と自動起票を実装。

採用・簡略化の考え方

全通知を自動でチケット化せず、対応が必要なイベントから広げる。

変更実現

Change Enablement

シンプル構成

定型変更は承認済み手順で記録。通常・緊急変更はリスクに応じた承認と結果確認。

複雑な構成

影響範囲、依存関係、変更予定、承認者、試験、切り戻し条件を一つの記録で管理。

採用・簡略化の考え方

両構成で最低限を採用。小規模でも無承認の本番変更にはしない。全変更を会議に掛ける設計も避ける。

展開管理

Deployment Management

シンプル構成

手順書、作業者、実施日時、確認結果、切り戻し手順を変更記録に添付。

複雑な構成

CI/CDや運用自動化と連携し、環境別の実行権限・承認・証跡・復旧を管理。

採用・簡略化の考え方

小規模では専用配布基盤を新設せず、既存の安全な手順を再利用する。

リリース管理

Release Management

シンプル構成

提供する変更内容、対象、利用者への案内をまとめて残す。

複雑な構成

複数変更をリリースに束ね、提供判断、利用準備、周知、提供後評価を管理。

採用・簡略化の考え方

小規模は変更記録内の項目として簡素化。展開の実行と利用者への提供判断は区別する。

サービス構成管理

Service Configuration Management

シンプル構成

重要サービス、責任者、関係する主要機器・システムへの参照を登録。

複雑な構成

CMDBでサービスと構成要素の依存関係を管理し、発見情報と管理情報の差分を照合。

採用・簡略化の考え方

全機器を網羅する複雑なCMDBは小規模では後回し。障害や変更の影響判断に必要な範囲から始める。

IT資産管理

IT Asset Management

シンプル構成

既存台帳を活かし、資産番号、利用者、保有状態、関連チケットを結び付ける。

複雑な構成

調達・契約・在庫・貸出・返却・修理・廃棄を連携し、機器と契約の履歴を追跡。

採用・簡略化の考え方

構成情報と資産の会計・所有情報を混同せず、既存の正本台帳を決める。

関係管理

Relationship Management

シンプル構成

業務部門の窓口を決め、定例で困りごとと改善希望を確認。

複雑な構成

事業部別の利用体験、需要、改善要望をサービス責任者がまとめ、計画と優先順位に反映。

採用・簡略化の考え方

専用CRMは必須にせず、利用者の声が担当者の記憶だけに残らないようにする。

サプライヤー管理

Supplier Management

シンプル構成

委託先の連絡先、対応時間、依頼範囲、エスカレーション先を登録。

複雑な構成

契約、対応目標、委託範囲、共有可能なチケット、各社の回答と責任分界を管理。

採用・簡略化の考え方

両構成で担当と責任を明確化。複数社が関与しても全体を追う社内責任者を残す。

サービスレベル管理

Service Level Management

シンプル構成

業務時間、優先度、初回応答・復旧・申請完了の目標を合意し、期限を見える化。

複雑な構成

サービス・契約別のSLA、社内分担目標、委託先の契約条件を対応させ、逸脱を追跡。

採用・簡略化の考え方

対応時間は一律に決めず、実績・要員・事業影響を踏まえて、お客様と合意します。

継続的改善

Continual Improvement

シンプル構成

月次で滞留・再発・FAQ不足を確認し、改善担当と期限を決める。

複雑な構成

複数サービスの改善案を価値・リスク・工数で優先付けし、実施後の変化を測定。

採用・簡略化の考え方

両構成で採用。ダッシュボードを作るだけで終わらず、次の行動に結び付ける。

情報セキュリティ管理

Information Security Management

シンプル構成

役割別の閲覧・更新権限、承認記録、監査ログ、バックアップ、保存期間を定める。

複雑な構成

会社・機密区分ごとの分離、職務分掌、特権操作承認、外部委託先アクセス、証跡保全を設計。

採用・簡略化の考え方

簡素化の対象から除外するのではなく、必要な統制を小さい構成で実装する。

ナレッジは、どちらの構成にも横断して組み込みます。

解決した内容を再利用できる回答に整え、公開範囲・確認者・見直し日を管理します。シンプル構成はFAQと関連チケットから、複雑な構成は版・承認・サービス別の公開管理へ広げます。情報を集めるだけでなく、古い回答を更新する運用まで決めます。

ITILの34プラクティスすべてを専用画面として作る前提ではありません。採用範囲は、業務への影響・件数・担当人数・契約・監査要件に基づいて合意します。上表の説明は当社の設計例です。

DESIGN EXAMPLES

2つの開発事例を、具体的に。

どちらもXEROTTAが作成した想定事例です。実在企業への導入実績や効果測定結果ではありません。

想定事例 / XEROTTA作成

少人数の情報システム部門で、受付と対応を一つにする

メール・口頭・チャットに分散していた依頼を集約し、誰が何を対応しているかを見えるようにする開発例です。画面と入力項目を絞り、日々の対応記録をナレッジと改善に戻します。

想定する条件

  • 想定規模：利用者約200人、対応担当3人、主な対象はPC・アカウント・社内SaaS。規模は架空の前提です。
  • 受付窓口をWebフォームと指定メールに統一。既存の社内ID基盤を認証に利用する設計です。
  • 対応時間と対象業務を合意し、時間外の緊急連絡は別の運用として決めます。
  • 全社の詳細なCMDBや複数会社への課金管理は、初期開発の対象にしません。
システム構成イメージ
  1. 01

    利用者の窓口

    フォーム・指定メール・FAQ。受付番号と進捗を本人へ通知。

  2. 02

    受付・対応台帳

    問い合わせと障害・申請を分類。担当、期限、履歴を一つに。

  3. 03

    必要な情報だけ連携

    社内ID、利用者、対象サービス、端末管理番号を参照。

  4. 04

    解決と改善

    利用者に結果を確認。再利用できる回答と改善候補を残す。

機能と情報の流れを示す設計例です。実際の構成は、既存環境・契約・権限・可用性の要件に合わせます。

業務がどう流れるか

01障害・問い合わせ対応
  1. 依頼を受け付ける
  2. 影響と緊急度を確認
  3. 担当者を決める
  4. 調査・復旧を記録
  5. 利用者へ結果確認
  6. 完了・ナレッジ候補へ

状態は「受付」「対応中」「保留」「解決」「完了」を基本にします。保留理由と次回確認日を必須にし、解決後の再発は再開・関連チケットとして追跡します。大きな障害は責任者へ即時連絡し、通常案件と分けて周知します。

02アカウント・端末などの定型申請
  1. 申請種類を選ぶ
  2. 必要情報を確認
  3. 必要な承認を取る
  4. 担当者が実施
  5. 実施結果を記録
  6. 申請者へ完了通知

申請種類ごとに必要な項目を切り替えます。閲覧だけの依頼と権限付与を同じ承認経路にせず、上長承認・実施担当・記録を必要な操作に設定します。

03最小限の変更管理
  1. 変更内容と影響を記録
  2. リスクを判断
  3. 承認または事前承認を確認
  4. 実施と確認
  5. 失敗時は戻す・再評価

繰り返し行う低リスク作業は、条件・手順・責任者を定義した事前承認で簡略化できます。条件外は個別承認へ戻します。高リスク作業の承認、切戻し手順、実施記録は省略しません。

管理するデータ・画面

受付に必要な項目
件名、内容、申請者・連絡先、対象サービス、影響範囲、発生日時。端末番号や添付は必要なときだけ追加します。
対応担当が持つ項目
種別、担当、優先度、状態、初回応答日時、期限、保留理由、次回確認日、対応履歴、解決内容。利用者が優先度を自由に確定しない設計にします。
シンプルな画面
利用者は「依頼する・自分の依頼・FAQ」。担当者は「未割当・自分の対応・期限超過・保留」を見られる一覧を用意します。
最小限の資産・構成情報
端末管理番号と利用者、対象サービスと担当窓口を参照します。詳細な全構成情報を集める代わりに、正しい更新元と更新担当を決めます。
回答ナレッジ
関連するチケット、対象者、公開範囲、作成者、確認者、見直し日を管理。機密情報を除いて確認後に公開し、古い回答は再確認します。

担当と権限

利用者
自分の依頼を登録・確認。原則として他人の依頼や内部メモは閲覧できません。
サービスデスク担当
受付・分類・対応・エスカレーションを実施。担当変更と対応履歴を残します。
責任者・承認者
優先度の例外、権限付与、重要な変更を判断。月次で滞留と改善候補を確認します。
システム管理者
分類・権限・通知・バックアップを管理。業務の承認とシステム設定の権限を分けて設計します。

効果をどう測るか

  • 初回応答は担当者が内容を確認して応答するまでとし、自動受付メールを分けます。解決時間・中央値・長時間案件・再開率も確認します。
  • 応答目標の例は「合意した営業時間内に4時間以内」。これは設計例で、実際の提供条件ではありません。計測の開始・終了・休日を定義します。
  • 保留で何の時計を止めるかを区別します。利用者待ちで解決時計を止める場合も、初回応答や次回連絡の管理は残します。
  • 未割当・期限超過・長期保留、利用者への結果確認、同種問い合わせの再発を月次で確認します。

公開・運用開始前に検証すること

  • 同じメールを再受信しても重複登録されず、通知失敗を検知できるか。
  • 利用者が他人のチケットや添付を閲覧できないか。担当者の内部メモが外部通知に混ざらないか。
  • 休日・営業時間・保留・再開時の期限計算が合意したルールと一致するか。
  • 担当不在、承認者不在、バックアップ復元、既存台帳の移行結果を確認する。

BUILD IN STAGES

設計から運用へ、段階を分けて進める。

  1. 01 / DISCOVERY

    要件と現状を整理

    対象サービス、依頼、既存台帳、責任分界、機密区分、現在の対応時間を確認。採用・簡略化・後回しの範囲を決めます。

  2. 02 / DESIGN & BUILD

    代表的な業務を実装

    画面、データ、権限、承認、連携を設計。既存製品や基盤を活かす部分と、個別開発する部分を整理します。

  3. 03 / VALIDATE & TRANSITION

    試験運用して移行

    正常系だけでなく、例外・不在・連携停止・復元を検証。移行データを照合し、切替と戻し方を決めます。

  4. 04 / OPERATE & IMPROVE

    測定して改善

    操作・管理手順を引き継ぎ、滞留・再発・利用者の声を確認。必要に応じて対象部門や機能を広げます。

上記は当社の開発工程例であり、ITILの公式ライフサイクル図ではありません。費用・期間・可用性・復旧目標は、要件と運用体制に応じて個別に決めます。

FAQ

個社ITSM開発のFAQ

どのバージョンのITILを参照しますか？

2026年10月30日時点で最新のITIL (Version 5) を参照します。既存のITIL 4ベースの運用も確認し、役立っている手順・データは活用します。バージョン名だけを置き換えるのではなく、製品・サービスのライフサイクルと利用者の成果につながる構成を検討します。

34プラクティスをすべてシステム化する必要がありますか？

本ページの開発方針では、一度にすべてを専用機能として実装する前提にしません。必要な目的・責任・統制を確認し、初期は受付、障害、申請、必要な承認、ナレッジ、改善から始める設計が可能です。掲載の対応表は設計例であり、ITILの公式必須チェックリストではありません。

市販のITSMツールと個社開発はどう使い分けますか？

標準機能で要件を満たす部分は既存製品を活かし、独自の申請、承認、データ連携、利用画面などに個社開発を組み合わせます。ライセンス、保守、更新、データ出力、運用担当者の負担を含めて比較し、すべてを独自開発する前提にはしません。

シンプルな構成から、後で大規模な構成に広げられますか？

サービス・社員・資産・チケットのID、権限、履歴、APIの境界を初期に整理することで段階的に拡張できます。最初から全社CMDBを完成させるのではなく、重要サービスと頻出依頼から対象を増やします。拡張時には既存データと承認ルールの整合性を確認します。

既存の人事・資産・監視システムを残して連携できますか？

利用可能なAPI、ファイル出力、認証方式、契約条件を確認して連携方法を設計します。データの正本と更新方向を決め、連携層で変換・再送・照合を行います。すべての製品が同じ条件で接続できるとは限らないため、実際の環境で接続・権限・障害時の動作を検証します。

AIを組み込めますか？ ITIL準拠や効果も保証されますか？

AIによる分類・要約・回答候補・ナレッジ草稿の作成は設計対象にできます。外部送信する情報、参照権限、評価方法、承認が必要な操作を定め、実データに近い条件で検証します。ITILを参照した設計というだけで、認証の取得や一定の改善率を保証するものではありません。効果は合意した指標で導入前後を比較します。

出典・確認情報

2026年10月30日に、PeopleCert・ITILの公式公開情報を確認しました。管理プラクティスの詳細や提供状況は、設計時に現行の公式資料と利用条件を確認します。

XEROTTA SUPPORT

複雑な業務を、扱いやすい仕組みに。

必要な管理を残し、利用者と担当者の負担を減らす構成を一緒に考えます。
既存システムの活用や、製品導入との組み合わせもご相談ください。

個社ITSM開発について相談する →ITSMツールを比較する