業務向け情報共有サービスに私が求めるもの
Markdown Night 2017 Summer - connpass で色んな話を聞けて刺激を受けたものの、その後の懇親会で自分の問題意識・欲求がいまいち上手く伝わらない・伝えられないことに気づいたので、自分なりに整理(?)しておきます。
TL; DR. 社内マニュアル向けシステムには、情報の構造化と新陳代謝を支援して欲しい
10年以上前から Wikiの一つを チーム内マニュアル書きに使ってきたものの、長年不満を感じている。 Wiki も色々有るし、更にもっと良さげな情報共有サービスも色々出てきたので、 実は既にこの問題は解決されているのかもしれないけれど… とにかく自分の問題意識を書き下しておきたい。
オーソドックスな Wiki の特性
- ページはページの名前で識別されリンクされる (例外: tcler’s wiki)
- ページの追加は、既存のページに(新ページへの)リンクを書くことで始まる
- 既存ページと新ページの間には、単にリンクが貼られている以上の(システム的)関係は無い(例えば「このページは元ページの子ページである」という情報は、システム内には記録されない。 (例外: redmine )
- ページの並び、という概念も存在しない。ゆえに、親ページ上に並んだリンクの順番はあっても、それに基づいて子ページ間に「前へ←、→次へ」のようなページャを配置することは、手作業になる (…sphinx ベースの wiki ってあるのかしら?)
- ページ内については wiki 記法で章立て・構造化をすることが出来るが、これが検索の単位と連動するとは限らない。 (例外: mediawiki)
要するに、Wiki で書かれたページ群は、(Wiki 奉行でも配して特別な注意と労力を払わない限り) ランダムに更新され成長してゆくグラフ・ネットワーク に近い構造に至る。
ページ群がランダムグラフに至ると、誰がどう困るか
- 新人教育で、教える側が困る。
- 指導用の教材は一本道に整理したいが、ページャのリンクを手書きはやってられない。
- 教わる新人が困る
- 読むべき資料が一本道の木構造なら、要する努力も見積もれるが、グラフでは底なし。
- ベテランも日々困る
- 検索をセクションで部分木に絞り込めないので、全マニュアルから各人が案件ごとに書いたアンチョコが無限にヒットする。が、どれが正しいか、今のオススメはどれか、今見ているページが古くないか…全くわからない。
- 検索が弱いので、重複した内容の、けど少しずつ違うマニュアルを各人が好きに書くことになり、余計に検索を悪化させる。
- 事例を既存のどのページにぶら下げるかべきか、どんな名前のページにするべきか、新しい事例ほど迷って時間を食う。けど、書き残さないとあとで困るので、とりあえずの場所にぶち込むことに。そして整理されない。Drag & Drop で移動したい…
- 更新のタイムラインを見る暇があれば、誰かがマニュアルを書き換えたことは把握できる。が、後で実際にマニュアルを見ている時に、それが参照するに値するのか、判断する基準がない。(例えば業務システム revision X のリリースより前なのか後なのか…) いつ頃誰が書いた記述かわからない(要するに git blame が欲しい)
- 新機能リリース時に、マニュアルのどこを改訂すればよいのか。自分で書いたマニュアルは改訂すれば良いとして、それに基づいて皆が書いたアンチョコは古いまま。どうするか。(機能とドキュメントの対応関係がシステム化されていない)
理想を言えば php.net (docbook) や amon2 (sphinx) のような一本道の 「本」 として構成された公式マニュアルをオンラインで作ることが出来て、かつ、その特定の章に絞った検索が出来て欲しい。それとは別に、その本という枠組みに縛られずに自由にページを足す機能は欲しいが、未分類なページを似たもの同士集めて分類を育てていく支援も欲しい。タグは…破綻させない仕組みがあれば…。重複マニュアルをどう見つけるか…。そして何より、部分的に古くなったマニュアルを、どう見つけて改定していくか…
おまけ
曰く「…多分、この内部構造のため、脳は(情報が)木構造にマップされる階層構造を持つ場合、一番効率よく働く…」 pic.twitter.com/HWzmvfa79A
— hkoba (@hkoba) 2016年2月21日