アカウント名:
パスワード:
こう言った図書館システムは、大学図書館も含めて大手ベンダー数社の寡占状態。公共(公立学校)の場合は数年に一度ハード更新特需で稼げるので、とても美味しい商売になっている。FさんやNさんは消耗戦をしたくないので、県や地域で住み分けしていると言う噂もちらほら。
図書館で必要な機能と言うのは・貸出返却管理・利用者管理・予約管理・蔵書検索・OPAC大体決まっていてほぼ枯れている。大手ベンダーは県内や地域で同一ソフトを揃えれば、学情や他図書館との相互貸出機能が便利と謳うけど、プロトコルは公開されているので別途実装すれば良い訳だし、頻度が少なければ、電子メールとFAXで連絡すれば事足りる。
なので三鷹の様にコンパクトに機能を作りこんで、機器更新が無い図書館にパッケージとして売り込むのはありかと思う。
図書館SE暦の長い漏れからすれば、
・利用者管理と予約管理 は普通1つのサブシステムに纏めるのがお約束だ。
・蔵書検索・OPAC は昔ならいざ知らず、イマドキなら同じ事だろ?
足りないのは、・蔵書管理(買った本とか雑誌の登録)・雑誌特有の処理(冊子化やコンテンツシート登録)・予算管理
で、システムにあわせて職員が運用してくれるなら、パッケージ品を買えばよい。 んが、業務にあわせてシステムをカスタマイズしたがる客が多いので、改造してくれやすい、ベンダべったりの大手寡占の状態になるんだよ。
単にRubyを使っただけならニュースでも何でもないですが、頭の硬いお役所がRuby(Ruby on Rails?)のような「実績のない」(≒レガシーでない)システムを採用するのは、まだまだニュースになるんだと思います。
お役所が採用したのはRubyという処理系ではなく、検索システムなのでは?
そりゃあ、お役所ってのは頭が固いかもしれないけどあんだけ人数がいりゃあ、何人かは腕の立つ変わり者も出てくるだろうし、運良くそれなりの立場になった人もいるだろう。(初期のパソコンオタクなら、ちょうど30-40代のはず。)
それほどクリティカルな業務ではなさそうだし、実際の使用例があって、導入費用が半額ならちょっとやってみようかねぇ、というのは自然な流れだと思う。
>実際の使用例があって、導入費用が半額なら>ちょっとやってみようかねぇ、というのは自然な流れだと思う。そういう「自然な流れ」が受け入れられないのが、「お役所仕事」ってもんでしょ。
失敗さえしない限り(ほぼ)終身雇用が保障されている原点主義の組織で、「安定しているから」を理由に公務員を選んだような人が、失敗したら責任を取らされることを知っていて、一生を棒に振るかもしれないリスクを背負ってまで挑戦するかな?
それにどれだけ税金を浪費したって、どうせ自分の懐は痛まないわけだしね。
>ソースごと丸投げするから保守は地元企業に発注して>地元に金を落としてくれ、というものなので仕様書もつけてくれるんでしょ?それやらないとソースからの解析になって逆にめんどくさくなる。ソースからの解析やっていくなら下手したらゼロから作った方が早いし
逆に公的機関に浸透しつつあるんで、警戒し始めているのだよ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
犯人は巨人ファンでA型で眼鏡をかけている -- あるハッカー
もうRubyも1言語として定着したことだし (スコア:2, すばらしい洞察)
タレこむなとか採用するなという意味じゃなくて、普通に。
Re:もうRubyも1言語として定着したことだし (スコア:5, 参考になる)
こう言った図書館システムは、大学図書館も含めて大手ベンダー数社の寡占状態。
公共(公立学校)の場合は数年に一度ハード更新特需で稼げるので、とても美味しい商売になっている。
FさんやNさんは消耗戦をしたくないので、県や地域で住み分けしていると言う噂もちらほら。
図書館で必要な機能と言うのは
・貸出返却管理
・利用者管理
・予約管理
・蔵書検索
・OPAC
大体決まっていてほぼ枯れている。
大手ベンダーは県内や地域で同一ソフトを揃えれば、学情や他図書館との相互貸出機能が便利と謳うけど、プロトコルは公開されているので別途実装すれば良い訳だし、頻度が少なければ、電子メールとFAXで連絡すれば事足りる。
なので三鷹の様にコンパクトに機能を作りこんで、機器更新が無い図書館にパッケージとして売り込むのはありかと思う。
Re:もうRubyも1言語として定着したことだし (スコア:1, 参考になる)
図書館SE暦の長い漏れからすれば、
・利用者管理と予約管理
は普通1つのサブシステムに纏めるのがお約束だ。
・蔵書検索
・OPAC
は昔ならいざ知らず、イマドキなら同じ事だろ?
足りないのは、
・蔵書管理(買った本とか雑誌の登録)
・雑誌特有の処理(冊子化やコンテンツシート登録)
・予算管理
で、システムにあわせて職員が運用してくれるなら、パッケージ品を買えばよい。
んが、業務にあわせてシステムをカスタマイズしたがる客が多いので、改造してくれやすい、ベンダべったりの大手寡占の状態になるんだよ。
Re:もうRubyも1言語として定着したことだし (スコア:1)
単にRubyを使っただけならニュースでも何でもないですが、頭の硬い
お役所がRuby(Ruby on Rails?)のような「実績のない」(≒レガシーでない)
システムを採用するのは、まだまだニュースになるんだと思います。
Re:もうRubyも1言語として定着したことだし (スコア:2)
お役所が採用したのはRubyという処理系ではなく、検索システムなのでは?
Re:もうRubyも1言語として定着したことだし (スコア: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言語として定着したことだし (スコア:1, すばらしい洞察)
Re:もうRubyも1言語として定着したことだし (スコア:5, 興味深い)
そう思って、リンク先の事業内容(PDF) [mitaka.ne.jp]をみると、図書館システムのコードを開示することで大手ベンダーの囲い込みを防止し、地場IT企業の育成を計り云々とあって、オープンソースで公共サービスを作るというアイデアのいい部分を実践してるように見える。
でも実際は、ソースコードは公開じゃなくて、ライセンス契約で開示するだけか。 これじゃあオープンソースと言えないんじゃない? 塩尻市はコードの著作権を持ってないのかな。
Re:もうRubyも1言語として定着したことだし (スコア:1, 興味深い)
オープンソースの基本は、使う人間が改造などができないという不便さを
無くす為の代物であって、使わない人間にも見せるというものじゃないよ。
フリーでダウンロードできるソフトは不特定多数の利用者がいるから
単に不特定多数が見られる様にしているだけ。特定が可能なのはそれに該当しない。
Re:もうRubyも1言語として定着したことだし (スコア:1, 興味深い)
作ったシステムを他のベンダーが改修するためにソースを使うのは
難しいということになるよね。
それなりに契約を結べばソースコードを閲覧できるWindowsも、
やはりオープンソースということになるよね。
開発する側がOSSの資産を使って安く開発できただけであって、
買う側・使う側はそんなに安くなってないというオチじゃないかな。
Re: (スコア:0)
ソースコードを開示して売っているだけのようですね。
あとこの第三セクターのビジネスモデルとしては、ソースごと丸投げするから保守は地元企業に発注して
地元に金を落としてくれ、というものなので、普通のパッケージソフト導入とあまり変わりはない気もします。
Re: (スコア:0)
>ソースごと丸投げするから保守は地元企業に発注して
>地元に金を落としてくれ、というものなので
仕様書もつけてくれるんでしょ?
それやらないとソースからの解析になって逆にめんどくさくなる。
ソースからの解析やっていくなら下手したらゼロから作った方が早いし
Re: (スコア:0)
開発会社内でコードの引き継ぎをするケースですらも、頻繁に前任者へのお伺いが発生しますし。
Re: (スコア:0)
> 開発会社以外で保守するのは面倒じゃないですかね。
在るのと無いのとではハードルの高さが全然違いませんか?
ドキュメントがしっかり揃ってても「面倒で」引き受け手が無いなら、
寡占状態になっても仕方ないと思いますが、
そもそも、「面倒」を引き受けて稼いでるんですよね?
むしろ一から作った方が安上がり、ってぐらい「面倒」ですか?
(そーゆー次元の話をしてるんですよね?)
> 開発会社内でコードの引き継ぎをするケースですらも、
> 頻繁に前任者へのお伺いが発生しますし。
それ、世間一般では「ドキュメントの不備」と見なされるんだと思ってました。
Re: (スコア:0)
スパゲッティだったり、仕様書通りに疲れていないという
ケースがよくあります。
特に、ソースコードを書いた本人しか、いや、書いた本人すら
理解できないものも少なくありません。
そのため、システムを開発して納品をした後は知らぬ存ぜぬを決め込んだり、
直すなら高額の費用を請求するベンダーがいるんです。
その結果、「ある独自ソフトウェアを改修する」という仕事が存在するわけ。
#そういう仕事って技術者を壊しちゃうんだよな。
Re: (スコア:0)
システムの本質は言語じゃないでしょ。
Re: (スコア:0)
Re: (スコア:0)
逆に公的機関に浸透しつつあるんで、警戒し始めているのだよ。