公務員叩きに物申す！−現職公務員の妄言 システム運用保守に、後期高齢者医療制度に、公務員叩き批判に、行政改革に、福祉行政に、ITに、WEB2.0に、SNS管理に、VBに、Scriptに、情報セキュリティに、IPネットワークに、SEOに、ほんの少し家族サービスなブログ。

上記の広告は１ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

　例の「未定稿」がようやく公になった。
　２１日の夜間に全国に公開されるや否や、翌日２２日に即差替えという混乱ぶりである。
　変更点は住基ネット外字、いわゆる統一文字コードの利用にかかる部分であり、直前まで総務省との調整が難航していた様子が見て取れる（いや、もしかするとまだ調整中かもしれない）

　２１日版に統一文字コードの記述が無いことに気づいたときは正直めまいを覚えた。
　失意のうちにその資料を多量コピーしているときに、２２日版のメールが転送されて筆者のパソコンに届いたのである。

　ここで、筆者は厚労省の担当者に二言ほど言いたい。

　１．調整お疲れ様。さぞ苦労されたことと推察します。
　２．紙代ｶｴｾﾖ（・∀・）ｺﾗ!!　２１日版たくさん印刷しちゃったじゃないか。

　冗談はさておき、ようやくこのblogでも心置きなく言及することができるようになった。
　せっかくなので数回に分けて中身を見ていきたい。

---

１．本書の位置づけ
　省略

２．前提条件

２．２　システム構成に関する前提条件
　ざっと見た限り、全般的にハイスペックである印象を受けた。平成２３年のレセプトオンラインの時期のリプレイスを見込み、それまでの使用に耐えうる内容と見るのが妥当だろう。
　とはいえ、サーバはともかくWebシステムの端末がこれほど高性能である必要はあるのか？やや疑問である。
　（後ほど触れることになるが、端末についてはWebシステムとしながらも専用端末を想定している。Webシステムで端末性能がボトルネックになるというのは考えにくい。文字通りの専用であるならば、さほど高い性能は必要ないのではないか）

　ソフトウェアのベースは、Win2003＋Oracle10gである。UNIXでなくて大丈夫なのであろうか？
　他のソフトの細かい仕様は現段階では示されていないが、他ベンダへの牽制としてJP1やコネズミ…じゃなかったコズミネクサスあたりのミドルウェアをねじ込んでくることは容易に想像がつく。「N」や「F」は頭が痛い部分であろう。
　端末のOSはXP。Vistaは見送りである。

　ネットワークについてはLGWAN前提であるが、それ以外の独自回線も可能である。ただし仕様についてはLGWAN前提で記載されているため、見直しが必要になる可能性がある。
　LGWAN＋他回線の混在は不可。確かに運用保守面から混在は避けるべきだろう。

　構築、保守、運用については資料に含まれないし、またサーバが占有するスペースについても言及されていない。
　これらは個別に見積や調査等の対応が必要になる。

　なお、概算費用算出表は国保中央会のHPからダウンロードできるが、内容については未定稿と矛盾する部分もある。（市町村窓口サーバのバックアップソフトの有無等）
　まあ、高めに見積もっておけ、ということなのだろうか。

　広域連合サイドのサーバ設置場所であるが、LGWAN利用に大きく影響するので留意されたい。
　広域連合が自前でセキュリティ設備が整ったサーバ室を確保できるのならばともかく、業者のIDCを利用する場合、その業者がLGWAN-ASPサービス提供業者でなければLGWANには接続できない。
　LGWAN-ASPサービス提供業者の一覧については、LASDECのホームページで確認できる。

　そして当たり前であるが、広域連合サイドのセキュリティポリシー策定が必要になる。

　ここで提言したいが、広域連合サイドでの導入にあたってはコンサルをつけることを強く推奨する。
　コンサルにあてる当年度の予算がないのなら、プロポ形式でベンダやインテグレータを選定しても良いだろう。
　ともあれ、事務局職員がシスアド（＋情報セキュアド）とテクニカルエンジニアの精鋭集団であるのならばともかく、素人がこの資料だけを元に競争入札の仕様書を起こすのは不可能に近い。

２．３　インターフェース仕様に関する前提条件
　漢字文字については住基ネット統一文字コード、住所については全国住所辞書コード、金融機関情報については全銀協コードである。
　統一文字コードについては、「市町村住基システム→住基ネット」で用いている変換の仕組みをそのまま流用できれば話は早い。とはいえ、個人情報関連の審議会や「偉い人」に、住基ネットとは直接関係無いことを説明するのは骨が折れる作業になるだろう。

　個人番号については、各市町村で一意なのか、広域内で一意なのか不明瞭である。桁数については16桁と十分に見えるが、このうち何桁かが市町村番号的に充てねばならず、実際にはより少ない桁数しか利用できないとなると、各市町村で対応できなくなる可能性がある。

　市町村と広域間のデータ転送については、面倒なポリシー調整がいろいろと必要になるであろう。
　例えば筆者の市のポリシーでは、中から外は比較的甘いが、（特定のプロトコルを除き）外から中は相当厳しい。広域から本市へのデータ転送は全てダメである。
　そのため、中から外へ定期的にデータを取りに行く仕組みを構築する必要がある。（この費用は誰が負担するのか？）
　もちろん、外部からの遠隔監視や遠隔操作も全てダメ。本市に限ってはJP1を導入する意義は全く無い。
（LASDECが定めるLGWANのFWプロトコルも同様の制約があるということを聞いたことがあるが、そこらへんは大丈夫なのであろうか？　筆者の勘違いならば良いのだが…）

　開発を手がける「この木何の木」さんには、そういう自治体もあるということを是非認識しておいていただきたい。

　そうそう、ある都道府県では税業務が電算化されていない自治体もあるとか。
　日時夜間バッチが始まるまでに、その役場の職員がオンラインで税情報をポチポチ入力するのであろうか？
　ここらへんのケアも是非怠らないようにしていただきたいものである。

２．４　カスタマイズ
　カスタマイズ用のDBを用意してやるから、本体はいじくりまわすな、というスタンスである。
　果たして十分な内容と種類のDBが用意されるのか、少々不安である。

（続く）

＊＊　追記　＊＊

12月1日　ミドルウェアの名前が間違っていたので修正しました。（×コズミネクス→○コズミネクサス）