長崎県、大型電算機からオープンソース利用のシステムへ移行 38
ストーリー by mhatta
小さなことからコツコツと 部門より
小さなことからコツコツと 部門より
mirz曰く、"MSN毎日インタラクティブの記事によると、長崎県は大型電算機など大規模なコンピューターシステムで実施している事務処理を小型サーバーなどのシステムに全面移行させ、12年度末には大型電算機を廃止する方針を明らかにしたそうだ。年間約4億円の経費削減を見込まれている。
記事上では「2005年度から8年かけて特定メーカーに依存したシステムから決別し、インターネットで公開され自由に使えるソフトを活用する」となっているが、長崎県の県政ニュース記事「『「大型電算機の戦略的見直し方針』の策定について」では「オープンソースソフトウェアの積極的な活用」との記述があった。
具体的なソフト名までは挙がっていなかったが、ミュンヘン市の事例の日本版が、ついに登場するということだろうか。"
去年開催したOpen Source Way 2003では、長崎でのオープンソース受容の立役者である長崎県総務部参事監の島村秀世氏をお招きしたが、氏が打ち出した方向性が定着しつつあるようで喜ばしい。島村氏の仕事について興味のある方は日経 IT Pro オープンソースの記事(ただし無料登録が必要)も読んで見るとよいだろう。
いくつかの懸念 (スコア:3, すばらしい洞察)
純技術的には高負荷・高信頼性のトランザクションでもない限り問題無いと思うのですが, 実際問題として以下のようなことは無いでしょうか?
Re:いくつかの懸念 (スコア:1)
富士通、日立、NECがWeb Reliablity実装をオープンソース化 [itmedia.co.jp]
ってのを連想しました。
ミュンヘン市？ (スコア:3, 興味深い)
ミュンヘン市は、市の職員が使う1万4000台のデスクトップと
ノートパソコンをLinuxに移行するということなので、今回の
基幹業務システムのオープンシステム化とは話が違うように
思います。
次は何するんだろう (スコア:1)
Re:次は何するんだろう (スコア:1)
アイデアは良いのだが、全国的に注目されていないところを見ると、アピールが下手なのか、それともこけてるのかどちらかかと。
ここのネットワークも結構島嶼地域が多いので、細かかった気がします。
そういえば長崎県の汎用機はＡＣＯＳだったかな？
問題はソフトでしょ (スコア:0)
＞メーカーの開発費を軽減、地元IT（情報技術）企業が参入しやすくする。
とあるので、新たに開発しなおしと言うことですか。
コスト的にどうなんだろ？
分割発注でインターフェース部分がひどい事になりそうだ・・・。
Re:問題はソフトでしょ (スコア:2, 興味深い)
という話は、Pick up 自治体 : 長崎県(第1回) [hitachi.co.jp]の島村秀世氏に対するインタビューに書いてありました。
システム間インターフェースに関する部分だけ抜き出してみます。
当然私は中身を覗いてないので正確な物言いはできないのですが、あるテーブルに対するデータはどのプログラムが更新・挿入し、どのプログラムが参照しているのかを管理するのが大変になりそうです…。
DAOは共有するというコーディング手法をとっているのかな？
それと遠隔地にあるシステムとの連携は、どうしてもファイル連携の形をとらざるをえないと思うのですが、どうなんでしょうね。
Re:問題はソフトでしょ (スコア:1)
> どのプログラムが参照しているのかを管理するのが大変になり
> そうです…。
その管理が必要な理由が解りませんが…。
ちゃんとしたトランザクション管理ができていれば問題ないように思います。
> DAOは共有するというコーディング手法をとっているのかな？
DAOってData Access Object？これってMSの独自技術なんじゃ…？
良く解らないので教えてもらえませんか？
Re:問題はソフトでしょ (スコア:2, 参考になる)
あるビジネスモデルを分析する際に、データを中心として捕らえ分析していく手法です。これに対する考えが、POE(Process Oriented Approach)といって、手続きを中心に分析していく方法です。
一般的に、従来からよく用いられてきた手法はPOEが多く、DOAは、割と新しい手法といわれています。
DOAのメリットは、手続きに比べ安定しているデータを中心に考えていくためビジネスモデルの変化に追従していくのが簡単だといわれています。
Re:問題はソフトでしょ (スコア:0)
＞あるビジネスモデルを分析する際に、データを中心として捕らえ分析していく手法です。
＞これに対する考えが、POE(Process Oriented Approach)といって、手続きを中心に分析していく方法です。
実はどちらかに傾倒するのはよくないのよね。
どちらもちゃんと考えてやらないとダメなんですね。
Re:問題はソフトでしょ (スコア:0)
失礼 POA です。ご指摘アリガト。
>実はどちらかに傾倒するのはよくないのよね。
そう思ってたんですけどね。
実際にDOAとPOAによってデータベースを設計していくと経験的には、やはり、DOAのほうがシステムのライフサイクル内でのテーブルの変更は少なくて済みましたね。というか、徹底してDOAを使ってある場合テーブルの変更は基本的にはまずありません。ただし、ビジネスモデルの変化によって、テーブル自体は
Re:問題はソフトでしょ (スコア:0)
うっ日本語になってない。はずかし..
以下修正
うまくDOAを使って設計されたシステムでは、ビジネスロジックの変更があっても影響するアプリケーションは、基本的に追加されたテーブルが影響する範囲内に収まるので変更点は最小限で済みます。
Re:問題はソフトでしょ (スコア:1)
>ちゃんとしたトランザクション管理ができていれば問題ないように思います。
テーブルの設計変更がおきたときの影響範囲を特定するためです。
データベース自体をインターフェースにし、複数システムがそれを参照しているというのであれば、必要になってくるのでは？
>DAOってData Access Object？これってMSの独自技術なんじゃ…？
そういえば用語が間違ってますね。
モデルとでも脳内変換しておいていただければありがたいです。
Re:問題はソフトでしょ (スコア:1)
> データベース自体をインターフェースにし、
他のシステムでも、インターフェース設計に変更が起これば同じ事のように思うのですが。
でも、示してもらったページ [hitachi.co.jp]を読むと、インターフェースとかそういう話ではなく、データ中心設計と言う話なんじゃないでしょうか。
データ中心と言う考え方は、プログラムやユーザインターフェースは変更が多いけど、データ(データベース)の設計には変更が少ない、ってことですよね。であれば、データベースに対する変更は少ないはず... ですが....
> モデルとでも脳内変換しておいていただければありがたいです。
モデル? モデルを共有するコーディング手法？うーむ…ちょっと意味が解らないです。
Re:問題はソフトでしょ (スコア:0)
Re:問題はソフトでしょ (スコア:1)
> データベース自体をインターフェースにし、複数システムが
> それを参照しているというのであれば、必要になってくるのでは？
たいていは View で何とかできるのでは？
＃設計しだいでいろんな運用の仕方があるとは思う。
# mishimaは本田透先生を熱烈に応援しています
Re:問題はソフトでしょ (スコア:1, 参考になる)
簡単に言えば、ビジネスオブジェクトからデータソースへのアクセスを分離することによって、データソースの違いによる影響範囲を狭め、ポータビリティを高めようというものです。
ビジネスアプリケーションでデータベースを変更するなんてことはめったに無いので、これだけでは利点がなさそうに聞こえますが、ロジック部分の外部環境への依存度を下げることが出来るため、単体テストが圧倒的に楽になります(モックのデータソースを使います)。
Re:問題はソフトでしょ (スコア:0)
いやいや。
Re:問題はソフトでしょ (スコア:0)
Re:問題はソフトでしょ (スコア:1, 興味深い)
>どのプログラムが参照しているのかを管理するのが大変になりそうです
大変です。
>DAOは共有するというコーディング手法をとっているのかな？
紙のスキーマを信じてバラバラにコーディングするという手法をとっています。
--
関係者なのでAC
Re:問題はソフトでしょ (スコア:0)
もしやlancard.com [lancard.com]の方でしょうか。
Re:問題はソフトでしょ (スコア:1)
イニシャルコストとして、4億円かかったとしても、2年目以降は断然コストが圧縮されていく
ので、コスト削減になるでしょう。
まあ、イニシャルコストが10億以上になるなら考えものかもしれませんが。。。
あと、分割発注といっても、詳細設計までは、1社が担当するのではないでしょうか？
プログラム設計以降の開発部分を、分割発注していく方向だと思います。
Re:問題はソフトでしょ (スコア:2, 興味深い)
ここ [nikkei.co.jp]を読む限り、「長崎ITモデル」では、仕様書を書くのは役人と言うことみたいですよ。
実際には企業からSEを派遣してもらって書くのかもしれませんけど、詳細設計までを一社に丸投げ、と言うことではなく、あくまでも詳細設計の責任主体は県なのでしょう。
今までの自治体関係の仕事でも、仕様書を書くのは自治体の責任と言うことになっています。しかし実際には、ある一社が(大抵は無償で)仕様書を書き、仕様の中にその会社でなければ受注できないような罠を仕掛け、別会社を通して受注する、というのがわりと行われているようです。
長崎ITモデルでは、発注単位を小口にすることでそういった罠を仕掛けにくくしている、と理解していいのかな…？
Re:問題はソフトでしょ (スコア:0)
要求仕様の取りまとめだって無理だと思うよ。
フィードバックのことを考えたら、分割発注はかなり無理があるような・・・。
プログラムの部品単位なら可能かな？
Re:問題はソフトでしょ (スコア:2, 興味深い)
とはいえ、それぐらいの人材がどれだけいるか、は確かに疑問。
＃グランドデザインくらいは、この人だけで出来そうだけど。
Re:問題はソフトでしょ (スコア:1, すばらしい洞察)
Re:問題はソフトでしょ (スコア:1)
ただ、情報システム関連のような高度な専門性を要求されるような職種は、上のようなキャリアパスでも、異動先でもその部署の情報システムを担当する、と言うような方法もとられているようです。
＃それがその人の出世にとってどうなのかは疑問ですが。
また、中途採用や派遣SEの利用と言ったような方法もあるでしょう。
いろいろがんばって欲しいものです＞公務員。
Re:問題はソフトでしょ (スコア:0)
異動までの年数が通常の部署の倍程度になっています。
また、Ryo.Fさんの仰るように異動先でも情報システムに関わる事が多いようです。
＃もうこりごりっていう方もいらっしゃいますが…
Re:問題はソフトでしょ (スコア:1)
詳細設計を役人の仕事にする必要はありませんが、
>要求仕様の取りまとめだって無理だと思うよ。
こちらは発注側がやるべきことだと思いますし、できる人をお役所の中に育てる必要があると感じます。
要求仕様が決まっていないのに予算を決めて入札するのは本当は不可能です。
国レベルでもベンダーの言われるままに予算化して随意契約してきた構図があります。「錆びたら大変」の論理で、要らないモノまで高い値段で買わされて来ている訳です。
>プログラムの部品単位なら可能かな？
プログラムの部品単位での発注を実現すれば、あっちでもこっちでも石を積むという、賽の河原が避けられますが、これは様々に難しい課題がありそうです。うまく実現できればオープンソースのメリットが活かせると期待します。
Re:問題はソフトでしょ (スコア:1, 興味深い)
ただ、実際問題、地元各社、上流工程をできる人について下流工程で食べている人を抱えているわけで、地元企業が上流工程を担当できる様なスタッフを県に出して下流の仕事は別途入札ということになると、上流工程に人を出してしまったら下流工程の人が食べられなくて困るという心配はある様です。
--
関係者なのでAC
Re:問題はソフトでしょ (スコア:0)
# 無理矢理な曲解であることは，自覚してます．
電子自治体アプリケーション・シェア推進協議会 (スコア:0)
電子自治体アプリケーション・シェア推進協議会 [fukuoka.jp]みたいのがあって、
基盤となる部分を各自治体でシェアして、コストの削減を図りましょう、という話があるようです。
基盤となるところはオープンにして各自治体でシェア出来るようにし
オープンソース？ (スコア:0, 余計なもの)
毎日の記事と長崎県政ニュースを見ても汎用機を止めたことと「オープンなシステムに全面的に移行」とは書いてありますが、「オープンソース」とは書いていないようです。
どこかに Linux であるとか「オープンソース」とかってニュースソースがあるのでしょうか。
誰か知っている人 URL 提示きぼん。
＃役所なんかだと Solaris や Windows でも（ベンダ独自の汎用機と比較して）「オープンシステム」と呼んだりすることがあったりするのでちょっと気になりました。
それにしても長崎県のニュースリリース画像なんですね。コピペしようとして『なぜかセレクトできない』とあたふたしてしまいました。
Re:オープンソース？ (スコア:2, 参考になる)
Re:オープンソース？ (スコア:1)
> タレコミ文からのリンクの一番下の「次のページ」からリンクをたどれば
一覧に戻るの隣だったもんで、てっきり次のニュースリリースへのリンクと思い込んでしまいました。
Re:オープンソース？ (スコア:0)
Re:オープンソース？ (スコア:0)
役所に限らず、昔から一般的にそういう区分けをしている。
ちなみに、日経システム構築などには長崎県のプロジェクトの説明の中で、はっきりとOSS活用と書いてある。