ナレッジマネジメントの企業事例。成功3社に共通する設計と失敗の分かれ目

運営者プロフィール

加藤晃寿郎（株式会社taiziii 代表取締役）。慶應義塾大学経済学部出身のエンジニア。在学中のスタートアップ設立、フリーランスを経てシステム開発会社を創業。企業のAI導入支援と、判断継承AIプラットフォーム「SkillRelay」の開発に従事。

1位

Amazonベストセラー獲得

著書『AI時代の経営デザイン』

データベースカテゴリ、2025年10月時点

「その事例、どこに載っていた話ですか」。社内で他社の取り組みを紹介したときに、こう聞かれて答えに詰まったことはないでしょうか。

ナレッジマネジメントの進め方を決めるとき、まず他社の成功例を集めるのは自然な順序です。事例は企画や稟議の材料になりますし、検索すれば紹介記事も数多く見つかります。

ところが、読めば読むほど自社との距離が開いていきます。人数も予算も違う。成果が出たという結論は並んでいても、その会社が何を決めたから成果が出たのかまでは書かれていません。事例を何十社分読んでも、自社で何から始めるかは決まらないままになります。

事例から持ち帰るのは、企業名でも数値でもなく、仕組みに何を入れ、何を仕組みの外に残したままにしたかという構造です。今回取り上げるのは、良品計画・花王・トヨタ自動車の3社。3社に共通する成功の構造を3点に整理し、実名では出てこない失敗事例の読み方と、自社に移すときの読み替え方までを順に示します。用語の定義や全体像は、別記事「ナレッジマネジメントとは何か」で整理しています。

成功事例3社。手段は紙から生成AIまで違う

取り上げる3社は、公開時期が2019年から2024年までにわたり、手段も紙のマニュアルから生成AIまでさまざまです。

良品計画。MUJIGRAM約2,000ページは業務の仕組みとして位置づけられている

良品計画（無印良品）は、店舗業務の標準化を徹底した事例として知られています。当時の会長である松井忠三氏の記述によると、店舗で使うマニュアル「MUJIGRAM」は約2,000ページ、本部の業務基準書は6,000ページ超にのぼります。個人のやり方に任されがちな業務を、会社の標準として文書化した形です。

出典　松井忠三『無印良品の教え』（角川新書）の抜粋記事・プレジデントオンライン・2021年11月29日 https://president.jp/articles/-/52255 ／サービス産業生産性協議会（松井元会長インタビュー）・2015年 https://www.service-js.jp/activity/structure/muji/

注目したいのは分量そのものではありません。約2,000ページという分量は、放っておけば誰にも読まれない文書になってもおかしくありません。それでも使われ続けているのは、マニュアルが個人の工夫ではなく、業務のやり方を定める文書として位置づけられているからだと読めます。担当者が自分のやり方を覚えているのではなく、会社の標準として文書に書かれている状態です。この点が、後述する成功の共通項の1つ目にあたります。

花王。顧客の声をため込まず当日中に使う側へ渡す

花王は「花王エコーシステム」の名称で、お客さまから寄せられた全ての声をその日のうちに入力する仕組みを公開しています。入力された声は、マーケティング・商品企画・研究・生産・品質保証などの各部門が日々確認し、改善を検討します。

出典　花王公式サイト（サステナビリティ）・2026年閲覧 https://www.kao.com/jp/corporate/sustainability/topics-you-care-about/safety-quality/improve/

この事例で目を引くのは、いつ入力し、誰が確認するかが最初から決まっている点です。声が入力されるのは当日中、確認するのは各部門、確認の頻度は日々と、情報が動く道筋が仕組みとして定められています。集めた声をため込んでから分析するのではなく、集めたその日に使う側へ届ける設計です。ナレッジマネジメントというとデータベースへの蓄積を思い浮かべやすいのですが、花王の仕組みは集めた情報をその日のうちに使う側へ渡すところに重心があります。

