３ＤＣＡＤモデルであれは、そこに記述する知識はいくらでも記憶できる。たとえ、実際の生産ラインで知り得た知識であっても、３ＤＣＡＤモデルに知識を記述する方法とすることで、設計の知識と生産の知識が関係性を持って保有することができる。

　企業のＩＴ化は全体最適を狙いつつも、結局個別システムになっている。それは、全体を捉えようとシステム設計しても、その途中で限界に直面し、システムを導入する企業も一度に全体を実施適用せずにスモールスタートで実施し、効果を見つつ成長をとの安易さで全体最適を真剣に検討することを避けて考えているからである。ここで、全体最適とは何か。どうなれば全体最適と言えるのか。そのことを研究することなく、単に全体最適と言っているだけではないのかと思えてならない。

　全体最適のシステムとはものづくり企業において、技術のトレードオフ検討ができるシステムを意味するものと考えている。自動で結論を出すシステムではない、最適化機能を含めるとしても、答えを出すのはあくまでも人間である。その為に、全体最適のシステムであることの最低条件はものづくり企業の知識をためることのできるシステムであると考えている。

　知識の対象はものづくり企業全体である。企業全体の知識をためる仕組みであれば、一部の部署から知識をためるシステムを活用しても全体に広がるものであるので全体最適のシステムをスモールスタートさせていることとなる。

　スモールスタートとはコストが安いやり方、一部の部署だけのシステム、一部の機能だけのシステムを言うものではなく、全体最適のシステムを設計した結果として、スモールな組織、機能にてその全体最適システムを立ち上げることをスモールスタートと言うべきである。

　スモールと言う以上はラージとは何かを捉えていなければ、意味のない逃げの表現である。このようなことを説明することすらできない製造業やＩＴ企業は生き残ることはできないだろう。ものづくりのＩＴ化は日本人しかできないと思っている。そこに閉塞感のあるＩＴ産業の突破口がある。

　また、そのＩＴを活用する日本のものづくり企業の突破口があるはずだ。ＩＥのＩＴ化と言うことを以前から提案している。この２つの産業が共に進化すること、共に成長することと期待している。

ものづくりの事例を上位概念の言葉マスターでまとめる

　
　どんなに多くの事例を述べられても、上位概念なくしては、知識の活用や転用ができない。その為に、知識の蓄積には言葉マスターを用いた上位概念の記述ができることが必要なのである。インターネット世代がものづくりの仕事をブレークスルーすること、イノベーション的なものをグローバルに提供できることの基盤として、言葉マスターからなるものづくり知識の体系的な蓄積を武器に企業を牽引することを期待している。

競争に打ち勝つ開発力は技術の蓄積から

　今、改善だけではグローバルな競争下では勝つことができない。改革するスピードが生き残りの条件である。ものづくり企業は今行うべき改革とは、圧倒的なスピードと効率性で新製品の開発を行うことだと言える。

　時間とマンパワーに依存した労働集約的なビジネススタイルではなく、少人数で超短期に製品の開発を行う仕組みを持ち得ていることが必要である。アウトソーソングを無くして、自社完結型ですべての構成品と製品が生産できる力を持つべきである。その上で、コアコンピタンスを明確化しなおすことである。

　ものづくり企業においてコアコンピタンスは新製品の開発力である。開発力とは単なる設計だけではなく、どのような製品をどの地域でどのようなサプライヤから調達することがＱＣＤの最適化となるかを決定できる力を持つことで、それがこれからの製造業のコアコンピタンスになると考えている。そのために、ＩＴ技術による技術の蓄積は必要条件である。これを持たないものづくり企業は生き残ることはできないだろう。

技術の蓄積の基本方式について

　では、知識はどのような方法で記述する方法が良いのであろうか。巷には知識の記録方法として、ドキュメントをそのままデジタル化し、そのドキュメントに検索の為のタグを付与するシステム、ビデオ撮影し、動画で作業方法を記録するシステムなどが紹介されている。

　しかし、これらのシステムには上位概念が定義できない。また、言葉のマスターという機能がない。したがって、知識を記録することはできないシステムと言える。知識はテキスト文書を読んだだけでは、理解ができないために動画を用いている。

　つまり、知識を理解するには現場が必要である。ものづくりの現場とはそこに設計図や生産ラインや部品がある場所である。このような現場にいつでも行けるわけではないので、現場を仮想的に表示することが必要となる。そこで、知識を記録する現場として３ＤＣＡＤモデルを用いた方法にその実現性がある。

