wiki はストックで blog はフロー、という考えで
- 某ツールはストック (※)
- Qiita Team はフロー
みたいな感じで皆捉えているけども、よく考えるとなぜ Qiita Team はフロー、と当然ように納得してしまっているのか。思考停止しているのではないかということを今少し思った。
仮に自分が同じようなものを作るとしても、一つのツールでフローとストックを両方面倒みれる道具にするには、ここを掘り下げて考えきれないといけない。
※ 元々社内文書として書いた文章なので、ツール名を伏せてある
なぜそんなことを思ったかといえば、Qiita Team じゃない方の Qiita は、Google で何か悩みがあったときに検索するとよくヒットして、その内容を元に問題を解決したりよくしていることから、フローではなくストック文書的な性格を持っていると感じる。
例えば以下のような文書がそれにあたる。
昨日 Google で検索してこれを見つけて非常に役に立った。タイムラインでおいかけていて見つけたわけでなく、検索でみつけた。そしてこれはかりに社内文書だったら「wiki に書こうよ」と言われそうな内容である。
自分はこの文書はストック的な文書を探すようなユースケースで発見した。実際これは昨年 12月に書かれたものだが少し時間が経った 1/22 に発見した。時間が遅れて発見されているという点に、文書のストック的性格がよく表れている。
ここから、この緑色の Qiita とほぼ同じ仕組みの Qiita Team のはずなのに、Qiita Team を「ただ単に blog のような体裁を持っているから」という理由だけでフローを処理する道具と断定するのには、実は認知の歪みがありそうだと感じた。
おそらく Qiita Team を作ってる人たちは、「wiki はストック、blog はフロー」とはとらえていなくて、「wiki 的なものをフローのようにも使える」という風に作った結果がこれなんじゃないか、と想像している。(だから wiki 機能がない。)
一方で、ユーザーは Qiita Team を使うと「wiki 機能が欲しい」と必ずといっていいほど考える。その差になっているのは何なのか。つまり、 Qiita Team に、wiki 的な、ストック的性格の強い文書を残した場合に問題になるとユーザーが暗黙的に感じていることは何なのか。
Qiita Team を wiki のように使うつもりの視点で評価するとその辺が見えてくるはずだ。
- 検索はできる
- 編集履歴は残る
- 共同編集もできる。ただし、あくまで「できる」でありこれで「やりたい」と思うかは別
- 承認なしでの共同編集はできない
- 文書そのものをツリーで構造化してメニューを作ることができない
あたりだろうか。
こう考えると、この後者、文書をディレクトリ型で管理したり、そのディレクトリ階層を利用して、下位概念をまとめる上位概念にある文書 (たとえば下位概念: 議事録、上位概念: プロジェクトトップページ) みたいなページを表現できない、ということがおそらく問題の本質ではないかという気がした。
決して
- wiki のような見た目になっていないとか
- フローの文書でストック的な文書がどんどん流れて行く
ということは全く問題ではない。
前者に関していえば、それは単にユーザー側の認知の問題であって、ユースケースには何ら影響を与えないのであれば問題外である。
後者に関して言えば、wiki の場合確かに流れてもいかないけど、タイムラインもないから「その新規に追加された文書に気づかない」わけで、どちらかといえばどんどん流れていきはするけど目に触れる可能性があるというだけで、流れていくほうがまだマシ、つまりこれも実は問題のように見えて問題ですらない (wiki では問題を内包しているけど実は顕在化しないだけ) だと考えられる。
文書のディレクトリ型階層での管理ができるとか、ページメニューが作れるというのがおそらく「wiki 的な機能が欲しい」と思うことの正体で、その次ぐらいが相手の承認なしで共同編集できること、なんじゃないかと自分は仮定した。
前者が主な課題として、考えていく。
このとき思うのは、確かにディレクトリ型での管理ができると一見うれしいのだけど文書を探すにあたっては、おそらく通常業務のうち 90% くらいは検索によってその検索要求が解決されるんじゃないだろうか。Yahoo! が廃れて、Google が台頭した歴史を我々はよく知っている!!
Qiita Team ではないほうの Qiita はまさにそれで、Qiita の中をタグやそのほかの手段で文書を探していくということはほとんどなく、Google で検索したら Qiita にぶつかりました･･･ということがほぼすべてである。
ディレクトリ型で階層的にまとめられることが効力を発揮する場面は、その階層的にまとめられた領域の知識をまとまって手に入れたい、というときである。(あるいはディレクトリツリーそのものをみて文書同士の関係性からその領域の知識をアウトラインとして獲得したい、つまりより抽象度の高い表現が欲しいときである。)
たとえば自分が何か既に進行中のプロジェクトにアサインされたとき、そのプロジェクトに関する文書を追いかけてキャッチアップしたいとか、そういうとき。こういう場面は、普段の業務の中で結構ある。
そしてさらに考察を進めると Qiita Team では、その
-「同じプロジェクトに関する文書をまとめる」的なユースケース
を、
- ディレクトリ型で文書を階層管理できる
ということではなく
- タグによって文書同士を関連づける
ということで解決することを期待して設計されている、と感じた。たとえば障害報告には「障害報告」というタグを付与することでまとめることができる。
確かにこれは理に叶っている部分があって、例えば、wiki で階層構造で文書を管理していると、実はその文書は複数の階層にまたがる文書である、というときに困ることがある。
例えばインフラの障害報告のつもりで書いた文書が、実はほにゃららプロジェクトの文書でもあるというとき
- インフラ関連文書の下に置くべきか
- それともプロジェクト関連文書の下に置くべきか
ということに頭を悩ませることになる。タグなら、一つのタグに二つのタグをつければいいのでこれで悩むことはない。
そういでば、そもそも今では死後になりつつあるフォークソノミーというのはまさにそういう考え方だった。階層型構造での文書管理はもう古い、ゆるやかにタグで関連づけるのが正解だという話だったはず。
そんなわけで、実は Qiita Team はストック文書を管理するのにも利用できるように設計されている。ただ
- タグを使ってフロー的な目的で書かれた文書をストック的文書に昇華させる
ということと
- 通常の wiki のようにディレクトリ型で文書を管理できる (という Qiita Team にはない機能)
とが本来的には実は似たような目的を果たす･･･ということを、ユーザーが自分で認知できるかということに、かなりギャップがあって、そういう風には認識されていないのだと思う。
あとは、タグだけでは、プロジェクトトップページや wiki のトップページのようなダッシュボード (ポータル) 的性格のページを作るのが難しい、というのも大きな理由かもしれない。
でも、よくよく考えてみると「ポータル」とか「ディレクトリ型」とか Web 1.0 っぽくてださいというので Web 2.0 のときにそれらを「タイムライン」と「タグ」という概念で置き換えてきたのがこれまでのウェブの歴史だったんじゃないの? というきもする。
とまあこんなことをいったって、使う人の多くがこれを wiki 的に使うという発想に至らないのであれば、そのように使ってもらうように納得してもらうのは難しいとも思える。
それから、今回はあまり考察しなかったけれど、ディレクトリ型で管理できないということの副作用で「ダッシュボード的ページを作り上げることができない」というのが、実は結構大きな問題なのかもしれない。ということも書いていて思った。
自分的には 某ツール がストック、Qiita Team がフローという現在の方針に異を唱えるものではないけれども、Qiita Team (やそれに似たようなツール) が、ストック的には使えないと断定するのはやや早計ではないかと思っている、というポジションであることを明確にするため、この考察を書いた。
たぶん、長くてみんな読まないと思うけど。そういう風にアイツは考えているんだな、ということが伝われば、現時点ではそれでいい。
+1