トヨタ自動車。9つのAIエージェントはどの疑問をどこへ尋ねるかで分けてある

トヨタ自動車はMicrosoftと共同で、生成AIエージェント「O-Beya」を構築しました。Azure OpenAI Serviceを活用して構築された基盤の上で、エンジンや法規など9つのAIエージェントが稼働し、熟練エンジニアの知見の継承を狙う取り組みです。

出典　Microsoft News Center Japan・2024年11月20日 https://news.microsoft.com/ja-jp/features/241120-toyota-is-deploying-ai-agents-to-harness-the-collective-wisdom-of-engineers-and-innovate-faster/ ／Car Watch・2024年 https://car.watch.impress.co.jp/docs/news/1640801.html

この事例の特徴は、対象が定型の手順ではなく、熟練者の知見という言葉にしにくい領域に置かれていることです。エージェントがエンジンや法規といった領域別に分かれている構成からは、どの業務の疑問をどこに尋ねるかを想定した設計がうかがえます。一方で、公表されているのは仕組みの構成と狙い、それに運用規模までです。2024年1月の運用開始以降、パワートレーン関連の開発に携わる約800人のエンジニアが使える状態にあり、月間の利用回数は数百回とされています。継承がどれだけ進んだかを示す成果の数値は出ていません。AIを入れれば知見が継承できる、と読むのは早すぎます。成果が公表されるまでは、どの領域の疑問をどこへ尋ねるかという設計のほうを参考にするのが妥当です。

成功の共通項。3つとも「貯め方」の話ではない

3社の手段は、紙のマニュアル、顧客の声を各部門へ届ける仕組み、生成AIとばらばらです。それでも3社を並べると、共通する設計が3つ見えてきます。どこに何をどう貯めるかという話は、この3つに含まれません。

経営の位置づけ。業務プロセスの中に組み込まれている

1つ目の共通項は、ナレッジマネジメントが業務と別立ての活動になっていないことです。良品計画のMUJIGRAMと業務基準書は、業務のやり方そのものを定めた文書であり、業務の傍らで任意に書くノウハウ集ではありません。花王のエコーシステムでは、各部門が声を確認して改善を検討する工程が日々の業務に入っています。トヨタ自動車のO-Beyaも、有志の実験ではなく熟練エンジニアの知見継承という会社の課題に対して構築されたものです。

裏返すと、知識の共有を現場の善意に任せ、業務時間の外で書いてもらう形はこの共通項から外れます。事例を参考にするなら、最初に確かめたいのは自社でナレッジの入力や確認が業務として認められているかどうかです。

更新の仕組み。書いた時点ではなく使う時点の正しさを保つ

2つ目の共通項は、情報を新しい状態に保つ工程が仕組みに入っていることです。文書は書いた時点から古くなり始めます。制度や商品が変われば、書かれた内容と現実の間にずれが生まれます。古い情報が残ったままだと、参照した人が現行と違う手順で対応してしまい、やがて文書そのものが当てにされなくなります。

3社の中でこの点が最も分かりやすいのは花王です。顧客の声はその日のうちに入力され、各部門が日々確認します。情報が入る頻度と確認する頻度の両方が高く保たれているため、古い情報にもとづいて検討する余地が小さくなっています。

自社に引き付けるなら、書く仕組みより先に直す仕組みを確かめるのが実際的です。文書ごとに更新の責任者はいるか。最終更新日は読み手に見えるか。更新が止まった文書を見直す機会はあるか。この3点が決まっていない蓄積は、時間の経過とともに参照されにくくなります。

使う場面の設計。誰がいつ開くかが先に決まっている

3つ目の共通項は、知識を使う場面が蓄積より先に設計されていることです。花王では、確認するのは各部門、頻度は日々と決まっています。トヨタ自動車のエージェントはエンジンや法規と領域で分かれ、どの業務の疑問をどこに尋ねるかの対応が付いています。

