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

  • インターフェース

  • Top
TAGWORD

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


はてなブックマークに追加 はてなブックマークのコメント livedoorクリップに追加 livedoorクリップ数 niftyクリップに追加  del.icio.usに追加  Yahoo!ブックマークに登録 Yahoo!ブックマーク数 googleに追加 

自由利用マーク
このマークは当blogの記事部分に付けられたものです。
タグリスト:
 通りすがりのSEさんから、先日の記事に関してコメントをいただいた。

 内容はともかく、こうしたコメントは大歓迎である。
 役所の電算システム事情について、知っていただくきっかけにもなるだろう。

http://genshoku.blog69.fc2.com/blog-entry-160.html#comment322

 手違いか、別の記事にコメントされてしまっているため、改めて記事上で回答したいと思う。

>市町村から提供のあった各種データ=マスタデータですが、
>マスタデータを直接変換するというのは普通は危険すぎて行わないと思います。

 なぜ変換を行うのが危険すぎるのか良く分からない。
 フリガナは、外国人のフリガナの記事やまたまたフリガナの話の記事でも述べている通り、法定記載項目ではないし、統一基準もない。
 もともとが事務効率化のためにつけられているものであるから、広域連合においても事務効率化の目的において統一基準で設定されるべきであろう。
 そのための変換である。

 そもそも多くの市町村ではフリガナは半角で保有している。
 今回においては全角で提出する必要があるため、市町村において必要な変換処理をかけているはずだ。
 この時点で既に市町村住基システム等のフリガナ(マスタ)からの原本性は失われている。

>  元のシステムが「シ゛ョン スミス」のような「゛」(濁音)の単独入力を許可するシステムであれば
>  例えば「あ゛」のような「濁音2文字を1文字」に置換できない例外を想定して設計するのが常識でしょう。
>  当然、まともなSEであれば「あ゛」入りの文字列を検索するために、「゛」が単独で入力可能なインターフェースを設計すると思われます。

 まず、全国の市町村の住基システム等の多くがフリガナを半角で保有していることを考慮せねばならない。
 半角カナの場合、当然、濁点は1文字、濁音は2文字で表現される。

 しかし、求められたインターフェースは全角である。
 「ジ」を全角に変換する際に「ジ」にしたベンダと、「シ゛」にしたベンダがいる。ただそれだけのことだ。

 とはいえ、フリガナというものの用途と入力しやすさを考えれば、「ジ」と「シ゛」のどちらが正解かはおのずから分かりそうなものだが、かつて独自キーボードでインターフェースにこだわりつづけたあの会社が、まさかこんな(以下自粛)
 もちろんこれは、しっかりとした要求を出さなかった側にもおおいに責任がある。

 話がそれた。
 ともあれ、「ジ」と「シ゛」の違いはデータ変換の仕様の問題であり、キーボードからとても入力しにくい全角の「゛」をわざわざ用いる奇特な職員が全国に大勢いたわけではない。
 標準システムのフリガナ入力が寛容であるのは別の理由(多様な外国人のフリガナ)による。

>  (1)「あ゛」を職権によって訂正できるのか
>  (4)既に亡くなられた方はどういう扱いにするのか

 「麻生」が「ア゛ソウ」となっていれば、「アソウ」の入力間違いであることは明らかである。法定記載項目でもないため、職権で「アソウ」に訂正してもなんら問題はない。
 もちろん「宏史」の「ヒロシ」を、「ヒロフミ」や「コウジ」に訂正する場合は全く話が別である。

>  (2)本人にいちいち読み方を確認できるのか

 「麻生さん、あなたのフリガナの「ア」の後ろに濁点が入っているんですが、取っていいですか?」と電話したら、「そんな電話かけている暇があったら仕事しろ!税金ドロボー!」と麻生さんに言われることだろう。
 もちろん銀行振込の口座事故等、フリガナが極めて重要な意味を持ち、是が非でも確認すべきシーンはある。

>  (3)読み仮名に「あ゛」を使ってはいけないというルールがあるのか

 使っていけないというルールはないが、むしろそういう使い方をすることが運用上あるかどうかを考慮すべきだろう。
 フリガナで検索するときは、他の主キー(個人番号や被保険者番号)が分からないときである。
 電話での聞き取りや、書類上の漢字氏名から、ディスプレイ上のフォームに「あ゛」を入力するケースがあるかどうか?
 それを考えれば「あ゛」の文字列を含むレコードの存在が有害かどうか、おのずから分かるはずだ。

