この本で我々は、人間の知識を二種類に分けている。一つは「形式知（explicit knowledge）」と呼ばれ、文法にのっとった文章、数学的表現、技術仕様、マニュアル等に見られる形式言語によって表すことができる知識である。この種の知識は、形式化が可能で容易に伝達できる。またそれは、西洋哲学の伝統において主要な知識のあり方であった。しかしあとで論じるように、より重要なのは、形式言語で言い表すことが難しい「暗黙知（tacit knowledge）」と呼ばれる知識なのである。それは人間一人ひとりの体験に根ざす個人的な知識であり、信念、ものの見方、価値システムと言った無形の要素を含んでいる。暗黙知は、人間の集団行動にとって極めて大事な要素であるにもかかわらず、これまで無視されてきた。それはまた、日本企業の競争力の重要な源泉でもあったのである。これが、日本的経営が西洋人にとってな謎であった大きな理由であろう。

　西洋哲学の主流においては、知識を所有する主要な主体は個人である。しかし我々は、個人と組織は知識を通して相互に作用し合うと見る。知識創造は、個人、グループ、組織の三つのレベルで起こる。したがって、我々の組織的知識創造の議論は、知識の相互作用の様式と知識創造のレベルの二つの大きな部分から成っている。暗黙知と形式知、個人と組織の二種類の相互作用は、（１）暗黙知から形式知へ、（２）形式知から形式知恵へ、（３）形式知から暗黙知へ、（４）暗黙知から暗黙知へ、という知識変換の四つの大きなプロセスを生み出すのである。

　著者の洞察の深さには驚かされます。本書は組織の知識構造を解明しています。そして、「（１）暗黙知の共有、（２）コンセプトの創造、（３）コンセプトの共有化、（４）原型（アーキタイプ）の構築、（５）知識の転移」からなる「組織的知識創造のファイブ・フェーズ・モデル」を提示しています。その上で、企業の組織論を展開しています。本書は、ITプロジェクト管理については触れていませんが、本質は同じと考えます。

　ITプロジェクトにおける知識創造についてはどうなっているのでしょうか。ITプロジェクト（特にソフトウェア開発プロジェクト）を見たとき、暗黙知を軽視して来たことは否めません。本屋に行けば、プロジェクト管理の解説書、それも選りすぐりの良書が山と積まれています。しかし、ITプロジェクトにおける知識創造のメカニズムを論じた書物を見かけたことはありません。ご存知の方がおられましたら教えて頂きたいと思います。

　本稿では、浅学を恥じながら、ITプロジェクトにおける暗黙知の重要性についてのみ取り上げたいと思います。

　先ず、いくつかの私の経験を紹介します。

　新入社員教育の機会を持ったことが何度かありますが、学校を出たての彼らには、「本当の知識は体で覚えている知識だよ、何かを生み出す力はこの知識だよ」と、何度も言ってきました。新入社員が学校で受けてきた教育の殆どがいわゆる形式知だったものですから、最初は何を言っているのか分からなかったようです。そこで、「ある男が酒で体を壊し、長年断酒していたのだが、ある日会社で嫌なことがあって、家路についていたときハッと気づいたら昔通った居酒屋の前だった」という心理学の本に書いてあった話を出して、体で覚えた知識とはこんなことを言うのだよと教えたことがあります。あまり良い例とはいえませんが、このように体で覚えた知識とは深いところにあるのです。

　新入社員に、「失敗すると本質が分かるよ、小さな失敗はいくらしても良い、大きな失敗をしないためにも小さな失敗はいくらでもしなさい」と、自分の失敗談を交えながら話したことがあります。私は思い出すのも嫌な、致命的な失敗を何度も経験してきました。多くのケースでは、自分の力の及ぶ範囲外に原因があったのですが、それに気づかず、あるいはうっすらと気づいていても、強力に上司を説得することもせず、のっぴきならない状況になってから問題が明るみにでてくるのです。経験を積み重ねるうちに大きな失敗をすることは殆どなくなりました。理由は勘所が分かるようになったことだと考えています。プロジェクトの進行にある種の不安を覚えたとき、不安の本質的原因を直観的に理解し、厳格なまでに対策を講じるようになったからです。この私の個人的経験を文書にまとめて新入社員に示しても、私と同じ境地に到らないはずです。私と同じプロジェクトで新入社員に仕事をさせながら、失敗する様子を見ていて、ほらこうすると失敗するだろうと指摘したとき、彼らはその失敗の本質を１００％理解するのです。他人の失敗経験をいくら学習しても所詮他人の失敗なのです。

