- Phrase Network
- Phrase Network とは
- ==== データ構造 ====
- データ単位
- グラフネットワーク
- ==== プール ====
- プール ~plane に phrase を置く前段階~
- ==== ノード ====
- ノードの操作
- 特殊ノード
- ==== グラフ ====
- トポロジー ~繋ぎ方のパターン~
- レイヤーコントロール
- ==== ユーザー ====
- ユーザーカーソル
- おわりに
- 更新履歴
Phrase Network
本文書は Phrase Network についてまとめたものである。このコンセプトを実現するために必要な諸々の要素を定義してみたものだ。
冒頭では Phrase Network の概要と必要性を述べている。以後は、ひたすら関連する概念や操作を述べている。
Phrase Network とは
Phrase Network(pnと略す)とは、phrase(短文) 単位で情報を扱ったりコラボレーションしたりするための仕組みである。
利用者はまず Twitter のように phrase を書いていく。その後、phrase を二次元空間上に並べ、関連付けていくことで整理やコラボレーションを行う。この営みは n 人で行うこともできる。
Chat との違い
チャットはメールに代わるコミュニケーション手段として普及しているが、以下の点が弱い。
- コラボレーションしづらい
- 時系列にメッセージを並べることしかできない
- 今現在盛り上がっている話題にのみフォーカスされており、他の話題を出しづらい
pn ではこの weak collaborative を解消する。pn は n 人が、二次元空間上に、phrase を自由に配置するモデルであるため、時系列の呪いにとらわれない。
Twitter との違い
Twitter は短文の投稿と共有には向いているが、以下の点が弱い。
- 後から参照・活用するのが難しい
- 文脈や関連が保存されていない、「ツイート単位」の羅列しかない
- きりの良い単位の成果物やコラボレーションエリアを確保できない
- たとえば数千文字ボリュームの主張を Twitter だけでつくるのは難しい
- たとえば会議単位ごとのエリアを設けることができない
- ツイートを俯瞰できない
pn ではすべて可能である。
pn では、いわゆる project という単位があり、利用者は必要に応じてつくることができる。また各 project には plane という「レイヤー」ともいうべき単位があり、ここに n 人が自由に phrase を配置していける。レイヤーは複数枚つくれるので柔軟な運用もできる。そもそもレイヤーは二次元空間であるため、phrase の俯瞰も行える。
Scrapbox との違い
Scrapbox はテキストベースの情報管理およびコラボレーションに向いており、n 人同時編集や 10000 ページ以上にも耐えるなどポテンシャル面でのスケーラビリティも備えているが、以下の点が弱い。
- 書き手に要求される素養が高い
- 多数のページや関連を自分でフィルターすること
- 箇条書きを用いて端的に書くこと
- タグで分類せず、リンクでネットワークをつくること
- 自動投稿やコピペに終始せず、自分の言葉で紡ぐこと・加工すること etc
- トピックシェアリング的であること
- 1つのページにn人が書くモデルであり、nを1に集約する何らかの協調・妥協が必要
- いわゆる「場の空気」が発動し、各自がのびのびと書きづらくなる
- かといって各個人用のエリア(personal project)に書けば、他人に読んでもらえない
pn ではどちらも緩和できる。
まず、要求素養については、「短文を投稿する」「二次元空間上に並べて関連付ける」という二つの直感的営為によって緩和する。自然言語で文章を書くことも、文章というパーツの配置と接続で関連付けることも、どちらも特殊な訓練は(さほど)必要とせず行える。少なくとも Scrapbox のように、デジタルの作法や知的生産のセンスを養う必要はない。
次にトピックシェアリングについては、並べるコミュニケーションによって緩和する。pn では n 人全員が phrase を書き、その塊を整理して提示できる。各 phrase は本人以外は修正できない。よって、pn では「n 人全員の意見が並んだ状態」が実現される。無論、意思決定に向けた収束は必要であるが、それは「並んでいる n 人の意見」をベースに行えば良い。トピックシェアリングでは個人の意見は残らないが、pn など並べるコミュニケーションでは残せるのである。
==== データ構造 ====
データ単位
基礎単位「4P」
- Plane
- Plate
- Plot
- Phrase
- Plot
- Plate
Phrase
- 1つの短文
- グラフとしては 1-phrase 1-node に相当する
Plot
- n-phrase から成る塊
- 主な用途
- n の短文を何らかの関連でまとめる
- n の短文から 1 の長文を表現する
Plate
- n-plot + n-phrase から成る塊
- 主な用途
- n の短文やプロットから 1 の「まとまった情報」を表現する
- n 人の意見をまとめたセットを表現する
Plane
- n-plane + n-plot + n-phrase を持つ単位
- 平面を並べて行き来させたり重ねたりするため、Layer のニュアンスでもある
ワークスペース単位「3P」
- Project
- Plane
- Pool
Project
- 一つのワークスペースを表現する単位
- n-(plane,pool) を持つ
Plane
割愛
Pool
- n-phrase を貯める単位
- ユーザーはまず pool に phrase を投下し、その後、pool 内の phrase を plane に配置していく
- pool は plane とは切り離され、各ユーザーの持ち物として管理される
詳細はプールの項を参照。
グラフネットワーク
pn は phrase をノードとしたグラフ構造とも言える。
本節では、pn の性質をグラフ的な見方から整理する。
グラフ
- plane は n-グラフを持つことができる
ノードとエッジ
- ノードは phrase である
- エッジ
- phrase と phrase を繋ぐ( リンク という)
- 有向である
リンク
内部リンク(inlink)
- ノードは基本的に同一 plane 内でのみリンクできる
- これを 内部リンク という
- 内部リンクは何本でも張れるが、同じノードには 1 本だけ張れる
外部リンク(exlink)
- ノードは、異なる plane にあるノードにもリンクできる
- これを 外部リンク という
- 外部リンクは、異なる plane に対して 1 本のみ張ることができる
表面から表面にリンクするということ
一般的にリンクには以下の 4種類がある。例とともに示す。なおここでいう in や ex は、上述の inlink や exlink とは関係がないため注意。
- in-in: Scrapboxの
[ページ名#XXXXXXXXXXXXXXXXXXXXXXXX]
- in-ex: Scrapboxの
[ページ名]
- ex-in: -
- ex-ex: ★pnが扱うのはここである
in とはリンク先オブジェクトの「内部」を指すものだ。Scrapbox は基本的にこの形態で、from としてはページ内の本文単位で行う。また、to としては、行リンクを使えば in になる。
pn では、from も to も ex のみ扱う。表面から表面にリンクすると言っても良い。これにより、リンクは「phrase」というノード同士を繋ぐものになる。phrase の本文(詳細)レベルをいちいち気にする必要がなく、ノードという単位で関連をつくっていける。
==== プール ====
プール ~plane に phrase を置く前段階~
pn には pool と plane があると述べた。ユーザーは phrase をまず pool に吐いていき、その後で plane に配置していく。これにより、Twitter でツイートするような直感的なやり方で書ける。
Pool is private
プールはプライベートな領域であり、本人以外が見ることはできない。
Pool is not a content
プールは plane が保持する情報 ではない。
たとえば plane を export しても、プールに書いた情報は出力されない。プールはプライベートなものだから当然である。
Pool is personal
プールはパーソナルな領域であり、保存場所は layer ではなく各個人の領域である。
したがって、plane-A を削除したからといって、そこで書いた(プール内の)phrase が消えることはない。phrase 自体は、その人の持ち物として保存されている。ただ「作業場所だった plane-A はもうなくなってます」のような警告を表示するだけである。
==== ノード ====
ノードの操作
基本的な CRUD は割愛する。
リンク(link)
ノードAからノードBに繋ぐこと。
アンリンク(unlink)
リンクを解除すること。
コピー(copy)
ノードを複製すること。
内部的には id が異なるだけであり、phrase の内容そのものは全く同じになる。ただしリンク情報はコピーしない。
コピーの挙動は deep である。そのためAをコピーしてBをつくった後、Bをいじっても、Aは変更されない。
同期コピー(sync)
ノードを同期すること。
ノードAを同期してノードBをつくると、ノードBは以下の性質を持つ。
- 内容を直接変更できない
- ノードAの内容が常に反映される
- リンクは行える
- ただしノードAのリンク状況は反映されない
- ノードAが削除された場合、その時点で同期を停止する(コピーと同じ挙動になる)
- 同期コピーは行えない
主な用途
- timer node などを自分(が活動している場所)の近くに表示しておく
- n 人のサマリーノード(自分の見解を一言で表現した phrase)を同期コピーして一箇所に配置することで、俯瞰できるようにする
- 「何かあったらノードAの中身を書き換えてコメントしてね」と周知した上で、ノードAを自分の近くに表示しておく
- 誰かがコメントすれば書き換わるので気付ける
🐰 煩雑かなぁ。実装も複雑だろうし。
トポロジャイズ(Topologize)
複数のノードに対して、ネットワークトロポジーの基本形を構築すること。
以下をサポートする。
- Line
- Star
- Ring
操作として右記の順となる――トポロジャイズ開始、n個のノードを順に選択、どの基本形を構築するかを選択。つまり、選ばれた順番に従って基本形を構築する。line の場合は選ばれた順に繋ぐ。star の場合は1番目に選ばれたノードを中心にする。ring の場合は line に加え、最初に選ばれたノードと最後に選ばれたノードも繋ぐ。
グルーピング(Grouping)
複数のノードを一つのグラフとみなすこと。
いわゆる「グループ化」であり、グルーピングされたノード群はまとめて操作できる。対応操作には限りがある。たとえば削除、コピー、二次元空間(plane)上の配置変更などが行える。
グルーピングは空間的な(視覚的な)グループ化である。二次元空間上で線で囲むと、その内部にあるノードすべてをグループ化するイメージ。この性質上、グルーピング情報は内部的にデータとして保存する。
グラファイズ(Graphize)
複数のノードを一つのグラフとみなすこと。
グラファイズは論理的なグループ化であり、選択したノードから辿れる部分グラフ(閉路)を検出してグループ化する。グルーピングとは違い、内部的にはデータを持たない(都度検出するだけである)。
活用について。ある部分グラフG上のノードAを操作する際、通常はノードAのみが操作対象となる。が、ここでグラファイズを行うと、部分グラフGが操作対象となる。いちいちグルーピング操作を使わずとも、Aから辿れる部分すべてを対象にできるという点で利便性が高い。
特殊ノード
phrase はノードだと述べたが、ノードには他にもいくつかの種類がある。
phrase node
pn におけるノードは基本的にこれ。一つの短文を表現する。
視覚制御系
pointer node
何らかの uri を表現するノード。
内部的には phrase node だが、視覚的表現(アイコン)が異なる。phrase ではなく uri であることを視覚的に強調するために使う。
また、uri を pointer node としてつくっておくと、あとで「参考情報の一覧」を取り出すのが楽になる(pointer nodeを列挙するだけで良い)。あるいは(pn 開発者の目線になるが)layer や project に「参考情報一覧」機能をつくるのも良い。
ちなみに uri の記述は強制ではない。本質は所在を記すことであるため、たとえば「ロッカーの A3 棚」などと書いても良い。
warp node
ある plane において、2 点間を(リンクを張らずに)繋ぐノード。必ず 2 ノードでワンセットとなる。
warp node は見た目がごちゃごちゃしそうなときに使う。たとえば繋ぎたいノードAとBがあるとして、そのまま繋ごうとするとごちゃごちゃするという場合、ワープノードWをつくり、AとW、BとWを繋ぐ。
warp node は、手続き型プログラミングで言えば goto 文のようなものである。多用すると、いわゆる「スパゲッティ」状態を生み出すため注意が要る。
走査系
starting node
ある plane において、「ここから読み始めると(辿り始めると)良いですよ」を示したノード。1-plane 1-starting-node。
block node
「ここから先は辿らなくてもいいですよ」を示したノード。1-plane N-block-node。
block node は、layer の essential export 時に使われる。具体的には block node を行き止まりとみなし、その先を辿らないようにする。これにより、エッジ(リンク)を設定していながらも「ここから先は辿らなくていい」と指示できる。
リアルタイム更新系
timer node
時刻、ストップウォッチ、カウントダウンなどを刻むノード。
counter node
カウントを行うノード。
利用者がこのノードに対してカウント操作を行うと、値が +1 される。
vote node
投票を行うノード。
このノードは選択肢を持っており、利用者は選択肢を一つ選べる。選ぶとその旨がグラフとして反映される。
以下はA,B,C,Dさんが投票した例である。
+----->B
|
[selection-3]
A
|
[vote-note]
| |
| |
V V
[selection-1] [selection-2]--->E
| |
| |
V V
A D
==== グラフ ====
トポロジー ~繋ぎ方のパターン~
plane は phrase をノードとしたグラフと言えるが、ノードの繋ぎ方には主なパターンがある(名称はネットワーク・トポロジーの基本系とほぼ同じ)。
Dot
1
2
4
3
繋がりがなく点在している状態。
頻繁に組み替えたい場合や、脳内で思考したい場合によく使う。
Line
1--2--3--4
主に文章や時系列を表現する。
Star
2--1--3
|
4
Mediator(仲介者)とも呼ばれる。主従、親子、抽象と具現、収束と発散など利用例は多い。
Ring
1--2
| |
4--3
Closed Chain(閉路)とも呼ばれる。終点から始点に戻れるという意味で、Line よりも利便性が高い。
Tree
1--2--3
| |
4 5
|
6--7--9
|
8
主に文書構造を始めとした何らかの分類構造を表現する。
Mesh
+-----+
| |
1--2--3
| | |
+--4--+
怪しい臭い(Smelly)を示す。メッシュは phrase の整理が上手くいっていないことを示す。
レイヤーコントロール
pn では plane 上に phrase を配置していく。plane は言わば「レイヤー」であり、ある phrase 群が載った一枚の世界と言える。
このレイヤーはしばしば複数枚を運用することになる。pn としても使い方、使い分け方、連携方法などを定めているため、本節にて解説する。
※データ単位としての正式名称は plane であるが、layer(レイヤー)の方がニュアンスとしてわかりやすいため、本節では後者の言葉を使う。つまり plane = layer。
レイヤーは n 枚つくれるが、1-main n-sub 構造となる
project には n 枚の layer をつくることができる。
layer は必ず 1 枚の main layer を持つ。main layer 以外はすべて sub layer となる。
レイヤー間リンクは main から sub の方向しか行えない。すなわち Star 型になる。
例:
[sub-layer] +--->[sub-layer]
A |
| |
[main-layer]--------------
| |
| V
V [sub-layer]
[sub-layer]
レイヤー間リンク
phrase と phrase はリンクで繋げることができるが、基本的に同一 layer 内でしか繋げない。
しかし 各 phrase は、異なるレイヤーに対しては、1つのみリンクを繋げることができる。上記のとおり main-sub 制約もあるため、結論を言うと main layer に存在する各 phrase は、各 sub layer ごとに 1 つだけリンクを繋ぐことができる となる。
レイヤー操作
基本的な CRUD はできて当たり前なので割愛する。
Duplicate
ある layer-a を、layer-b として複製する。
- b は必ず sub layer になる
Copy
ある layer-a 内の 部分グラフ を、layer-b に複製する。
- b は main layer も指定できる
- たとえば個人用 sub layer で仕上げたグラフを、main layer にコピーできる
- b は a と同じでも良い
- たとえば main layer 内の部分グラフを複製できる
Duplicate との違い
- Duplicate は
- main から sub をつくる操作である
- layer 単位で複製する
- Copy は
- main から sub でも、sub から main でも可能(一方向ではなく双方向)
- layer 単位ではなく、laner 内のグラフ単位
- 同じ layer 内でも行える
Extract
ある layer-a 内の部分グラフを、layer-b として切り出す。
- b は必ず sub layer になる
Merge
ある layer-a の内容を、layer-b にマージする。
- a 側のすべてのノードとエッジを、b 側に追記する挙動となる
- node1@a と node2@b が同じ phrase 内容だからといって重複処理は発生しない
- (phrase にはすべて固有のidが振られておりオブジェクトとして別物である)
- node1@a と node2@b が同じ phrase 内容だからといって重複処理は発生しない
- マージ時、layer のどの部分に描画するか(この場合は b のどの部分)はそのとき選ぶ
Export
ある layer の内容を、様々な形式でエクスポートする。
エクスポートの形式の例
- Readble Text
- txt
- markdown
- HTML
- Parsable Text
- XML
- json
- Image
- SVG
- PNG
- JPEG
Export は可逆的であり、バックアップや移行用途として使える。
Essential Export
ある layer の内容の「要点」をエクスポートする。
要点とは、starting-node から辿れるグラフである(詳細は特殊ノードの項を参照)。
Essential Export はあくまでも for human(人間が読む用)であり、不可逆的である。たとえば node の配置情報(二次元空間上のどこに何があるか)は出力しない。もちろん、Essential Export したデータを import することもできない。
レイヤーコンセプト
上記のような設計になっている理由を記載する。
管理や分類に忙殺させない
layer を無秩序に作成・リンクできるようにすると収拾がつかなくなる。
pn では 1-main N-sub、main から sub へのリンクのみ許す、sub へのリンクは layer ごとに 1 つのみ、と制約を課すことで秩序を与えている。これにより利用者は、基本的に main で活動を行い、本質でないものを sub に分ける(そして必要ならリンクを張る)というシンプルな運用に強制される。
無尽蔵なデータストアではない
pn の触発元である Scrapbox は 10000 ページでも破綻しないポテンシャルを持っているが、pn はそうではない。また肥大化するデータに対処する仕組みもサポートしていない。
pn は汎用的で長期的な用途としては想定されていない。あくまでも特定の仕事やコラボレーションを解決するための一時的手段にすぎない。たとえば pn にて全体像が明らかになった後は、タスク管理なり文書化なりツールのフィールドを移すべきだし、別の仕事やコラボレーションが必要になったのなら新たな project を立てるのが良い。
ベストプラクティス
ここで挙げたテクニックはごく一部にすぎない。
共通して言えることは、main layer ではコラボレーションに集中し、それ以外の非本質は sub layer に切り離す(必要なときに見に行けば良い)ことである。
定義レイヤーをつくる
用語の定義を書いた phrase を集めたレイヤー。
コラボレーションにおいて共通理解は重要である。その根幹を支えるのが(用語の)意味の統一だが、これを実現するためには定義を書くしかない。しかし、main layer に定義を並べてしまうと layer 内がごちゃごちゃするため、定義を扱った専用の layer をつくる。それが定義レイヤーである。
定義レイヤー(内のphrase)へのリンクは適当に行う。「この言葉の意味はこうですよ」と強調・周知したい場合に使っても良いし、片っ端から使っても良いだろう。
個人ワークレイヤーをつくる
自分ひとりだけが自由にいじれるレイヤー。
main layer は共同エリアであるため、(自覚がなくとも心理的にどうしても)のびのびと活動しづらい。そこで自分用の sub layer を設け、まずはそこで作業すると良い。
ただし、個人ワークレイヤーが行き過ぎると main layer がただのお披露目場になってしまい、コラボレーションが促進されない。コラボレーションは、皆が main layer を同時編集することで実現できる。多用には注意が要る。
履歴レイヤーで履歴を保存する
現時点の main layer を複製して保存したのが履歴レイヤーである。その名のとおり、main layer の履歴を保存することができる。
特にドラスティックな変更を行う前後で保存すると良い。適宜保存しておくことで、(後で戻せるようになるため)思い切って作業しやすくなる。
決定事項レイヤーをつくる
会議において pn を用いる場合、決定事項をどう記述していくかという問題がある。無論、main layer に並べても良いが、main layer は作業エリアであり「変化しないもの」を置いておくのはあまり適さない。そこで、決定した事項は sub layer に保存しておく。これを決定事項レイヤーという。
決定事項レイヤーにより、利用者は main layer では作業に集中できる。決定事項を見たければ、sub layer を見れば良い。
決定事項レイヤーには「決定事項そのもの」と「それを支える背景や根拠」を両方置くと良い。前者を目立たせておき、後者は必要に応じて辿れるようにする。もっとも、後者を整理するのは手間であるから、最悪そのまま(main layer で作業していた時の状態)で置いても良い。
決定事項レイヤーの粒度は、1-決定事項 1-sublayer が良い。
==== ユーザー ====
ユーザーカーソル
カーソル
plane は n 人が同時編集できる。各ユーザーは カーソル を持っており、これが plane 上で動く。
ユーザーの操作はカーソルから反映される。たとえば A さんが phrase を追加したり、phrase-A と phrase-B にリンクをつけたりするときは、その部分には A さんのカーソルが表示されている。これにより、A さんがそういう行動をしているのだとリアルタイムに知ることができる。
仕事同居性を高める
カーソルの主目的は、仕事同居性(仕事中の「一緒にいる感」)を高めることである。
人は社会的動物であるため同居性を求めるが、リモートワークでは不足しやすい。しかし都度対面会議を設定するのもコスト面や自由度の面で望ましくない。
カーソルであれば、対面会議ほど強制約的ではないが程々の同居性を確保できる。たとえばカーソルの有無により誰がいるかがわかるし、カーソルの動き方やそこから映えている内容を見れば誰が何しているかもわかる。カーソルの集まり方次第で盛り上がりを表現することもできる。
カーソルミュート
自分のカーソルは一時的に非表示にできる。これを カーソルミュート という。
カーソルミュートは、監視の目を緩めるための機能である。もしミュートできない場合、休憩したい場合やサボりたい場合にカーソルが止まったままに見えてしまい不信感を与える。ミュート機能があれば、ミュートすることでそのような状態を曖昧にできる。
Q: ミュート≒サボっていると取られないか?
Ans: そうはならない。
なぜなら人は心理上、不要なときはカーソルを自ら非表示しにいくからである。
たとえば他人の活動を見たい場合、愚直にカーソルを合わせにいくと相手にも見えてしまうが、ミュートしてから見れば相手には気付かれない(覗ける)。そのような自己隠蔽的な使い方を皆が行えば、カーソルミュートは自然な営為となる。「ミュート=サボっているかもしれないが、皆普通に使うことだからまあそういうものだ」という認識に収束できる。
Q: ミュートを解除し忘れたらどうなる?
Ans: ある程度は仕組みで防げる
たとえば以下の仕組みを入れる。
- ある plane 上でカーソルミュートしているユーザー A が、その plane 上で活動を再開した場合、A のミュートを自動で解除する
- plane presence を設ける
- ある plane P をユーザー A が開いている場合、P には「Aさんは今ここにいます」という情報(plane presence)を表示する
- A が P を閉じた場合、plane presence もなくなる
おわりに
本文書では Phrase Network を実現するための諸々――特に概念と操作まわりを定義してみた。Phrase Network を形にする上でのたたき台となるだろう。
筆者はつい最近、Teeting(テキスト会議) や トピックピック なども検討した。テキストコミュニケーションのあり方や可能性を変えたくて、色々と足掻いているのだと思う。
更新履歴
- 2021/11/18 v0.0.1
- 初版
- 2021/10/19 開始