※2012年12月1日より新ブログに移行しました。自分で言うのもおこがましいですが、20代の頃に書いた本ブログよりも、30代に入ってから書いている現行ブログの方がはるかに中身が濃く、内容が多岐にわたり、面白いと思いますので、是非ご覧いただけるとありがたいです!
>>>現行ブログ free to write WHATEVER I like
Top > ナレッジマネジメント アーカイブ
<<前の3件 次の3件>>
November 01, 2010

ナレッジマネジメントシステムの話は一切出てきません−『経験知を伝える技術』

拍手してくれたら嬉しいな⇒
ドロシー・レナード
ランダムハウス講談社
2005-06-23
おすすめ平均:
著者の提示する「ディープ・スマート」という概念に疑問
OJTを過剰に重視する風潮に一石を投じる一冊。
経験知の重要性を論理的に説いた本
posted by Amazon360

 団塊の世代が一斉に退職を迎え、彼らの熟練技術が企業から消失するという「2007年問題」が注目されていた頃は、「ナレッジマネジメントシステム」が有益なソリューションとしてそれなりに脚光を浴びたような気がする。しかし、それから数年が経った現在、企業側の需要やシステム側の機能はどうなっているんでしょうね?誰か詳しい方がいらっしゃったら、このブログのコメント欄か、twitterのDMで教えていただけると嬉しいです(何という他力本願、汗)。

 以前もこのブログで触れたことがあるが、コンサルティングファームのBain & Companyが世界中の企業経営者を対象に、戦略プランニングやベンチマーキング、シックスシグマ、バランススコアカードといったマネジメントの主要なツールについて、「利便性」と「満足度」を尋ねる調査を定期的に実施している。最新の調査は2008年に行われており、その結果は"Management Tools 2009"として公開されている。

 Management Tools 2009; An Executive's Guide
 (調査対象となった25のツールと、最新のトップ10)
 Download a report on Management Tools & Trends 2009
 (調査結果本文)
 Download a PDF presentation of the results
 (パワーポイント資料のPDF版。地域別の結果や過去の順位なども掲載されている)

 調査対象のマネジメントツールには、「ナレッジマネジメント」も含まれている。この調査においては、グループウェアだけでなく、知的資本管理や組織学習、マネジメント・イノベーションといった非IT系のコンセプトも含めて「ナレッジマネジメント」と呼んでいるため(「http://www.bain.com/management_tools/tools_knowledge.asp?groupCode=2」を参照)、システムそのものに対する評価までは解らないのだが、結果を見ると散々たるものだ。

 2006年こそ「利便性」で69%というスコアを出してトップ10ツールの仲間入りをしたものの、2008年は一転して「利便性」、「満足度」ともに平均値を下回り、「ダメなツール」の烙印を押されてしまっている。

 ナレッジが企業の競争力を左右する貴重な経営資源であり、ナレッジを組織内で効率的に流通させ、社員間で効果的に共有することの重要性は今さら強調するまでもないだろう。しかし一方で、それをITで実現しようとすると困難を伴うことも、多くの人が認識していることだ。明文化できる形式知ならまだしも、言葉で表しにくい暗黙知をITに乗っけようとデータ化するのは至難の技である。

 数年前の話になるが、トヨタケーラムの取締役の方によるナレッジマネジメントシステムの講演を聞きに行ったことがある。同社のソフト「指南車」は、熟練設計者の暗黙知を抽出して、若手の設計者に伝承することを目的としている。熟練設計者の細かい設計技法をデータ化してCADシステムに紐付けると、若手はCADを使いながらいつでも熟練者のナレッジを参照できるようになる。

 面白いことに「指南車」は、単にケースに応じて使用すべきパラメータや数式を登録するだけではなく、「『なぜ』このケースではこのパラメータや数式を使うのか?」といった、設計者の「意図」も蓄積するようにデザインされている。講演を聞いた時は、「ナレッジマネジメントシステムで、ここまで機能が充実しているものがあるんだなぁー」と妙に感銘を受けた。

 ただ、今振り返ってみると、CADを用いた設計のナレッジは、もともとデータ操作に関するものが多いため、その意味でITと親和性が高い類のナレッジであるとも考えられる。それに比べると、製造現場の加工技術や医師の診断・治療技術のように肌で覚える技術、営業担当者・顧客サービス担当など顧客接点で働く人々に求められるヒューマンスキルなどは、やはりITで表現しにくい(過去の記事「提案書のナレッジマネジメントシステムはなぜうまくいかないか?」を参照)。

 ドロシー・レオナルドの『経験知を伝える技術』は、本当に重要なナレッジはITで伝達できないことを暗に示している。同書の中にはシステムの話が一切出てこない。著者が注目しているのは、むしろ徒弟制度のような泥臭いものだ。ナレッジ共有の本質は、やはり生身の人間同士のやりとりにあることを教えてくれる1冊である。
 ディープスマートは、その人の直接の経験に立脚し、暗黙の知識に基づく洞察を生み出し、その人の信念と社会的影響により形づくられる強力な専門知識だ。それは、数ある知恵のなかで最も深い知恵である。ディープスマートは、個々の情報よりノウハウに基礎を置く。複雑な相関関係を把握してシステム全体の把握に基づく専門的な判断を迅速に下し、必要に応じてシステムの細部にも踏み込んで把握できる能力である。
 ディープスマートは練習により築かれる。ただし、単純な繰り返しでは効果がない。よく考えられた練習とは、スキルの反復練習に省察と計画性を加えたものだ。指導のもとでの練習は、学習者が自分のパフォーマンスを振り返るのを助け、フィードバックを受けられるようにする。(中略)コーチの指導のもとでよく考えられた練習をおこなえば、このプロセスを正確に、効果的におこなえる。知識コーチは、学習者自身が思いもよらなかったスキルを習得する必要性を見いだし、経験の分布のギャップを埋めるための練習を促し、建設的なフィードバックをおこなって、将来の練習を導くことができる。(※太字は私がつけた)
 学習者はよき知識コーチの下で、よく考えられた練習や指導を受ければ、知識コーチのディープスマートを享受することができるというわけだ。ここで、「よく考えられた練習や指導とは何ぞや?」ということになるが、要はコーチが学習者と作業をともにしながら、随時アドバイスやフィードバックを与えることである。この点で、結局のところナレッジの伝達は、泥臭いコミュニケーションなのだ。

 著者のディープスマートの概念に関して1つ違和感があるのは、熟練者は伝えるべきディープスマートを頭の中に既に持っていて、それを徒弟制度のようなメカニズムを通して学習者に移転する、という一方通行の認知モデルを前提にしていることだ。タイトルが『経験知を"伝える"技術』となっているように、ナレッジの「伝達」がテーマであるから一方通行の流れだけを論じているのかもしれないが、これは次の2つの点で現実と異なる気がする。

 まず第一に、熟練者は最初から自分のディープスマートを意識しているわけではない。別の言い方をすると、熟練者が伝えようとしているディープスマートは、最初から明確にこういうものだと意識できるわけではない(暗黙知としてのディープスマートは、その定義からしてそもそも無意識の下に存在するものである)。

 熟練者は、学習者の仕事ぶりを見たり、学習者からの質問を受けたりする過程で、自分の記憶や経験を探索し、ディープスマートを再構築している。すなわち、ディープスマートは熟練者と学習者の「共同作業」によって生み出されているのである。

 そしてもう1つは、「伝達」に絞ってしまうと、新しい知識を創造する可能性が排除されてしまう点である。例えば、20年前からシステム開発をしているベテランSEのAさんと、経験がまだ5年程度しかない若手プログラマのBさんがいるとする。Aさんが社会人になった頃は、コンピュータのメモリ容量が非常に小さかった。そのため、メモリを必要以上に消費しない簡潔なプログラムを書くように先輩から叩き込まれた。

 一方、コンピュータが飛躍的に進歩した時代に社会人になったBさんにとって、コンピュータのメモリ容量は制約条件ではなくなっている。むしろ、ぎりぎりの開発スケジュールの中で、とにかく動くプログラムを早く開発することが求められている。Aさんから見れば、Bさんのプログラムは冗長であり、手を加えたいところが山ほどある。

 この2人の間では、ディープスマートの「伝達」は起こらないだろう。メモリの容量に関するナレッジはもはや意味をなさなくなっているからだ。だが、違った切り口から考えてみると、例えばAさんが持っている「簡潔なプログラムを書く」ノウハウを基盤として、「システムの運用・保守を容易にするような、可読性の高いプログラムの書き方」といった新しいナレッジを2人で「共創」する可能性は十分にあるのではないだろうか?残念ながら、本書からはこのようなナレッジの「共創」を読み取ることはできない。
June 04, 2010

ES調査の結果通りに研修やったら、社員から文句を言われたという矛盾

拍手してくれたら嬉しいな⇒
 twitterで「社員満足度(ES)調査では『研修をもっとやってほしい』という声が多いのに、実際に研修をやろうとすると嫌がられることが多い」というつぶやきがあって、他のユーザーの同情を買っていた。いやはや、確かにこれは同情したくなる。ES調査も研修も、人事部にとっては結構大変なんですよ。ES調査をやる時は、現場の各部門に「ちょっとだけ時間を割いてアンケートに答えてくださいね」お願いして回らなければならないし、新しい研修を導入する時も、「こういう研修をやるから是非参加してくださいね」と現場に知らせて回る必要がある。

 そこまでお膳立てしておいたのに、いざ研修をやろうとすると現場から文句を言われるのだから、そりゃ人事部だってたまったもんじゃないだろう。こうした矛盾がなぜ起こるのか、私なりに3つの仮説を立ててみた。

(1)研修の中身に問題がある
 真っ先に思いつくのがこれ。研修の内容が現場で使える内容でなければ、当然現場は嫌がる。こうしたミスマッチは、ES調査で「もっと増やすとよい研修は何ですか?」という設問に、「技術スキル系」、「営業スキル系」、「マネジメント系」、「コミュニケーション系」、「自己啓発系」といった選択肢で答えさせる場合に起きやすい。

 「ES調査の結果、コミュニケーション系の研修を望む声が多かったから、来年度は新しくコミュニケーション研修を導入しよう」と考えた人事部が、外部の研修会社にいくつか問い合わせてみたところ、「コーチング」を勧める会社が多かったので、新しくコーチング研修を採用したとしよう。

 しかし、「コミュニケーション系」と言っても非常に幅が広い。人事部は、社員がコミュニケーションのどの部分に課題を抱えているのかをもっと具体的に調査しない限り、最適な研修を企画することは絶対にできない。いつも結論が出ない社内会議のやり方に現場の社員は苛立ちを感じているのかもしれないし、上司が仕事に関するフィードバックをちゃんとしてくれないことに部下が不満を覚えているのかもしれない。あるいは、もっと基礎的な部分で、若手社員の「報・連・相」が身についていないと上司や先輩が思っているのかもしれない。

 ES調査はあくまでも現状把握の第一段階に過ぎず、表面的な調査結果だけを捉えて研修を導入しても、効果は薄いと言わざるを得ない。

(2)研修を企画・実行するプロセスに問題がある
 「参画型マネジメント」という言葉を聞いたことがある方も多いだろう。重要な意思決定に現場社員を参画させると、経営意識が強くなり、仕事に対するコミットメントが高まると言われている。

 それでは、研修の企画に現場社員を参画させている人事部は果たしてどれほどあるだろうか?ES調査の結果、新しい研修の企画が決まったとしても、たいていの人事部は会議室にこもって研修カリキュラム、テキスト、日程を全て自分たちで決めてしまう(多少なりとも現場社員にインタビューなどを行って、現状業務やスキル上の問題を把握しようとしているならまだましな方だ)。

 現場からすれば、「もっと研修をやってほしい」と声を上げたものの、人事部からは何の音沙汰もなく、ある日突然、「研修ができあがったから参加してください」と言われることになる。これでは現場が嫌がるのも無理はない。

 参画型マネジメントの原理に従うならば、研修企画チームに現場社員および彼らの上司も何人か参加させ、現場サイドの意見やニーズを取り入れながら研修の内容を詰めるのが望ましいだろう。また、企画プロセスで都度できあがってくるカリキュラムやテキストについても、社内イントラを通じて随時現場に公開し、広く意見を募るのも有効かもしれない。

(3)実は、現場が望んでいるのは「研修」ではない?
 3番目の仮説はちょっと大胆なものだが、「研修をもっとやってほしい」という現場社員の言葉の真意を汲み取ると、実は現場社員が望んでいるのは「研修」というスタイルではない、ということも考えうる。

 「研修をもっとやってほしい」という言葉の裏には、「自分自身のスキル向上の機会が不足している」という現場社員の問題意識がある。スキル向上の機会は、何も研修に限られた話ではない。上司から受けるOJTや、社内のナレッジマネジメントシステムの活用を通じてスキルアップを図ることもできる。あるいは、ジョブローテーションによって異分野の仕事に携わることも学習の機会になる。さらに、会社の福利厚生を利用して外部のセミナーや資格取得に走ることだって、立派な学習と言える。

 もし、社員がそれらを問題視しているということになれば、彼らの本音は「上司の育成能力が足りない」、「社内のナレッジマネジメントシステムが機能していない」、「自分が望む異動が実現しにくい」、「福利厚生が充実していない」ということなのかもしれない。こればかりは、ES調査に答えた本人に聞いてみないと解らない。

 少なくとも1つ言えることは、ES調査は所詮「社員満足度」という主観的な指標を計る曖昧な調査であるから、調査結果を額面どおり受け止めるのではなく、その数値の意味するところを深く読み取ることが必要だということである。
January 17, 2010

模倣は他者の「やり方」を自分のものにすること、学習は他者の「問題」を自分のものにすること

拍手してくれたら嬉しいな⇒
 最近、いくつかの記事でナレッジマネジメントシステムに言及しているが、ナレッジマネジメントシステムやグループウェアを導入している企業の方と話をさせていただくと、必ずこんな話になる。

「提案書を作るスピードは確かに上がったのだが、前後のストーリーがつながっていない提案書が増えた」
「ただ単に資料をコピペして、案件内容に合わせてちょちょっと言葉を直しているだけだから、部下の考える力が落ちている気がする」
「さらにそのロジックの通っていない資料をまた誰かが流用してシステムに登録するから、余計に変な資料が増える一方だ」

 こんな話を聞くたびに、私は『"働く"をじっくりみつめなおすための18講義』に書かれていたこんなエピソードを思い出す。

村山 昇
クロスメディアパブリッシング
2007-08
おすすめ平均:
結局、よく分かりませんでした
自身を見直す契機を与えてくれる
自分を見つめなおしたい時にには・・・
posted by Amazon360
 私(=著者である村山昇氏)がかつてビジネス雑誌の記者だったころ、米国の有名なグラフィックデザイナーにインタビューで質問したことがあります。

 廉価で高度なスペックを持ったパソコンが普及し、今や誰でもイラストや写真を自由に画像処理できる時代が来た。こうした技術は、人びとの創造性を増したか?

 「いや、ヘタな絵が増えただけだ」、と。

 情報量の増加や技術の進歩が、必ずしも人間の創造性や賢さを比例して増すものではないことはさまざまに語られています。
 まー、なんとバッサリ斬ってしまうか、このデザイナーは(笑)。情報技術が進歩し、他人の知恵を拝借できる機会はぐっと増えたというのに、大半は単なる真似事に留まっていて、新たな創造にはつながっていないというのは残念なことだ。

 もちろん、模倣が絶対にダメだということでは決してない。学習が模倣から始まることを否定する人はいないだろう。子供は周囲の人間の言動を真似しながら成長していく。模倣を否定したら、人間の成長もありえないことになってしまう。しかし、模倣は学習の始まりにすぎないのであって、学習の全てではない。

 トニー賞とエミー賞を受賞している名振付師であり、アメリカを代表するダンサーの一人、トゥイラ・サープは、DIAMONDハーバード・ビジネス・レビューのインタビューの中で、模倣と学習の違いについて次のように述べている。

posted by Amazon360
 だれかの真似をすると自分らしさが失われるといったことは、私はまったく心配していません。真似をしない人なんて、いるのでしょうか。いないわけがありません。とにかく、私は気にしません。むしろ、それを生かして作品作りに励みたいと思っています。

 ですが、真の学習とは模倣ではありません。こんな言い方ではわかりづらいですね。つまり、模倣とは、ほかのだれかのやり方を自分のものにすることで、一方学習とは、ほかのだれかの問題を自分のものにすることです。
(トゥイラ・サープ「創造は『心身の没頭』から生まれる」)
 うまい表現だなーと思った。一方で、それこそ、私がトゥイラ・サープの言葉を模倣して終わりにしないよう、「ほかのだれかの問題を自分のものにする」とはどういう意味なのか、もう少し解釈が必要だとも思う。オーバーラップする部分もあるかもしれないが、私なりに3通りの解釈をしてみた。

 1つ目は、他人が取り組んだ問題とそれに対して他人が導き出した解決策を、自分が直面しているケースでどう活かすかを徹底的に考えることである。そのためには他人の問題や解決策の前提を紐解き、自分のケースとどこが共通していて、どこが違うのかを明らかにしなければならない。

 具体的に言えば、商談において誰かの提案書を参考にする際、クライアントの背景や状況を注意深く読み取り、提案者の問題提起から解決策導出に至るまでの思考プロセスの裏にある意図を追っていく必要がある。なぜ提案者はそれを問題だと捉えたのか?そしてなぜ提案者はその解決策を提示したのか?そうした行間を読む作業が、自分の置かれている状況との違いを浮き彫りにする。その違いを基に、自分のケースでは問題の定義を少し変えたり、解決策の中身をカスタマイズしたりする。そうすると、自分流の提案書が書けるようになり、新たな学習効果が生まれる。

 2つ目は1つ目と関連するが、他人の問題解決の思考プロセスを読み解く時に、敢えて批判的な見方をするということである。例えば他人の資料を見て、ここは別の考え方ができるのではないか?自分ならこういう落とし所に持っていくのではないか?と角度を変えて検証してみる。

 私が担当している研修で、受講者に同じ課題を与え、ある一定期間の間に1人1人がそれぞれ提案書を作成するという長丁場の研修がある。そして、最終日にもう一度受講者が集まり、各々が作成した提案書をプレゼンし合い、お互いに採点するというワークをやっている。同じ課題に取り組んだはずなのに、提案内容が見事にばらばらになるのがこの演習のミソである。お互いの多角的な分析の切り口が刺激になる上に、受講者は相手の採点をしなければならないから、自ずと批判的な思考が活性化される。だから、最終日のセッションではいろんなアドバイスが受講者間で飛び交う。このセッションは受講者の間でも割と評判が高い(自分で言うのも何だが…)。

 3つ目は、問題や解決策の本質を見抜くということである。これはかなり難しいことだ。あるベストプラクティスが注目されると、その表面的な部分だけを真似してしまい、取り組みの本質的な部分が見過ごされることはよくある。私の先輩のコンサルタントが好んでする話で恐縮だが、80年代に日本の自動車メーカーがアメリカ市場で躍進を遂げた時に、アメリカ企業は揃ってトヨタのカンバン方式を取り入れようとした。

 当時のカンバン方式は、それこそカンバンのような形をした帳票を手作業でやりとりする方式であった。つまり、後工程の仕掛在庫がなくなったら作業員が前工程に出向いてカンバンを手渡し、前工程はそのカンバン受領をもって生産を進める、という流れである。そのスタイルをそのままアメリカ企業は真似しようとした。

 ところが、なまじっかIT化が進んでいたアメリカの工場では、手作業のカンバン方式を導入するとかえって効率性が落ちるという皮肉な結果を招いてしまった。結局、「日本企業は特殊だ」ということで片付けられてしまい、カンバン方式ブームは沈静化した。

 それからしばらくした後、アメリカの学者が実際にトヨタの工場で数ヶ月間働き、カンバン方式の研究を行った。その結果彼らがたどり着いた結論は、カンバン方式の本質はカンバンという形式そのものにあるのではなく、後工程が前工程に必要な部品や材料に関するデータをきめ細かく、かつ素早くフィードバックする仕組みにある、というものであった。その発見をアメリカに持ち帰り、いくつかの企業で実践したところ、今度は成果を上げることができた。しかし、それらの工場を見渡してもカンバン自体は存在せず、一見しただけではカンバン方式が採用されているとは解らないという。

 模倣は他者の「やり方」を自分のものにすること、学習は他者の「問題」を自分のものにすること−また1つ、大切にしたい教訓が増えたなぁ。