初出：2015年01月26日
野口悠紀雄氏の著作に『「超」整理法』と言う本がある。
1993年出版で私が購入したのが94年なので、もう20年以上前である。
この本の傑作なところは、「情報は、分類し整理すること自体、不可能であり、無駄である」とバッサリと切り捨てているところだ。図書館のように専門のスタッフが居る所以外、情報を分類し、索引を作り、検索する整理は事実上不可能であり、個人等での情報管理を図書館方式を理想とする整理を行ったところで必ず破綻すると言うのだ。
だからと言って、情報を無秩序に収集すると、それもまた破綻する。
野口氏は、情報整理の唯一の解決策『アリアドネの糸』として時間軸を提案している。
具体的には、紙の情報は入手or作成した日付を書いた封を開けた封筒に入れて並べる『押出しファイリング』、当時普及し始めたパソコンに関しては年月をフォルダー名にして電子的な情報ファイルを保存する方法を提案している。一方、スケジュール管理とノートについてはパソコンよりも従来通りの紙の手帳・紙のノートが良いと結論付けている。
この本に感化された私は、早速実行してみた。紙の情報は押出しファイリングに、電子情報は年月をフォルダー名に入れた。スケジュール管理は紙の手帳に、ノートはA5サイズの大学ノートにした。
20年を経て、どうなっているか。
『押出しファイリング』は早々に破綻した。早々と言っても5～6年はもったが。
今となっては『押出しファイリング』は悪名が高い。「封を開けた封筒に埃が入る」とか「古封筒を並べるのはみすぼらしい」と言ったものだ。
しかし、私の『押出しファイリング』が破綻したのは、埃のせいでも見た目でもない。野口氏が『押出しファイリング』で扱うと想定していた情報と私の情報では、質・量・保存期間が違っていたためだと推定される。
「超整理法」の中で明言されてはいないが、野口氏の扱う情報は主に他の人が作った情報で、また平均的な保存期間も3～5年程度を想定していたように思える。これなら『押出しファイリング』の長さで160センチほど、仮に8センチに入れたなら20冊ほどになる。この程度の量であるなら、『押出しファイリング』は機能する。
問題は私の扱う情報は、私自身が作ったものが主体であり、その保存期間はずっと長いことだ。
誤解の無いように断わっておくが、私だって扱う情報量の9割9分は他の人が作った情報を受け取ったものだ。しかし、量で言えば1％、個数で言えば、その10倍は自分で作った情報があり、その上、保存期間が長い。
他の人が作った情報は、多くの場合、その人が良く推敲し整理まとめてから発表する。そのため、紙にして10ページ以上になるのが普通だ。しかし自分で作った情報はまとまっておらず、整理もされていない。量的にも少なく、極端な場合、紙一枚に数行の数式を書いただけのものまである。一つの情報あたりの紙の量が少ないが、その代わり数はある。
これらの紙の情報は思い付きを書きなぐったものが大半で、ほとんどが何の役にも立たない。ところがだ、数年とか時には10年以上経って再び必要になる時が来る。もちろん、思い付きの書きなぐりの全てが数年から10年後に再び役に立つのではなく、逆に大半は20年過ぎても再び見られることもないものだ。ごく一部のみが再び役に立つことがあるのだが、この場合の平均は7年くらいではないかと思っている。私の場合、未来を予想してアイデアを考え、それを書きなぐっておくのだが、時代が早すぎて受け入れられないことが多い。その後、何年か経ち、環境が変わり私のアイデアが受け入れられる素地ができると、そのアイデアの情報が再び役に立つ。つまり私のアイデアは平均して7年ほど時代を先取りしているわけだね。
『押出しファイリング』が有効なのは、保存期間が3～5年程度だと既に述べたが、私のアイデアは平均7年、最長20年の保存期間が必要だとすると、まるで足りない。じゃあ、情報の99％を占める他人が作った情報を捨てれば良いじゃないかと言われそうだし、実際にやってもみた。しかし、やってみると自分の作った情報と他人の作った情報を分類するのも意外に大変だ。結局、自分と他人の情報を分ける作業の2回目くらいで『押出しファイリング』自体を止めてしまった。
年月をフォルダー名に入れた電子情報はどうなったか？
実は仕事上の電子ファイルは、いまだに年月をフォルダー名に入れている。
調べてみると、1998年12月から現在まで、ファイル数にして1万8千、容量19.8GBになっている。（98年11月以前のファイルは、PC換装の時にCD-Rにバックアップしたままになっている。CD-Rにバックアップしているくらいだから、容量的には大したことない）
では、プライベートの電子ファイルは？
実は、仕事上の電子ファイルは、ほぼ強制的にMS-WORDやEXCEL、PowerPointを使うことになっている。しかし、プライベートの情報は、LaTeXで作っているし、その他、CやRubyのプログラムなど、自分で作る情報のほとんどはテキストファイルだ。例外は写真・動画と絵くらいのものだ。
テキストファイル形式に限るなら年月をフォルダー名にして管理するよりも良い方法がある。CVSやGitだ。2000年頃にCVSを使うようになり、数年前にGitに切り替えてから、ほぼ全ての自作電子情報は、CVS・Gitで管理している。
他人が作った情報や、自作でも写真・動画・絵の電子ファイルは、困ったことに自宅のファイルサーバーに無秩序に取り込んでいるだけだ。ファイルサーバーを調べてみると、その総量は1TB、ファイル数にして400万を超えていた。
一方、『超整理法』ではパソコンには向かないと書かれていたスケジュール管理だが、これは、逆にパソコン等での電子的な管理に成功している。
2003年にザウルスと言うPDAを購入したことを切っ掛けに電子的なスケジュール管理を始めた。この時はザウルスだけで集中管理していた。2009年にノートPCを購入した際に、スケジュール管理プログラムを自作した。Rubyを使うことで、LinuxでもWindowsでもクロスプラットフォームで使えるようにし、携帯電話も含めて、スケジュール情報が同期できるように作っている。現在、Windows8.1のタブレットPC上でも全く同じプログラムでスケジュール管理している。
最後のノートが最大の問題。
A5サイズの大学ノートは、50冊を超える頃に破綻。
2005年以降、システム手帳に切り替えたが、これも同じくらいの量に膨れ上がり、破綻状態。特に『押出しファイリング』が破綻して以降、自作情報の多くが、システム手帳に書かれるようになってから、情報量の爆発的増加が酷い。
前半の大学ノートは必然的に時系列に並んでおり、後半のシステム手帳の情報はバックアップファイルに分類してファイリングしているが、結局、検索が難しくて再利用ができない状態になっている。その大半は、私の考えたアイデア。多くは「アイデア倒れ」なんだが、検索さえ上手くできれば、再び役立つ時が来るかも知れないのに・と言う状態だ（野田司令の20年以上にわたるアイデアノート・・誰か整理してくれないかな）
『新』アリアドネの糸
ここでやっと本題に戻る。
超整理法は、時間軸をアリアドネの糸にしていた。しかし、時間軸のアリアドネの糸は、せいぜい3～5年の情報管理にしか有効でない。分類は、システム手帳のバックアップファイルで再挑戦したが、やはり機能しないことを再確認しただけだ。
それでは、アリアドネの糸として、時間軸に代わるものは何だろうか？
もっと長い期間、もっと大量の情報を扱える、そんなアリアドネの糸は何だろうか？
前述したスケジュール管理プログラムを自作している時に気が付いた。
新しいアリアドネの糸、それは『乱数』だ。
自作したスケジュール管理プログラムは、複数のパソコンで使えるようにしている。また、電車通勤している最中にスケジュール管理する私のライフスタイルに合わせて、それぞれがスタンドアロンで動くようにしている（今でこそ、電車内でのネット接続は難しくないが、当時は不可能に近かった）
Aと言うパソコンで入力したスケジュール情報が、Bと言うモバイル端末に反映される。電車の中のネット非接続状態でB端末で修正したスケジュール情報が、次にインターネット接続されたときに同期される仕組みだ。
プログラムを作り始めた当初、スケジュール情報の識別つまりアリアドネの糸として、やはり時間軸を使っていた。たとえば、2015年1月30日10時開始の会議なら、2015013010と言う識別子IDとした。しかし、この場合だと、2つの会議がダブったような場合、区別がつかなくなる。たとえば、PC Aから「1月30日10時にA衛星の会議」、端末 Bから「1月30日10時にBロケットの会議」と入力するとコンフリクトが発生する。また、会議の開始時間を変更するとIDまで変わって、元の時間と変更後の時間の２つの会議情報ができてしまう。
そこで、会議の開始時間ではなく、入力した時間を秒単位で表した数字をIDとした。しかし、不都合が起きた。秒単位での時刻ではIDが重なってしまう可能性があるのだ。人間がキーボードやマウスでスケジュールを一つずつ入力するなら、秒単位でIDが重なることはまずない。しかし、「毎週月曜日の10時から定例会議」のようなスケジュールの場合、同時に複数のスケジュールが発生するのだ。「毎週月曜日の10時から定例会議」のような場合、一連のスケジュールを同一としてIDを一つだけ割り振るという方法も考えたが、「2月2日の月曜日だけ、10時30分からに変更」などがあり、それも駄目だ。
考えた挙句、3年ほど前に、IDとして『乱数』を使うことにした。厳密には、『SHA-1と言う暗号的ハッシュ関数を使った疑似乱数』だ。入力した時刻(1000分の1秒刻み）と乱数などなどを元にSHA-1でハッシュを作って、それをIDにする。SHA-1を使ったのは、3年前には今ほどSHA-1の脆弱性が取り出さされていなかったからで、今だったらSHA-256を使ったかもしれない。まあ、個人的な使い方でSHA-1で問題になることもなかろうけど。
スケジュール・プログラムの管理IDにSHA-1ハッシュを使い始めて3年、問題が起きていないから、それなりに有効なんだろう。そこで、スケジュール以外の情報つまり『押出しファイリングに入れていたもの』『電子情報』『CVSやGitで管理しているテキストファイル』『紙のノートに書いているメモ』をSHA-1ハッシュを使おうと思い始めた。（Gitは元々SHA-1で内部管理しているけどね、と言うかSHA-1ハッシュを使おうと思ったのはGitからヒントを得たんだけど）
情報の整理で、大きな問題は、次の2つである。
・保管場所
・検索
保管場所も検索も、情報を再利用する時に必要なものである。と言うか、再利用しないのなら、情報は全て捨てちまうのが最善の方法だ。
すなわち、再利用しやすい様に情報を保管し、検索するようにしておくことが、情報整理に重要なわけだ。
例えば、私が20年以上に渡ってアイデアなどをメモった紙のノートは、本棚の2段を占める。仕事上の電子情報、1万8千のファイル総容量19.8GBを全て印刷するとたぶん大変な量になるであろう。A4コピー用紙は、1枚4グラムらしいので、1つのファイルを印刷すると平均10枚（両面印刷で20ページ）になると仮定すると、680㎏になる。
ファイルサーバーの400万のファイルは、同じ仮定だと160トン(!!)になる。
当たり前だが、こんな量の情報を紙の状態で保存するのは困難だし、ましてや持ち歩くことなど不可能だ。唯一「本棚の2段を占める紙のノート」だけは保存可能な量だが、それでも持って歩くことは不可能だ。
「別に持って歩く必要ないだろう」と言われそうだが、そんなことはない。いつ何時、昔の情報を再利用することになるか判らない。だから、常に持って歩くことができれば、それが本当にベストなのだ。
紙のノートの場合、スキャンすると1ページあたり20kバイト程度なので、ざっと計算しても総容量200MB程度にしかならない。仕事上の電子情報19.8GBなど、最近のノートパソコンなら十分に入る。USBメモリも64GBで2千円強だ。暗号化しておけば、仮に紛失してもセキュリティ上の問題はないだろう。
流石に400万個で1TBの情報は多い。しかし、ファイルが重複している部分を除くと、200万のファイルで800GBに減る。さらに、まず使わないであろう巨大な動画を除くと、350GBになった。これなら、大きめのHDD内蔵のノートPCなら入るだろうし、SSDのように小さなストレージの少ないPCやタブレットでも、500GBのUSB HDDが6000円程度で売っているので問題はない。128GBのUSBメモリが5000円程度なので、それを3つと言う方法もある。要は全ファイルを持ち歩こうと思っても不可能ではないのだ。1TGBのUSB HDDが7000円なので、本当に全て持ち歩いても良いかも知れない。
とにかく、電子ファイルなら全てのファイルを保存することも、持ち歩くことも可能だということだ。
さて、保管する方法があるなら、残った問題は検索だ。どうすれば、再利用する情報を効率良く検索することができるかだ。情報の整理は、検索を効率的に行うかが鍵だと言っても過言ではない。
情報を分類するのも検索を効率的に行うためのものだ。野口氏は、頭から分類整理することを否定しているのではなく、図書館のように専門のスタッフが居れば分類し索引を作ることも有効であることを認めている。個人の情報の場合、分類することも不可能に近いくらい難しい上に、索引を作ることは非効率で非現実的だと言っているだけだ。
では、個人の情報の場合、どうやって検索するか？
全く無秩序で並んでいる情報から目的の情報を探すには、一つ一つ情報を取り出し探している情報かどうかを調べる必要がある。情報の総数が10個なら、最大10回調べれば、目的の情報を取り出せる。運が良ければ、1回目で見つけることができるし、運が悪ければ9回だ（9回目に調べて、それまで全て違う情報なら10個目の情報が目的の情報である）。平均すれば、(1＋9)÷2＝5回で見つけられる。1000個情報が保管されていれば、平均500回だ。
野口氏の提案のように、時間軸をアリアドネの糸としている場合、1000個の情報の中から見つけるのは、もっと少なくてすむ。
例えば、時間順に左から右に並んだ1000個の情報から2001年1月1日に書いた資料を見つけ出すには、まず、1000個の情報の真ん中の情報の日付を見る。1996年8月17日だ、つまり目的の資料は、もっと左にある。次に真ん中と右端の半分、つまり全体では4分の3のところの日付を調べる。2009年9月20日だ・・・
この方法だと、n回調べると2のn乗の情報の中から目的の情報の資料が取り出せる。10回調べれば、1024の情報から目的の資料が取り出せる。
情報の総量が100万個なら、一つ一つ調べると平均50万回かかるのが、アリアドネの糸を使えば、20回で済む。
アリアドネの糸としてのIDは、時間軸に限る必要はない。
検索に必要な回数を少なくするには、IDを比較した時の前後関係が崩れないことが重要だ。A＜B でB＜Cならば、必ずA＜Cになる必要がある。時間軸なら、Aの日付がBより前、Bの日付はCより前なら、Aの日付はCより前なので、この関係は明らかだ。 グー・チョキ・パーのように グー＞チョキ、チョキ＞パーなのに、グー＜パーのような関係はIDに向かない。
SHA-1ハッシュは160ビットの2進数であり、実体は0から1461501637330902918203684832716283019655932542975までの整数だ。だから、SHA-1ハッシュは、比較した時の前後関係が崩れることは有り得なく、従って、アリアドネの糸としてのIDとしての要件を、少なくとも一つは満たしていることになる。
ここで問題は明らかだ。「そんな大きな数をIDとしても、数自体を覚えられない。資料の内容とIDを対応付けるためには索引が必要で、索引を作ることは、図書館のように専用のスタッフが必要だと野口氏も言っている」と。
まさに野口氏は、この点を付いて、アリアドネの糸としてのIDに時間軸を提案している。資料を作ったり受け取ったりした日時なら索引を作らなくても判るであろうと。
しかし、『押出しファイリング』だけでも5～6年、電子情報を年月をフォルダー名にして保存する方法なら20年も試した結果、野口氏は意図してかしまいかは別として、言外に「資料を作ったり受け取ったりした日時を覚えている」と言う「記憶」を「索引」として使うことを示唆していることに気付いた。
あなたなら、資料を作ったり受け取ったりした日時を正確に覚えているだろうか？
私の経験から言うと正確に日付を覚えているのは、せいぜい数カ月から1年くらいだ。それも超整理法を始めた30代前半の頃の話で、50代の現在では記憶力はずっと落ちている。正確な日付ではなく、年月程度に精度を緩めても、覚えていられるのは、3～5年が限界だ。
今一度、あなたに聞こう。
「10年前の今日、あなたは何をしていたか？」
覚えていないだろう。
私は？
私だって、10年前の今日、何をしたか何て覚えていない。
しかし、10年前の今日、何をしたかは判る。何故なら、私は日記を付けているからだ。
私は、超整理法に関わらず、30年以上日記を付けている。その間に一部抜けもあるが、それを引いても都合25年以上日記を付けている。
私は、もう習慣になったので苦痛ではないが、一般的に日記を付け続けるのは相当きついことらしい。
「アリアドネの糸としてのIDに時間軸を使う」と言うことは、言外に「記憶か日記を索引代わりにする」ことを示唆し、そのためには「記憶の限界ないにするか、多くの人が付けることをためらう日記を付けるか」が必要となることだ。つまり、野口氏自身が言う「索引を作ることは不可能だ」と言う状態に、ある程度以上の期間の情報を扱う場合には、なってしまう。
そもそも、索引を人間が作ること自体間違いなのだ。1万を超える情報、もしかしたら、200万を超える数の情報の索引を人間が作ることは不可能に近い。コンピュータに索引を作らすべきだ。全文検索機能などを使ってコンピュータが索引を作るなら、アリアドネの糸として、時間軸を使おうがSHA-1ハッシュを使おうが変わらない。
SHA-1ハッシュには次のように3つの長所がある。
(1) 分類などを行わずに情報を整理できる。
(2) IDが重複しない。
(3) 情報の重複を防げる。
(1)については、SHA-1ハッシュは時間軸と同等である。しかし、時間軸を除く分類などに比べると、SHA-1ハッシュの方が（少なくとも図書館など専門スタッフが居る場所以外は）優れている。
(2)は、既に述べたように、同時に作っても、また、複数の人が同時に入力しても、（確率的に）IDが重なる可能性は、考慮に当たらないほど低い。
(3)については、少し詳しい説明が必要だろう。
私の自宅のファイルサーバーにある情報は、400万個の総量1TBのファイルが重複を除くと、200万個の総量800GBのファイルになると既に書いている。逆に言うと、200万個の総量200GB、一つあたり平均100KBのファイルが重複していたってことだ。（一つのファイルが重複するのは2つまでとして計算。実際は3つ以上重複する可能性もある）
ハッシュについて知識のある人には常識だが、ハッシュを作成するときに入力が異なれば違うハッシュを生成し、入力が同じであれば同一のハッシュを生成すると言う性質を持つ。入力は文字列であっても数字であってもファイルの中身全体であっても構わない。
私のファイルサーバーの中に重複して存在したファイルは「同じファイル名だが違うフォルダーに入っていた」か「違うファイル名でも中身は同じ」状態だろう。逆に「同じファイル名でサイズ・日付ともに同一でも内容の異なるファイル」もあり得る。
一つ一つファイルの内容を比較すると非現実的な時間がかかる。ファイル毎にハッシュを作って、ハッシュ同士を比較した方が速い。実際、私のファイルサーバーの内容調査した時もハッシュを用いた。
それならいっそ、ハッシュをIDとして管理すれば、重複したファイルでも一元的に管理できるのでは？と言う発想が源流にある。
前述したように、既にスケジュール・プログラムの管理IDに『新アリアドネの糸』SHA-1ハッシュを使う試みには成功している。
次は、『新アリアドネの糸』SHA-1ハッシュを「ファイルサーバーにためこんだ大量の電子情報」と「紙のノートの置き換え」の管理に拡張しようと考えている。
うまく行くかな？
注意
ブログのコンテンツの内、「告知」など時期よって情報価値が無くなるのは除いてある。また、コンテンツに付いたコメントは書き込み者に著作権があるものと判断し、ここに持ってきていないので、コメントを見るときは、元々のブログコンテンツを参照してもらいたい。
その他、ブログ発表後、コメントなどの内容を反映するなど、内容を変更しているものもあるので、注意してほしい。