まずはとことんツナガリだけで構造化してみよう

結びの言葉に代えて。
  1. Piggydbを図解風にボトムアップ思考で使いたいなら、まずはとことんまでツナガリだけを使ってフラグメントを構造化することに挑戦してみよう。
  2. その中で、これだけは特別な関係だ、これは俺だけの閃きだ、これは私だけの新鮮な発見だ、というフラグメントの構造を見つけたら、そこだけ特別にタグフラグメントを使って、『ID810番』をしてみよう。
    1. このとき、既存のツナガリを削除する必要はない。ダブって良い。それが二重構造。だからこそ、『ID810番』。

これにて、#800から始まった一連の簡易説明を終わりたいと思います。皆様、お付き合い頂きまして、本当にどうもありがとうございました。
あくまでも、まだ今の段階では、私の脳内シミュレーションを行っただけの思いつきに過ぎません。いろいろと粗やケアレス発想などあるかも知れませんが、試してみる価値のあるアイデアだと自分では思っています。
早足で簡易な説明となりましたが、私の意図がmarubinottoさんやPIggydbユーザーの皆様に僅かでも伝わり何らかのヒントとなれば幸いです。
改めましてmarubinottoさん、素敵な知的生産ツールであるPiggydbを開発し続けて下さり本当にどうもありがとうございます。
P.S.
Piggydbユーザーの皆様に知の実りがありますように。

実験的に"つながり"をツナガリとカタカナ表記してみました。どうも、つながりだけは平仮名なので、他の単語と比べて、浮くんですよね。だから""と強調するのが癖になってしまっています。ただ、つながりが平仮名で表現されていること、他の単語と少し違うこと、それ自体にもなんとなく意味を感じたりする瞬間もあるんですよね。

イメージを共有出来ていれば、情報の断片でも理解を得られるかもしれない

実は今、私の頭の中に知的生産の技術に関する1つのアイデアがあります。しかし、その手法を紹介するためだけにサンプル例を探して実践する時間の余裕が、残念ながら今の私にはありません。
最後の図解化から文章化ですが、ここにはまずこの作業自体をそもそもやろうとしないという決定的な問題があります。KJ法を単なる情報の整理法だと考えている人に特にこの間違いをする方が多いのではないかと思います。
又、上記で書かれているようにKJ法や発想法のゴールは文章化だそうなので、piggydb.jpで文章で説明できるレベルにまで、自分のプライベートなPiggydbで実践を重ねたら、その時に紹介させて頂きたいと思います。
ただし、そのアイデアはmarubinottoさんが抱いている今現在抱いているイメージに類似しているかもしれない、という気がしています。元々、marubinottoさんが最近仰っていること、そして過去に仰った内容にとても刺激を受けているので、類似することは決しておかしくないのですが。ここで伝えたいことは、イメージが類似している、していない、オリジナルの画期的な発想か否か、ということではありません。
もし、marubinottoさんのイメージと私のイメージが類似していれば、すなわち、私がmarubinottoさんのコメントの意図の少なくとも一部を理解していることになると思います。逆に言えば、もし両者が類似していれば、私のアイデアの断片だけを紹介しても、marubinottoさんには理解して頂けるかもしれない、ということです。
その可能性を信じて、この後のフラグメントからそのアイデアの簡易な説明をpiggydb.jpで行わせて頂きたいと思います。その説明は、Piggydbを実際に使わないと実現できないものになるからです。また、普段はウェブ上と言うことで自粛している、Piggydbらしいフラグメントの使い方をさせて頂きたいと思います。
一連の説明が終わりましたら、終了宣言をさせて頂きますので、少しだけ私に説明の場をお貸し下さい。どうぞよろしく御願い頂きます。

『ドアコン(仮称)』(ID801番) → ...

 まさにその瞬間、彼の脳裏にハッとイメージが浮かんだ。そのイメージこそ、今彼の脳内宇宙を駆けめぐっている疑問への答えそのものである。と、彼は理屈抜きに確信していた。彼はそのイメージを脳内宇宙で何度も反復し、暗唱し、そのイメージを確かな言葉、キーワードとしてから、おもむろに明かりをともした。のっそりと体を起こすと、枕元から愛用のメモ帳を取りだしお気に入りのペンでそのイメージのキーワードを書き記した。
「――――」と。
 そこで、彼はふと思いとどまった。このイメージは本当にキーワード、問題を解く鍵そのものなのだろうか。むしろ、ドア、入り口のようなものではないか。そう思い立った瞬間彼の脳内宇宙に知的快感が波となって押し寄せた。新たなイメージ達が、次から次へと波に乗って彼の脳内宇宙に押し寄せてきた。
 ドア。入り口。鍵。ゴール。ドアは1つか。いや複数だ。ドアの集合体。コンプレックス。ドアコンプレックス。シネコン。シネマコンプレックス。ドアコン。ドアコン、これこそが新しいキーワードだ。いや、またキーワード? それじゃあ矛盾する。座標。ID。固有識別番号。無感情。先入観の排除。キーワードは先入観を招き、想像力を阻害する。本当にこのイメージはドアコン、だけなのか。驚異の部屋。(博物学)。新鮮な素材。たくさんの様々な種類の新鮮な素材。市場。食材の市場。青空市場。うん、やっぱり多数のイメージがある。座標。そうこのドアの座標だけがあればいい。その座標からたくさんの四次元ドアが広がっている。! タグフラグメント。名前のないタグ。フラグメント番号を機械的にIDとして割り振れば。やっぱりPiggydbはスゲェ。スゲェよ。タグフラグメント。名前のない括り。タグフラグメント。・座標ID。・ドアコンプレックス。・キーワードは付けない。・ゴールではなくこれが、入り口。・先入観を排除し、想像力の広がりを。・食材の市場。タグフラグメント。・座標ID。・ドアコンプレックス。・キーワードは付けない。・ゴールではなくこれが、入り口。・先入観を排除し、想像力の広がりを。・食材の市場。タグフラグメント。……。
 ひとしきりイメージの波が落ち着いた後、彼はまたそのイメージを思い返した。
 一度、二度。
 最初からもう一度。
 どんな風に連想したのか、ゆっくりと思い出した。
 ふーっと深呼吸を挟む。
 そして、もう一度イメージを反芻する。