３DCADを用いた技術知識の蓄積方法は弊社の特許となっています。詳しくは、こちらからお読みください。

　今日、設計も設備も生産ラインも部品も３ＤＣＡＤモデルで設計される時代である。その３ＤＣＡＤモデルどおりに現物の物が存在している。この仮想的な現場である３ＤＣＡＤモデルに言葉マスターを用いた知識の記述をすることは、コンピュータの容量以外にその記憶限界はなく、優秀な知識記憶媒体といえる。映像はその仮想的な３ＤＣＡＤモデルのアニメーションである。5Gに期待している。また、現場の音は予測シミュレーションで生成する時代も到来するであろう。

　いずれにしても、人は具体的なものを見ないとその知識が記憶できない動物であると思う。子供が段々と物を理解できるプロセスはなんとなく同じものであるということを身につけることにより、全く同じ形（形状）でなくても特徴が同じであれば、犬か猫とを理解をすることからも分かる。私は脳科学の知識はないが、知識をためる形は、子供が知識を身に付ける方法にヒントがあると考えている。その方法が、一番人が理解しやすく知識を成長させるベストな方法であるのではないだろうか。
　

今こそ知識の蓄積に関心を持つべき

グローバルな人材流動においても、常に知識は企業の財産として保有しつづけ、管理されるような取り組みをすべきであると考える。企業の管理者は目前の問題解決、業務遂行に関心はあるが、その問題を解決した材料やデータ、業務遂行に活用した知識などはその個別問題と業務の完了と共に失われることに関心を示していない。

　その問題が再発し、類似業務の遂行の必要がある時には、その知識を持つ担当者を探して、その過去の振り返りを行う。Know-whoという言葉がエンジニアの中で語られ、IT化にあたり、Know-whoが分かればよいという意見も聞く。人は異動することを考えれば、このような仕組みに効果がないことは言うまでもない。

IT技術の適用ができていない知識の蓄積

　Know-who依存したエンジニアリングこそを抜本的に改革する必要がある。上位の管理者であればある程、エンジニアリングの全体を把握する必要がある。その細部が人に依存し、あるいは外部の企業に依存し自社の製品が生産されていることに心配を持つのが普通の感性であるはずだ。

良い品質の部材でないことを前提にものづくりの品質管理が必要

　国内で良い品質のものが納入される前提で、企業の仕組みができているが、グローバル生産において、良くない品質のものが納入される前提で企業の仕組みを構築する必要がある。

　これまで、日本の企業は、ものづくりが不安定になる可能性のあるポイントを管理することで、製品の品質を維持してきた。これからは、原点に戻り、ものづくりで守るべき品質の整理と明確化が求められる。海外の地域、企業の持つ固有技術のレベルにより、品質管理対象は適切に選択されなければならない。

　多くの優秀なサプライヤに支えたれた国内生産と全く異なる意識が必要である。品質の問題が発生すると、何故その問題が発生したのかを、改めて１から調査し直すことが必要な仕組みではグローバル生産は不可能である。常に、守るべき品質と守らなければなにが問題となるかを共有する生産運営でなければならない。

エンジニアリングの判断の蓄積も重要

　では、この共有をどのように実現するかである。製品が生まれるプロセスにおける知識を蓄積するが一番効率的である。製品設計、解析、実験、生産技術などのどの組織機能のエンジニアであっても、最終製品の品質、性能に問題は無いかという視点でものの構造や加工法を考えている。

　その考えている中には、従来と同じであるので、大丈夫であるという承認と、少し、従来とは異なるので判断ができないという保留と、このままでは問題であるとはっきり言える問題との３つに頭の中で考えているはずである。

　保留と問題は解決をしなければならない点であるので、課題管理などのシートに記載され、マネージメント対象になる。しかし、承認はどこをだれが承認しているかの記録はされず、設計完了後に改めて、自工程が必要な加工や作業をリストアップすることから仕事をスタートさせている。

　この暗黙の承認は海外の生産には通用しない。海外の生産の場合には、この暗黙の承認を含めて、共有しマネージメントする必要がある。つまり、国内では問題なく生産加工できることであっても、海外の現地メーカではその生産加工の経験が薄い場合があるからだ。

　出図した図面に対して、現地メーカの経験が薄い箇所はどこであるかを事前に知ることはできない為、設計側が守るべき品質の全てを現地メーカに示す必要があるからだ。実は、この事は、国内のエンジニアにも有益な知識となる。

技術知識の判断・承認・保留のタグ付けを行うこと

