私は都市に住んでいるので、大きなビルや交差点などが頭に記憶している。ある意味、自分の都市の中を、自分が知っているビルや交差点によって自分なりの地図を保有している。その地図はタクシーの運転手とは程遠いレベルな簡素な地図である。しかし、人と会話する際には、その程度のアバウトさであのビルの東側とか、交差点の北側100mとの言葉づかいだけで十分に会話を進めていくことができている。詳細は不要なことが多いのである。

　今回の論点は、このようなアバウトなお互いの認識で済むことに対し、情報システムはあまりにも細かい単位だけで処理が行われている。その結果が、知りたいことを知る手間に時間をかけてしまっていることはないだろうかと思っている。

　はっきりと分かっていることから、その周辺のビルや様子を追加の知識として獲得していく。外の位置関係として自分の地図に少しずつ情報を追加しているのだと思う。そして、覚えたことを時々忘れてしまうのでもある。しかし、昔この近くに来たことがあるとか、よく通った喫茶店があった場所などは、おぼろげながら見つけることができる。

　これは、自分の記憶として忘れることのないであろうビルや交差点を目印とした自分の地図に、位置関係と共に、知り得たことを記録しているのではないかと思います。

　ものごとを遡り、記憶を探る方式は、このような間違いのない自分の地図を頭に描き、その近くにどのようなことが、起こったのか、それはどんな人が関係していたのか、どのような思いをしたのかなどを思い出すきっかけにしているように思う。

　自分なりの地図から広がる記憶したことは、幹から枝葉のようにつながり、そして、他の木の枝葉に結合するように関係していく。このことをから、表形式にはデータを蓄積する価値は限界があり、その表は、違う視点や緻密化により、役の立たない粒度のデータと関係性と理解されて、再利用性が低下しているのであろう。

　知り得た知識は、その枝葉の自在な適切な場所に記録することができなければならないことと、検索の入り口として誰にも明確な、地図のようなトピックをビジュアルにした分類による見え方が必要である。この分類は万人の理科できないような細分化は無意味な定義となるために、適度な分類にとどめ、幹、枝葉に展開してしまうのがよい。分岐される場所は目印となるビジュアルな絵で表示されながら、展開された知識についても他の知識との区別ができる絵であることが必要となる。

　ものづくりに適用して具体的に述べてみたい。ものづくり企業には、ものを作る工場がある。その工場のレイアウト図が、その企業のものづくり知識をためる地図になる。その地図には、大きな設備と誰でも分かる建屋の柱番号が記されているだろう。設備以外にも、部品の置き場があり、人の作業場もあるはずだ。この配置図が企業内にものづくり知識を知るための入口となる。この配置図に対して、自分の知っている知識を大きな観点から順に記載すれば良い。自分の知っている部品の知識でもよく、その加工方法でもよい。また、外注先の名前でもよい。品質の管理規格でもよい。品質の管理規格ならば、関係する部品との規格値との関係について、幹や枝葉を超えた繋がりを関係づけた知識が記録できることになる。

ノウハウや知識を受け継いでいくことは特に技(わざ)の伝承にて語られることが多い。腕一本でものづくりを行なっている人達がいる。創業100年を超える企業が日本にはたくさんある。この企業は、腕一本で創業者が事業を興し、弛まぬ努力の積み重ねで継続していることは疑いのない事実である。

　一方、日本には多くの企業があるが、それぞれの企業はノウハウや知識を受け継ぐことができているのだろうか。利益優先で、事業をズバッと切り捨て、開拓するのもやむを得ない時もあろう。しかし、そのような状況でない中でも、日常的にノウハウや知識を受け継ぐことができているだろうかと思っている。
このノウハウや知識は企業の事業内容によって特別な固有のものも多いが、一般的なことも相当あると思う。知らないのは自分達だけではないかと心配して業務に接することが一番安心な心構えであろう。

　一番、ノウハウや知識を受け継いでいく良い方法は話しをしながら、作り方を見せながら体得する方法であることは昔から変わらない。最近は動画がいっぱい無料で配信されていて、これでも十分だと思うこともある。しかし、時々、なぜなのかと質問したくなることにも遭遇する。この時のなぜは人によって、深さや範囲は異なる。しかし、分かると言うことも人ににより異なる。分かったつもりのように、どこまで分かっているのかと心配なこともある。

　小生も分かっていないことばかりに直面し、いつも頭を抱えているのである。私達人間は知りたいと言う好奇心は際限のないことであり、人によって、その優先順序や重要性がまちまちなだけなのだと思う。したがって、他者に強制もできないし、次から次へと沸き起こる疑問は、もはや、他の人からはどうにもコントロールもできないことなのである。