「……よし、もう大丈夫だ」
 彼は、自分の脳内宇宙が、最低限の落ち着きを得て、仮組みではあるがイメージを構造的に記憶できたことに安堵感を覚えてペンを取った。その時、彼の脳内宇宙に知的快感の余韻はもう無かった。彼の脳内宇宙では大迫力のビッグウェーブだったが、現実世界の紙にインクを引けば、それがとてもちっぽけなものに見えた。それが文字だろうが、絵だろうが、図解だろうが、皆同じ事だ。A6のメモ帳の見開き1ページ。客観的に見てまさに手のひらサイズだ。
 客観的。
 そう、彼はもう自分のアイデアを客観的にみれるまでに落ち着いていた。先ほどまでの彼は、自分が天才だと錯覚していたが、今はもう正常だ。彼は自分が凡人であることをよく知っている。あいにく、彼は酒を飲んだことがなかったが、『酔いが覚める』とはまさにこういう気分を指すのだろう。
 だが、彼は知ってもいた。複雑怪奇で入り組んだアイデアの方がいかにもかっこよさそうだが、現実に役に立つのは、短く小さく圧縮された情報であること。シンプルで分かりやすい組み方をされたアイデアであること。
 そして、分かっていた。それでもそのアイデアは現実の世界において、とてもちっぽけなものであるとも。現実には、同じように圧縮され、シンプルに組み立てられた情報がたくさん集まって、本になり、辞書になっていることを。だから彼は謙虚に素直に、そしてポジティブに思った。
「良い道に向かって、一歩前に進めた。今日は良い日だなぁ」

----

作者注。

この描写は長いです。後半部分は1フラグメントに1コンテキスト、という原則から見たら蛇足。後半部分があることで、複数のコンテキストが存在してしまっている。ただ、ストーリーの余韻としてはあっても良いかなと思い、残しました。

また、後半部分のコンテキストも知的生産に関する素敵なコンテキストである気がしていますし、また前半部分のコンテキストとのつながりも大事に記録しておきたいとも感じています。

事後的に発見されるアイデアとは? → ...

アイデアとその実現を別々に考える、というのは、おそらく今でも多くの人にとって自然な考え方でしょうし、特に組織においては支配的な考え方だと思います。まずブレインストーミングなどでアイデアを出すフェーズがあり、そのアイデアに対して評価を行い、その後に、良さそうだとされたアイデアの実現に向けて行動を開始する。
しかし、実際はそのようなやり方が機能することはほとんどなく、組織で生み出されるものは概して流行を追いかけるものばかりだったりします。
現代において新しくて価値のあるものを生み出そうとするなら、ほぼ例外なく、探索的な手法を取らざるを得ないのではないかと思います。トライアル&エラーで常に学習しながら軌道修正していかざるを得ない。その探索の結果を後からまとめたものがアイデアとなる、つまり、そのように事後的にしか発見し得ないのが画期的なアイデアだと思うのです。
探索的、というのは進捗が堂々巡りになったときのクリエーターの言い訳にも聞こえますが、今では探索的な手法を如何に制御可能にするか、予測可能にするかという観点に立ったプロジェクトの管理手法も多く提案されていますし、今後ますます重要な考え方であることは間違いありません。
とは何か?
それは、「”つながり”で構造付けられたフラグメント群の『ID816番』がタグフラグメント化した時に発見されたアイデア」の事ではないだろうか?

まずはとことんツナガリだけで構造化してみよう → ...

結びの言葉に代えて。
  1. Piggydbを図解風にボトムアップ思考で使いたいなら、まずはとことんまでツナガリだけを使ってフラグメントを構造化することに挑戦してみよう。
  2. その中で、これだけは特別な関係だ、これは俺だけの閃きだ、これは私だけの新鮮な発見だ、というフラグメントの構造を見つけたら、そこだけ特別にタグフラグメントを使って、『ID810番』をしてみよう。
    1. このとき、既存のツナガリを削除する必要はない。ダブって良い。それが二重構造。だからこそ、『ID810番』。

これにて、#800から始まった一連の簡易説明を終わりたいと思います。皆様、お付き合い頂きまして、本当にどうもありがとうございました。
あくまでも、まだ今の段階では、私の脳内シミュレーションを行っただけの思いつきに過ぎません。いろいろと粗やケアレス発想などあるかも知れませんが、試してみる価値のあるアイデアだと自分では思っています。
早足で簡易な説明となりましたが、私の意図がmarubinottoさんやPIggydbユーザーの皆様に僅かでも伝わり何らかのヒントとなれば幸いです。
改めましてmarubinottoさん、素敵な知的生産ツールであるPiggydbを開発し続けて下さり本当にどうもありがとうございます。
P.S.
Piggydbユーザーの皆様に知の実りがありますように。

