コンテンツやランキングを損なうことなく、ナレッジベースプラットフォームを統合する方法

複数のナレッジベースを所有していて、そのうち少なくとも一部を統合したいと考えているとします。しかし、どのコンテンツを移動すべきでしょうか？どのコンテンツをそのまま残すべきでしょうか？また、重複した記事、翻訳、添付ファイル、あるいは既にGoogleで上位表示されているページはどうなるのでしょうか？

このガイドでは、まずナレッジベースの統合（一部のコンテンツを分離しておく方が理にかなっている場合も含む）について見ていき、次にナレッジベースの移行そのものについて、移行できるもの、移行の準備方法、そして移行中にコンテンツや検索トラフィックが失われないようにする方法について説明します。.

ナレッジベース統合とは何ですか？

これらの要素は、新しいシステムに直接対応するものが必ずしも存在するとは限りません。あるナレッジベースではカテゴリを使用しているのに、別のナレッジベースではフォルダを使用している、あるいは翻訳や記事フィールドの保存方法が異なっているといったケースがあります。そのため、すべてのコンテンツが1か所に集約された後、コンテンツの整理方法が異なってくる可能性もあります。.

統合か統合か：どちらが必要か？

知識ベースを分離したままコンテンツを見つけやすくしたい場合、統合を選択する人が多い。とはいえ、同じ情報を複数の場所で管理するのをやめたい場合は、統合を検討すべきだろう。.

例えば、開発チームが技術文書を Confluence に、サポートチームが顧客向けガイダンスを Zendeskにそれぞれ保存しているとします。誰もがこれらのシステムを引き続き利用することに満足していますが、従業員は両方のシステムを1か所から検索したいと考えています。そのような場合、統合検索が有効な解決策となるでしょう。例えば、Happeoは Confluence や Zendesk といった連携システムからの検索結果を同じ検索インターフェースに表示できます。.

しかし、問題がコンテンツ自体にある場合、統合検索は役に立ちません。2つのナレッジベースが重複している場合、同じ情報の2つのバージョンを維持する必要があります。ナレッジベース統合により、ナレッジベースのコンテンツを統合し、1つのバージョンで管理できるようになります。.

しかし、すべてを統合する必要はありません。サポートコンテンツは1つのナレッジベースにまとめ、開発者は既に管理している Confluenceでドキュメントを保管すればよいのです。.

知識ベースを分離しておく方が理にかなっている場合

では、製品変更後に何が起こるかを見てみましょう。同じ質問に答える記事を2つ更新するために、2人の担当者が必要になるのでしょうか？どちらのバージョンがどのシステムに属するかを覚えておく必要があるのでしょうか？読者は両方のバージョンを見つけることがあるのでしょうか？

そうであれば、同じ知識を二重に管理していることになります。それらの記事を統合することで、更新すべきバージョンは1つになり、その他の知識ベースはそのまま維持できます。.

チームが知識ベースを統合するに至る理由

企業はドキュメントを5か所に保管したいと考えている。買収に伴い、ナレッジベースが1つ追加される場合もある。サポート部門は新しいプラットフォームを使い始めるが、役立つ記事は古いプラットフォームに残される。製品部門とサポート部門はそれぞれ別のドキュメントを作成するが、後になって一部が重複していることに気づくこともある。.

知識ベースを統合する前に、まずそれらがどのようにしてできたのかを整理しましょう。その答えを知ることで、何を統合し、何を別々に保持するのが適切かを判断するのに役立ちます。.

合併・買収

企業買収によって、長年にわたる未活用コンテンツが残る場合があります。OneflareがUrbanYouを買収した際、UrbanYouには20万件以上のチケットに加え、ナレッジベースやその他の顧客データがありました。Oneflareはその履歴を保持したかったため、 Help Desk Migration 移行しました 新しい Zendesk 。

しかし、両社のヘルプセンターコンテンツを統合する前に、記事を詳しく見てみましょう。アクセス数は多いものの旧ブランドを使用している記事や、自社の記事と同じトピックを扱っているものの、自社の記事にはない詳細情報が含まれている記事が見つかるかもしれません。複数のナレッジベースを統合する前に、それぞれのケースについてどう対処するかを、元の記事が front にあるうちに決めておきましょう。.

ツールの乱立と重複したドキュメント

