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

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, インターフェース,
 あるSNS会員の冗談から思いついた話。

 標準システムのカスタマイズは、原則外付けのみが可能である。
 カスタマイズ用の参照専用DBや帳票作成用DBを用いて行うわけだが、これがOracleから出力されるCSVのようなものであれば、この部分をオープンソースで出来ないだろうか。

 規格は全国共通であるし、抱える課題も多くは共通することが考えられる。
 市町村システムに取り込む前提のものは千差万別であるため困難であるが、例えばExcelやAccessのVBAのようなものであれば理論上は全広域全市町村が利用できるわけであり、そのレベルのものでもそれなりのことは出来る。
 そしてそれをなしうる技術を持つ者は、会員の中に少なからず居る。
 
 何が可能で何が出来ないかということは現時点では分からないが、手法としては悪くない気がする。
 あとはどれだけ賛同と協力を得られるかということだろう。

 とはいえ、基本設計はおろか要求定義すら定まっていない現時点では所詮絵に描いた餅である。

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

自由利用マーク
このマークは当blogの記事部分に付けられたものです。
タグリスト: 標準システム, カスタマイズ, オープンソース, DB, CSV,
2006
0704

 さて、グアムでの土産話でも書こうと思う。
 
 娘がレストランで大騒ぎだったとか、女房殿の免税店ブランド物あさり武勇伝とか、筆者が流水プールでワカメのように連日浮かんでいたとか、そんな月並みな話でも良いのだが、せっかくだから公務員や行政に関する話をしたい。

 とはいえ、日本でも普通の暮らしをしていれば、役所の世話になることはあまり無い。
 それは外国旅行でも同様である。避けて通れないのは、せいぜい税関、検疫と入出国管理ぐらいであろうか。

 というわけで、今回のテーマはUS-VISITである。

 US-VISITを簡単に説明すると、アメリカ国土安全保障省のIT技術を駆使した最新式入出国管理システム、ということになろうか。 
 訪米者は(システム導入後の)初入国時にパスポート番号と顔写真、そして指紋を採取され、データベースに登録されることになる。

 日本でも、外国人登録という制度があり、同様に指紋や顔写真等の登録を行うが、US-VISITとは大きく事情が異なる。
 外国人登録が、入国後に市町村の役所役場を窓口として、入国管理局と紙ベースの書類のやり取りを行うのに対し、US-VISITは入国の水際、しかもオンラインで行われている。
 また外国人登録は原則長期滞在者のみであるが、US-VISITは滞在期間の長短に関係なく、また日本人のグアムの短期滞在等、ビザが免除されるケースにも例外なく適用される。
 どちらが厳密で厳格かは言うまでもないだろう。テロと戦う国、アメリカならではのシステムといえる。

 さて、筆者のグアムの訪問は、今回で3回目であるが、パスポートに米国出国のスタンプは1回しか押されていない。
 1回目はまだUS-VISITが導入されていなかった。出国のスタンプはこのときのものである。
 2回目は導入されて最初の訪米である。例に漏れず、デジカメとスキャナ装置によって、顔の映像と指紋情報を採取されたが、手続き自体は、ものの1分程度で終わったと記憶している。
 ちなみに国土安全保障省は数秒と公表しているが、数秒では幾らなんでも無理であろう。長蛇の列が出来ていたことを覚えている。
 
 ところで、国土安全保障省が記録する、こうした旅行者の情報はどれくらいになるのであろうか。

 まずアメリカを訪れる旅行者の数であるが、機内で読んだ航空会社の雑誌には年間数億人とあった。
 日本の訪米者数は年間約400万人で第2位だそうである。1位は隣国カナダであろうか。
 結局、正確な全年間訪米者数は見つけることができなかった(というより、英語のウェブサイトをそこまで検索する根気がなかった)ので、仮に2億人として計算を試みる。
 登録する情報は、顔写真と指紋情報と、パスポートの情報は最低限所有している。仮に1人100キロバイトとしよう。
 単純に掛け算をすると、年間20テラバイトとなる。
 こうした情報は1年程度で破棄していては意味がないから、少なくとも数百テラバイト単位のデータベースとなる。
 莫大な規模だと言って良い。

 話を元に戻そう。今回は3回目である。
 果たして、手続きは3人で1分もかからなかった。
 パスポートをリーダーに通し、米国職員がディスプレイに一瞬目をやり、キーボードに何らか入力、あとはパスポートに入国ハンコを押して終わりである。
 前回のように指紋の登録や顔写真の撮影は要求されなかったということは、登録済みのデータベースと正しく照合されたことを意味する。
 しかも、オンラインウェイトはほぼゼロであった。手続きは昼間に行われたため、それなりのトランザクショントラフィックは存在していると考えてよい。
 素人目に見ても、優秀なシステムではなかろうかと思う。

 ところでこのUS-VISIT、利用者サイドの使い勝手はどうであろうか。
 国土安全保障省はUS-VISITによって手続きをスピーディーにするといっている。
 とにかくアメリカの手続きは日本に比べて時間がかかると言う印象があるが、US-VISITによってそれが短縮されたかというと、なるほど2回目以降の訪米は確かに手続きが簡素化されているという印象を受ける。
、しかし前述のとおり、新規登録者がいるとそれなり時間が余分にかかり、訪米1回目と2回目以降で窓口が異なるわけではない。
 かくして、US-VISITの部分もそうでない部分も、相変わらず長蛇の列である。

 まあ、そんなものである。

アメリカ国土安全保障省:US-VISIT
http://www.dhs.gov/us-visit




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

自由利用マーク
このマークは当blogの記事部分に付けられたものです。
タグリスト: システム, DB,

ナビゲーション

特集記事

カテゴリー

ブログ内検索

RECENT ENTRYS

RECENT COMMENTS

RECENT TRACKBACKS

プロフィール

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

HSタグクラウド

Feed Me!

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

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





リンク

中の人

FC2カウンター


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

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

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