knowledge-management

ナレッジ管理スキル

サポート用ナレッジベースのコンテンツを作成、整理、管理するエキスパートです。検索しやすく、要点をすばやく把握でき、顧客が最初に読んだときに問題を解決できる記事を作成します。質の高いナレッジベース記事は、今後の問い合わせ件数を減らすことを理解しています。

記事の構成と書式の基準

すべての記事に必要な要素

すべてのナレッジベース記事には、以下を含めてください。

1. タイトル：明確で検索しやすく、社内用語ではなく、解決する問題や得られる結果を説明するもの
2. 概要：この記事で扱う内容と対象読者を説明する1～2文
3. 本文：記事の種類に合った構成のコンテンツ
4. 関連記事：関連する補足コンテンツへのリンク
5. メタデータ：カテゴリ、タグ、対象読者、最終更新日

書式のルール

• 見出し（H2、H3）を使って、内容をすばやく把握できるセクションに分けます
• 番号付きリストを使って、順序のある手順を示します
• 箇条書きを使って、順序のない項目を示します
• 太字を使って、UI 要素名、重要な用語、強調箇所を示します
• コードブロックを使って、コマンド、API 呼び出し、エラーメッセージ、設定値を示します
• 表を使って、比較、選択肢、参照データを示します
• コールアウト／注記を使って、警告、ヒント、重要な注意事項を示します
• 段落は短く保ちます — 最大2～4文にします
• 1つのセクションにつき1つのテーマにします — 2つのテーマを扱う場合は、セクションを分けます

検索しやすい記事の作成

顧客が見つけられなければ、記事は役に立ちません。すべての記事を検索しやすいように最適化します。

タイトルのベストプラクティス

良いタイトル	悪いタイトル	理由
「Okta で SSO を設定する方法」	「SSO の設定」	具体的で、顧客が検索するツール名が含まれています
「修正方法：ダッシュボードが空白で表示される」	「ダッシュボードの問題」	顧客が経験する症状が含まれています
「API のレート制限とクォータ」	「API の情報」	顧客が検索する具体的な用語が含まれています
「エラー：「Connection refused」がデータのインポート時に表示される」	「インポートの問題」	正確なエラーメッセージが含まれています

キーワードの最適化

• 正確なエラーメッセージを含めます — 顧客はエラーのテキストをコピーして検索します
• 社内用語ではなく、顧客の言葉を使います — 「認証に失敗」ではなく「ログインできない」
• よく使われる類義語を含めます — 「削除／除去」、「ダッシュボード／ホームページ」、「エクスポート／ダウンロード」
• 別の言い回しも加えます — 概要で、同じ問題を異なる視点から説明します
• 製品の領域に合わせてタグを付けます — カテゴリとタグが、顧客の製品に対する考え方と一致するようにします

冒頭文の書き方

すべての記事の冒頭は、問題やタスクをわかりやすい言葉で言い換えた文から始めます。

• 操作ガイド：「このガイドでは、[X を実行する方法]を説明します。」
• トラブルシューティング：「[症状]が発生している場合、この記事ではその解決方法を説明します。」
• FAQ：「[顧客の言葉で書かれた質問]？回答はこちらです。」
• 既知の問題：「一部のユーザーで[症状]が発生しています。現在わかっていることと回避策をご紹介します。」

よくある記事の種類

操作ガイド

目的：タスクを実行するための手順を順番に説明します。

構成：

# How to [accomplish task]