知識ベースが肥大化すると、記事を編集する前にどの記事がどこに属するのかを考えなければならなくなるため、ドキュメント作成ツールを統合する良い理由となる。.

チーム間でドキュメントを統合したいとしましょう。サポート部門はヘルプセンターを、製品部門は独自のドキュメントを管理しており、古い記事は誰も完全に廃止していないシステムにまだ残っています。新しい記事は複数のシステムに掲載される可能性があり、その掲載場所は公開者によって決まることがよくあります。時間が経つにつれて、誰も意図的に重複を作成しなくても、関連コンテンツはこれらのシステムに分散してしまうのです。.

断片化された知識ベースのコスト

に APQCが 982人の知識労働者を対象に行った調査によると、回答者は必要な情報を探したり要求したりするのに平均して週2.8時間を費やしていることが明らかになった。また、既に存在する情報を改めて作成したり、質問に答えてくれる人を探したりするのに時間を費やしていると回答者から報告があった。

断片化されたドキュメントは、同じような作業を生み出す可能性があります。あるナレッジベースの記事で質問への回答が得られたとしても、別のシステムに新しいバージョンがあるかどうかを確認する必要が出てきます。ナレッジマネジメントの統合によって、重複するコンテンツを一つにまとめることで、このような余分な手順を削減できます。.

統合できるもの

移行できる内容は、関係する2つのプラットフォームによって異なります。ソースに存在するレコードやフィールドが、移行先に同等のものがない場合もあるため、移行は両方のシステムがサポートする範囲内で実行する必要があります。.

記事、カテゴリ、メディア

記事と、読者が記事を利用するために必要なすべての要素との関連性を維持することが重要です。例えば、インストールガイドはスクリーンショットがなくなると価値が下がりますし、トラブルシューティング記事は添付のPDFファイルがないと不完全になる可能性があります。.

カテゴリについては、プラットフォームによって記事の整理方法が異なる場合があるため、もう少し慎重に検討する必要があります。古い構造をそのままコピーするのではなく、ソースカテゴリを移行先の別のカテゴリやフォルダにマッピングすることができます。Help Help Desk Migration 対応しています サポートされているプラ​​ットフォームの組み合わせにおいて、このようなマッピングに加え、インライン画像や添付ファイルにも

翻訳および多言語コンテンツ

翻訳は個別に確認してください。プラットフォームによっては、元の記事と一緒に翻訳を移行できるものもありますが、デフォルト言語のコンテンツしか移行できないものもあります。.

両方のプラットフォームが翻訳をサポートしている場合でも、ソースでの翻訳の保存方法が重要になります。 Help Desk Migrationたとえば、 言語バージョンを移行 。IDが一致しない場合は、デフォルトバージョンのみがインポートされます。

著者、メタデータ、およびカスタムフィールド

メタデータとアクセス設定を再作成する前に、現在も使用している設定を決定してください。チームによっては、記事の作成者、ステータス、タグ、カスタムフィールド、または表示設定に基づいて、コンテンツの閲覧や公開権限を管理している場合があります。.

残しておきたい項目を確認し、その情報を新しいシステムでどこに配置できるかを検討してください。中にはすぐに一致する項目もあるでしょうが、カスタムフィールドを作成したり、適切なマッピングのために多少の作業が必要になる項目もあるかもしれません。.

ナレッジベース統合プロジェクトの計画方法

まず、既存の知識ベースをすべて監査します。

統合を予定しているすべてのナレッジベースについて、包括的なインベントリを作成します。各記事のURL、ステータス、言語、カテゴリ、最終更新日、所有者、リダイレクト、添付ファイルを記録し、トラフィックデータや利用状況データ（もしあれば）を追加します。.

各記事に関連する情報もすべて含めてください。翻訳、内部リンク、読者が手順に従うために必要なファイルや画像などを記録しておきましょう。これらの詳細は、後で新しいナレッジベースでコンテンツがどのように機能するかを確認する際に必要になります。.

目的地のプラットフォームを選択する

在庫リストには、検討中の各プラットフォームに対して確認すべき項目が記載されています。現在使用しているコンテンツと構造を確認し、プラットフォームがカテゴリ、翻訳、権限、および維持したいフィールドに対応できるかどうかを検討してください。特に、置き換えが難しいと分かっている項目には注意を払いましょう。.

