三鷹市の三セク企業がオープンソースの図書館システムを塩尻市へ納入 47
タレコミ by maimi09
maimi09 曰く、
朝日新聞むさしの（東京武蔵野支局２００９年２月１２日付け２５面）の報道によると、三鷹市の第三セクター（三鷹市９８％出資）株式会社まちづくり三鷹が開発した図書館業務用コンピューターシステムが、長野県塩尻市で採用されることとなった。
大手企業が開発するシステムは企業の技術者しか保守点検できない制約があるが、まちづくり三鷹のシステムは仕組みを学べば誰でも保守作業できる「オープンソース」が特徴。「コストを削減し地元経済の活性にも役立つ」と初の導入例として全国にアピールしてゆく。
まちづくり三鷹のシステムが開発した図書館業務用コンピューターシステムはプログラミング言語Rubyで記述されており、価格を従来の半額程度に抑えた。 複数の公共図書館や学校図書館をインターネットで結び、約７０万件の図書情報をすばやく検索・管理できる。
２０１０年度予定の新しい図書館の開館に合わせてシステムの入れ替えを検討していた塩尻市が納入先第１号となった。
大手企業が開発するシステムは企業秘密もあり改良や不具合の修正が必要になった際は技術者の派遣を要請し、その都度料金を支払うことになる。これに対しオープンソースのシステムはプログラムが公開されているため、各地のＩＴ企業が新たな機能を付け加えたり改修できたりでき、コスト削減や雇用創出につながるという。
塩尻市立図書館の館長補佐は、「メンテナンス契約で囲い込みをしたがる大手に対し、地元経済を重視した第三セクターならではの発送に共感し、導入が決まった。」と話す。保守契約は長野県内のＩＴ業者と契約するという。
まちづくり三鷹には、図書館システムの更新時期を控えた他の自治体からも問い合わせが寄せられているという。関連記事
もうRubyも１言語として定着したことだし (スコア:2, すばらしい洞察)
タレこむなとか採用するなという意味じゃなくて、普通に。
Re:もうRubyも１言語として定着したことだし (スコア:5, 参考になる)
こう言った図書館システムは、大学図書館も含めて大手ベンダー数社の寡占状態。
公共（公立学校）の場合は数年に一度ハード更新特需で稼げるので、とても美味しい商売になっている。
ＦさんやＮさんは消耗戦をしたくないので、県や地域で住み分けしていると言う噂もちらほら。
図書館で必要な機能と言うのは
・貸出返却管理
・利用者管理
・予約管理
・蔵書検索
・OPAC
大体決まっていてほぼ枯れている。
大手ベンダーは県内や地域で同一ソフトを揃えれば、学情や他図書館との相互貸出機能が便利と謳うけど、プロトコルは公開されているので別途実装すれば良い訳だし、頻度が少なければ、電子メールとFAXで連絡すれば事足りる。
なので三鷹の様にコンパクトに機能を作りこんで、機器更新が無い図書館にパッケージとして売り込むのはありかと思う。
Re:もうRubyも１言語として定着したことだし (スコア:1, 参考になる)
図書館SE暦の長い漏れからすれば、
・利用者管理と予約管理
は普通１つのサブシステムに纏めるのがお約束だ。
・蔵書検索
・OPAC
は昔ならいざ知らず、イマドキなら同じ事だろ？
足りないのは、
・蔵書管理(買った本とか雑誌の登録)
・雑誌特有の処理(冊子化やコンテンツシート登録)
・予算管理
で、システムにあわせて職員が運用してくれるなら、パッケージ品を買えばよい。
んが、業務にあわせてシステムをカスタマイズしたがる客が多いので、改造してくれやすい、ベンダべったりの大手寡占の状態になるんだよ。
Re:もうRubyも１言語として定着したことだし (スコア:1)
単にRubyを使っただけならニュースでも何でもないですが、頭の硬い
お役所がRuby（Ruby on Rails？）のような「実績のない」(≒レガシーでない)
システムを採用するのは、まだまだニュースになるんだと思います。
Re:もうRubyも１言語として定着したことだし (スコア:2)
お役所が採用したのはRubyという処理系ではなく、検索システムなのでは？
Re:もうRubyも１言語として定着したことだし (スコア:1, 興味深い)
滅法評判の悪いものを導入してしまう、
と言うのはよく聞く話ですよ。
技術そのものの評価より、
提案者とクライアントの関係次第では？
名の通った企業もサポートサービスとか始めましたし、
提案はし易くなったんじゃないでしょうか？
Re: (スコア:0)
そりゃあ、お役所ってのは頭が固いかもしれないけど
あんだけ人数がいりゃあ、何人かは腕の立つ変わり者も出てくるだろうし、
運良くそれなりの立場になった人もいるだろう。
(初期のパソコンオタクなら、ちょうど30-40代のはず。)
それほどクリティカルな業務ではなさそうだし、
実際の使用例があって、導入費用が半額なら
ちょっとやってみようかねぇ、というのは自然な流れだと思う。
Re: (スコア:0)
＞実際の使用例があって、導入費用が半額なら
＞ちょっとやってみようかねぇ、というのは自然な流れだと思う。
そういう「自然な流れ」が受け入れられないのが、「お役所仕事」ってもんでしょ。
失敗さえしない限り（ほぼ）終身雇用が保障されている原点主義の組織で、
「安定しているから」を理由に公務員を選んだような人が、失敗したら責任を
取らされることを知っていて、一生を棒に振るかもしれないリスクを背負って
まで挑戦するかな？
それにどれだけ税金を浪費したって、どうせ自分の懐は痛まないわけだしね。
Re: (スコア:0)
http://headlines.yahoo.co.jp/hl?a=20090213-00000000-zdn_ait-sci
＞Rubyがプロジェクトでも利用され始め、特に開発効率の高さで公共関連プロジェクトを中心に採用され始めていることを表している。
Re:もうRubyも１言語として定着したことだし (スコア:1, すばらしい洞察)
Re:もうRubyも１言語として定着したことだし (スコア:5, 興味深い)
そう思って、リンク先の事業内容(PDF) [mitaka.ne.jp]をみると、図書館システムのコードを開示することで大手ベンダーの囲い込みを防止し、地場IT企業の育成を計り云々とあって、オープンソースで公共サービスを作るというアイデアのいい部分を実践してるように見える。
でも実際は、ソースコードは公開じゃなくて、ライセンス契約で開示するだけか。 これじゃあオープンソースと言えないんじゃない？ 塩尻市はコードの著作権を持ってないのかな。
Re:もうRubyも１言語として定着したことだし (スコア:1, 興味深い)
オープンソースの基本は、使う人間が改造などができないという不便さを
無くす為の代物であって、使わない人間にも見せるというものじゃないよ。
フリーでダウンロードできるソフトは不特定多数の利用者がいるから
単に不特定多数が見られる様にしているだけ。特定が可能なのはそれに該当しない。
Re:もうRubyも１言語として定着したことだし (スコア:1, 興味深い)
作ったシステムを他のベンダーが改修するためにソースを使うのは
難しいということになるよね。
それなりに契約を結べばソースコードを閲覧できるWindowsも、
やはりオープンソースということになるよね。
開発する側がOSSの資産を使って安く開発できただけであって、
買う側・使う側はそんなに安くなってないというオチじゃないかな。
Re: (スコア:0)
ソースコードを開示して売っているだけのようですね。
あとこの第三セクターのビジネスモデルとしては、ソースごと丸投げするから保守は地元企業に発注して
地元に金を落としてくれ、というものなので、普通のパッケージソフト導入とあまり変わりはない気もします。
Re: (スコア:0)
>ソースごと丸投げするから保守は地元企業に発注して
>地元に金を落としてくれ、というものなので
仕様書もつけてくれるんでしょ?
それやらないとソースからの解析になって逆にめんどくさくなる。
ソースからの解析やっていくなら下手したらゼロから作った方が早いし
Re: (スコア:0)
開発会社内でコードの引き継ぎをするケースですらも、頻繁に前任者へのお伺いが発生しますし。
Re: (スコア:0)
> 開発会社以外で保守するのは面倒じゃないですかね。
在るのと無いのとではハードルの高さが全然違いませんか？
ドキュメントがしっかり揃ってても「面倒で」引き受け手が無いなら、
寡占状態になっても仕方ないと思いますが、
そもそも、「面倒」を引き受けて稼いでるんですよね？
むしろ一から作った方が安上がり、ってぐらい「面倒」ですか？
（そーゆー次元の話をしてるんですよね？）
> 開発会社内でコードの引き継ぎをするケースですらも、
> 頻繁に前任者へのお伺いが発生しますし。
それ、世間一般では「ドキュメントの不備」と見なされるんだと思ってました。
Re: (スコア:0)
スパゲッティだったり、仕様書通りに疲れていないという
ケースがよくあります。
特に、ソースコードを書いた本人しか、いや、書いた本人すら
理解できないものも少なくありません。
そのため、システムを開発して納品をした後は知らぬ存ぜぬを決め込んだり、
直すなら高額の費用を請求するベンダーがいるんです。
その結果、「ある独自ソフトウェアを改修する」という仕事が存在するわけ。
#そういう仕事って技術者を壊しちゃうんだよな。
Re: (スコア:0)
システムの本質は言語じゃないでしょ。
Re: (スコア:0)
Re: (スコア:0)
逆に公的機関に浸透しつつあるんで、警戒し始めているのだよ。
秋田県立図書館 (スコア:2, 参考になる)
平成17年に秋田県立図書館がPostgreSQL＋PHPでシステムを開発して一部で話題になりました。
担当者の努力の痕跡が、pgsql-jpメーリングリスト [postgresql.jp]やPHP-usersメーリングリスト [php.gr.jp]などに残っています。
# オープンソース化するって話は、ぽしゃったんですかね。＞秋田県立図書館様
Re:秋田県立図書館 (スコア:1, 興味深い)
先ほど同僚に確認したら、「平成17年に、普通のベンダ製品に入れ替えちゃったんじゃなかったかな？」とのこと。
そうなると平成17年までPostgreSQL＋PHPだったということになります。
ということで、記憶が少しあいまいですが、先例は既にあるということは間違いないです。
引用のルール (スコア:1)
興味深い内容ですが、分量的に「転載」の域に達しているような気がするし、「強調は引用者」などと書かないとそれもまた引用の要件を満たしません。もうちょっと工夫してタレコんでほしいと思いました。
どこにも書いてないが (スコア:1)
＞約70万件の図書情報をすばやく検索・管理できる
これはRubyじゃないだろ？
データベースの機能だろ？
Re:どこにも書いてないが (スコア:1)
DBエンジンもRubyで書いたんじゃね？:-P
Re:どこにも書いてないが (スコア:1)
蔵書情報を外部に公開して、Google に検索させるほうが早い上に安く上がる気がするのだが、気のせいだろうか…
fjの教祖様
Re: (スコア:0)
http://www.google.co.jp/enterprise/mini/ [google.co.jp]
これ30万までしか検索できないよ
Re:どこにも書いてないが (スコア:1)
なしてminiで検索せにゃならんのじゃ。 site: でURLを制限すればいいだけじゃないか。
# ちなみに私の蔵書･既読書ページも perl で作られています。
# 正確には perl で「コンパイルして」 static な HTML と javascript を作っているだけですが。
fjの教祖様
Re:どこにも書いてないが (スコア:1)
マジレスすると、貸し出し管理のためには結局手元にデータベースが必要になるわけだし、
検索だけGoogleにしても、そっちとの連携を考えるとそれほどシステム規模が小さくならないんじゃないかな。
それに、自由キーワード検索だけですむならともかく、
検索エンジンをGoogleにまかせで「書名の部分一致」「著者名の部分一致」とかが出来るようにするのはかなり難しいと思う。
「書名と主キーだけのHTMLファイル」「著者名と主キーだけのHTMLファイル」とか、項目別に静的htmlファイルを作ればいけるか。で、それぞれの検索結果のAND処理はフロントエンドで行う、と。
#私はDBMSを使わない、textファイルとgrepベースの蔵書管理CGIを動かしてます。
#6000件程度だと、それでも速度的に全然問題なかったり。
Re:どこにも書いてないが (スコア:1)
Google Book 検索 [google.co.jp] というものもあるわけだし、必ずしも難しいとは思えないのだが…。
特に図書館プロジェクト [google.com]とは親和性がよさそうなんだがなぁ。
fjの教祖様
Re: (スコア:0)
70万件のデータを抽出するところまではRDBSの機能だが、そこから先(表示など)はRubyじゃないですか。
元の文章を読むと「Rubyは大規模システムには不向きと言われてたが、そこをきちんとやったよ。ほら70万件でもサクサク」という文脈でしょう。全然つっこむポイントじゃない。
Re:どこにも書いてないが (スコア:2, すばらしい洞察)
＞元の文章を読むと「Rubyは大規模システムには不向きと言われてたが、そこをきちんとやったよ。ほら70万件でもサクサク」という文脈でしょう。全然つっこむポイントじゃない。
Rubyは数年も前からAmazonや楽天の商品データベースの素早い検索と管理をRubyで実現していますからね。
やっぱりつっこむポイントじゃないですか？
っていうか、全然Rubyの機能ではないのにRubyの手柄みたいな書き方は誤解を生みませんかね？
ただのフロントエンドでしょ？
普通に開発すれば、Rubyの仕事は70万件の書籍情報の取り扱いじゃなく、70万件中から抽出した検索結果の取り扱いでしょう。
本当にRubyだけで実現してるならそれこそ税金の無駄遣いでニュースになりますよ。
Re:どこにも書いてないが (スコア:1)
「すばやく検索・管理」というのはUIも含めて、という意味でしょう。
Re: (スコア:0)
＞約70万件の図書情報をすばやく検索・管理できる
>これはRubyじゃないだろ？
>データベースの機能だろ？
いいえ、第一にシステム全体の要件を述べたものであり、
第二にデータの規模と読み取れます。
あのう、もしかして機能面を誇っていると読み取りました？
それでrubyだけで出来る訳ないとムキになって否定してます？
誰もそんな風には受け取らないと思うけどなあ…いるのかなあ。
Re: (スコア:0)
普通にやっちゃったらRubyではそれだけ重い、チューニングの余地がものすごくある、ということなんじゃないのか？
Railsとか、gemsとか。
＃Ruby大ファンなのだがgemライブラリのあの起動の遅さには閉口してるのでAC。ちっともお手軽スクリプティングでもサクサク開発でもないよorz
重傷の認識力低下 (スコア:1, オフトピック)
塩昆布に見える様では…
Ruby は図書館システムにぴったり (スコア:1)
だって、和書に Ruby はつきものですし。
まあ、お約束はこのくらいにして、70万件なんてさほど大きい
データベースとは思えませんが、それでも強調しているのは、
RoR 標準の AcriveRecord がチューニングなんて少しも考えていない
SQL をはくからかもしれません。
プロトタイプ開発にはいいですが、本番で使う時には、
すこし手をいれた方がよいでしょうし、今回のは
それをちゃんとやってあるということなのでしょうかね。
Re: (スコア:0)
そういえば少々気になるのがRails(AR)のスキーマ構造の縛り。
PKは「ID」のみだとか、
FKは「(別テーブル名)_ID」のみだとか、
という縛りに従ったうえで、
数十万オーダーを無事捌けているってことだと理解していいんですかね？
テーブルの綺麗さ(ワケワカになりにくさ)という意味ではARなどが採用するあの「ID縛り」は歓迎してるんだけど、
性能を両立しないと隣人を説得できないんでさ。
どんなもんですか？＞実地投入なさってる諸兄
＃気まぐれとしか思えないような"様々な"方法でテーブル間をJOINしやがってる読みづらいスキーマよりは(メンテコストが)マシだろ、と思う。
塩尻市といえば (スコア:0)
20世紀に接続料無料のISP [shiojiri.ne.jp]をやっていたイメージがあるが
今もやっていたのに驚いた。
オープンソース? (スコア:0)
煽るつもりはありませんが。(フレームの元?) (スコア:0)
> 約70万件の図書情報
って、この程度の件数で高速も糞もないと思った。
Re: (スコア:0)
--
つい先日Ignore.txtが12万行を越えましたが、7年も前のミドルレンジのPC上で平然と動いてます。
そのうちCOBOLで開発されたシステムに (スコア:0)
ストーリーが作られるようになるから、それまで我慢してください。
Re: (スコア:0)
Re: (スコア:0)