手順書や機器の情報を蓄積する機能です。運用の属人化を防ぎ、担当者が変わっても同じ品質で対応できる状態を作ります。
何を保管すべきか
情報システムの運用では、担当者の頭の中にしかない情報が蓄積していきます。
| 属人化しやすい情報 | 失われたときの影響 |
|---|---|
| ネットワーク機器の設定と接続構成 | 障害時に構成が分からない |
| 業務システムの復旧手順 | 復旧に時間がかかる |
| 契約情報と連絡先 | 問い合わせ先が分からない |
| 各種の認証情報 | 作業自体ができない |
| 過去のトラブルと対処 | 同じ調査を繰り返す |
これらをNinjaOne Documentationに集約すると、デバイス情報と同じ場所で管理できます。
扱える情報の種類
用途に応じて3つの形式があります。
| 形式 | 用途 |
|---|---|
| Apps & Services | 機器やサービスの構成情報を定型で記録する |
| ナレッジベース | 手順や対処方法を文書として残す |
| チェックリスト | 定型作業の実施項目を管理する |
構造化された情報はApps & Services、文章で説明するものはナレッジベース、実施の記録が必要なものはチェックリスト、という使い分けになります。
他のツールと比べた利点
汎用の文書管理ツールでも情報は残せます。NinjaOne Documentationの利点は、デバイスやOrganizationと紐づけられる点です。
| 場面 | 紐づけによる効果 |
|---|---|
| 障害対応中 | そのデバイスに関する手順をその場で開ける |
| 顧客対応 | その顧客の構成情報をすぐ参照できる |
| 引き継ぎ | 対象と情報がセットで渡せる |
情報を探すために別のツールを開き、検索し、目的の文書を見つける、という手間がなくなります。
アクセス権限
情報の種類によって、参照できる範囲を制御します。
| 情報 | 参照できる範囲 |
|---|---|
| 一般的な手順書 | 運用担当者全員 |
| 顧客固有の構成情報 | その顧客の担当者 |
| 認証情報 | 限定した担当者 |
| 契約や費用の情報 | 責任者 |
MSPでは特に重要です。顧客Aの担当者が顧客Bの構成情報を参照できる状態は、契約上の問題になり得ます。
Custom Fieldsとの関係
デバイスに紐づく情報は、Custom Fieldsでも管理できます。どちらを使うかの判断基準は次の通りです。
| 情報の性質 | 保管先 |
|---|---|
| デバイス1台ごとの属性値 | Custom Fields |
| 検索や絞り込みに使う | Custom Fields |
| 文章での説明が必要 | ナレッジベース |
| 機器やサービス単位の構成 | Apps & Services |
資産管理番号のような短い値はCustom Fields、「このサーバーの復旧手順」のような文書はナレッジベースです。
運用ルールの決め方
作っただけでは使われません。次を決めてください。
- どの情報を必ず記録するか
- いつ記録するか
- 誰が記録するか
- どのくらいの頻度で見直すか
2番目が重要です。「あとで書く」は書かれません。作業の完了条件に「記録を残すこと」を含めてください。
【運用のポイント】 完璧な文書を目指さないでください。断片的でも記録がある方が、何もないより大幅にいい状態です。まず書き始め、使いながら整えていく進め方を推奨します。