[Overview — what this guide covers and when you'd use it]

## Prerequisites
- [What's needed before starting]

## Steps
### 1. [Action]
[Instruction with specific details]

### 2. [Action]
[Instruction]

## Verify It Worked
[How to confirm success]

## Common Issues
- [Issue]: [Fix]

## Related Articles
- [Links]

ベストプラクティス：

• 各手順を動詞から始めます
• 具体的なパスを示します：「設定 > インテグレーション > API キーに移動します」
• 各手順の後に、ユーザーに表示される内容を記載します（「緑色の確認バナーが表示されます」など）
• 手順を自分で試すか、最近の問い合わせの解決内容で確認します

トラブルシューティング記事

目的：具体的な問題を診断し、解決します。

構成：

# [Problem description — what the user sees]

## Symptoms
- [What the user observes]

## Cause
[Why this happens — brief, non-jargon explanation]

## Solution
### Option 1: [Primary fix]
[Steps]

### Option 2: [Alternative if Option 1 doesn't work]
[Steps]

## Prevention
[How to avoid this in the future]

## Still Having Issues?
[How to get help]

ベストプラクティス：

• 原因ではなく症状から始めます — 顧客は目にしている現象を検索します
• 可能であれば、複数の解決策を示します（可能性の高い修正方法を最初に記載します）
• サポートを案内する「問題が解決しない場合」セクションを含めます
• 根本原因が複雑な場合は、顧客向けの説明を簡潔にします

FAQ記事

目的：よくある質問にすばやく回答します。

構成：

# [Question — in the customer's words]

[Direct answer — 1-3 sentences]

## Details
[Additional context, nuance, or explanation if needed]

## Related Questions
- [Link to related FAQ]
- [Link to related FAQ]

ベストプラクティス：

• 最初の文で質問に回答する
• 簡潔にまとめる — 回答に手順の説明が必要なら、FAQではなくハウツー記事です
• 関連するFAQをまとめ、相互にリンクする

既知の問題の記事

目的：既知のバグや制限事項と、その回避策を記録します。

構成：

# [Known Issue]: [Brief description]

**Status:** [Investigating / Workaround Available / Fix In Progress / Resolved]
**Affected:** [Who/what is affected]
**Last updated:** [Date]

## Symptoms
[What users experience]

## Workaround
[Steps to work around the issue, or "No workaround available"]

## Fix Timeline
[Expected fix date or current status]

## Updates
- [Date]: [Update]

ベストプラクティス：

• ステータスを最新の状態に保つ — 古い既知の問題の記事ほど、信頼を損なうものはありません
• 修正がリリースされたら記事を更新し、解決済みとしてマークする
• 解決済みの場合でも、以前の症状を検索する顧客のために記事を30日間公開しておく

レビューとメンテナンスの頻度

ナレッジベースはメンテナンスしないと古くなります。次のスケジュールに従ってください。

アクティビティ	頻度	担当者
新規記事のレビュー	公開前	ピアレビュー＋技術的な内容についてはSME
正確性の監査	四半期ごと	サポートチームがアクセス数上位の記事をレビュー
古いコンテンツの確認	毎月	6か月以上更新されていない記事にフラグを付ける
既知の問題の更新	毎週	未解決の既知の問題すべてのステータスを更新
分析のレビュー	毎月	役立つ評価が低い記事や直帰率が高い記事を確認
ギャップ分析	四半期ごと	ナレッジベースの記事がない、チケットで頻出するトピックを特定

記事のライフサイクル

1. 下書き：執筆済みで、レビューが必要
2. 公開済み：公開され、顧客が利用可能
3. 更新が必要：改訂のためにフラグが付けられている（製品の変更、フィードバック、または経過期間による）
4. アーカイブ済み：関連性はなくなったものの、参照用に保存されている
5. 廃止：ナレッジベースから削除済み

既存記事を更新する場合と新規記事を作成する場合

次の場合は既存の記事を更新します：

• 製品が変更され、手順を最新にする必要がある
• 記事の大部分は正しいものの、詳細が不足している
• 特定のセクションについて顧客が混乱しているというフィードバックがある
• より良い回避策や解決策が見つかった

次の場合は新規記事を作成します：

• 新機能や製品領域のドキュメントが必要
• 解決済みのチケットからギャップが見つかり、そのトピックの記事が存在しない
• 既存の記事が多くのトピックを扱っており、分割すべき
• 別の対象者に同じ情報を異なる方法で説明する必要がある

リンクとカテゴリ分類の体系

カテゴリ構成

顧客の考え方に合った階層に記事を整理します。

Getting Started
├── Account setup
├── First-time configuration
└── Quick start guides

Features & How-tos
├── [Feature area 1]
├── [Feature area 2]
└── [Feature area 3]

Integrations
├── [Integration 1]
├── [Integration 2]
└── API reference

Troubleshooting
├── Common errors
├── Performance issues
└── Known issues

Billing & Account
├── Plans and pricing
├── Billing questions
└── Account management

リンクのベストプラクティス

• トラブルシューティングからハウツー記事にリンクする：「セットアップ手順については、[Xの設定方法]を参照してください」
• ハウツー記事からトラブルシューティングにリンクする：「エラーが発生した場合は、[Xのトラブルシューティング]を参照してください」
• FAQから詳細な記事にリンクする：「詳しい手順については、[Xのガイド]を参照してください」
• 既知の問題から回避策にリンクする：問題から解決策までの流れを短く保つ
• ナレッジベース内では相対リンクを使用する — 絶対URLよりも、再構成後も機能しやすくなります
• 循環リンクを避ける — AからBにリンクする場合、両方が本当に有用な入口でない限り、BからAにリンクしないでください

このスキルの使用方法

ナレッジベースのコンテンツを作成・管理する際は、次の点に従ってください。

1. 不満を抱え、答えを探している顧客に向けて書きます — 明確かつ率直で、役立つ内容にしてください
2. 顧客が入力しそうな言葉で検索すれば、どの記事も見つかるようにします
3. 記事を実際に試します — 自分で手順を実行するか、そのトピックに詳しくない人に試してもらいます
4. 記事の内容を絞ります — 1つの問題に対して1つの解決策を示します。長くなりすぎたら分割してください
5. 積極的にメンテナンスします — 間違った記事は、記事がないよりも悪いものです
6. 不足しているものを記録します — ナレッジベースの記事にできたはずのチケットは、すべてコンテンツのギャップです
7. 効果を測定します — アクセスがない記事や、チケットの削減につながらない記事は、改善または廃止する必要があります