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

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

マインドマップについて

最近、Piggydbのユーザーさんに以下のような記事を紹介して頂いて、マインドマップについてちょっと考える機会がありました。まだ考えがまとまっているわけではないのですが、思うところをつらつらと書いてみます。
ちなみに上記の記事にはマインドマップを作るツールの一覧が紹介されているので、興味がある人にはとても有益な記事だと思います。
マインドマップという言葉は既に大変な売り物になっていて、インターネットや書籍上には美麗辞句が溢れています。コンセプトがシンプルで、グル的な人物がいて、コミュニティが出来ていて、門番的な人間があちこちにいる。こういう場合に「マインドマップとは何か」ということについて書くと罠にはまるので、そこに言及するのは避けて、そのコンセプトの構成要素から重要だと思えるものを「適当に」ピックアップして、それらについて考えてみることにしました。
以下が、マインドマップから取り出したコンプセプトの一覧です。
そして、以下はそのコンセプトから考えられる特徴の一覧です。
以下、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を使って）。発想法などに興味がある人にとっては必読の内容になるかもしれない（？）ので、お楽しみに。

ツリービュー、アウトラインビュー → ...

EBtのツリーで、カレントメモを起点として両手が同じメモにつながっている構造を最初に見たとき、「何じゃこりゃ？」とすごく違和感があったのを覚えています。ところがだんだん使い慣れてくると、理屈は抜きにしてメモを探しやすい。メモをたぐっていって自分の見つけたいものが出てくると、検索した方が早かったんじゃないかと思いながらも、自分の頭を使いながら探している感覚が快適でとてもいいです。
Piggydbのフラグメントだと例えば#224は#209からつながっていることは見えますが、#209が何とつながっているかはそこまで移動しないと分からない（末端のフラグメントを開いているときはアウトラインビューもツリービューも使えない？）ですよね。
EBtでもその事情は劇的には違わないのですが、常にツリービューでメモ間を動けるのと移動のレスポンスが軽快なのとで、全体を俯瞰したり捜し物をするのに重宝しています。

「構造」と「機能」からPiggydbのモデルを分析する → ...

ここ数日、タグについてのとても有意義な議論（#240より）が展開されていて、いろいろと刺激になっています。Piggydbの機能の背後にあるコンセプトやそこから派生するいろいろな考え方などは、研究サイトで検討しようと思っていたことで、こちらに載せるつもりはなかったのですが、せっかく機会を頂いたので、ちょっとログ的に書いておきたいと思います。
（注意）以下には無根拠な妄想が多分に含まれるので、あんまり真剣に読まないように。
以前に私のブログを読んだことがある方ならご存じの方もおられるかもしれませんが、私は、物事について考えるときに、「構造」と「機能」という概念が極めて強力なツールとして機能すると感じています。「構造」と「機能」は人間の認知の根幹を成すもので、人間が何かを認識する際、同じものを見ていても、構造的に捉えるか、機能的に捉えるか、基本はこの二つだけで説明できてしまいます。何故なら、これらの認知は人間の知覚器官に由来する云々、、、（略）
Piggydbはテキストや画像のような静的なデータの集まりを扱うツールなので、これについて分析する際は、「機能」は「意味」と言い換えた方がいいでしょう。
さて、まずこの道具立てを用意したところで、件の議論で比較の対象となっているEBtとPiggydbの違いについて考えてみます。EBtについては認識違いがあるかもしれないことは予めご了承下さい（間違いがあれば訂正します）。
#224でも書いたように、EBtの基本要素はメモとリンクだけです。Piggydbはそれに加えて、リンクに方向があり、タグという仕組みがあります。
「構造」と「意味」の枠組みで考えると、EBtで表現しているのはほぼ「構造」だけです。その構造がどのような「意味」を持つかはすべてユーザーの解釈に委ねられています。例えば、リンクはただつながっている以上の意味はなくて、つながりの意味は何なのか、例えば、従属関係なのか、あるいは修飾の関係なのか、といったようなことは表現されておらず、ユーザーの解釈次第です。以上のような特徴がEBtの柔軟性の高さの理由ではないかと思います。
と、これを書いた後にEBtの仕様を改めて見てみると、リンクにラベルが付けられるようになっているんですね。しかも、ラベルは方向別に付けられるようになっているようです。これは進化の方向としては凄く正しい気がします。というのも、リンクが具体化する過程でタグ的な概念が生じてくるからです。ますます興味深いEBt、、、
Piggydbでは、EBtにおいては暗黙に意識しているような「意味」も表現手段に加えていると解釈できると思います。つながりに方向があるのは、視点を意識しているためです。例えば、A → B と B → A は異なります。Aの視点から見たBとの関係とBの視点から見たAとの関係は異なるからです。つまり、これは「意味」を単位にしているということです。タグも同様です。タグというのは、情報の「意味」を表すために純化して設計された仕組みです。
以上のように、わかりやすさ、柔軟性の高さはEBtの方が優れているわけですが、では、Piggydbには+αの表現力を追加しているとして、それが何の役に立つのかという部分が問題になります。と実はこれが今後の研究課題だったりします。一つ言えるのは、Piggydbはメモやアイデアツールとしてはややオーバースペックなのではないかということです。このことが原因で、件の議論にあるように、タグとつながりに関する混乱が起きてしまうのだと思います。
こうやって考えると、Piggydbはかなりモデリングツールに近いような感じです。ああやはりと言うか、そうなる理由は個人的にはよく分かります。基本的に自分の思考パターンがそうなっているからでしょう。モデリングツールとしての力を十分に発揮できるようにするためには、また別の戦略が必要になるんでしょうね、、、
ひとつここで注意しておきたいのは、以上の議論はあくまでモデルについてだけの話で、アプリケーションの機能自体は別のパラメータとして議論する必要があるということです。だから本当は、上記のように単純な比較はできないのが実際のところです。