統合前にコンテンツの重複排除と標準化を行う

ナレッジベースの記事を統合する際には、重複する記事をどうするかを決める必要があります。あるバージョンには既に保持すべき情報がすべて含まれているかもしれませんが、最新版が最も正確であるとは限りません。最終的な記事には、複数のバージョンの情報が必要になる場合もあります。.

移行パスによっては、ナレッジベース全体を移行するのではなく、不要なコンテンツだけを残すことができます。 Help Desk Migration時に、カテゴリ、セクション、または日付範囲で記事をフィルタリングできます FreshdeskからZendesk 移行。

各記事の出典がまだ分かっているうちに、用語やカテゴリを整理しておくのも良いでしょう。統合されたナレッジベースで使用する名称を決定し、移行対象として選択したコンテンツに適用してください。.

手順：プラットフォーム間でナレッジベースコンテンツを移行する

移行前

まずは、問題が発生しやすい記事から始めましょう。例えば、ネストされたカテゴリ、特殊な書式設定、インライン画像、添付ファイル、または移行先に明確な対応関係がないフィールドを含む記事などです。次に、移行後のバージョンと元のバージョンを比較して、正しく移行された部分とそうでない部分を確認します。.

Help Desk Migration を使ってこれを実現できます デモ移行機能。ランダムサンプルを使用することも、最大20件の記事を自分で選択することもできます。これは、どの記事が移行に困難を伴う可能性があるかを既に把握している場合に便利です。

移動中

移行に伴ういくつかの問題が予想されます。

移行レポートには失敗したレコードとスキップされたレコードが表示されますが、残りのレコードについては移行済みのコンテンツを確認する必要があります。.

その他の問題は、移転自体が成功したように見える場合があるため、予測がより困難です。

• フィールドによって動作が異なります。送信先は値を受け入れますが、解釈の仕方が異なります。
• HTMLが変更されると、記事が最初は問題なく表示されていても、表、アンカー、埋め込み要素、またはコードの書式設定が崩れる可能性があります。
• API制限により移行が遅くなる。小規模なテストは制限内に収まる可能性があるが、本格的な移行は制限される。
• 自動化機能はインポートされたレコードに反応します。移行されたコンテンツが移行先で受信されると、通知、ワークフロー、Webhook、またはその他のプロセスが実行される場合があります。
• 検索結果は変更される場合があります。同じコンテンツでも、リンク先によってインデックスの仕方が異なるため、一部の記事が見つけにくくなることがあります。

移行先のAPI制限を確認し、インポートされたレコードが自動化処理をトリガーした際に何が起こるかを確認することで、これらの問題の一部に備えることができます。フォーマットと検索は予測が難しいため、完全移行する前に、移行したコンテンツで両方を試してみてください。.

移行後

移行が完了したら、ソースと宛先を比較して、既に失敗またはスキップされたレコード以外に不足しているものがないか確認してください。複数のソースからのサポートドキュメントを統合するために移行を使用している場合は、移行の実行中に追加または更新されたコンテンツも取り込む必要があります。.

では Help Desk Migration、 デルタ移行機能により 、サポート対象レコードに対する後からの変更に対応できるため、移行全体を繰り返す必要がありません。ナレッジベースコンテンツにデルタ移行機能を利用する前に、ソースと移行先でデルタ移行がサポートする内容を確認してください。

最後に、切り替え後もしばらくの間は古いナレッジベースを利用できるようにしておきましょう。古いリンクが機能しなくなったり、コンテンツが見つからないという報告があったりした場合、元の情報源を確認することで、リンク先を迅速に修正できます。.

統合はSEOランキングに悪影響を与えるのか？

記事の統合によってURLが変更になった場合、しばらくの間、ランキングが変動する可能性があります。Googleは新しいURLを見つけてクロールする必要があり、 ランキングが多少変動するのは正常なことです 。しかし、古いURLをどう扱うかの方がより重要です。

統合されたソース間でURLとリダイレクトを保持する

複数の記事が1つに統合される場合、同じ新しい記事に対して古いURLが残ってしまうことがあります。例えば、別々のナレッジベースから類似した3つの記事を統合した場合、たとえ一部が別のプラットフォームやドメインからのものであっても、それぞれのURLは統合されたバージョンにリダイレクトされる必要があります。.

