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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

文書作成ソフトの問題点

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

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

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

創造性に使われるKJ法のプロセスを残せていない。

商業用途の検索は仕事には使えない。時間の無駄であるが、他に代替方法がないから、やむを得ず使うしかない。使わないよりも探す時間は短くて済むからだ。それでも、別な方法がないのだろうか？といつも思っていた。
　昔、川喜田二郎先生が考案したKJ法であるが、企業の中でも、今でも使われている。一つのテーマについて、多くの意見を出し合い、その結果をいくつかのグループに層別し、テーマについての結論を見つける手法である。
　この結果は報告記録されるが、そのカードは輪ゴムで束ね、いつしか捨てられてしまう。そして、いつかまた同じようなテーマを違うメンバーがKJ法で行うことになる。思い出す行為は何回も繰り返えされるのである。このストレスは大変なものだ。
　環境の変化や技術の変化で、同じテーマであっても、異なる結論がまとめられることもある。しかし、記入したカードの8割が過去と同じであり、10人が半日かけて40時間の工数を使ったならば、過去のカードを利用できる場合には、10人で1時間で結論が出せる可能性がある。
　チームでアイデアを出し合い際でも、最後に残った結果以外は破棄されてしまう。
　或いは、原価低減活動におけるものづくりのコストを減らすアイデアも、効果の大きなアイデアだけが採用されて、他のアイデアは捨てられてしまう。原価低減活動は、実際のものを見ながら行うことが多い。この場合、形やサイズを変更すれば安くると分かっても、生産設備の改造ができないので、そのアイデアは却下となることもある。

特徴点記述法のメリット

　ものができてしまった後の原価低減は難しい。本来、この原価低減アイデアは、次の製品設計で織り込まなければいけないアイデアである。しかし、チームが異なる、しばらく開発の計画がなければ、忘れ去られてしまう。このようなせっかくのアイデアが企業の中で継承されないことが多いと思う。
　このようなメモはどこに記録できるだろうか？PCでテキスト作成ツールでメモを書いても、社内で共有は難しい。ファイルの置き場のフォルダ階層を、探しすのは面倒であるから守られない。個人のフォルダにファイルを保存するくらいしかやらないだろう。
　どこに置かれていても、原価低減アイデアが繭の糸のように引き出すことができなければならない。このようなことが可能になるのが、特徴点記録法なのである。

人は目に見えたことから思考する。

人はどのように物事を考えるのか？目で対象を観察することだ。対象は書類やディスプレー、スマホ、物、景色なんでも対象だ。
その対象に対して、考える。これをメモすることが重要。
　どんなドキュメントを如何なるフォーマットで作成しても、見ている目は点の集合の像である。網膜に.pdfなどの拡張子は無関係。
したがって、スマホ、ディスプレーのスナップショットを撮ることが、見ている目の象に近いはずだ。見ている目は、100ページの文書を同時に見ているわけでなく、欲しい対象はその見ている対象の部分でしかない。残りの99％はその考えに無用である。
　人は、複数の対象を見た結果として、一つの考えを捉えるものと思う。
　それは同じ文書内の複数であるし、あるいはそれぞれ別な文書の複数である。このことが記録できれば良いのである。人の社会における仕事とは何かということも考えなければならない。
　何かの目的の為に、どのように考えて、どのような結論を出したかを、関係者間で意見を整えることとなるのでは無いか。関係者が企業の中だけであったり、他の企業の人であることにおいても、同じである。この関係者間の利益が双方で合致できれば、話はまとまるので、その合致点を考えることをするのだと思う。

非定型業務には特徴点記述法が必要となる。

このようなことが文書になっているのである。つまり、文書は使い回しができることは本当の仕事には少ないのである。本当の仕事とは定型的でないことを言う。
　では、ファイルと言う単位はなんだ？ただ、コンピュータが管理しやすい単位でしかない。何十年もだ。人が使いやすい単位にコンピュータが合わせていく動きが何故無いのか？更に、ホルダーとはなんだろう？ネットサーフィンというだけでなく、PCの中での物探しに明け暮れしている自分の時間を無駄だと思わないのは何故なんだろうか？紙の場合はバインダーの整理を中を見ながら行なって、バインダーの名称も変更することをじていたと思う。
　そこで、特徴点という有利なことが出てくる。
目で見たことを関係づけながら、その文脈を記録する手法である。
　これは、ユーザの一番表面に機能が存在していれば良い。特徴点→目（絵）→保存（特徴点＋絵）の順である。
「特徴点＋絵」が人に意味のある単位であると思う。
　次に必要なことは、この「特徴点＋絵」がいっぱいある中で、自分の欲しい「特徴点＋絵」をどのように見つけるかについてである。
　この「特徴点＋絵」がどのような分野についてのもであるかは、個人、組織、企業、地域によって様々である。年齢によっても違いがある。
　そのような中で、共通の概念としては、グローバルな分類によらざるを得ないが、細かすぎる分類は、逆に、ホルダー階層を繰り返しパズルのと同じことになってしまう。
　川喜田二郎先生がフィールドサイエンスと呼んだ野外科学を今日でも人は続けているのだと思う。見ることは本当に大事なことで、それを研究室に持ち帰リ、科学的なアプローチをしたい。そして、川喜田先生のKJ法をIT技術で発展させたいと思います。