実験的に"つながり"をツナガリとカタカナ表記してみました。どうも、つながりだけは平仮名なので、他の単語と比べて、浮くんですよね。だから""と強調するのが癖になってしまっています。ただ、つながりが平仮名で表現されていること、他の単語と少し違うこと、それ自体にもなんとなく意味を感じたりする瞬間もあるんですよね。

つながりの構築に掛ける手間、タグとの二重構造、はムダではない。

おはようございます。magicianです。昨日の投稿から一日が経ち、自分の中でいろいろと整理が出来てきたので、少しmarubinottoさんのコメントや、Piggydb.jpからの引用を中心に、昨夜の一連の流れを補足したいと思います。というのも、昨日の一連の投稿は、要するに私の中でmarubinottoさんの過去の発言意図がようやく"生の理解"されはじめてきたことだと感じているからです。今、過去のmarubinottoさんの発言を読み返すと、新鮮な驚きがたくさんあります。まずは、Piggydbが考える二段構えの知識構築より。
Piggydbが考える二段構えの知識構築
最近、Piggydbをバリバリ使っているのだけど、これは本当にいいものだなあと、恥ずかしいぐらいに自己満足なんだけど、思ってしまう今日この頃。
ちょっとした調べものなら、タグなど使わずに、つながりだけを使ってゆるく情報を構成していくだけでも、かなり便利に使える。
まずは調べたいテーマを表すフラグメントを作ってから、その下に入手した情報をぶら下げていく。大切なのは、テーマの下にいきなりカテゴリや区分けを表すフラグメントを作らないこと(始めから構成を固定してしまう人がかなり多い)。最初はとにかく手に入れた情報をそのままぶら下げていく。そして、ある程度フラグメントの量が増えてきて見通しが悪くなって来たなと感じたら、どうやって整理するかを考える。このようにして、自己発生的にツリーを構成していくのが基本になる。
単に情報をツリー上に構成していくだけだったら、あらゆるツールでできる、それこそテキストエディタでも可能なんだけど、Piggydbの本領はその先にある。例えば、重要だけどツリーの深いところにあるフラグメントに対して、上の階層のフラグメントから直接つながりを作ったり(これは本当によくやる)、既にできあがった階層の中を横断するようなグループ分けを新たに作ったり。サブフラグメントの順序を気軽に並び替えられるのも便利で、いろいろ考えながら、並び替えたり、整理したりするのはなかなか楽しい。
ここまでの、情報を収集して整理するプロセスだけでも結構使えるのだけど、その先に従来とは違う「タグ」の世界がある。集めた情報から何かを立ち上げていくプロセスである。これについては、いずれきちんとした説明を書かないといけないんだろうと思う。
情報を沢山集めて、その中からある結論(コンセプト)を立ち上げる、そういった知識構築を行う場合は、つながりだけでは不十分で、コンセプトの中核を成す構造と、それらを根拠づけるための材料となる情報との区分けが必要になってくる。中卒の自分が言うと説得力がゼロなんだけど、学術論文とかはそのように書かれるものだと自分は理解している(書いたことないけどね)。
こういった知識構築術というのは、学者だけではなくて、ジャーナリストや批評家、さらには小説家のような創作に関わる人たちでも、意識的、あるいは無意識的に行っているはずである。
このいわゆる二段階の情報構成という観点からは、まだまだ機能の改善が必要なのだけど、V5.0で行ったタグフラグメントの導入がいかに重要だったかというのは、このような理由によるわけだ。
ただ少なくともPiggydb.net周辺の議論では全く理解されている雰囲気がないので、より機能を洗練させていかなくてはならないし、説明も必要だと思う今日この頃な訳である。
この記事の内容が今ではすんなり理解できます。今、思えばこの記事も何度も読んだのに、なぜ今のように理解できなかったが不思議ですが、それはおそらく「つながりとタグが重なることへの違和感」が合ったんでしょうね。一見、非効率的なやり方なのですよね、この記事のやり方は。基本的に、情報の入力を効率的に、マニュアル的に行うならば、最初の記事入力の段階でタグで整理していった方が、効率的なのですよ。
また、Piggydbを使っていく内に、どうしてもぶち当たる壁の1つに、「つながりでもタグでもどちらでも表現できる情報の構造を"どちらで"表現するか?」というものがありますが、その考え方がそもそも違っていたんですよね、多分。今の私なりの答えは、「基本的には、つながりで作り、その上で必要ならばタグID810番していく。両者が重なるというムダ、非効率さこそが、実はPiggydbの二重構造の本当の価値」です。
なので、「Piggydbにおける情報入力の効率性」の優先度を大幅に引き下げた最近の私だからこそ、この記事をすんなり理解できるようになったのだと思います。やはり、良いものにはそれなりの手間を掛けるべきなのでしょう。(逆に、情報入力の効率性を突き詰めたら、Evernoteで良いと言うことになるので、この非効率性こそがPiggydbの差別化ポイントであり、隠された利点、なのではないでしょうか。もちろん、Piggydbが情報入力のインターフェイスを改善し、更に進化するのは大歓迎です。とくに、つながりの周辺は、marubinottoさんも進化させるおつもりのようなので、今から楽しみです。とにかく今回の論点は、学問に王道なし、ということでしょう。
そもそも根本的に、図解的、ボトムアップ的、Piggydb的、なタグの運用の仕方をするのであれば、凡人の頭では"この記事ならこのタグ"というというゴールに、最初の記事入力の段階でたどり着けるはずがないのです。つまり、記事入力の段階でタグを当てはめるという作業は、どうしても、検索のためのタグ付け、自分の把握している既存のカテゴリー分類をトップダウン的に当てはめるタグ付けになりがちである、と私は考えます。
最近のPiggydbが、キーワードによる検索能力を高める更新を行っているのも、逆説的にこの考えを裏付けているように感じます。marubinottoさんは、Piggydbにおいて「情報の入力時における検索時の視点の必要性、を出来る限り低くしよう」となさっているのではないでしょうか?

コンセプトの中核を成す構造と、それらを根拠づけるための材料となる情報との区分け

ここまでの、情報を収集して整理するプロセスだけでも結構使えるのだけど、その先に従来とは違う「タグ」の世界がある。集めた情報から何かを立ち上げていくプロセスである。これについては、いずれきちんとした説明を書かないといけないんだろうと思う。
情報を沢山集めて、その中からある結論(コンセプト)を立ち上げる、そういった知識構築を行う場合は、つながりだけでは不十分で、コンセプトの中核を成す構造と、それらを根拠づけるための材料となる情報との区分けが必要になってくる。中卒の自分が言うと説得力がゼロなんだけど、学術論文とかはそのように書かれるものだと自分は理解している(書いたことないけどね)。
やっと、つながりで構造をつくる、という入り口に辿り着いたところなので、タグフラグメントの運用面についてはまだあまり実感がありません。これから自分のPiggydbをこの方式で実践していく中でしか、つかめないのかもしれませんが、marubinottoさんによる「きちんとした説明」を受けられる日を楽しみにしています。(もしかしたらもう既にあるのかもしれませんね、探してみます)

コンセプトの文脈を支えるタグフラグメントの二層構造 → ...

#651で見つけたブログ記事(「KJ法は発想支援ツールとして有効?」)で展開されている考察がなかなか興味深かったので、ここからちょっと展開してみたいと思います。
このブログの筆者であるyama氏は、キーワードを中心にした共同作業でのアイデア創造手法(KJ法の変形)について、
私をして違和感を持たせたというのは、おそらく、提出させられた「キーワード」の裏にあるアイディア、そしてその背景、文脈が全く切り取られたかたちで議論の俎上にあげられたということだったように思う。... しかし、複数の参加者が、突然、「キーワード」あるいは「一行見出し」のみをならべ、相互の関連を考察しようとしても、何も新しい発想など生まれる筈がない。「一行見出し」がそれに代表されているリッチな内容が参加者間で了解されていないからだ。こうした議論が、表面的なもので終わるのは不思議なことではない。
という感想を述べておられますが、これは全くその通りであると私も思いました。
キーワードや見出しの質にもよるとは思いますが、発想のために重要なのはその背後にある膨大な文脈の方であって、キーワードはあくまで結果に過ぎないと思うのです。
面白いと思ったのは、このキーワードを中心としたある種の恣意的な連想ゲームというのは、この記事にある研究会の中だけではなく、現在のメディアを媒介した一般的なコミュニケーションにおいても同様のことが展開されているという点です。
特にインターネット上のコミュニケーションでは、こういった現象がますます加速していって、キーワードから完全に文脈が排除され、受け手の好きなように解釈・再利用されるという感じになっています。
私自身は、これはいわゆる創造的なプロセスとは逆行するものではないかと考えていて、故に共同作業でのアイデア創造についても懐疑的に考えざるを得ないと思ったりしています。
Piggydbではコンセプトタグフラグメントというもので表現しますが、これは試行錯誤の結果発見されたコンセプトにせよ、これから調べたいと考えて、予め設定されるコンセプトであるにせよ、その下に膨大な文脈情報をぶら下げることができるようになっています。
タグフラグメントとは「タグとしても使えるフラグメント」のことですが、このタグフラグメントはつながりとタグという二つの経路を使って他のフラグメントと関連付けることができます。以下のスクリーンショットのように、二層のグループ化されたフラグメントを持つことができるわけです(上部がつながりによるもので、下部がタギングによるもの)。
http://piggydb.files.wordpress.com/2011/08/full-fledged-tag-page.png
コンセプトを下支えする情報が二層化されることによって、コンセプトにとってより本質的な情報はつながりで接続、単に関係がある情報はとりあえずタギングしておく、という感じで、関連情報を振り分けながら、コンセプトの輪郭を作り上げていくことができます。あるいはその過程で、別のコンセプトを発見したりということも起こりやすくなります。
創造的なプロセスを実現するためには、膨大な文脈情報をいかにうまく構成できるかというのがキーポイントで、それをタグフラグメントによる二層構造で表現してみよう、というのがPiggydbのアプローチです。

包摂の二重性問題

「つながりでもタグでもどちらでも表現できる情報の構造を"どちらで"表現するか?」
これは今までに何度も書いていますが、かなり重要な問題だと思っています。ヒトの認識・認知的にも根拠があるようなので、近々考えを書いてみようかなと思っています。概念的包摂と構造的包摂の認識問題ですね。
「両者が重なるというムダ、非効率さこそが、実はPiggydbの二重構造の本当の価値」というのも、この包摂の二重性問題に関わっているので、なかなか的を得ているかもなあと思いました。自分も良く分かっていないことが多いので、開発を続けながら理論的な部分を詰めていきたいところです。

つながりの意味が、分かった時にタグフラグメントが生まれるんだ。 → ...

見た目が悪くなってしまい残念ですが、一番シンプルなモデルで表現してみました。AとBのフラグメントの間にあるつながりの意味を考え、その意味が「対義語だ」分かったとき、その意味と意味が支配する範囲をタグフラグメントで規定する。その時、タグフラグメントは名詞でなく、文章で良いのです。むしろ、文章の方が良いかもしれません。
ここでの注意点は、タグは決して、共通点を括ったときにのみ発生するものではないということです。(以前の私の考えとは変化してきていますので、ご注意下さい)

タグフラグメントが 指し示す中心と周辺 → ...

フラグメント群をつながりで構造化し、つながりの意味が見えたとき、その意味とその意味が支配する範囲をタグフラグメントで規定しよう」という考えの内、タグフラグメントが 指し示す中心と周辺に関するイメージ画像です。

フラグメントを人に見立てて、チームにしてみた。

フラグメントを人に見立てて、チームにしてみた。
  1. とにかくフラグメントを作って、思った通りにどんどんつなげてみよう。
    1. 後から考えると、これヘンだなぁっていうつながりがあっても大丈夫だから、なんとなくつなげたいと思ったら、どんどんつなげてみよう。
  2. そのうちに、いろんなつながりで構造化されたフラグメントたちの中に、特に強調したいフラグメントたちが見つかるかもしれない。その時は彼らのリーダーをタグフラグメントにして、全員に同じユニフォームを着せて1つのチームにしてみよう。
    1. 今までのつながりはそのままにしておいていいよ。それでも、タグフラグメントのチームになって同じユニフォームを着たことで、ほかのつながりとは違うっていうことが分かるようになったよね。
  3. こうして、チームをいっぱい作っていこう! その時、チームが出来ないつながりやフラグメントも出てくるけれど、残念、それは仕方がないことなんだ。でも、いつか彼らのチームが見つかる日が来るかもしれないよ。
    1. だから、チームはきちんと作らないといけないけれど、つながりは思いつきで作っても大丈夫なんだけど、それは何故かな? その理由がちゃんと分かったら、キミは今日から一人前のPiggydb監督だ!

ゆるやかなタグと重み付けされたタグフラグメントの差異と区別

camiさんの想定されているものとは少し異なるかもしれませんが、強い関係(つながり)と弱い関係(タギング)という二層化されたグルーピングを提供するのがタグフラグメントなんですね。
たとえば、あるタグフラグメントを起点として考えた場合、まずそのフラグメントに「もしかしたら関係あるかも?程度の繋がり」のあるフラグメントをタギングで関連付けておきます(タグフラグメントタグとして貼り付ける)。これが情報収集の段階です。これはゆるい関係なので、いわゆるつながりのようにきちんとした構造(例えば順序)を持たせるわけではなく、単にグルーピングされている状態です。その後、当該タグフラグメントにとって重要だと思えるフラグメントをタギングからつながりに移行させて構造を作っていきます(この移行作業を簡単にできるようにしていく予定です)。これが、Piggydbで提案しようとしている知識構築(情報の重み付け)の核心部分です。タグフラグメントのページを見ると、上部につながり、下部にタギングと、二層のグループがあることが分かるかと思います。
つまり、ゆるい関係はタグによるグルーピングで表現した方が良いかも、ということなのですが。なんとなく関係しているなというフラグメントの集合を選択して、一括タグ付けする機能は既にありますので。

タグは、いわゆるフォルダ的なカテゴリー分類よりも柔軟な分類手段です。私も当初は疑いなくタグが有用なものだと思ってPiggydbに導入しました。ところが、やはりというか「分類」というのは鬼門でした。データベースが大きくなるにつれて、分類の体系を維持するのが難しくなることに気づきました。何故なら、利用者自身が学習によってよりよい分類方法を発見するからです。そうなった場合、過去のタギングをさかのぼって修正するのは容易ではありません。
結果的に、軽はずみにタグを使うのは良くないな、と考えるようになったわけですが、その一方で、情報を蓄積・整理していく過程で、重要になっていく情報を浮き立たせる手段として、タグが使えるのではないか、という考えがありました。
タグを使わずに、フラグメントとつながりだけで情報を構成していると、情報収集の中心となっているフラグメントがあることに気づきます。それらのタイトルは、自分がフォーカスしている問題だったり、重要なコンセプトを表していたりします。こういったフラグメントを後からタグに変換して、もっと広範囲の情報を収集したり、表示したりできるようにすれば良いのではないかと考えるに至りました。
今までのタギングというのは、コンテンツの中から適当にキーワードをピックアップしたり、自分が知っているカテゴリーの中から選択する、というのが一般的だったのではないかと思います。タグを付ける際、後々どのようなキーワードでその情報を特定できれば便利だろうかと考えるわけですが、Piggydbの利用方法が探索的になればなるほど、その予想は外れる、あるいは利用者自身の成長によってタグツリーが陳腐化してしまう可能性が高くなります。
そこで、タグの役割を少し変えてみて、データベースの中から自然発生的に現れるタグ、あるいは利用者のフォーカスを表すためのタグという形にシフトさせたらどうなるだろう、というのが今回導入されたタグフラグメントで実験しようとしていることです。

上記の2つのバランスを取るためには、つながりとタグの図 解 Piggydb風 | davinci noteの図にある「共通のフラグメントとつながりでつなげる」をイメージすると良いのかなと、漠然と思っています。つまり共通のフラグメントがゆるやかなグルーピングのタグのような役割をするわけです。情報の入力はタグに比べて少し煩雑になりますが、後々にタグフラグメントなどと混ざって混乱することが無くなる方が有益ではないかなと。

強い関係と弱い関係 → ...

camiさんの想定されているものとは少し異なるかもしれませんが、強い関係(つながり)と弱い関係(タギング)という二層化されたグルーピングを提供するのがタグフラグメントなんですね。
たとえば、あるタグフラグメントを起点として考えた場合、まずそのフラグメントに「もしかしたら関係あるかも?程度の繋がり」のあるフラグメントをタギングで関連付けておきます(タグフラグメントタグとして貼り付ける)。これが情報収集の段階です。これはゆるい関係なので、いわゆるつながりのようにきちんとした構造(例えば順序)を持たせるわけではなく、単にグルーピングされている状態です。その後、当該タグフラグメントにとって重要だと思えるフラグメントをタギングからつながりに移行させて構造を作っていきます(この移行作業を簡単にできるようにしていく予定です)。これが、Piggydbで提案しようとしている知識構築(情報の重み付け)の核心部分です。タグフラグメントのページを見ると、上部につながり、下部にタギングと、二層のグループがあることが分かるかと思います。
つまり、ゆるい関係はタグによるグルーピングで表現した方が良いかも、ということなのですが。なんとなく関係しているなというフラグメントの集合を選択して、一括タグ付けする機能は既にありますので。
camiさんの想定とはちょっと違うかなという気もしないではないですが、、、あるいは、ちょっとした具体例があると、もう少し検討しやすくなるかもしれません。

タグを中心にした知識の構築 → ...

なんとか正式版のV5.0をリリースするところまで持ってこれました。この5.0で導入したタグフラグメント#454)について、混乱している方も多いと思いますので、ここで改めてその意図について説明してみたいと思います。
Piggydbは、いろいろな情報を入力しつつ、それらを「つながり」や「タグ」によって柔軟に整理することができる、情報管理システムです。Piggydbという名前から想像できるように、ある程度形式が定まったデータベースとして利用される方が圧倒的に多いようです。
しかし、このデータベース的用途とは異なる、Piggydbの真の目的があります。それは、あらゆる角度でつながりを作ることによって、発想を刺激し、新しいアイデアの発見を促す、より創造的なツールになることです。
整理法などの本を読むと分かりますが、情報を探しやすくするために情報を分類・整理することは、あまり費用対効果が高い作業ではありません。情報の量と種類が多くなればなるほど、管理が難しくなります。探すことにフォーカスするのであれば、高度な検索機能があれば事足ります。とりあえず何でも保存しておいて、あとから検索すればいいわけです。実際にそのようなツールは沢山あって、それらの機能は信じられないほど高度になっています。
Piggydbでは、もうちょっと情報を形作る部分にフォーカスしようと考えました。そこで、つながりやらタグやらを持ち込んだのですが、、、当初はあんまり深く考えていなかった部分もあり、いろいろと思い通りに行かない部分が出てきました。その一つがタグです。
タグは、いわゆるフォルダ的なカテゴリー分類よりも柔軟な分類手段です。私も当初は疑いなくタグが有用なものだと思ってPiggydbに導入しました。ところが、やはりというか「分類」というのは鬼門でした。データベースが大きくなるにつれて、分類の体系を維持するのが難しくなることに気づきました。何故なら、利用者自身が学習によってよりよい分類方法を発見するからです。そうなった場合、過去のタギングをさかのぼって修正するのは容易ではありません。
結果的に、軽はずみにタグを使うのは良くないな、と考えるようになったわけですが、その一方で、情報を蓄積・整理していく過程で、重要になっていく情報を浮き立たせる手段として、タグが使えるのではないか、という考えがありました。
タグを使わずに、フラグメントとつながりだけで情報を構成していると、情報収集の中心となっているフラグメントがあることに気づきます。それらのタイトルは、自分がフォーカスしている問題だったり、重要なコンセプトを表していたりします。こういったフラグメントを後からタグに変換して、もっと広範囲の情報を収集したり、表示したりできるようにすれば良いのではないかと考えるに至りました。
今までのタギングというのは、コンテンツの中から適当にキーワードをピックアップしたり、自分が知っているカテゴリーの中から選択する、というのが一般的だったのではないかと思います。タグを付ける際、後々どのようなキーワードでその情報を特定できれば便利だろうかと考えるわけですが、Piggydbの利用方法が探索的になればなるほど、その予想は外れる、あるいは利用者自身の成長によってタグツリーが陳腐化してしまう可能性が高くなります。
そこで、タグの役割を少し変えてみて、データベースの中から自然発生的に現れるタグ、あるいは利用者のフォーカスを表すためのタグという形にシフトさせたらどうなるだろう、というのが今回導入されたタグフラグメントで実験しようとしていることです。
と、長々とタグフラグメント導入の経緯を書いてきましたが、この考え方が必ずしも多くの人に受け入れられているわけではなく、実際には反対意見も多くて、いろいろと議論も行われました。私自身もこの方法を取り入れてから日が浅いので、必ずうまく行くという保証は出来ませんが、良い感触は得ています。なにより、Piggydbの真のゴールである「創造的なツール」を目指すためには、失敗を恐れずにいろいろと試行錯誤していくしかありません。

つながりを作りやすくする3つの更新

#742 Piggydb 6.11 リリース - 「インクリメンタル・キーワード検索」 では、現在選択しているフラグメントを表示したまま、検索することが出来るので、つながりやタグ、特につながりを作るのが、今までよりもとても手軽に行えるようになっていますね。
この時に#668 Piggydb 6.8 リリース - 「スマートレイアウトの改良」 を活用するとより便利ですね。画面を縦に3分割(されないときは、ブラウザの文字サイズを縮小すると3分割されます)すると、更につながりを付けやすくなります。
#784 Piggydb 6.12 リリース - 「IDによるピンポイント検索」 では、ウェブブラウザのタブ機能で多くのページを開いているときに、違うタブで開いているフラグメント同士でつながりやタグ、特につながりを作りたいときに、非常に便利です。
この3つの更新は、フラグメントのつながりによる構造化、を基本にPiggydbを使っていくときの大きな助けになりますね! 改めて素晴らしい機能の追加、本当にどうもありがとうございます。

ID810番

重み付け → ...

重み付け

つながりの構築に掛ける手間、タグとの二重構造、はムダではない。 → ...

おはようございます。magicianです。昨日の投稿から一日が経ち、自分の中でいろいろと整理が出来てきたので、少しmarubinottoさんのコメントや、Piggydb.jpからの引用を中心に、昨夜の一連の流れを補足したいと思います。というのも、昨日の一連の投稿は、要するに私の中でmarubinottoさんの過去の発言意図がようやく"生の理解"されはじめてきたことだと感じているからです。今、過去のmarubinottoさんの発言を読み返すと、新鮮な驚きがたくさんあります。まずは、Piggydbが考える二段構えの知識構築より。
Piggydbが考える二段構えの知識構築
最近、Piggydbをバリバリ使っているのだけど、これは本当にいいものだなあと、恥ずかしいぐらいに自己満足なんだけど、思ってしまう今日この頃。
ちょっとした調べものなら、タグなど使わずに、つながりだけを使ってゆるく情報を構成していくだけでも、かなり便利に使える。
まずは調べたいテーマを表すフラグメントを作ってから、その下に入手した情報をぶら下げていく。大切なのは、テーマの下にいきなりカテゴリや区分けを表すフラグメントを作らないこと(始めから構成を固定してしまう人がかなり多い)。最初はとにかく手に入れた情報をそのままぶら下げていく。そして、ある程度フラグメントの量が増えてきて見通しが悪くなって来たなと感じたら、どうやって整理するかを考える。このようにして、自己発生的にツリーを構成していくのが基本になる。
単に情報をツリー上に構成していくだけだったら、あらゆるツールでできる、それこそテキストエディタでも可能なんだけど、Piggydbの本領はその先にある。例えば、重要だけどツリーの深いところにあるフラグメントに対して、上の階層のフラグメントから直接つながりを作ったり(これは本当によくやる)、既にできあがった階層の中を横断するようなグループ分けを新たに作ったり。サブフラグメントの順序を気軽に並び替えられるのも便利で、いろいろ考えながら、並び替えたり、整理したりするのはなかなか楽しい。
ここまでの、情報を収集して整理するプロセスだけでも結構使えるのだけど、その先に従来とは違う「タグ」の世界がある。集めた情報から何かを立ち上げていくプロセスである。これについては、いずれきちんとした説明を書かないといけないんだろうと思う。
情報を沢山集めて、その中からある結論(コンセプト)を立ち上げる、そういった知識構築を行う場合は、つながりだけでは不十分で、コンセプトの中核を成す構造と、それらを根拠づけるための材料となる情報との区分けが必要になってくる。中卒の自分が言うと説得力がゼロなんだけど、学術論文とかはそのように書かれるものだと自分は理解している(書いたことないけどね)。
こういった知識構築術というのは、学者だけではなくて、ジャーナリストや批評家、さらには小説家のような創作に関わる人たちでも、意識的、あるいは無意識的に行っているはずである。
このいわゆる二段階の情報構成という観点からは、まだまだ機能の改善が必要なのだけど、V5.0で行ったタグフラグメントの導入がいかに重要だったかというのは、このような理由によるわけだ。
ただ少なくともPiggydb.net周辺の議論では全く理解されている雰囲気がないので、より機能を洗練させていかなくてはならないし、説明も必要だと思う今日この頃な訳である。
この記事の内容が今ではすんなり理解できます。今、思えばこの記事も何度も読んだのに、なぜ今のように理解できなかったが不思議ですが、それはおそらく「つながりとタグが重なることへの違和感」が合ったんでしょうね。一見、非効率的なやり方なのですよね、この記事のやり方は。基本的に、情報の入力を効率的に、マニュアル的に行うならば、最初の記事入力の段階でタグで整理していった方が、効率的なのですよ。
また、Piggydbを使っていく内に、どうしてもぶち当たる壁の1つに、「つながりでもタグでもどちらでも表現できる情報の構造を"どちらで"表現するか?」というものがありますが、その考え方がそもそも違っていたんですよね、多分。今の私なりの答えは、「基本的には、つながりで作り、その上で必要ならばタグID810番していく。両者が重なるというムダ、非効率さこそが、実はPiggydbの二重構造の本当の価値」です。
なので、「Piggydbにおける情報入力の効率性」の優先度を大幅に引き下げた最近の私だからこそ、この記事をすんなり理解できるようになったのだと思います。やはり、良いものにはそれなりの手間を掛けるべきなのでしょう。(逆に、情報入力の効率性を突き詰めたら、Evernoteで良いと言うことになるので、この非効率性こそがPiggydbの差別化ポイントであり、隠された利点、なのではないでしょうか。もちろん、Piggydbが情報入力のインターフェイスを改善し、更に進化するのは大歓迎です。とくに、つながりの周辺は、marubinottoさんも進化させるおつもりのようなので、今から楽しみです。とにかく今回の論点は、学問に王道なし、ということでしょう。
そもそも根本的に、図解的、ボトムアップ的、Piggydb的、なタグの運用の仕方をするのであれば、凡人の頭では"この記事ならこのタグ"というというゴールに、最初の記事入力の段階でたどり着けるはずがないのです。つまり、記事入力の段階でタグを当てはめるという作業は、どうしても、検索のためのタグ付け、自分の把握している既存のカテゴリー分類をトップダウン的に当てはめるタグ付けになりがちである、と私は考えます。
最近のPiggydbが、キーワードによる検索能力を高める更新を行っているのも、逆説的にこの考えを裏付けているように感じます。marubinottoさんは、Piggydbにおいて「情報の入力時における検索時の視点の必要性、を出来る限り低くしよう」となさっているのではないでしょうか?

まずはとことんツナガリだけで構造化してみよう → ...

結びの言葉に代えて。
  1. Piggydbを図解風にボトムアップ思考で使いたいなら、まずはとことんまでツナガリだけを使ってフラグメントを構造化することに挑戦してみよう。
  2. その中で、これだけは特別な関係だ、これは俺だけの閃きだ、これは私だけの新鮮な発見だ、というフラグメントの構造を見つけたら、そこだけ特別にタグフラグメントを使って、『ID810番』をしてみよう。
    1. このとき、既存のツナガリを削除する必要はない。ダブって良い。それが二重構造。だからこそ、『ID810番』。

これにて、#800から始まった一連の簡易説明を終わりたいと思います。皆様、お付き合い頂きまして、本当にどうもありがとうございました。
あくまでも、まだ今の段階では、私の脳内シミュレーションを行っただけの思いつきに過ぎません。いろいろと粗やケアレス発想などあるかも知れませんが、試してみる価値のあるアイデアだと自分では思っています。
早足で簡易な説明となりましたが、私の意図がmarubinottoさんやPIggydbユーザーの皆様に僅かでも伝わり何らかのヒントとなれば幸いです。
改めましてmarubinottoさん、素敵な知的生産ツールであるPiggydbを開発し続けて下さり本当にどうもありがとうございます。
P.S.
Piggydbユーザーの皆様に知の実りがありますように。

実験的に"つながり"をツナガリとカタカナ表記してみました。どうも、つながりだけは平仮名なので、他の単語と比べて、浮くんですよね。だから""と強調するのが癖になってしまっています。ただ、つながりが平仮名で表現されていること、他の単語と少し違うこと、それ自体にもなんとなく意味を感じたりする瞬間もあるんですよね。

タグフラグメントにはいくつの要素が詰まっているのだろうか? → ...

タグフラグメントをいくつかの要素に分けてみる。特に、私なりのやり方、Piggydbをボトムアップ中心で図解風に使っていく場合、という視点で分けてみる。
  • "つながり"で構造づけることができる。
    • 名前を付けることなく、図解のように"線でつなげたり"することができる。
  • タグフラグメントで『ID810番』する事が出来る。
  • 本文を表現できる
    • 名前を与えられる(=本文に対応した一行見出しを作ることが出来る)

以下は、Piggydbをボトムアップ中心で図解風に使っていく場合のイメージ作りには役に立ちますが、タグフラグメントの『ID810番』を重視する場合にはあまりオススメしないやり方です。(フラグメントの『構造』は"つながり"で作るべきだと考える場合)

『ID#810』をする=◯◯◯◯をする、イメージを#810フラグメントとその周辺から考えて下さい。 → ...

以後は、『ID#801』,『ID#810』,『ID#816』等という風に入力、表記していきたいと思います。これが一番シンプルで楽だと感じたので。(自動でリンクが張られるので)。
極端な話、単に#801だけでも話は話は通じると思うんですよ。例えば、
どちらも、-"つながり"で『構造』を作り、"タグフラグメント"で◯◯◯◯をする。という◯◯◯◯の間の言葉を#810フラグメントとそれにつながるフラグメント、それを規定するタグなどからイメージして下さい、よろしく御願いします、という事なので。ただ、他の単語との最低限の差別化のための飾りは必要かなと考え、『ID#801』とすることにしました。
IDをQID(Question ID)にしようかなとも一瞬思いましたが、そもそもQuesutionとは限りませんし、この仕組みの名称自体、『ID#801』で思案中な訳なので。
時間もないので特に遡って表記を修正したりはしませんが、今後はそうしていきたいと思いますので、どうぞよろしく御願い致します。