　これまでは基礎的な知識はエンジニアがOJTで獲得している。管理も問題点の管理が主体であるので、問題だということは言いやすく、問題なく可能だと宣言する承認はベテランでないと難しいのである。

　したがって、承認点を共有することはエンジニアが問題ないとの判別の事例と理由を知ることができ、一人では経験のできない多くの判別の事例と理由を知識として身に付けることができるのである。問題であることを知っている知識と問題でないことを言える知識とは知識の範囲が異なり、それぞれを身に付けることで、より深い知識を身につけることができることになる。

知識管理システムの紹介はこちらから

情報探索の入口は分かりやすいビジュアルな抽象化モデル(絵)である必要がある。その絵は実際の具体的なものであるが、そのものが何かを知ることが目的ではなく、その絵から自分が探したいことの分野を区別することが目的である。絵が増えたら見つけにくいので上位概念的なまとめた絵を登録する事が重要である。

　例えば、子供向け図鑑の目次の絵のような大分類がよいだろう。この大分類は、個人のメモを記録するならば、自分が関心のある分野を自分が想像できる絵ならなんでも良い。要は、自分が間違えることなく、その内容を管理できれば良いのである。これは容易なことである。

　一方、仕事のためのメモを記録するには、仕事がどのような分野であるかが分かる絵を入口に配置する必要がある。企業の中で共有するのであるから、誰でもその絵を見て、中にどのような情報が記録されているかが分かる必要がある。より分かり安く間違えないために、テキストで文言を絵の中に記入しても良い。

　例えば、製品を開発して販売する企業であれば、設計、製造、販売などのイメージがつく絵が良いだろう。設計でも複数のカテゴリの製品を設計する企業ならば、カテゴリA、カテゴリB、カテゴリCの区別のつく絵でも良い。製造が複数の地域にある場合は工場a、工場bなどの絵で良い。変化の可能性のある組織の名称を用いずに、一般的な呼び方である組織名称を用いることが必要である。工場名称などは滅多に変更しないだろうし、県の形のイメージに工場がある絵を用いれば、誰でも区別つくであろう。

　企業の中のある組織の企業人のメモは、やはり自分の担当分野を明示できる絵を情報探索の入口にする。この絵も誰が見ても内容が想像できるものであることが必要だ。非常口のサインのようにものを想像すると良い。

　このように入口を表す明確な絵を取り決めて用いることが情報蓄積の第一歩である。情報は粒度も分野も異なるもので、それにもれなく分類を決めようとすると逆に分類からはみ出す情報が出てきてしまう。私達のホルダー名称の不思議な命名は、変化する分類と仕事の内容によっては複雑化されたことを表している。そこまでの分類を決めるのは統一的で遵守できる範囲を超えてしまうので、全号で説明したように失敗してしまうのである。

　では、大分類の中にどんな絵を配置するのかと言えば、それは、その組織における最終アウトプット文書のイメージ図を用いるのが良い。設計の最終アウトプットイメージ図は部品表と製品の設計図と日程表である。それ以外にあるものは最終アウトプットを作成するための、文書である。部品表と設計図と日程表の3つの絵にメモを記述するのである。それぞれの絵には、気がついた時に複数のテーマの特徴点を追加していくのである。既にテーマが登録されているならば、その点に更に追記するだけである。テキストと参照文書を添付するだけなのでシンプルである。

　製造側は、何をどの様なプロセスや日程で行うべきかを書いた標準日程表、生産ラインの全体図、製品の全体構成図などが検索の入口モデルにすると良い。その中に業務日程詳細図、加工プロセスの詳細図、部品図などをモデル登録する。全体図にも詳細図のどのモデルにも特徴点登録できる。詳細図の中にも特徴点登録できる。それぞれの特徴点には参照モデル登録できる。モデル登録したモデルは他のモデルのどこにでも親子関係を定義できる。このようにすることで、製品構造と工程と生産計画を関係づけて記録することができるようになる。

　ここで登録する情報は技術的思考を記録することであり、関係者の意見を記録することである。また、その文言を全文検索対象にする事で、改めてタグを付与せずに、もれなく検索できるようにすることにある。

　モデルの親子関係は詳細を図で説明する時に必要であり、参照図はより横断的な知識共有により決定合意の速度を高めることにある。
　親子関係を後で付加できることは、思いついた時に追加できる自由さのためである。誰でも完全なる網羅的登録を最初からできるのではないから。

　モデル図を的確にたどり、必要なモデルを見つける方法は、モデルのネットワーク図の見せ方が重要である。言葉を知らない場合のビジュアルな図の探索発見方法と対象の検索言葉を知っている場合のなどの全文検索が重要である。　　　　　　　　絵の中に特徴点を記述することは、技術情報が必ずその絵の中にあることを意味していることを保証している。絵に特徴点を登録しなければ会話が登録できないようにできている。