> (2)運用上の問題
>  市町村から提供のあった各種データを変換するバッチ処理のタイミング。
>  市町村から提供のあった各種データを次の日の営業開始までに必ず変換が終わることを
>  保障できません。「外国から1万人の長期出張中の老人が転入してきたらどうする?」

 差分異動データはせいぜい月数千件、大型広域でも1日100件あるかどうかのレベルである。
 「外国から1万人の長期出張中の老人が転入してきたら」システム云々以前に窓口と入国管理局がパンクするだろう。(そしてネットワークも)
 そして、皮肉を言っているつもりはないのだが、外国から1万人の長期出張中の老人が転入することを想定してシステム設計が出来るほど、自治体の財政は潤沢ではない。

 もちろん運用上の問題は大きな懸案である。
 だが、データ件数やレコード長も聞かずに「保障できません」というのは、SEとしての姿勢に問題があると言わざるを得ない。

> (3)解決策
>  (1)データベース側での解決
>    「ジ」が入力されたときに「シ゛」と「ジ」を検索するようにする。
>  (2)インターフェースでの解決
>    「あいまい検索」のような機能を作りこみ「ジ」が入力されたときに「シ゛」と「ジ」を検索するようにする。
> ⇒いずれの方式もDBアクセスが数倍になるため、ハード設計からやり直しとなり、不可能と思われます。

 元データを変換出来ない場合でも、アクセスを数倍にする必要はなく、あらかじめ検索専用のDBをもう1つ作っておけば良いだけジャマイカ?
 マスタのフリガナ(元データと同じ)に加えて、変換済みの検索用のフリガナを別に保有させ、紐つけておくのである。
 つまり外部データ取り込み時に「シ゛」「ジ」どちらの入力があっても「ジ」で検索専用のDBに登録するようにし、オンラインインターフェースからの入力も同じ変換をかけて、検索専用のDBを参照するという方法は、無理なく導入可能だと思われる。

 いずれにせよ、元データを変換出来ないという制約はない。
 自分が開発に関与できる立場であれば、2文字の濁音をSQLで1文字に統合し(たかだが数十通りである)、かつ統合できないものがある場合には濁点のみを抹消してそのレコードを特定できるログを出すように、要求を出すだろう。
 後ほどログを確認し、支障があればオンラインで修正する。それだけのことである。

 後期高齢者医療制度開始まであと206日!