　OSの開発部門に配属された新入社員に対しては、タスク管理とは何か、ジョブ管理とは何か、ファイル管理とは何か、OSの知識を片っ端から数ヶ月かけて教育するというのが普通でしたが、これらの講義の間、居眠りをする人達が続出するのです。実感の湧かない詰め込み教育をいくら重ねても、彼らの脳みそが働かないのです。毎年入ってくる新入社員に対してそうした教育が続いていたのですが、ある年から簡単なシステムを４、5人からなるチームで開発してもらうコースを実施したところ、居眠りをするものは１人も出ませんでした。もちろん、設計方法、プログラミング言語、OSなどについて必要最小限の知識は事前に教えましたが、教材のすべてを説明することはしませんでした。しかし、彼らは課題を解くために、作業分担を決め、議論しながら２ヶ月ほどかけてシステムを完成させたのです。チームは全部で１０チームありました。コースの途中と最後で全員参加による発表・討議会を行い、設計に疑問がある場合は、何故かを説明してもらいました。完成したシステムの評価は行わなかったのですが、新入社員達は、このコースを通して、いろいろなことを学んだはずです。その中で一番価値があったことは、彼らがチーム作業を通してプロジェクトの意味を学習したことではないかと考えています。このようにして身につけた知識こそが暗黙知です。この暗黙知は紙に書かれた書物や論文から得られる知識ではありません。

　暗黙知を継承していた部門に所属していたことがあります。それはOS開発部門です。OSは、仕組みが複雑で巧妙に作られています。OSの開発においては、長年にわたり、経験者の指導を受けて若手が開発を引き継いでいく必要がありました。いわゆるOJT （On the Job Training）がそのやり方でした。同じことを一緒にやって経験を共有しながら、経験者から暗黙知を引き継いで行ったのです。この部門からは、システム開発の勘所を押さえた人材が多く排出されたと思います。人事部門の人は、極めて事務的にローテーションが必要だからOS開発者の何人かをシステム部門に異動させろと言ってきますが、人事部門の言うとおりのことをしていては、OS開発はできなくなるのです。暗黙知の共有の必要性は、OS部門に限ったことではありません。システム部門にも当てはまります。しかし、システム部門では異なるお客様の異なるシステムの開発を行うものですから、暗黙知を共有する機会が若干少ないようです。異なるシステムであっても、整理すると同種のシステムであり、暗黙知の共有は可能であり、新しいシステムの開発とは言っても、既存のシステム開発の経験を活かすことが可能なのです。

　私の経験の一部を紹介しましたが、経験豊かな皆さんも、大なり小なり、同様の経験はしておられるものと思います。しかし、ITプロジェクト管理において、組織的に暗黙知の活用に取り組んだことがあったでしょうか。

　ITプロジェクトにおける「組織的知識創造のファイブ・フェーズ・モデル」の適用は今後のテーマであると思います。「（１）暗黙知の共有、（２）コンセプトの創造、（３）コンセプトの共有化、（４）原型（アーキタイプ）の構築、（５）知識の転移」と言う視点からITプロジェクトを見直すと、プロジェクト組織の組み立て方が見えてきます。

　新しいITプロジェクト組織を組み立てるには、経験豊かな人材を登用し、若手技術者と一緒になって、システム構築の方法論をつくり、改善していく仕組みを導入する必要があると思います。

　次の稿では、ITプロジェクトにおける組織的知識創造の仕組みを整理したいと思います。

■