使う場面が決まっていれば、何をどの粒度で残すべきかも決めやすくなります。順序が逆になり、まず貯めてから使い道を考える進め方を取ると、誰も開かない文書が積み上がりがちです。導入の企画段階で、誰が・どの業務の・どんな場面で開くかを具体的に1つ書き出せるか。書き出せないまま進めると、蓄積だけが先行して使う場面は後回しになります。

失敗に共通するのは貯めたまま業務に反映されない状態である

共有の仕組みを入れたのに定着しなかったという失敗談は、細部が違っても行き着く先は似ています。成功の共通項3つの裏返しにあたります。ただし、原因が1つに絞れるという意味ではありません。書く時間が業務として認められない、更新の責任者がいない、使う場面が決まっていないといった要因が重なって、結果として貯めるだけの状態に落ち着きます。

実名の失敗事例が出ないのは動機の問題。匿名の失敗談は構造で読む

成功事例と違い、ナレッジマネジメントの失敗が社名入りで公開されることはほとんどありません。うまくいかなかった経験には対外的に発表する動機がなく、公表すればツールの提供元や社内の関係者にも影響が及びます。その結果、失敗談は「A社では」「ある企業では」といった匿名の形でしか流通しません。匿名の失敗談は、実在の事例なのか典型例をまとめた作り話なのかを確かめようがありません。

だからといって、失敗から学べないわけではありません。匿名の失敗談を読むときは、個別の話の真偽ではなく構造に注目します。多くの失敗談は、書かれない（投稿が集まらない）・検索されない（あっても探されない）・使われない（見つかっても業務に反映されない）の三段のどこかに位置づけられます。出所の分からない失敗談を集めるより、この三段構造で自社の状態を点検するほうが実務に役立ちます。三段のそれぞれで何が起きるかは、別記事「ナレッジ共有が進まない理由」で詳しく扱っています。

貯めても再現されないもの。判断はどの事例でも仕組みの外に残る

成功事例を読むときに見落としやすいのは、仕組みに入っていないもののほうです。ナレッジマネジメントの仕組みに入るのは、手順書・規程・FAQ・顧客の声といった、言葉やデータになった知識です。良品計画のマニュアルは手順を、花王のエコーシステムは顧客の声という事実を扱います。一方、ベテランが例外的な場面でどちらを選ぶか、なぜ標準と違う対応を認めるかといった判断の基準は、本人も言葉にできていないことが少なくありません。書いてくださいと頼んでも、そのままでは文書にならない領域です。言語化される前の判断は、どの事例の仕組みでも保管対象の外に残ります。

トヨタ自動車のO-Beyaが熟練エンジニアの知見の継承を狙いに掲げているのは、まさにこの領域への取り組みです。ただし公表されているのは仕組みの構成までで、判断の継承がどこまで進んだかは公表されていません。

貯めるだけで終わった経験は、「ナレッジマネジメントはもう古い」という評価につながることがあります。ただ、問題は手法が古いことではなく、扱う対象を取り違えていることです。手順や規程のような管理する知識に対して仕組みは機能しており、判断のように仕組みの外にある対象が課題として残っているだけです。

事例を自社に移すには2つの読み替えが要る

規模ではなく構造をまねる。3つの共通項を自社の問いに置き換える

3社と自社では、人数も予算も扱う知識の量も違います。まねる対象を数値や仕組みの規模に置くと、大企業だからできたという結論で止まりがちです。移すべきは、3つの共通項がそれぞれの会社でどう業務に組み込まれているかという形のほうです。次の表では、右列に共通項を自社へ向けた問いとして置き換えています。

右列に1つでも答えられない問いがあれば、事例やツールの調査を広げる前に、そこを決めるほうが先です。3つとも、1部署・1業務の範囲からでも決められます。

手順の共有か判断の継承か。対象を分けてから始める

