2015年10月25日()<< 前の日記 | 次の日記 >>
この日の詳細

■1 シリーズ武雄市TSUTAYA図書館(31) - 続・検証「9つの市民価値」[https://www.nantoka.com/~kei/diary/?20151018S1][図書館][武雄市][CCC][TSUTAYA図書館] このエントリーをはてなブックマークに追加

みんなの図書館 1997-11 前回の、 検証「9つの市民価値」[https://www.nantoka.com/~kei/diary/?20151018S1] で、宿題にしていた「365日、朝9時〜夜9時までの開館時間」について検討したいと思います。
まず、 「図書館をいつ開けるか?」[http://id.ndl.go.jp/bib/4315995] *1 という問題。決して簡単な問題ではありません。
長時間開いていた方が便利。休日が無い方が便利。と、多くの方が一見、感じられると思うのですが、それが本当に図書館サービスの向上に資するかということで言えば、ただ長時間開いている、毎日開いているというだけでは、必ずしもサービスが向上するとは言えないのです。
このことを検討するためには、図書館の費用構造や、図書館サービスとは何か、そもそも開館時間の延長は何を目的としたものなのかといった議論が必要になりますので、今回はこういった、開館時間の延長を考えるためのいくつかの背景を説明してみたいと思います。

図書館の費用構造:

公共図書館の運営経費の構造ですが、もちろん図書館毎に状況の違いはありますが、ほぼ半分がスタッフの人件費に充てられているという状況と想像して頂いて間違いはないと思います。
人的なサービスを提供する施設である以上、これは当然の構造なのですが、この費用構造の側面から見て、費用対効果が最大化されるポイントを検討することができます。
非正規雇用の割合を増やしていけば、開館時間の延長には対応しやすくなりますが、これは図書館サービスの質的な低下を伴います。非正規雇用の人が提供するサービスが低いという事では無く、不安定な勤務形態がもたらす結果です。
人件費が費用構造の中で大きいウェイトを占めているという構造を考えますと、開館時間を延長する事は、人件費一定という制約の下では、質の低下をもたらすということです。

図書館サービスとは何か:

開館時間の延長の声が多い背景には、開館時間を延長することにそれほどのコストが掛かるとは思えないという理由もある様に思います。
例えば、コンビニやレンタル店が深夜まで、あるいは24時間開店しているのと同様に、図書館も開館すれば良いと考えられるのでしょう。貸出や返却は、バイトでもできる。そう難しいことでは無いように思えます。
しかし、図書館が提供するサービスの中で、本の貸出はごく一部のサービスに過ぎません。
利用者が図書館資料を利用する上での相談に応じる、レファレンスという大切な役割があります。貸本屋と図書館を分けている役割の一つと言って良いと思います。
もちろん、この他にも図書館が担っている役割はたくさんあります。しかし、その時間に来館する利用者にレファレンスサービスを提供しないのであれば、「図書館サービスを提供している」とは言えないと思います。

開館時間延長の目的:

ここで、「レファレンスサービスなんていうのは一部の利用者しか利用しないサービスなのだから、貸出さえやってくれれば良いんだ」という意見もあるのではないかと思います。
確かにそれは考え方としてはありだと思います。貸出機能だけは夜間も提供する様にしようという考え方です。
実は、そういうサービスを提供している図書館は既にあります。貸出ロッカーを使用すれば、無人で24時間貸出が可能となる訳です。
目的が「貸出時間の延長」なのだったら、図書館全体を開館しておく必要は無く、貸出ロッカー等を利用すれば、人件費だけでなく光熱費 *2 も節約できますし、夜間等と言わず、24時間、貸出・返却に対応することも可能になるのです。

まとめ:

こうやっていくつかの論点を見てきましたけれど、私はツタヤ館の開館時間と言うのは、公共図書館としての機能の面から見た場合、中途半端な設定だと考えます。
図書館のフルサービスを提供するのであれば、日中でさえレファレンスカウンターにスタッフがいないという状況はあり得ませんし、休館日や夜間にしか、貸出を受けられない利用者に貸出サービスを提供しようと言うのであれば、自動貸出機を導入している位ですから、貸出ロッカーでの提供は考慮されて然るべきだったと思います。
では、どう考えて今の開館時間になっているか。結局のところ、ツタヤやスタバの営業時間に合わせただけなのではないかと考える訳です。
ツタヤ館の構造。店舗だけ営業するという事が難しい構造になっています。例えば、蔵書点検で図書館だけを休館するとか、店舗の営業時間を延ばすという事が難しい訳です。
これは、商業施設と公共施設を混ぜ込んだために生じた重大な欠陥だと思います。
建築の世界で使われる「縁を切る」という言葉があります。建築物の構造上、お互いに影響を与えない様に、敢えて切り離すことを言うのですが、この「縁の切り方」という見方は、複合施設のデザインを見る上で大きなヒントを与えてくれるように思います。 お互いの独立した機能には影響を与えない様にしつつ、意匠上の一体感や相乗効果を望める…複合施設にあっては、そういうデザインが理想だと思うのです。
そういう意味で、ツタヤ館とは異なるコンセプトを持ってデザインされた施設として、「桶川マイン」を見ています。一体感は持たせながら、独立して営業できるようになっている訳です。
こういう施設であれば、お互いの施設にあった営業形態を選びながら、相乗効果を望めたのかも知れません。

(2015-10-25)本稿書きかけという感じもあるのですが、このままいじっていると、いつまでたっても公開できない様な気がするので一旦公開します。いつか追記をするか、別の記事で。

*1: 特集 図書館をいつ開けるか?. みんなの図書館 / 図書館問題研究会 編.. (通号 247) 1997.11. 1〜61 ISSN 0386-0914
*2: 公共図書館の経費の中でも、結構な割合を占めます。資料費より多いというのは稀だと思いますが、資料費と比較できる程度の割合になっている館が多いと思います。

■ 関連記事

詳細はこの日の詳細から

2010年10月25日(月)<< 前の日記 | 次の日記 >>
この日の詳細

■1 iPhoneで人の情報丸見え…閲覧ソフト原因[http://www.yomiuri.co.jp/national/news/20101024-OYT1T00747.htm][セキュリティ][ケータイ] このエントリーをはてなブックマークに追加

「閲覧ソフト原因」とは、 [http://www26.atwiki.jp/librahack/ 岡崎市立中央図書館事件] を連想させる微妙なタイトルだ。
アイフォーン利用者の間でそんなトラブルが起きている。本来、携帯サイトの閲覧はできないスマートフォンに、携帯電話の識別番号(携帯ID)を付与して 一般の携帯電話に「なりすまし」て、サイト閲覧を可能にするソフトが原因だ。
技術者は、つい「Impersonate」の訳語として、「なりすまし」とか「偽装」という言葉を使ってしまうが、ネガティブな意味に受け取られやすい言葉なので注意が必要だと感じた。
日常的に「殺す(kill)」とか「皆殺しにする(killall)」とか「死ぬ」とか物騒な言葉を使っているUNI*X管理者としては反省させられた。
この事件、実際のところは、 「閲覧ソフト原因」ではなく、サイトの脆弱性が原因 だ。
会社側が出しているプレスリリースにもそう書かれている。
このたび、 携帯版「クロネコメンバーズのWebサービス」に脆弱性が見つかり、下記の通り対応いたしましたのでお知らせいたします。メンバーズの皆様にはご心配をお掛けしましたことを深くお詫び申し上げます。
発見者の ブログ[http://mobaphoto.blogspot.com/2010/10/yomiuri-onlineiphone.html] でも指摘されているが、 YOMIURI ONLINE[http://www.yomiuri.co.jp/national/news/20101024-OYT1T00747.htm] のまとめ方はあまりにも乱暴だろう。
紙面ではまともな記事になっているという情報もあるが、アップデートが可能なオンライン版で不正確な記事が掲載されているのはどういうことか。まさか、 炎上マーケティングでヒット数を稼ぎたいわけでもあるまい。
ところで、「携帯電話の識別番号」を偽装する行為。不正アクセス行為にあたるのだろうか。 不正アクセス行為の禁止等に関する法律[http://law.e-gov.go.jp/cgi-bin/idxselect.cgi?IDX_OPT=5&H_NAME=&H_NAME_YOMI=%82%A0&H_NO_GENGO=H&H_NO_YEAR=&H_NO_TYPE=2&H_NO_NO=&H_FILE_NAME=H11HO128&H_RYAKU=1&H_CTG=1&H_YOMI_GUN=1&H_CTG_GUN=1] によれば、
第二条(定義)
2  この法律において「識別符号」とは、特定電子計算機の特定利用をすることについて当該特定利用に係るアクセス管理者の許諾を得た者(以下「利用権者」という。)及び当該アクセス管理者(以下この項において「利用権者等」という。)に、当該アクセス管理者において当該利用権者等を他の利用権者等と区別して識別することができるように付される符号であって、次のいずれかに該当するもの又は次のいずれかに該当する符号とその他の符号を組み合わせたものをいう。
一   当該アクセス管理者によってその内容をみだりに第三者に知らせてはならないものとされている符号
二  当該利用権者等の身体の全部若しくは一部の影像又は音声を用いて当該アクセス管理者が定める方法により作成される符号
三  当該利用権者等の署名を用いて当該アクセス管理者が定める方法により作成される符号
サイトにアクセスすれば、 無差別に自動的に送出され、アクセス先に知られることになるものが「みだりに第三者に知らせてはならないものとされている符号」であるわけがない から、
第三条(不正アクセス行為の禁止) 何人も、不正アクセス行為をしてはならない。
2  前項に規定する不正アクセス行為とは、次の各号の一に該当する行為をいう。
一  アクセス制御機能を有する特定電子計算機に電気通信回線を通じて当該アクセス制御機能に係る他人の 識別符号を入力して当該特定電子計算機を作動させ、当該アクセス制御機能により制限されている特定利用をし得る状態にさせる行為(当該アクセス制御機能を付加したアクセス管理者がするもの及び当該アクセス管理者又は当該識別符号に係る利用権者の承諾を得てするものを除く。)
「不正アクセス」にあたらない ことは言うまでもない。

■ 関連記事

詳細はこの日の詳細から

2009年10月25日()<< 前の日記 | 次の日記 >>
この日の詳細

■1週末の過ごし方次の記事 >> このエントリーをはてなブックマークに追加

予定していた打ち合わせが無くなったので、この時間にオフになることが決まった。
折角の週末だから、家族サービスしておきたいが、何をするかな。

■ 関連記事

■2関連記事検索のデバッグ[hns]<< 前の記事 このエントリーをはてなブックマークに追加

昨日[http://www.nantoka.com/~kei/diary/?20091024&to=200910242#T200910242]フライドチキンの記事[http://www.nantoka.com/~kei/diary/?20091024&to=200910241#T200910241] で、関連記事が出てこないのがおかしいと気づいたので、デバッグしてみることにした。
関連記事検索は、 tf-idf[http://ja.wikipedia.org/wiki/Tf-idf] に、単語の長さや構成文字を基にした係数を掛けたものを使っているのですが、まず、 フライドチキンの記事[http://www.nantoka.com/~kei/diary/?20091024&to=200910241#T200910241] でのTFと係数を確認してみる。
nikki=# SELECT keyword, SUM(idf * score) AS tf
 FROM article, keywords, keywordlist, keywordidf
 WHERE
      article.id = keywords.article_id
  AND keywords.keyword_id = keywordlist.id
  AND keywords.keyword_id = keywordidf.keyword_id
  AND nikki_date = '2009-10-24'
  AND article_no = 1
 GROUP BY keywordlist.id, keyword
 ORDER BY tf DESC, keywordlist.id
 LIMIT 20;
       keyword        |        tf
----------------------+------------------
 フライドチキン       | 26.7149831502022
 ウイスキー           | 22.0210056597938
 チキン               | 19.0775761355412
 チューリップ         | 18.7641749203457
 手羽                 |  14.800030254366
 フライ               | 11.6098572215477
 チキンコルドンブルー | 10.7105371331685
 パン粉               | 9.96949422252275
 バスケット           | 8.92901630926261
 ハイボール           | 8.92901630926261
 バリエーション       | 8.39633371310052
 サントリー           | 8.13467576459694
 中華                 |  7.9603645104895
 ニッカ               | 7.73729569284771
 水                   | 7.43782102731242
 南蛮                 | 6.89175645936501
 コショウ             | 6.65943587933492
 仕上げ               | 6.64632948168183
 鶏                   | 6.58386048611456
 ブランド             | 6.29698286894017
(20 行)
これを見る限り、キーワード抽出はできていそう。
関連記事を抽出してみると、
SELECT t.nikki_date, t.article_no, t.title, SUM(i.idf * kl.score)
 FROM article AS t, article AS f, keywords AS kt, keywords AS kf, keywordidf AS i, keywordlist AS kl
 WHERE
      kt.keyword_id = kf.keyword_id
  AND kt.keyword_id = i.keyword_id
  AND kt.keyword_id = kl.id
  AND kf.article_id = f.id
  AND kt.article_id = t.id
  AND kt.article_id <> kf.article_id
  AND kt.is_top_a = true
  AND kf.is_top_a = true
  AND f.nikki_date = '2009-10-24'
  AND f.article_no = 1
 GROUP BY t.nikki_date, t.article_no, t.title
 ORDER BY SUM(i.idf * kl.score) DESC, t.nikki_date DESC, t.article_no
 LIMIT 20;
 nikki_date | article_no |         title          |       sum
------------+------------+------------------------+------------------
 2009-10-25 |          2 | 関連記事検索のデバッグ | 17.2882571048631
(1 行)
と、この記事しか出てこない。
キーワード「フライドチキン」を含む記事は、他にもあるはずと思って、namazuで検索すると、 この記事[http://www.nantoka.com/~kei/diary/?20050721&to=200507211#T200507211] が該当するので、この記事のキーワードを出力させてみると、
nikki=# SELECT keyword, SUM(idf * score) AS tf
 FROM article, keywords, keywordlist, keywordidf
 WHERE
      article.id = keywords.article_id
  AND keywords.keyword_id = keywordlist.id
  AND keywords.keyword_id = keywordidf.keyword_id
  AND nikki_date = '2005-07-21'
  AND article_no = 1
 GROUP BY keywordlist.id, keyword
 ORDER BY tf DESC, keywordlist.id
 LIMIT 10;
    keyword     |        tf
----------------+------------------
 map            | 5.39923757027701
 136            | 4.87010409776545
 ウオッ         |  4.4648073217977
 2500           | 4.28534718647156
 フライドチキン | 4.19842599961785
 愛知           | 3.88369534940785
 ごはん         | 3.87365236116891
 壱番屋         | 3.86885297764766
 フィット       | 3.82346161453322
 カナル         | 3.52469145626482
(10 行)
確かに入っている。ということは、関連記事を探すクエリに問題がありそうだ。
実は、tf-idfをそのまま使うと、当該の記事では注目されていない単語なのに、相手の記事での出現回数によって上位のスコアを得てしまうという現象があって、これに対処するために足きりを設けているのだが、これが悪さをしているのでは無いかと思って、調べてみた。
nikki=# SELECT keyword, SUM(idf * score) AS tf, is_top_a, article_id
 FROM article, keywords, keywordlist, keywordidf
 WHERE
      article.id = keywords.article_id
  AND keywords.keyword_id = keywordlist.id
  AND keywords.keyword_id = keywordidf.keyword_id
  AND nikki_date = '2009-10-24'
  AND article_no = 1
 GROUP BY keywordlist.id, keyword, is_top_a, article_id
 ORDER BY tf DESC, keywordlist.id
 LIMIT 10;
    keyword     |        tf        | is_top_a | article_id
----------------+------------------+----------+------------
 フライドチキン | 25.1905559977071 | f        |       2687
 ウイスキー     | 21.2552644018479 | f        |       2687
 チキン         | 18.7477481006029 | f        |       2687
 手羽           | 14.1647925793949 | f        |       2687
 チューリップ   | 12.8219076117393 | f        |       2687
 フライ         | 11.3454736539966 | f        |       2687
 パン粉         | 9.54158980464597 | f        |       2687
 バリエーション |  8.0359515101913 | f        |       2687
 中華           |   7.756388653075 | f        |       2687
 サントリー     | 7.67048978541913 | f        |       2687
(10 行)
is_top_aがtrueのキーワードだけが使用されることになっているので、これでは検索結果に出てこないはずだ。
is_top_aは、各キーワードを、文字数と構成文字種から得た係数で補正済みのtfの降順に並べて、上位15ワードを選択するようになっている。コード断片は以下の様な感じだ。
UPDATE keywords SET is_top_a = true WHERE id IN (
 SELECT
    MIN(keywords.id)
  FROM
     keywordlist
   , keywordidf
   , keywords
  WHERE
       keywordlist.id = keywords.keyword_id
   AND keywordlist.id = keywordidf.keyword_id
   AND keywords.article_id = [article_id]
  GROUP BY
     keyword
   , keywordidf.idf * score
  ORDER BY
     keywordidf.idf * score DESC
  LIMIT 1
);
これを掛けなおしてやったら、フライドチキンつながりの記事は表示されるようになった。現状、インデックス生成はバックグラウンドでやらせているのだけれども、記事更新のタイミングと絡んで、排他処理にミスがあるのかも知れない。
あと、top15という抽出が狭すぎる感じがしたので微調整してみる。

■ 関連記事

詳細はこの日の詳細から

2005年10月25日(火)<< 前の日記 | 次の日記 >>
この日の詳細

■1出張5日目[おしごと]次の記事 >> このエントリーをはてなブックマークに追加

ホテルのランドリーにお願いして、一通り着替えをなんとかした。7,000円ちょっと。
普通のクリーニングの価格からするとかなり高く付くのだけど、ホテルというのはサービスを売るところなので、高くてもそういうサービスが受けられるところは、それだけ払う価値のあるサービスを提供しているものだ。
超特急サービスを提供しているところは、深夜に出して早朝に仕上がりを届けてくれる。ランドリーの伝票が3種類位あって、超特急で仕上げられるものは限られていたりもするけれども、極端な話、急な出張で着の身着のままで最終便で出張に行くことになっても、翌朝にはすっきりした格好で仕事に臨めるわけだ。そういう事情で、ランドリーバッグは部屋の外に掛けられる様になっていて、ランドリーに電話を掛けると、取りに来てくれたりする仕組みになっていたりして感心する。
もちろん、費用はその分かかるのだけど、そのために深夜に働いている人がいることを思うと、払える金額だったりする。
今回はさすがにそこまでの状況は無かったけれども、一日分の下着とハンカチと靴下を個別にパックしてくれていたのはうれしかった。

■ 関連記事

■2 長崎県が電子県庁システムのソースコードをGPLで公開[http://slashdot.jp/article.pl?sid=05/10/24/0534233&threshold=-1]<< 前の記事 このエントリーをはてなブックマークに追加

うーん。もう少し、オープンソースについて啓蒙すべきだったな。反省。

この記事に頂いたコメント

Re: 長崎県が電子県庁システムのソースコードをGPLで公開 by osho    2005/10/26 13:03
昨日付で公開元への貢献義務条項が変更されて、 貢献を期待する程度に留まってますね...

■ 関連記事

詳細はこの日の詳細から

2004年10月25日(月)<< 前の日記 | 次の日記 >>
この日の詳細

■1 プログラミングテクニック番外編[http://www.bsddiary.net/doc/misc.html][CLIP] このエントリーをはてなブックマークに追加

素晴らしい。
念力デバッグ[http://www.bsddiary.net/doc/misc.html#nenriki-debug] は昔は高度な能力を持っていたと思うのだけど、開発環境が良くなるにつれて退化していってしまった能力だと感じます。

■ 関連記事

詳細はこの日の詳細から

2003年10月25日()<< 前の日記 | 次の日記 >>
この日の詳細

■1 株式会社 日本ブレイク工業[http://www.nbk.gr.jp/] このエントリーをはてなブックマークに追加

愛生会病院[http://www.aiseikai.or.jp/] みたいなブレイクの予感。
何がすごいって、 社歌[http://www.nbk.gr.jp/song.html] がすごい。
家を壊すぜ! 橋を壊すぜ! ビルを壊すぜ! 東へ西へ 走る! 走る! 日本ブレイク工業
ですよ。 ちゃんと [http://www.nbk.gr.jp/melody/nbk.mid] もついてます。

■ 関連記事

詳細はこの日の詳細から

2002年10月25日(金)<< 前の日記 | 次の日記 >>
この日の詳細

■1 BBQ and KICK4[http://www.kick4.net/tkk/tkk0210.html][freebsd] このエントリーをはてなブックマークに追加

明日はBBQの日。

■ 関連記事

詳細はこの日の詳細から

2001年10月25日(木)<< 前の日記 | 次の日記 >>
この日の詳細

■1shiorin壊れる[おしごと] このエントリーをはてなブックマークに追加

ファンのベアリングがずれたような音が聞こえたので、 異音の元を探ると、長いことnameサーバーを勤めてきたshiorinであることが判明。
メモリ32M、Pentium200という今となっては非力なマシンですが、 今の仕事には必要十分。保守部品があれば現役を続けさせても良かったのですが、 もはや入手が難しいAT電源ケースですし、他の保守部品ストック *1 も不安なので、引退させることにして新しいマシンにお引越し。
*1: ハードウェアの障害が発生したときに、互換性のある部品のストックがないと復旧に時間が掛かるので、 サーバ各々の構成に対して、置き換えが出来る分だけのストックを用意しておきます。 もちろん全く同じ構成であればストックが少なくて済むので有利です。 今回電源が壊れたAT構成のマシンはまだ退役していないのがあるので、AT電源のストックは残しておきたい事情があります。 今回の様に置き換えに時間の余裕が取れる場合に、次世代の構成にシフトしていって、 長期的に部品の供給に不安が生じないようにする訳です。

■ 関連記事

詳細はこの日の詳細から

以上、14 日分です。

指定日の日記を表示

前月 2019年10月 翌月
1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31

最近の日記

2019年04月01日

新元号「令和」について

2019年03月23日

DXアンテナ ワイヤレスチューナー メディアコンセント DMC10F1

2019年02月17日

#例のグラボを活用する

2019年01月03日

シリーズ5・myHomeAlexaで自分のCDをかける

2018年12月25日

シリーズ4・英語の楽曲・アルバム・アーティスト名をカタカナに直す

2018年12月23日

シリーズ3: Echo Dotがやってきた

2018年12月19日

続・Echo Dotがやってきた

分野別タイトル一覧


全て
CLIP
SYA!nikki
book
freebsd
hns
magic
おさけ
おしごと
お買いもの
ぐる
ごはん
アクセシビリティ
オープンソース
セキュリティ
音楽
地域情報化
電子自治体
日記

予定

    ToDo

      link

      keikuma on Twitter

      keikuma Name:前田勝之
      Location:長崎市
      Web:http://www.nantok...
      Bio:前田勝之(まえだかつゆき)。長崎在住。コンサル、SE、プログラマー、 なんとか株式会社代表、非常勤講師(情報セキュリティ)。 セキュアド、テクニカルエンジニア(SV,NW)。サーバ管理とWeb日記を10年ほど。 ネットとリアルの接点に関心あり。食べること・歌うこと・愛すること・作ること・飲むこと。おいしいものがぜんぶすき。

      サイト内検索

      Google AdSense

      Powered by hns-2.19.9, HyperNikkiSystem Project