　インターネットで動画による解説を聞いても、それだけでは十分に満足できない。先輩から話を聞いても、疑問は全ては解決しない。大学の研究者のように、分からないことを明らかにしたいのは人間の本質である。企業の中においては、その知りたい行動を、組織や自分の役割というタガで、それ以上の行動の制限をかけているのである。このタガが、今、一番成長や創造性や生産性に良くない影響を出している。若い人の柔軟性を管理者がタガをはめて、窮屈な思考の場にしてしまっている。

　このような好奇心という人の性に対し、知りたいことや知り得たことをメモするなんらかの構造的な方式が欲しくなる。単なる断片的に孤立化したメモではなく、知りたいことと、知ったことを都度適切な場所に記録する方法である。そして、それは、他者が知りたい、知ったことを記録できる共有の場所でなければならない。既存の方法では答えがないのである。
もし、このようなことが可能になれば、追加も自由で、蓄積型の知識の記録方式になる。それこそノウハウや知識を受け継いでいけるはずだ。これが特徴点記述式と呼んでいる私の方式である。

システム手帳を使い出して何十年も経過し、携帯のメモアプリやスマホにメモを書くことも、かなり早くから始めてきたのであるが、未だにシステム手帳も使っている。システム手帳の使う場面は、会議の時だけになっている。どうしても、キーボードを打ちながらでは、会議に集中できないからがその理由である。ブラインドタッチでも、会議は絶対に紙にメモを書くことにしている。そもそも、私は、会議中にパソコンに打ち込んでいながら、仕事をするのは、考えることに集中せず相手に失礼だと思っているのである。

　では、手書きメモをどうしているかと言えば、改めてデジタルのデータにすることはしていない。つまり、システム手帳は会議録専用にしているのである。これが一番自分には効率的だと思っている。

　さて、スマホに記録したメモはどう扱っているのかと言えば、これも用途に分けている。プレゼンのネタを思いついた時には、keynoteにメモして、それを見ながら、別のkeynoteファイルにプレゼンを記載している。投稿や出版のネタは、pages にメモしている。Windowsなら、PowerPointとword ソフトである。

　
　numbersなどの表アプリは使っていない。表は思考のプロセスの随分と後の手続きに必要にはなるだけのことであるからだ。その他のメモは、メモアプリを使っている。自分なりに、メモの種別によって使うアプリを変えている。ゆくゆく絵を挿入するからkeynoteへ、メモを成長させて文章化していくものはpagesへ、断片的な自分だけの記録はメモを使うのが一番しっくりしている。本当は、どのように種別でも、一つのアプリで済ませたいのであるが、それができないのが歯痒い。

　このように、その後の発展活用用途に分けてメモの場所を変えてはいるが、どうしても、アプリを超えてメモを再整理する必要がある。それも結構な頻度で行っている。結局、カードシステムのようなことをパソコンの上で、行っているのである。これが大変面倒なのである。記録することに偏り、データを使うことへの機能開発が不足している。カードシステムよりも良い点は、コピペすれば、オリジナルな場所のメモは消えていない点である。すると、このようにアプリを超えたメモをどんなアプリに集合させるのが良いのかを探す必要があり、いろいろ試しているが推薦できるものがない。

　そもそも、全てを行えるアプリを開発していただけないかと願うばかりである。パソコンが生まれて以来、これらのアプリを受け入れ、その上で仕事をしてきてしまったことから転換することは容易でない。仕事の細部手続きの中に、アプリが特定され埋め込まれてしまっている。だから、そのような統一的アプリにチャレンジする人がいないのかもしれない。

　人が考えることを行う場合、紙と鉛筆が基本であった。そこに、アプリと言う機能を限定した考えを持ち込んでしまった上に機能の競争になり、多種多様なアプリ乱立の状態になってしまったのである。私は、紙のカードシステムの軽快性と可視化性の上にパソコンの記憶力と検索力が知識の記録方式の基本であると考えている。その上で、枝葉である機能を作り直してみたいと思っている。

知識管理システムの機能

知識管理システムの業務への活用は２つの機能を対象とすることが必要である。１つは企業での標準化を推進する機能と２つ目は実際の設計や生産などの実務を実施する機能である。標準化を推進する機能は組織単位に標準化のグループを設け、その組織に関する技術の標準化を推進することが多い。この組織単位に設置された標準化グループはそれぞれが知識管理システムのユーザとして標準化を推進することとなる。これにより、自組織の個別最適な標準化ではなく全体最適な標準化を実現することができる。

