ナレッジベースとチェックリスト

手順や対処方法を文書として残す機能と、定型作業の実施を管理する機能です。前者は「どうやるか」、後者は「やったか」を扱います。

ナレッジベースの用途

文章で説明が必要な情報を記録します。

記録する内容	効果
障害時の復旧手順	担当者以外でも対応できる
よくある問い合わせへの対処	一次対応で解決できる範囲が広がる
システムの構成と経緯	なぜこの構成なのかが分かる
業務アプリの操作説明	利用者への案内に使える

2番目が実務では効果が大きい部分です。一次対応担当が参照できる記事があれば、エスカレーションの件数が減ります。

記事の書き方

読まれる記事にするための要点があります。

1. 何の問題を扱う記事かを冒頭に書く
2. 前提条件を明記する
3. 手順は番号を付けて順に書く
4. 判断が必要な箇所は基準を示す
5. うまくいかない場合の対処を書く

5番目を省かないでください。手順どおりに進まなかったときこそ、記事を見ている人は困っています。

【運用のポイント】 記事は問い合わせ対応の直後に書いてください。調査した内容が記憶にあるうちなら10分で書けます。後日書こうとすると、思い出す作業から始まって1時間かかります。

記事の分類と検索性

記事が増えると、目的のものを見つけられなくなります。

分類の軸としては次が実務的です。

軸	例
対象	Windows、macOS、ネットワーク、業務システム
目的	障害対応、設定変更、初期構築
利用者	一次対応者向け、インフラ担当向け

タイトルの付け方も重要です。「メール設定」より「Outlookでメールが受信できない場合の確認手順」の方が、検索でも一覧でも見つけやすくなります。

チェックリストの用途

実施すべき項目を並べ、完了を記録します。ナレッジベースが「やり方」なら、チェックリストは「実施の記録」です。

適しているのは次のような作業です。

作業	チェックリストの内容
新規デバイスのキッティング	設定項目の一覧
新入社員のアカウント作成	作成するアカウントと権限
退職者の処理	停止するアカウント、回収する機器
サーバーの定期点検	確認する項目
顧客のオンボーディング	実施する設定と確認事項

3番目は特に重要です。退職者の処理は項目が多く、漏れると情報漏えいにつながります。チェックリストで管理すれば、実施の記録も残ります。

チェックリストの作成

実施する項目を登録します。テンプレートとして用意しておけば、必要なときに複製して使えます。

Drag items to reorderとあるとおり、項目の順序は後から変更できます。手順に沿ったチェックリストを作る場合、まず思いつく項目を並べてから順序を整える進め方ができます。

各項目は編集と削除が個別にできます。運用しながら文言を調整してください。

項目を書く際の注意点は次の通りです。

1. 実施したかどうかが明確に判断できる粒度にする
2. 順序に意味がある場合は並べ替えられないようにする
3. 担当が分かれる場合は担当者を明示する
4. 確認だけの項目と作業する項目を区別する

1番目が重要です。「セキュリティー設定を確認」では、何をもって完了とするか分かりません。「BitLockerが有効で回復キーが保管されていることを確認」と書けば判断できます。

Organizationやデバイスとの紐づけ

チェックリストは対象に紐づけられます。Organizationのオンボーディングであればその組織に、デバイスのキッティングであればそのデバイスに関連付けます。

紐づけておくと、後から「この顧客の初期設定は完了しているか」を確認できます。

共有リンクと権限

作成した文書は、必要な範囲に共有できます。

共有先	用途
運用担当者	手順書、対処方法
エンドユーザー	操作説明、よくある質問
顧客	構成情報、報告書

エンドユーザー向けの記事を公開すると、問い合わせ自体を減らせます。「パスワードの変更方法」のような定型の質問は、記事を案内するだけで解決します。

【注意】 共有する前に、記事に内部情報が含まれていないか確認してください。手順書には管理者しか知るべきでない情報が含まれていることがあります。共有範囲を広げる際は、内容を確認してからにしてください。

定期的な見直し

手順は古くなります。システムの更新や構成変更で、記載どおりに操作できなくなります。

契機	対応
手順どおりに進まなかった	その場で記事を修正する
システムを更新した	影響する記事を洗い出す
半年ごと	参照回数の少ない記事を確認する

1番目を習慣にしてください。「今回は違ったが、まあいいか」で放置すると、記事は徐々に使えなくなります。