情報を構成して「知識」にする

Piggydbの肝は、登録した情報の断片同士をつなげたり、分類したりする情報の意味付けにあります。単に情報を貯めておいて必要なときに後から検索する、という利用を想定しているのであれば、わざわざPiggydbを選択する理由はありません。情報同士をつなげたり分類したりという過程を経ることによって、利用者が何らかの学びを得る、というのがPiggydbの狙いです。
コンセプト自体はメモツールやデータベースというよりも、マインドマップに近いかもしれません。ただマインドマップよりPiggydbの方が複雑です。その代わり、多様な情報を無理なく結びつけることができますし、大量の情報を扱うことができます。

階層構造とネットワーク構造

情報を整理する方法としてはファイルシステムやアウトラインプロセッサのように情報を階層的に構成するのが一般的ですが、Piggydbで管理される情報はネットワーク構造になるのでより柔軟性が高く強力です。例えばファイルシステムの場合、一つのファイルが所属できるディレクトリ(フォルダ)は一つだけですが、Piggydbのフラグメントは複数のフラグメントからの「つながり」を受け付けることができます。

マインドマップについて

最近、Piggydbのユーザーさんに以下のような記事を紹介して頂いて、マインドマップについてちょっと考える機会がありました。まだ考えがまとまっているわけではないのですが、思うところをつらつらと書いてみます。
ちなみに上記の記事にはマインドマップを作るツールの一覧が紹介されているので、興味がある人にはとても有益な記事だと思います。
マインドマップという言葉は既に大変な売り物になっていて、インターネットや書籍上には美麗辞句が溢れています。コンセプトがシンプルで、グル的な人物がいて、コミュニティが出来ていて、門番的な人間があちこちにいる。こういう場合に「マインドマップとは何か」ということについて書くと罠にはまるので、そこに言及するのは避けて、そのコンセプトの構成要素から重要だと思えるものを「適当に」ピックアップして、それらについて考えてみることにしました。
以下が、マインドマップから取り出したコンプセプトの一覧です。
  • ツリー構造
    • BOI(Basic Ordering Idea)
  • セントラルイメージ
  • 放射構造(一枚の紙)
  • キーワード
  • 視覚的イメージ(絵、色、形態)
そして、以下はそのコンセプトから考えられる特徴の一覧です。
  • 情報の整理
  • フォーカス
    • 優先順位(重み付け)
    • 記憶しやすい
  • 見晴らしの良さ(俯瞰性)
    • 省スペース
    • 全体像の把握
  • トップダウン
  • 連想
    • 網羅性
以下、Piggydbとの比較で検討してみます。
ツリー構造での発想法は、まずセントラルイメージという根となるテーマを決めることが前提で、そこから連想を広げていくという方法です。発想の方法としてはトップダウン式です。Piggydbでは、既存の情報から連想をしながら情報を入力していくことも可能ですが、最初は関係を意識せずランダムな情報を入力することもできます。そして情報と情報の間の関係は後から定義することができます。つまりトップダウン、ボトムアップ、どちらでも可能であると言えます。ただし、Piggydbとしてはどちらかと言えば、ボトムアップ式の方法にフォーカスしていきたいと考えています。まだまだ機能としては完全に表現しきれていないのが現状ですが。
興味深いのは発想方法の相違で、根を起点とするツリー構造において、発想方法の基本は「連想」ですが、Piggydbの場合は、もちろん連想式も可能なのですが、既に収集された情報の中から「つながり」を見つけるのが、発想法の基本になります。これはKJ法で言うところの「異質のデータの組み合わせから何かを発見する」プロセスです。
データの構造で比較すると、Piggydbはネットワーク構造を採用しています。ネットワーク構造の利点としては、情報を多次元に構成することができるという表現力の高さが挙げられます。同じ情報を複数の視点から眺めることができますし、あるいは同じ情報を違う文脈で再利用することができます。反面、ツリー構造と比較して複雑になることは避けられませんし、ネットワーク構造には中心がないので、知識全体としてはフォーカスがボヤけてしまう傾向があります。
ツリー構造には表現力を犠牲にしただけの利点があります。まず、多くの人にとって親和性の高い構造であること、そしてツリーというのは、生の情報の複雑さを縮減させる機能を持っていて、情報の把握がとてもしやすくなります。ということは反面、複雑な情報の一つの側面しか見れないというデメリットもあるわけですが。その他、今何が重要なのかということにフォーカスしやすく、議論や発想が発散するのを避けることができます。そもそもツリー構造だけでも、見晴らし良く情報を整理できるわけですが、その特徴をさらに強力にするための仕組みとして、放射構造やキーワード、視覚的イメージがあるということではないかと考えています。
視覚的なイメージについては、Piggydbに最も足りないと思える部分で、このようなビジュアルに訴えかけるような効果をどうやって取り入れていくかは今後の課題です。ただどちらかと言えば、キーワードではなくて、ある程度の長さのテキストを単位とすること、Webページというフォーマットに従って、情報を上から下に配置するレイアウトが基本になっていることなどから考えると、フラグメントの見晴らしを良くするのには限界があります。それを補完する知識の地図として機能するものが「階層タグ」だと捉えると良いと思います。タグのセットは知識の最終成果として、マインドマップのようなものになるようにする。そういう意味でまさしくボトムアップの知識構築になるのではないでしょうか。
ツリー構造とネットワーク構造、それぞれ適材適所があるので、並列に比較すると誤解を招く可能性があるかもしれません。両者は、情報整理の入り口としてツリー構造、それらを蓄積、統合するデータベースとしてネットワーク構造、そのデータベースから情報を取捨選択してスナップショットを作るためにまたツリー構造、という感じで使い分けられます。
しかし、ツリー構造を礼賛しすぎる傾向に一石を投じたいという考えもあります。例えば、読書録をマインドマップでまとめると効果的だという話がありますが、複雑な内容を主張している書籍を分析すると、必ずしもツリーが有効だとは限らないと思うことがあります。書籍の内容をその構造のままツリーでなぞったとしてそれで本当に理解したことになるのか、以前にも書いたような記憶がありますが、構造を一旦解体して再構成することによって、そうやって自分なりにパラフレーズすることによって、より深い理解と洞察を得られるようになるのではないか、とそんなことを考えたりしています。