最後に、扱う対象を2つに分けておきます。1つは手順や規程、FAQのような、言語化済みか言語化しやすい知識です。この領域は3社の事例が示すとおり文書化との相性がよく、wiki型やマニュアル型のツールが有効に働きます。もう1つは、例外時の線引きやベテランの判断基準のような、言語化される前の知識です。こちらは置き場所を用意するだけでは集まりません。質問で引き出し、誰の・どの条件での判断かという帰属を保ったまま、条件付きのルールに変換する別の工程が必要になります。複数のベテランで判断が食い違う場合も、平均して1本にまとめるのではなく、それぞれの判断を条件ごとに分けて残します。

自社の課題がどちらの領域にあるかを分けてから始めると、事例の選び方もツールの選び方も絞り込めます。手順の共有が課題なら、ツールの比較検討に進めます。判断の継承が課題なら、ツールの機能一覧より先に、誰のどの判断を残すかの特定が出発点になります。

よくある質問

中小企業の参考になるナレッジマネジメント事例はあるか

この記事で扱った3社は大企業ですが、参考にする対象を構造に置けば規模の差は障害になりません。花王の仕組みから学べるのは規模ではなく、入力の期限と確認の頻度を決めるという設計です。同じ設計は、営業日報を翌朝の打ち合わせで確認するといった小さな運用でも再現できます。中小企業では、対象の業務と使う場面を1つに絞って始めやすい分、構造をまねる条件はむしろそろえやすいはずです。

事例で紹介されている数値は自社でも見込めるか

事例の数値を、自社で見込める効果の根拠に使うことはできません。良品計画の約2,000ページという分量も、同社の店舗数・商品数・オペレーションを前提にした結果です。導入時期も体制も違う組織の見積もりに、そのまま流用できるものではありません。事例の数値が参考になるのは、効果を測る指標の例としてです。利用者数・利用頻度・削減時間など、自社で何を測って取り組みを評価するかを決める材料にはなります。

SECIモデルは事例を読むときに役立つか

SECIモデルは、知識がどう共有され形式知になっていくかを整理する地図としては役立ちます。良品計画のマニュアル化や花王の声の共有は、野中郁次郎らが提唱したSECIモデルの言う表出化や連結化の観点で整理できます。一方でSECIモデルは知識の変換を扱う枠組みであり、この記事で残る課題とした判断の基準、つまりなぜそうするかは4つの段階のどこにも直接は乗りません。事例の整理にはSECIモデルを使い、判断の継承は対象の違う別の課題として分けて考えると混乱なく読めます。

失敗事例をもっと詳しく知る方法はあるか

社名入りの失敗事例集は、公開される動機が乏しいため今後も期待しにくいのが実情です。確実に調べられる失敗事例は、自社と身近な組織の過去にあります。以前導入して使われなくなった共有ツールや、更新が止まったマニュアルは、匿名の失敗談より詳しく検証できる一次情報です。いつから書かれなくなったか、検索はされていたか、最後に業務で使われたのはいつかをたどると、書かれない・検索されない・使われないのどこで止まったかを特定できます。

事例から持ち帰るのは構造と自社への問い

3社に共通していたのは、知識をどう貯めるかの工夫ではなく、業務のどこで使うかを先に決めていたことでした。

• 取り上げた3社は良品計画・花王・トヨタ自動車。手段は紙のマニュアルから生成AIまで違う
• 成功の共通項は経営の位置づけ・更新の仕組み・使う場面の設計の3つで、貯め方の工夫ではない
• 失敗は実名で公開されにくい。匿名の失敗談は書かれない・検索されない・使われないの三段構造で読む
• どの事例でも、言語化される前の判断は仕組みの保管対象の外に残る
• 自社に移すときは規模ではなく構造をまね、手順の共有か判断の継承かで対象を分けてから始める

事例は答えの一覧ではなく、自社で確かめる問いを引き出すための参考資料です。3社の名前や数値を覚えることより大切なのは、3つの問いを自社に向けることです。入力と確認は業務に入っているか。更新の責任者はいるか。誰がいつ開くかを言えるか。この3つが次の一歩につながります。