** 9月9日追記 **

 SEの姿勢云々については言い過ぎだったと少し反省。
 ただ、要求を出す側の立場とすれば「詳細を聞かずに出来ないとは言って欲しくないなぁ」という気持ちがあることは理解していただきたいと思う。

 「SQL」云々については自分の書き方がまずかった、というかトンチンカンな文章だった(汗

 外部ファイルをインポートしてからDBのテーブルにupdate文を実行するということではなく、テーブルにインポートする前の外部ファイルにバッチ処理で項目の変換を施す、ということがいいたかった訳である。

>マスタデータを直接変換するというのは普通は危険すぎて行わないと思います。

 のくだりが提出されたデータの原本性云々の話ではなく「直接テーブルにupdate文を実行するのが危険」という趣旨であるならば、それは良く分かる。(やれと言われて、恐る恐るやったことはあるが)

 件のシステム(後期高齢者医療の標準システム)の根幹仕様については、テーブルも含めほとんど公開されていないので、
 テーブルに対して直接update文を実行するのはそもそも不可能であるし、同様に、あいまい検索機能を作りこんだり、検索画面のフォームから入力された内容に同じ変換をかけるようなカスタマイズも不可能だ。

 なので、できることはせいぜいインポート前に最低限の変換をかけるぐらいではないか、と。

 既に登録されているDBについては、2回目のセットアップのときに全部破棄される(と筆者は理解している)ので、考慮はしていない。



** 9月20日追記 **

 9月12日付で名寄せのロジック向上ツールがリリースされたようであり、そのせいか名寄せに用いられていたフリガナは下記イチゴウさんのコメントにあるような清音処理がなされていたとの報告があった。
 気になる木さん、GJである。

 ただ、オンライン検索時に同様な恩恵が受けられるかどうかは未確認。更なる作りこみを期待したい。

スポンサーサイト

はてなブックマークに追加 はてなブックマークのコメント livedoorクリップに追加 livedoorクリップ数 niftyクリップに追加  del.icio.usに追加  Yahoo!ブックマークに登録 Yahoo!ブックマーク数 googleに追加 

自由利用マーク
このマークは当blogの記事部分に付けられたものです。
タグリスト: フリガナ, DB, インターフェース,
 住基情報を広域に提供するために、自治体の保有する住基システムから、指定されたインターフェースへの、レコード項目やコードの「あわせ」作業が発生するわけだが、全国的にこの作業労力を軽減する裏技を提案。

 一部の例外を除き、ほとんどの自治体は住基ネットに接続し、異動データを市町村独自の住基システムから提供している。

 当然、そこには「市町村システム→住基ネット」の変換規則が構築済みであるわけだが、
 ならば「住基ネット→広域」のレコード項目指定やコード変換の規則を作ってしまえば、自動的に「市町村システム→広域」が導き出されるのではないか?

 そして、それは全国共通で使えないか?

 もちろん、そのまま問題なく使えるわけでは無かろうが、とりあえずの叩き台とするのには十分であろう。

 どこかのベンダがやらないかな?
 それとも、もうやっているのかな?
 


はてなブックマークに追加 はてなブックマークのコメント livedoorクリップに追加 livedoorクリップ数 niftyクリップに追加  del.icio.usに追加  Yahoo!ブックマークに登録 Yahoo!ブックマーク数 googleに追加 

自由利用マーク
このマークは当blogの記事部分に付けられたものです。
タグリスト: 後期高齢者医療制度, 住基ネット, インターフェース, 裏技,
3.標準システム概要

3.2.1 資格管理業務機能概要
 誰もが思うことであろうが、被保険者証の即時交付をどうやって実現するかが全く見えてこない。
 広域外転入時に交付される証は、仮の証ではない。その証拠に、未定稿7日版ではここに「仮証」の記述があったが、14日版以降ではその記述が消えている。紛れも無い、本物の証ということである。

 「広域連合による資格確認・被保険者証の交付決定をもとに、市町村において、窓口端末より登録した内容にて、即時に、被保険者証の引渡しを行う」

 この記述から見るに「市町村端末のオンラインで広域連合側のサーバにデータを転送し、その処理結果を元に証交付」というような雰囲気である。
 しかし、市町村からの住基や税情報の転送は5.3.1で日時と指定している。

 あるいは窓口サーバにいろいろ重めのアプリやDBがあって、そこでの処理を広域での交付決定と見なし、日時でその結果を広域に集約するのであろうか?
 しかし4.2.4や4.3.2を見る限り、窓口サーバにはDBもテープバックアップも無い。中身はスカスカに見える。

 「窓口端末より登録した内容にて」というのがクセモノだ。まさか職員にオンラインで氏名から住所情報から全て入力させるつもりか?
 住民課で転出証明書と転入届から住基システムにオンラインでポチポチ入力し、その職員がそのまま書類を持って国保課に走っていって別端末で全く同じ情報をポチポチ入力しろというのであろうか?
 それとも住基システムにオンラインで入力し終えた後、住民課職員がフロッピーディスクを持って窓口サーバまで走るのであろうか?

 とにかく不明瞭であり、本当に証交付が実現できるかどうか疑問だ。あるいは実現できたとしても窓口で多大な労力を強いられることになるやもしれない。
 もし貴方の市において、住基システムと老健システムのオンライン連携が取れているのであれば、証の作成は市町村システムで独自に行うことを前提に設計を進めていくほうが良いかもしれない。

 他にもいろいろあるが割愛。取りあえず証を出せないと話にならない。

3.2.2 賦課業務機能概要
3.2.3 収納業務機能概要
 一番不安であるのは収納と賦課の連携部分、特に広域内転居が絡む場合である。収納情報が広域に反映されるタイムラグの間に転居をした場合等、うまく処理されるのかどうか疑問だ。対応できないから市町村同士が考えてシステム組んでくれ、という話にならなければ良いが。
(そもそも賦課と収納を切り離すこと自体にかなり無理があるのだが、いたし方あるまい)

 特別徴収については、現行、介護では年金保険者から受給額は通知されない。どうやって市町村で1/2判定を超過するか否かの判定をするのであろうか?
 今後年金保険者が受給額を市町村に通知するようになるのであろうか? その場合の個人情報の取扱(本人の同意等)は大丈夫なのであろうか? 

3.2.4 給付業務機能概要
 広域内転居で医療機関が旧証で請求した場合、全て返戻処理となるようでは広域化の意味が無い。自動修正されるような仕組みが求められる。
 給付確認については是非、労力が削減できるような仕組みにしていただきたい。(再審査の大半は診療内容ではなく請求内容に問題があるものが大半であり、こんなものは人の手を煩わすまでもなく、ロジカルチェックで全てはじくべきである)
 療養費については、件数が多い都市の事情も勘案し、オンライン入力だけでなくデータインポート(ならびにエラーつぶし)の機能を設けるべきである。とりわけ、制度上はともかく受領委任行為が常態化している柔道整復や鍼灸マッサージの請求書については、直接広域でインポート処理できるような仕組みにした方が効率的であろう。

3.3 業務帳票一覧
 逐一はチェックしていないが、3.3.4の32「老人保健保険者別医療費給付額通知」が目に付いた。
 現行制度では保険者との拠出金の調整に用いる書類であるが、いったい何を想定した帳票なのであろうか?

3.4 外字処理の方式について
 残存外字の報告用インターフェースや同定処理が不明瞭であるから評価できない部分が多いが、統一文字コードへの変換自体は「市町村住基システム→住基ネット」で用いている変換の仕組みをそのまま流用できれば話は早い。
 業者が違う等、プログラム著作権等の問題が絡んでくると厄介だ。
 外字フォントの関係で、端末はWebシステムでありながらも専用端末とせざるを得ない。他システムとの流用には難が生ずる。

(続く)


はてなブックマークに追加 はてなブックマークのコメント livedoorクリップに追加 livedoorクリップ数 niftyクリップに追加  del.icio.usに追加  Yahoo!ブックマークに登録 Yahoo!ブックマーク数 googleに追加 

自由利用マーク
このマークは当blogの記事部分に付けられたものです。
タグリスト: 広域連合, 被保険者証, 住基ネット, 外字, インターフェース, Webシステム,
 例の「未定稿」がようやく公になった。
 21日の夜間に全国に公開されるや否や、翌日22日に即差替えという混乱ぶりである。
 変更点は住基ネット外字、いわゆる統一文字コードの利用にかかる部分であり、直前まで総務省との調整が難航していた様子が見て取れる(いや、もしかするとまだ調整中かもしれない)

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

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

 1.調整お疲れ様。さぞ苦労されたことと推察します。
 2.紙代カエセヨ(・∀・)コラ!! 21日版たくさん印刷しちゃったじゃないか。

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



1.本書の位置づけ
 省略

2.前提条件

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(続く)

** 追記 **

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

はてなブックマークに追加 はてなブックマークのコメント livedoorクリップに追加 livedoorクリップ数 niftyクリップに追加  del.icio.usに追加  Yahoo!ブックマークに登録 Yahoo!ブックマーク数 googleに追加 

自由利用マーク
このマークは当blogの記事部分に付けられたものです。
タグリスト: 住基ネット, 外字, LGWAN, 国保中央会, 広域連合, セキュリティ, インターフェース,

ナビゲーション

特集記事

カテゴリー

ブログ内検索

RECENT ENTRYS

RECENT COMMENTS

RECENT TRACKBACKS

プロフィール

現職公務員SE Author:現職公務員SE
 シスアドでセキュアドな後期高齢者医療制度SNS管理人。
 後期高齢者医療制度の資格事務担当だったはずがひょんなことで電算担当に。

HSタグクラウド

Feed Me!

公務員叩きに物申す!-現職公務員の妄言のRSSフィード

後期高齢者医療制度開始カウントダウン





リンク

中の人

FC2カウンター


公務員サイトランキング 現職公務員サイトランキング ビジネスブログランキング 人気ブログランキング - 公務員叩きに物申す!-現職公務員の妄言

スカウター : 公務員叩きに物申す!?現職公務員の妄言 はてなブックマークカウンター
  • seo

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