ネットワーク型のメモソフト - EBt → ...

ちょっと前にユーザーさんから教えて頂いたEBtというソフトウェアを試してみたのですが(#208)、このソフトウェアのコンセプトはPiggydbにとても似ています。いままでPiggydbに似たものとして、WikiとかEvernoteなどを紹介したり、されたりしてきたのですが、このEBtこそがPiggydbと同じようなソフトウェアとして紹介できる初めてのものではないかと思いました。しかもEBtは結構歴史が長いようなので、Piggydbにとっては先輩にあたるソフトウェアです。
EBtのコンセプトはPiggydbよりも遥かにシンプルです。あるのは情報の単位となる「メモ」とそれらをつなぐ「リンク」だけです。はっきり言って、手軽なネットワーク型メモツールが必要なのであれば、Piggydbよりも、このEBtの方が遥かに軽くて使いやすくてオススメです。元々はZaurusというPDA向けに開発されていたということで、モバイル上のアイデアプロセッサとしても最適なソフトウェアだと思います。
情報の構造がネットワーク型になるのはPiggydbと同じですが、EBtのリンクは双方向のつながりであるところがPiggydbと異なる点です。双方向リンクのメリットとして、リンクを辿って進むのも戻るのも同等の操作になるので、ネットワークの移動操作が一元化できるということがあります。
Piggydbの「つながり」は有方向なので、EBtのリンクと比較すると、+αの意味付けが行われていることになります。そういった意味でも、EBtの方がずっとプリミティブなモデルを採用していることが分かります。さらに、EBtでは情報の分類もリンクで行うようになっています。つまり、メモがタグの役割も兼ねています。
このプリミティブなモデルに意味付けを追加していけば、Piggydbのモデルと同等のものが出来上がるわけです。そういった意味で根を同じくするソフトウェアだと思います。
とても興味深いと思ったのは、EBtの作者の方も私と同様の悩みを抱えておられるようで、既存の情報管理というものはツリー構造というものに支配され過ぎているので、こういった自由なネットワーク構造が果たしてどれほど受け入れられるのか、という部分を気にされているようでした。
ツリー構造は、例えば書籍などがそうですが、情報の構成に制約を追加することによって、ある種の分かりやすさを実現しています。ツリー構造は一次元の構造なので、誰でも順序に従って情報を追いかけることができます。しかし、実際に書いている内容はもっと複雑な構造を持っていることがほとんどなので、書籍の構造に束縛されすぎると内容を正しく理解できない恐れがあるわけです。個人的な経験から言えば、こういった「束縛」は結構馬鹿にできないところがあると感じています。
と、ここではこれ以上深入りするのは避けますが、こういったEBtとPiggydb、あるいはその他の情報管理とのモデルの差異を考えていくのは結構興味深いものがあります。
こういった話題が出たからという訳ではないのですが、実は近々Piggydbのモデルをネタにした裏Piggydb研究サイトをスタートしたいと目論んでいます(もちろんPiggydbを使って)。発想法などに興味がある人にとっては必読の内容になるかもしれない(?)ので、お楽しみに。

タギングの可能性

タグはとても柔軟性の高い分類の方法です。
情報を整理するための手法としては、予め分類の体系を作っておき(カテゴリー)、情報をそれらのいずれかに振り分けていく、というトップダウンのやり方が一般的でしたが、タギングはこれと反対で、ボトムアップに情報を分類します。
どのような分類があるのかは気にせずに、その情報に相応しいと思えるラベルを思いつくだけ貼っておいて、同じラベルの付いたものを後から引き出す、というのがタギングのコンセプトです。
Piggydbのタグシステムは、従来的なタグ(ボトムアップ)としての使い方だけではなく、カテゴリーのように予め分類を作っておいて、それらを適用する(トップダウン)という使い方も可能です。必要に応じて両方の使い方が出来るようになっています。
さらにタグはカテゴリーと違って、単なる分類・整理の用途には留まらず、様々な応用が可能です。例えば、自分がやらなければならない仕事の一覧(TODO)を管理したり、情報を共有している他のユーザーに対するメッセージとして利用したり、等等。

何のために「分類」するのか? → ...

そもそも何のために「分類」するのでしょう? おそらく多くのケースにおいて、分類は後々の検索性のために行われるのではないでしょうか。例えば、カテゴリーは、全ての情報が、体系化されたカテゴリーのどこかに必ず所属するという条件を以って、情報の検索性を保証する仕組みです。
しかし検索性を確保するためのカテゴライズは情報量が多くなるに従って必ず破綻することが知られています。いわゆる「こうもり問題」です。また分類という作業は継続的に行うには知的負荷の高い作業です。カテゴリーの多重化などによって「こうもり問題」を解決しても一貫性のある分類を維持するのは至難の業です。よって、分類することは放棄され、情報は時系列に保存しあとは検索すれば良い、ということになります。
これは完全に私の主観的な考えですが、こういったいわゆる情報管理のための整理術云々(書店に行くとそういった書籍が沢山並んでいますが)、というのは全く重要なことではない、はっきり言って、どうでもよいと考えます。それよりも「何か重大な情報を見逃してしまっているのではないかという強迫神経症」から早く解放されるべきです。
ではPiggydbにおける「分類」とは何なのか? それは一言で言えば、「ユーザー自身が学習するため」の分類です。本来分類という作業は機械的にできるものではありません。先程書いたように知的負荷の高い作業です。検索のためのタグ付けであれば、単純にキーワード検索でもいいということになってしまうかもしれませんが、本当の分類(classification)は、そのキーワードが情報に含まれるかどうかとは無関係です。よって、Piggydbではユーザー自身が考えてタグ付けすることが重要です。

フラット(一階層)なタグとフォークソノミー

Web2.0に分類される、多くのインターネットサービスが採用するタグシステムがフラット(一階層)であることには理由があります。複数の人間によって付けられるタグの、意図しない一致による集合知やコミュニケーションの発生を目的にしているためです。いわゆるフォークソノミー(folksonomy)と呼ばれるものです。こういった場ではできるだけコストの低い分類方法が求められます。
Piggydbは、こういったWeb上のサービスとは異なり、情報の共有を個人あるいは少人数に限定することによって、人のメンタルモデルが持つ本来の複雑さをできるだけそのまま表現できるような道具立てを提供する、というのが一つのコンセプトになっています。

できあがった構造を眺めて理解を補強すると共に、フラットな俯瞰を使って常に新たなつながりを発見しに行く

バラバラな情報につながりを作っていく、というのがPiggydb流の知識構築ですが、一度構造が出来上がってくると、その構造に囚われてしまい、新しい発見が少なくなってきます。そこで、マルチカラムビューのようなフラットなビューを利用して、新たなつながりを発見しに行くことが重要になってきます。
Piggydbではその仕組み上、バラバラな情報であるフラグメントの集合の上に、何重にも構造を積み上げることができます。一つの構造を作っただけで満足せずに、新たな視点でのつながりを発見できるよう、様々なビューを使い分けながら試行錯誤すれば、驚くようなアイデアを発見できるかもしれません。

フラグメント・ツリービュー

フラグメントページには、そのフラグメントからつながりのあるフラグメント(子フラグメント)の一覧が表示されています。タイトルの左側にある [+] トグルをクリックすることで、そこからつながるフラグメントをどこまでも辿ることができます。
ツリー内にあるフラグメントコンテンツを見たい場合は、▼ボタンをクリックするとその場でコンテンツを表示させることができます。
ツリーの右上にある「並び替え」ボタンをクリックすると、並び替えモードになって、ドラッグアンドドロップで子フラグメント(直接の子だけ)の順番を変更できるようになります。この順番はデータベースに保存されます。

フラグメント・マルチカラムビュー → ...

マルチカラムビューでは、フラグメントの一覧が複数列に渡って表示されます。そしてこのカラムの幅(厳密には最低幅)は、スライダーによって変更することができます。
マルチカラムは、ウィンドウのサイズによって自動的にカラムの数を調節し、スペースを有効に活用するように設計されていますので、より大きな解像度のディスプレイで威力を発揮します。