つまり絵と会話は分離されることがない。
　絵を見つければ技術情報を見つけることができる。また、言葉を知っていれば、見たこともない技術情報を絵を指し示して理解することができる。
　このよう情報を知る目次的な機能としても役に立ち、真の図面などは、この後ろに続いて他の固有システムを操作して知ることができる。

　一方親子関係の中あるいはそれを超えた関係の中で付与された特徴点はどのように振る舞う必要があるのか？
　親の会話テーマが子供の会話テーマと親子の関係テーマであるかは難しい。
　１つの目的の為に、複数のテーマを検討する場合には、関係を定義できる。親のテーマがいつ子供のモデルのテーマがその親子関係として認識されるかはわからない。親のテーマがいつまで親のテーマでありつづけるかは確かではない、その時の親のテーマにしただけのことである。このような方法で、日常的なメモを後で検索しやすくすることができるのである。

メモアプリの使い方と問題点

これまで、いろいろなITツールを使ってメモを書いてきた。どれも満足のできないやり方であった。その失敗例を紹介したい。
　メモをスマホの良くあるメモアプリを使って記録した。これは、日付もタイトルも自由入力であり何でも書ける自由度が高いアプリであった。メモを全文検索もできるので、数文字の入力で候補が絞られるので便利であった。しかし、問題は、メモを分類できないことであった。分類機能は必要である。KJ法のように。
　ある時から、新聞の電子版を購読し始めた。毎日必ず読んでいて、その時に知ったことをアプリに保存を始めた。その理由は、それまでのメモアプリでは、新聞の記事内の写真が保存できなかったからだ。この時から新聞記事が、分類をつけて記録できるようになり今でも継続している。しかしこのアプリで困ったことは、自分の意見や考えを、その記事について記録が見えやすい場所に書き加えれないことであった。記事のタイトル欄に付け加えて、意見を書き込んでいるが、その意見は元々の記事のタイトルがどのような文であったのかが全く分からないので困ってしまった。Webの記事も同じ問題がある。

メールやチャットの問題点

次はメールでの配信文書の記録。メールで届く内容で、イベントの日時案内、情報の提供、知り合いからのメールに記録したい事が多い。その中でメール文中にURLが記載された記事がキチンと記録できない。URLを開いて、中身が記憶にだけあって、もう一度見たいと思った場合は、URLをお気に入りに入れていた。しかしこの操作は時としてやり忘れ、頭の中で、あの人のメールに案内されていたように思えるという薄い記憶を頼りに、受信メール一覧の中を探し回る。本当にストレスの高い行為である。お気に入りも、雑然としてゴミになってきている。

　更にメールは、何回かのやりとりしたことが見つけにくい。差出人名で探すのが一番だと思っているが、次に、その中から該当のメールを見つける事がストレスである。件名が、同じものがいくつもあり、これは、実は、返信の際に件名との無関係な内容を含めてやりとりするからである。もはや、一件づつ開いて読むしかないという原始人のやり方に戻っている事が腹立たしくなる。
　以上がテキストをメインとするメモアプリを使っての課題である。

文書作成ソフトの問題点

自分で書いた報告書など一つのテーマに関して、まとめた文書は、報告後は自分のPCに保存され、後にクラウドの有料サーバに保存するように変更した。しかし、これはアプリ依存した文書を保存するので、アプリ横断的な検索を行ったとしても、ファイル名しか対象とされない。この場合もいろいろ考えたことがファイルの中に閉じこめられてしまい、ファイルを開かなければ欲しかった考えを見つける事ができない。同じくストレスのある作業となっている。更に、クラウドサービス会社によっては、MacとWindowsのファイルは共存できないなど、困った問題がある。

必要なことは色々なアプリやサーバにあるメモを一体として扱える

自分のためのメモもあれば、会社でのメモもある。これらのでメモは、タイミングが来るまで、思考を暖め、個人の記録として分けて保有したかった。ところが、この区別が、明確に出来なくなってきたのであった。
　メモは次第に合流し、また、分岐して異なる目的の中で扱われる。その間に新しい発見があり、そのことの説明にも用いられることになる。メモを探すことができないことが問題である。それも思い出せないメモをである。
　結局、いろいろなアプリやサービスが氾濫してしまった今日では、どこにでもつながる入口と仮想的に集合されたイメージによるメモ環境が必要だと考えたのである。