オンライン上に学習コミュニティを作るその２| 実践コミュニティ | 正しい「デジタル学び舎」の作り方 | オンラインコミュニティの運営・ソーシャルラーニング向けLMSなら「フローパッド（FlowPAD®）」

学習コミュニティを作る　その２

テレビ番組で面白い特集を組んでいました。
「さよなら、失敗するワタシ～失敗学最新事情～」2015年4月5日放送（NHK「さきどり」）
番組中では、失敗を経営に活かす取り組みとして、部品メーカー「太陽パーツ」で行っている「大失敗賞」の事例を紹介していました。

「大失敗大賞」

とは、社内においてチャレンジしたけど大失敗した社員を半年に一回表彰するユニークな制度です。

同社社長によれば、会社のモットーである「チャレンジ精神」があだになり、社員が引き起こした大失敗で、経営が大きく揺らいだこともあったのとこと。

ただし、失敗した社員にペナルティを与えてしまっては、「チャレンジ精神」が単なるかけ声になってしまう事を懸念。そこでひねり出した手が、失敗した社員を表彰し、賞金まで出してしまうという逆転の発想でした。

社長「ピンチをチャンスに変えるにはどうしたらいいのか？うちはそんなことでおじけづいたり、怒ったりしないよと。もう一回これにめげずにチャレンジしようやと、彼に対するメッセージでもあるし、全社員に対するメッセージにしたかったんです。」

この制度によっては、社員のチャレンジ精神はその後も維持され、そのきっかけを作った社員さんは、中国上海支社長として活躍されているそうです。いい話ですね。

表彰制度の効果（武勇伝を伝える）

これらの表彰制度の面白い点を「ストーリーの共有」という観点から見てみると、その本当の効果が見えてきます。

それは、表彰された経緯について、表彰者がみんなに伝える機会があり、それによって、「武勇伝」が社員間で自然にシェアされるという事です。

通常、失敗談は「恥ずべきこと」として隠される事がほとんどですので、その詳しい経緯は関係者しか知りません。

ただその失敗が、よく現場で起こりがちな判断ミスによるものだとしたら、その経験自体が貴重な価値と言えます。見方を変えれば、会社は社員に投資して失敗という貴重な情報を手に入れた訳で、それは明らかに「知的資産」なのです。それを活かさない手はありません。

その意味で失敗を表彰してそのストーリーを共有するのは極めて意味が大きいのです。

このストーリーの力をうまく活用しているのがリクルート社です。

リクルートでは社員の表彰制度があり、表彰された人は「なぜ自分は成功したのか」をみんなの前で雄弁に語る事が半ばルールになっています。ところがその話が面白くないと、

「ダサい！」

という烙印を押されるため、表彰された人（＋その人の上司）は感動のストーリーを必至に考えるとの事。

そして面白いストーリーには「主人の旅立ち」「試練」「葛藤」「勝利」「帰還」といった要素が必須であり、そのようなストーリー（物語）を通じて、ビジネスのエッセンスが効果的に社内にシェアされる環境を作り出しているのです。

武勇伝で語られるストーリー

ストーリー共有の重要性については、ゼロックスのパロアルト研究所の研究員で人類学者のジュリアン・オーアが、著書

「Talking about Machines(機械について語る)」

で詳しく分析しています。

オーアは、同社のコピー機の修理工たちがどのように情報交換しているのかを詳細に研究しました。

そして彼らが仕事に必要な知識を得ているのは、会社の研修でもマニュアル本ではなく、仲間からの

「武勇伝（War Story=戦いの物語）」

であることを発見しました。

