数年前から，ナレッジDBが「はやり（流行り）」だ。その流れで，reference事例の共同データベース（DB: ディービーと読む）を作るところがいくつか，ある。ま，knowlege management自体は，日本経営学者の提唱で米国に広がったもんだから，それなりに意味はあろうと思うけど。
で，レファDBだけど，reference史のmissing linkなぞを書くわちきであれば，当然賛成なのかとえば，かなりちがう。
かなり冷笑的（一度，書いたかな…）。
というのも。理屈と経験からあまりお得なシステムとはいいがたいのだ(･∀･)/
ヘリクツ（理論ともいう(･∀･)）
またたとえ話ね。
referenceっちゅーのは方程式の解法に（概念的には）似てる。
いきなりむこう（お客）から問いがだされたのを，答えが出そうな方向に何段階か，問いを変形させて最終的な答えに落とし込んでいく。
方程式の問題集をみると，答えと，それにいたる何段階かの式の変形が書いてあるよね。reference共同DBってのは，本質的にはそれと同じもの。
ん？
答えが書いてあるから，それを他の図書館（や担当者）がパクれていいじゃないか，ってか。
そうだねぇ。その部分だけでは確かにラクにはなるねぇ。
でも考えてみてごらんよ。
方程式で，問題集の答えを暗記しても（本質的には）全く意味ないでしょ。数学が嫌いで嫌いで，もう金輪際やるつもりはなくて，でもこの一週間，この一学期，この一年だけ乗り切ればいい！ って人には確かに問題の答え集ってのは役にたつねぇ(･∀･)。
でも，そゆふーに方程式を乗り切った人は，死ぬまで「方程式ができた」とは言えないよねぇ。
まとめると，
他人のreference事例は，たしかに役に立つことはある。けどそれは，解法の途中の方程式の変換部分を，詳細に，解説つきで解説したものに限られる。
あるいは，すでにreferenceの基本的スキルがある人が，省力化のためにパクるとか，さらにはまた，もう１，２年で異動しちまう人が当座しのぐために使う，ってのはありだわな。
で，実際問題
解答部分をどのように書くかが最大の問題になるねぇ。お客さんのプライバシーも問題だけど，それは（このてのシステムにとっては）二次的なものなのじゃないだろか。
ほとんどは，ほんとに結果だけ，痕跡だけの最低限情報しか書かず，事例として若干の普遍性があるもののみ，かなり詳しく書き込むって２極分化したものになるべき。
詳細なほうは，なにを「見なかったか」，なにを「見ようとしてみれなかったか」など，選ばれなかった選択肢の書き込みがかなり重要となるし，もちろん，検索戦略のような抽象的なものも。これらを，思想の科学の連中のマネして「補助線」と呼ぶね。
簡略なほうは，ほんとに答え（つまり典拠と答えそのもの）だけとか。
でも，こーゆーのって，得てして上司への報告書みたいに，その中間の中途半端なものになっちゃうんだよ。
レファレンス実務のためにデータを作ってるんだか，上司のためにレファレンスを作ってるんだか，わからなくなっちゃうとゆー最悪のパターン。
結果として…
レファレンスがたてこんでいそがしいのに，現実の我々には役にたたない上司にとって「美しい」データを入力する手間が，さらに増える。結果として，省力化にもならないし，たいして新人教育にも役立たない。残業代が増えた（つまり税金の無駄遣いをした）だけ。
とゆーことになるのだ…
いやはや。激してしまった… (＾-＾;) なんでだろーねぇ。なんでだかわちきには，ちーともワカラナーイ(･∀･)
