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

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

　通りすがりのＳＥさんから、先日の記事に関してコメントをいただいた。

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

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

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

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

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

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

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

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

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

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

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

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

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

> 　（２）本人にいちいち読み方を確認できるのか

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

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

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

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

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

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

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

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

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

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

---

＊＊　9月9日追記　＊＊

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

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

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

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

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

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

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

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

---

＊＊　9月20日追記　＊＊

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

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