2012年に Google が検索エンジン結果ページ (SERPs) に Knowledge Graph を導入したとき、それに伴うフィーチャードスニペット（ページの最上部に表示される短い関連データポイント）は、迅速な答えを求める人々の頼りにされる存在となりました。 Wikipedia のようなサイトからのデータを大いに活用することで、Google は他者が編纂したデータを活用し、自社のエコシステムにユーザーを留めることができました — 広告収益に依存するビジネスにとっては大きな利点です。 しかし、もう一つ別のことが起こりました: Wikipedia へのトラフィックが減少しました。 統計学者が私たちに 相関関係は因果関係を示唆しないと再確認する権利があるにせよ、私たちの行動を振り返ることで何が起こったのかを知ることもできます。 もしあなたが知りたいのが、たとえば、今年のノーベル物理学賞を受賞したのは誰なのか、そしてその答えがページの最上部にあるなら、他の 1億500万 件の結果を探し続ける必要はありません。

私たちは本能的にこれを知っていますが、知識ポータルに関しては、しばしばそれらをリポジトリとして設定しており、必要な情報を簡単に浮き上がらせる手段として機能していません。 それが理由です — これは聞くのが難しいかもしれませんが — 私たちは全体的なアプローチを完全に再考する必要があります。

もしあなたの企業の知識ポータルがほとんどのものと同じであれば、質問があるとき、あなたは a) 自分が正確に何を探しているのかを知っている必要があります、または b) 数百（または数千！）の単語を含むマルチページの FAQ や PDF の中から埋没した回答を探す必要があります。

Control-F はこのセットアップを機能させるために不可欠でしたが、なぜあなたは単純な回答を得るために実質的に迂回策を使わなければならないのですか？ それは、従業員に知識を掘り出させる負担をかけさせるだけでなく（これはかなりの時間を取る可能性があります）、その知識に何か変更があるたびに、会社はまったく新しい PDF、ビデオ、または FAQ をアップロードしなければならないことを意味します。 それは時間と予算を無駄にします。

より良い解決策は、知識アーキテクチャを根本的に再考し、短くて、消費しやすく（そして更新可能な）、明確な知識の断片に移行することです。

検索と救出

「ほら、それほど悪くない」とあなたは今言っているかもしれません、「それは仕事をこなしています！」 それについて話しましょう。 これは Guru ブログでこの話をしたのは初めてではありません。 ほぼ三年前に、私たちはその点を指摘しました:

営業職の人々は、仕事内容に必要な情報を探すのに、最大で1日の三分の一を費やしています。 情報は即時に求められ、現在の解決策はオンデマンドの世界のために作られていません。 ドキュメントやウィキはあなたに Control+F を使わせて、単語を探させ、その後に答えを組み立てさせます。

もし顧客とチャットしていて、質問に答える必要があるとき、現在の長く非効率的なプロセスを通じて答えを探す時間はありません。 正しい答えを持つドキュメントを探して、それを開き、キーワードを検索し、そして最終的に、自分が入力した単語が15回表示されるのを見ます。 正しい情報を得るには、すべてのオプションをクリックしなければなりません。その間、顧客は答えを待っています。

しかし、それは貴重な秒を無駄にするだけではありません。 長いコンテンツは短いコンテンツよりも検索が難しくなります。 これを知識管理の領域から外し、私たち全員が関連できる分野に移しましょう: 娯楽目的でコンテンツにどのように関与するか。

あなたが知っているかどうかわからない質問があります: ザ・シンプソンズ の初演は何年でしたか？ あなたは Wikipedia を引き出し、「ザ・シンプソンズ」と入力すると、このページが17,000語以上表示されます。 あなたは古い依存である Control-F に依存し、「初演」と検索すると、次のことが起きます:

え、何? 結局のところ、「リリース」を検索する必要がありました:

あなたはこの（非常に整理された、私たちが指摘すべき）ページがどのように設定されているのか、また、著者が開始日を示すために使用した正確な用語を知っている必要がありました。 その間、Google に移動して「シンプソンズ初演」を入力すると、次のような結果が得られます:

「シンプソンズ リリース」を検索すると、同じ情報が得られますが、プレゼンテーションが少し異なります:

どちらにしても、結果は役立ち、迅速で、最も重要なことは、使用した正確な言い回しに関係なく見つけやすいということです。 Control-F を使用する必要すらありませんでした。

まだ探しているものが見つかりません

さて、この議論を再び知識管理に戻しましょう。 あなたの詰め込まれた10ptフォントの3ページのPDFや48項目のFAQは素晴らしい — 印刷コストを節約するために。 それらは、従業員が知る必要がある内容に正確に集中するためには最適ではありません。新入社員の福利厚生情報、製品の立ち上げ時のマニュアル、または配布する正しいワンシートを見つけることについて話しても。

面白いことに、知識をデジタル化するほど、私たちは実際に何を見つけるのかに集中するために迂回策に頼らなければならなくなりました。 あなたの若き日の非常に嫌われていた教科書？ 索引は、あなたが最も良い時間を過ごした部分でした。 ついにはそれは、あなたが必要な情報を正確に見つける場所を教えてくれました — あなたが必要のないものを無視するために — そして、通常は（例: 月面着陸、ソ連の反応など）文脈の分解も含まれていました。

今は？ 私たちは、コンピューターや AI がより効率的にできる仕事を自らに強いています。 知識を一口サイズのチャンクに保存することは、文脈に応じた検索をはるかに迅速に行えるようにします。 多くの企業が、企業検索における機械学習とAIの能力について話していますが、それらの解決策は、従業員が大量の文書を検索しなければならない場合には無意味です。

もし、文書が印刷用に設計されていないのなら、個々のコンポーネントに分解して、より良い知識参照体験を得る理由はありません。 さもなければ、会社としては、「セキュリティ」という単語が製品文書で強調表示された50か所を検索する手動作業に従業員に対して支払っているかもしれません — それでも彼らは、Control-F 検索により文脈を追加できずに、探しているものを見つけられないかもしれません。

このアプローチは、知識を追加し維持する人々だけに利益をもたらすだけでなく、収益チームにも大いに役立ちます。 営業担当者が取引を締結しようとしているとき、彼女が特定の情報に即座にアクセスできることを望みますか、それとも... 45項目の営業準備文書で探すことを望みますか？ もしあなたのカスタマーサポート担当者が怒りの電話を受けた場合、彼が答えを見つけるためにFAQを必死にスキャンしていることを望みますか、それとも彼が関連するセクションだけを引き出す力を与えますか？

持続可能な知識基盤の構築

私たちは、一口サイズの知識カードが私たちに役立つことを見てきたので、それらがあなたにとっても同様に機能することができると信じています。 それは、あなたが本当に必要な情報を見つけるのを早く、簡単にするだけでなく、知識の維持がはるかにシンプルであることを意味します。 包括的な企業全体の知識管理システムの採用による利点についてもっと知る。

短い形式の知識ベースアーキテクチャへのアプローチを実施することで、常に完全に新しい文書をアップロードする必要がなくなります。 20ページのドキュメントに1つの文の更新があると、それ全体を再アップロードし、その変更が12ページの9番目の箇条書きに埋まっていることをすべての人に知らせる必要があります。

逆に、4文の知識の断片に1文の更新を行うと、数秒ですぐに実行できるのです。 このアプローチは、より長いドキュメントを検証するよりも、正確性を確認するために一口サイズの情報を確認する方がはるかに簡単になります。各知識の断片は個別に正しいかどうか検証でき、検証は最終的には誰もが信頼できる知識ネットワークを作る核心です。

確かに、これは皮肉なことに、知識アーキテクチャに関するより良いアプローチを説明するために多くの言葉を使っていますので、ここでの要点は短いコンテンツを追加する方が簡単、更新する方が簡単、検証する方が簡単、検索する方が簡単です。 それを語彙フラッシュカードと辞書のようなものと考えてください: 一つはすべて持っていますが、来週の試験の準備には役立たないでしょう、もう一方は試験を通過するために必要なものであり、ミッドタームや期末のために強化され、無限に異なる方法で再編成できます。 あなたはどちらを選びますか？