Googleは、 301や308などの恒久的なサーバーサイドリダイレクトを推奨しており、これらはPageRankの低下にはつながらないと述べています。古いURLは、別のリダイレクトを経由するのではなく、新しい宛先に直接アクセスするように設定する必要があります。

ナレッジベース内のリンクについては、より細かく制御できます。リンク先を新しいURLに直接設定し、バックリンク、ブックマーク、および管理していないサイトのリンクについてはリダイレクトに任せましょう。カノニカルタグ、hreflangアノテーション、サイトマップについても同様です。古いURLが含まれている場合は、新しいURLに置き換えてください。.

新しいナレッジベースが公開されたら、Search Console で Google が引き続きクロールしている古い URL、インデックス登録されていない新しいページ、クロールやインデックス登録のエラーなどを確認すると良いでしょう。Google によると 、小規模または中規模のサイトのほとんどのページがインデックスに登録されるまでには数週間、大規模なサイトではさらに時間がかかる場合があるとのことです。そのため、Google が URL を再クロールして新しい URL にシグナルを転送する時間を確保するために、リダイレクトは少なくとも 1 年間は維持してください。

ナレッジベース統合のリスクとその回避方法

統合作業を進める中で、データの損失、リンク切れ、重複記事や矛盾記事といった問題に既に遭遇しました。それでは、どのような問題が発生する可能性があるのか​​、そしてそれらにどう対処すればよいのかを詳しく見ていきましょう。.

データ損失と破損

データ損失の一部は、配信先自体の制限によって発生します。プラットフォームによっては、記事のサイズ、添付ファイル、カテゴリの深さ、または知識ベースのその他の部分が制限されている場合があり、一部のフィールドが全く利用できない場合もあります。.

本格的な移行を行う前に、移行元と移行先それぞれの制限事項と移行に関する注意事項を必ず確認してください。これらの制限事項は驚くほど詳細な場合があります。プラットフォームによっては、記事の日付が移行日に変更される場合や、タグ、添付ファイル、その他のデータを移行するためにカスタム移行が必要になる場合があります。.

壊れたクロスリンク

記事間のリンクは、移行先で新しいIDが付与されると切れてしまうことがあります。一部の移行ツールは、これらのリンクを自動的に更新できます。例えば、 Help Desk Migration、サポートされている移行中に内部リンクと相互参照を自動的に更新します。.

移行が完了したら、新しいナレッジベースをクロールして、リンク切れがないか確認してください。翻訳された記事や記事のHTML内のリンクは見落としやすいので、別途確認してください。.

重複または矛盾する記事

移行前にコンテンツを整理したとしても、重複が発生する場合があります。統合しようとした2つの記事が別々の記事として移行されたり、移行したコンテンツが移行先の既存のコンテンツと重複したりする可能性があります。.

統合したトピックを新しいナレッジベースで検索し、結果を比較してください。この段階では、移行中に発生した重複がないかを確認します。ソースで見つかった重複は既に処理済みです。.

統合チェックリスト

すべてを手作業で確認する必要はありません。一部の決定には内容を熟知した担当者が必要ですが、エクスポート、移行レポート、クローラーなどを使えば、多くのチェック作業を自動化できます。.

結論

優れたナレッジベース統合は、必ずしもすべてのコンテンツを1つのシステムに集約することで終わるわけではありません。一部のコンテンツは現状のままにしておく方が良い場合もありますが、残りのコンテンツについては明確な移行先と、移行時にその構造、リンク、その他のデータがどのように扱われるかについての計画が必要です。.

これらの決定が済んだら、 Help Desk Migration がサポート対象プラットフォーム間のデータ移行を処理できます。 デモ移行機能 コンテンツがどのように移行されるかを確認できます。

よくある質問

執筆者

クヴィトスラヴァ・マルツィニシン

コンテンツマーケティングマネージャー、 Help Desk Migration

クヴィトスラヴァはコンテンツマーケティングマネージャーとして、 Help Desk Migrationに関するマーケティング活動を推進しています。彼女は包括的なガイド、チェックリスト、ランディングページを作成し、技術的な移行プロセスを分かりやすく、価値重視のメッセージに落とし込んでいます。.