　また、各実務の実施機能は実務における個別最適ではなく、各実務においても組織を横断的に捉えた全体最適判断を行うために、それぞれの組織が知識管理システムのユーザとなることになります。

　この全社的な運用を行うには、マスターデータである言葉のマスターの維持が重要である。言葉の全体管理を担う事務局とその言葉の承認を判断する検討ワーキングが継続的に運営されなければならない。一見、大変であるように思えるが、新規に承認すべき言葉は同じような製品を繰り返し開発生産する企業では多く発生しない。最初にこのマスターを登録し、整理することだけで多くは解決されるはずである。日ごろ怠っていることにより、言葉の矛盾や分類のあいまい性からの無駄な時間を考えれば圧倒的な効率化となるはずである。

　例えば海外とのコミュニケーションにも多いに有意義なことである。技術用語辞典を作成していることと同じであり、そのメンテナンス機能を持ったシステム化であると理解すればよい。この事から、言葉マスターの登録機能には、最低限、組織単位に使われる言葉の登録機能が必要である。そうでなければ、膨大な言葉の選択が組織の実務者に負担となるからである。

　また、組織単位に登録されたものの中から、類似した言葉を検索し、その類似した言葉群を一つの標準の言葉として扱う機能が必要である。これは、ユーザは良く使う簡略語を持ってコミュニケーションし、標準の言葉を正確に話しながら（記述しながら）コミュニケーションを行っていないためである。つまり、システムに対して、簡略語を入力（選択）しても、システムでは標準の言葉として記憶されるようにするべきである。また、言葉のマスターは技術、管理の２つの分類にて言葉の区分がなされていることも必要である。更に、言葉の見直しにおいては、標準の言葉を修正できるようにすべきである。

　これらの機能を用いて、標準化の推進業務が円滑に行われるように配慮している。
　実際の実務推進での業務活用方法は、まず、実際の製品開発にて知識管理システムを使うことである。要件書やチェックリストをまとめて知識管理システムに登録することは言葉のマスターといった体系的な整理がされていない限りは推奨できない。

　実際の製品開発にてコツコツと言葉のマスターの体系的分類の中に知識を蓄積していくことがベストな方法である。製品開発の段階では具体的な事実と共に、意思決定をする必要があり、その為に、具体的な事柄の１つひとつを過去の知識を整理しつつ業務を進めるからである。その為に、知識管理システムに蓄積しやすい業務となっている。と言うよりも、知識管理システムは製品開発段階で活用する前提で機能開発をしたものである。

　１つの製品を開発から量産、サービスまで企業内にて運用が進むと、その蓄積された知識がどのように関係しているかを俯瞰できるようになる。この知識を参考に次の製品開発に知識管理システムを活用する。その時に、既に蓄積された知識や言葉のマスターとどこが同じであり、どこが異なるかをユーザは自然と意識することができる。その時に、数々の気づきが得られ、その結果を蓄積することでより広く、深い知識を知ることができることを確信するはずである。

　製品開発のマネージャは開発日程や原価、品質などの視点で設計を判断する必要がある。今日、３ＤＣＡＤシステムが運用され、このような判断をどのように実施すべきか迷っている企業も多い。

　知識管理システムは標準の知識に比較して良否を判断することを基本コンセプトとしている。そのためには知識管理システム内で、標準の知識と実際の設計の２つが扱えることが必要である。この両者を比較する手法とその比較した結果を共有することが機能として織り込まれている。

　まず、比較する手法は３ＤＣＡＤモデルへの特徴点記述という方法を用いている。ここで特徴点とは人が気づきを持った対象となる３ＤＣＡＤモデルにおけるx,y,z座標である。他者からどのようなことに人はどのような判断をしているかを見える化する方法である。それには、あらゆる対象がその特徴点記述の対象となりえる。そこで、特徴点の対象を点、線、面、部位など形状だけでなく対象を区分する言葉を選択する方法を採用している。これによりx,y,z座標と区分をセットにした単位を比較対象の単位と定義する。

　比較した結果を共有する方法は３ＤＣＡＤモデルのひとつの特徴点に対して、複数の組織がその知識を記述できることと、標準の知識と実際の設計の比較した技術判断の結果を保留点、問題点、承認点などの区分を登録することで、エンジニアがどのような判断をしているかを他者やマネージャに見える化する方法を保有している。エンジニアは知識がないことは判断ができない。

　従って、知識がないことは保留点とされる。知識があることは問題点か承認点のいずれかに判断される。判断に使われた知識は知識管理システムで記述できるので、知識があることと無いこと、技術判断の区分にマネージャは着目し、製品開発のマネージメントに活用することや、技術の進展をリードすることができるのである。