修理工たちはカフェテリアに集まり、自分が担当しているコピー機を怪物に見立て、いかに自分が戦ったか（修理したか）を語り合います。その話を聞いて、他の同僚が質問したり、自分の経験を付け加えたりしながら武勇伝を共有する事で仕事に必要な情報を得ていたのです。(ちょうど原始時代にたき火を囲んで、狩りについて語り合っているイメージです）

もちろん武勇伝は１００％正確な情報ではなく、場合によっては誇張されているかも知れません。

またあくまで日常会話の延長線上なので、その話に誰が責任も持つわけでもなく、聞いている人も詳細までは覚えている訳でもありません。

しかしそのような武勇伝を通じて、

自分が同じような問題に直面したときに誰に相談すれば良いか(Know-WHO　ノウフー)、

そして

自分が「怪物」と戦うときに、どんな手があるか(Know-HOW　ノウハウ)

についての重要なヒントを得ていたのです。

オーアは

「サービスマンはちょうど羊飼いの群れが羊一頭一頭を知っているように、担当のコピー機について熟知している」

と言います。同じコピー機に見えても、客先の使用条件によってコピー機にクセがあり、サービスマンはそれを熟知して修理するのですが、そのようなノウハウはマニュアルには一切載っていないのです。

このような理由から、社員が持っている知識（ナレッジ）を積極的に会社内で蓄積・共有しようという「ナレッジマネジメント」というコンセプトが重要視されるようになりました。

知恵を共有する挑戦

黎明期のインターネットを使って、もっともと「ナレッジマネジメント」に熱心に取り組んだのはコンサルティング会社でした。コンサルティング業界では、顧客にアドバイスする知識自体が商品となるため、過去に行った分析や、ベスト・プラクティス（成功事例）を社内で閲覧できるようにしておけば、似たような依頼を受けた際に役に立つと考えたからです。

併せて提案書のフォーマットも、全体構成や図解の方法、矢印の使い方や文字の大きさなどを決めておけば、サービスレベルを標準化することもできます。

経営コンサルティング会社のマッキンゼーでは

「Don’t reinvent the wheel (自動車を発明しようとするな)」

という言葉が標語になっていますが、まさにこれは社内の知識を十分活かせということを表しています。

ただし、このようなナレッジマネジメントが最初からうまく行った訳ではありませんでした。過去の提案書や分析データが役に立たない訳ではないが、それだけでは

「レシピの書いていないケーキカタログ」

と同じだったからです。

欲しいのは出来上がったレシピ（アイデア）ではなく、そのレシピを発想するための思考方法。しかし、それを学ぼうと思ったら、結果だけを見せられてもダメだったのです。それを考えだした本人の口から、現場でどんな会話が交わされ、どんな空気のなかで考えたのかという物語を聞くことで、はじめて発想の原点が分かります。

ところが、そうした生々しい体験談は文書に書かれる事は滅多にないのです。

この事が明らかになってから、人間臭いナレッジマネジメントが重視されるようになりました。

マッキンゼーではコンピューターを使った「PDネット(Practice Development)」と呼ばれるデータベースや、スタッフの業績や論文を小冊子にした「ナレッジ・リソース・ディレクトリー(KRD)」が作成される一方で、コンサルタント同士が連絡を取り合うための紳士録が整備されました。

「詳しいことが知りたかったら、直接本人に聞いてください」という訳です。

（まさに必要な情報について社内で知っている人がすぐに分かる「Know-HOW」データベースを作ったのです。）

さらに同僚のコンサルタントから電話やメールで問い合わせが来たときは、積極的に協力することが推奨される仕組みを作りました。

同僚が同じターゲット顧客を奪い合うライバル同士の関係であれば、ノウハウが共有されることは滅多にありませんが、知のネットワーク（トランザクティブメモリー）を会社の競争力の源泉と位置付け、それを積極的に推進する戦略をとったのです。

通常のシステムではうまくいかない

最近ではどんな企業でも知識の共有をすることが、サバイバルのためのキーになっています。そのために最先端のITシステムを導入し、社員全員でナレッジマネジメントを促進しようとしたにもかかわらず、失敗している例が無数にあります。

その原因としてありがちなのが、顧客データベースに下記のような入力フォームを設定してしまう事です。

・顧客名（　　　）
・訪問日（　　　）
・営業担当者（　　）
・案件規模（　　）
・結果（　　　）

　このような項目リストを作ってデータを入力すると検索しやすいというメリットはありますが、それが戦略的に活用される事はほとんどありません。

「高いお金をかけて導入したんだから活用するように」

と上司に言われて、みんな最初のうちはしぶしぶデータを入れてみるものの、そのうち売上管理ぐらいにしか使われなくなり、「戦略的活用」などは夢のまた夢になってしまうのです。　

通常データベースに自分の体験談を書いて、親しくない他人とシェアしようというモチベーションはなかなか沸かないものです。さらに不特定多数の人に読まれてもいいように書こうとすればするほど、主観的な判断やネガティブな情報はカットされます。そして結局は無機質で、無味乾燥な情報の寄せ集めになってしまうのです。

当然つまらないので、ほとんどの人は目を通しません。

さて、ここまで読めば、本当に役立つ生きた情報は、単なるデータではなく、血の通った「物語」で伝えられることが分かってきます。

失敗をどう活かすかという「失敗学」の研究で知られる工学院大学の畑村洋太郎教授によれば、失敗事例のデータベースには、通常は

「原因」「結果」「対策」

の３つしか記録されません。

たとえば、新型コピー機の商談で失敗したとすれば、「原因」は取引先の予算カットで、「結果」はコピー機導入の見送り、「対策」は先方の予算が下りるのを待つ、という情報しか書かれないのです。これでは第三者が読んでも、書かれていること以上の事は分からず、ほとんど失敗から教訓を得ることが出来ません。。

ただ下記のような情報を付け加えれば、他人が読んでもヒントが得られる「失敗知識データベース」になります。

事象：どのような事故、失敗が発生したのか
経過：どのように失敗が進行したか、ポイントは何だったか
推定原因：失敗を起こしたその時点で考えついた推定原因。その後、真の原因が明らかになった場合は追記する
対処：失敗に対してどんな応急処置をとったか
対策：再発を防ぐために行った、もしくは行うべき恒久的な措置
知識化：今後繰り返さないための教訓
背景：失敗発生の要因となった背景
後日談／よもやま話：類似の失敗や、失敗を後で振り返っての思いや、関連する話

畑村洋太郎「失敗学のすすめ」より

付き合いの長い会社であれば、コピー機導入見送りには、購入担当者の人事異動が影響している事をこっそり教えて教えてもらえるかも知れません。またライバル会社のコピー機販売手法について聞く事があるかも知れません。そのような情報をできるだけデータ化する仕組みにすれば、乾いたデータは知恵を含んだ「インテリジェンス」に変わります。

そして、このような「インテリジェンス」を実践者の間で共有する集団としての

「実践コミュニティ（Communities of Practice）」

の価値が、ますます注目されているのです。

ストーリーを共有する仕組み

ではそれがどうすれば可能になるかと言えば、TwitterやFacebookの成功をみれば分かります。毎日ちょっとしたエピソードが交換されているこれらのサービスを応用できれば、会社のデータベースでも生き生きした「物語」を交換するプラットフォームに作り替えることができるのです。(かといって、安易にFacebook会社版的なシステムを入れても、ほとんどの場合は失敗します）

前述のゼロックスは、まさに社員が持つ「物語」をデータベース上で共有するための「ユーレカ」と名付けたプロジェクトに９０年代から取り組み成功を収めた事で知られています。

また日経ビジネス（2014.2.17号　P44）にはダイキン工業の事例が紹介されています。

同社では営業担当者に顧客情報をデータ入力させて共有する仕組みを２０００年前後に導入しましたが、同社の金子秀夫・副事業部長は

「社員の多くが書き終わるだけでぐったりしていた」

といいます。

そこで２０１０年にこの仕組みを刷新し、「この案件は期待できそう」といった＜所感＞を重視する仕組みに変えたと言います。変更後には社員から「読んでいて面白い」という声が続々と上がり、コメントがついたり、ディスカッションが行われるようになりました。

まさに、ナレッジやインテリジェンスが正しくシェアされるようになったのです。