- ------- Ads by Google
- 2007-1225 日次連携は問題がいっぱい
- 2007-0926 官僚だろうがSEだろうが、思考速度というものは早くなりません。
- 2007-0908 またまたまたフリガナの話
- 2007-0903 標準システムver1.0のユーザビリティは最悪らしい
- 2007-0809 標準システムはEUCツールを搭載せよ！
新しい記事を書く事で広告が消せます。
このマークは当blogの記事部分に付けられたものです。
出力帳票とオンライン入力の仕様を少し変更するだけで無くなるはずの、毎日の無意味な（この部分自粛）作業とか、
（この部分自粛）の中身を改変しないと動作しないバッチ処理とか、
言い始めればキリがない。
だが、もっとも深刻なのは連携の整合性に関連するものであろう。
端的に言えば、市町村の住民基本台帳等の情報と、広域連合の保有する情報とに「ズレ」が生ずる可能性があるということだ。（影響範囲は推して知るべし）
こんなものは概要設計時の問題である。
（異動事由に「連携開始」「連携終了」の２つを付け加え、ロジックを工夫すれば解決できるはず）
この段階からの仕様変更が困難なのは誰の目にも明らかであるが、連携を開始している広域も既にあり、最優先に解決してもらわなければならない案件だ。
もちろん、個人情報の取り扱いに抵触したり、概要設計のミスをユーザーに押し付けるような解決法は、問題外である。
（この部分自粛）の中身を改変しないと動作しないバッチ処理とか、
言い始めればキリがない。
だが、もっとも深刻なのは連携の整合性に関連するものであろう。
端的に言えば、市町村の住民基本台帳等の情報と、広域連合の保有する情報とに「ズレ」が生ずる可能性があるということだ。（影響範囲は推して知るべし）
こんなものは概要設計時の問題である。
（異動事由に「連携開始」「連携終了」の２つを付け加え、ロジックを工夫すれば解決できるはず）
この段階からの仕様変更が困難なのは誰の目にも明らかであるが、連携を開始している広域も既にあり、最優先に解決してもらわなければならない案件だ。
もちろん、個人情報の取り扱いに抵触したり、概要設計のミスをユーザーに押し付けるような解決法は、問題外である。
このマークは当blogの記事部分に付けられたものです。
平成１８年２月時点での予定↓
平成１９年８月時点での軌道修正↓
今たぶんこんなかんじ↓
デスマーチはもういやん。
後期高齢者医療制度開始まであと188日！
平成１９年８月時点での軌道修正↓
今たぶんこんなかんじ↓
デスマーチはもういやん。
後期高齢者医療制度開始まであと188日！
このマークは当blogの記事部分に付けられたものです。
通りすがりのＳＥさんから、先日の記事に関してコメントをいただいた。
内容はともかく、こうしたコメントは大歓迎である。
役所の電算システム事情について、知っていただくきっかけにもなるだろう。
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日付で名寄せのロジック向上ツールがリリースされたようであり、そのせいか名寄せに用いられていたフリガナは下記イチゴウさんのコメントにあるような清音処理がなされていたとの報告があった。
気になる木さん、ＧＪである。
ただ、オンライン検索時に同様な恩恵が受けられるかどうかは未確認。更なる作りこみを期待したい。
内容はともかく、こうしたコメントは大歓迎である。
役所の電算システム事情について、知っていただくきっかけにもなるだろう。
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日付で名寄せのロジック向上ツールがリリースされたようであり、そのせいか名寄せに用いられていたフリガナは下記イチゴウさんのコメントにあるような清音処理がなされていたとの報告があった。
気になる木さん、ＧＪである。
ただ、オンライン検索時に同様な恩恵が受けられるかどうかは未確認。更なる作りこみを期待したい。
このマークは当blogの記事部分に付けられたものです。
実際、筆者が端末に触れたわけではなく、SNS会員の書き込みからの勝手な邪推であると前置きするが、断片的な噂話だけでもそう確信できるのだ。
まず資格管理の画面展開に世帯という概念がない。
国保や老人保健の事務が、常に世帯単位で状況を把握しながら行わなければならないことは言うまでもないが、
それ故に、市町村の国保や老健システムは、世帯→個人という単位で画面が展開するものが多い。
たとえ検索画面からダイレクトに個人画面が展開する仕様であっても、容易に同一世帯員に遷移できる工夫がなされているのが普通だ。
これは後期高齢者医療制度においても同様であるが、ver1.0にはそうした工夫が一切ない。
世帯単位の画面は存在せず、個人画面が展開後、他の同一世帯員を表示させるためには、最初から検索を行わなければならない。
ならば、世帯番号で検索すれば…ということなるが、展開後の個人画面ではTABキーによる移動では世帯番号欄にカーソルがいかないうえ、右クリックも利かないため、操作する職員は、以下のような操作を頻繁に強いられることになる。
１．検索画面から個人画面を展開
２．個人画面にてマウス操作で世帯番号をドラッグ→ctrl＋Cでコピー
３．検索画面に戻る
４．世帯番号をctrl＋Vでペースト
５．他の同一世帯員の個人画面を展開
マウスとキーボードを交互に操作しなければならないわけで（以下省略）。
あと、マウスを操作しにくい障害を持った人とか、アクセシビリティ面でも（以下省略）。
更に言えば、個人単位の検索にも難がある。
前々から口を酸っぱくして訴えているが、フリガナに関する諸問題を放置し、統一基準や規格を作成することを避けているためだ。
フリガナは住所地特例対象者の名寄せでも大きな問題となっているが、むしろ台帳に登録された後の方がはるかに大きな障害となりうる。
現実問題、「ジョン スミス」をフリガナのみで確実に検索するためには、以下の４通りを試さなければいけない。
１．ジョン スミス（濁音１文字、拗音小文字）
２．ジヨン スミス（濁音１文字、拗音大文字）
３．シ゛ョン スミス（濁音２文字、拗音小文字）
４．シ゛ヨン スミス（濁音２文字、拗音大文字）
仮に生年月日と組み合わせて、ワイルドカード等の正規表現検索が可能としても（しかしながら、これは住基ネットで散々批判を浴びたことを忘れてはならない）、１文字目が濁音であれば２通り試さなければいけない。
暴論を言えば、検索に２倍の時間がかかる＝人件費２倍である。
こんな状態でまともな事務が（以下省略）
ていうか、検索時に「゛」を入力しなければならないインターフェースって（以下省略）
真面目な話、各広域はこうしたフリガナの乱れや揺らぎを防ぐための対策を講じた方が良いだろう。
そんなに難しい話ではない。
市町村から提供のあった各種データにSQLをかけて、濁音２文字を１文字に、拗音や促音の小文字を大文字に置換するだけである。（あとはズとヅ、ヂとジ、オとヲなどの揺らぎをどう考えるか）
どこかのベンダが他に先んじてそういうモジュールを作れば、確実に全国の広域に売れるだろう（と煽っておく）。何しろ人件費２倍を防止できるのだから。
まあ、辛らつなことをいろいろ書いたが、ver1.0はα版という理解で、正式版では改良されていることを期待する。
気になる木さんは、現場の意見に真摯に耳を傾け、こうした細かい部分にも配慮していただきたいものである。
後期高齢者医療制度開始まであと211日！
まず資格管理の画面展開に世帯という概念がない。
国保や老人保健の事務が、常に世帯単位で状況を把握しながら行わなければならないことは言うまでもないが、
それ故に、市町村の国保や老健システムは、世帯→個人という単位で画面が展開するものが多い。
たとえ検索画面からダイレクトに個人画面が展開する仕様であっても、容易に同一世帯員に遷移できる工夫がなされているのが普通だ。
これは後期高齢者医療制度においても同様であるが、ver1.0にはそうした工夫が一切ない。
世帯単位の画面は存在せず、個人画面が展開後、他の同一世帯員を表示させるためには、最初から検索を行わなければならない。
ならば、世帯番号で検索すれば…ということなるが、展開後の個人画面ではTABキーによる移動では世帯番号欄にカーソルがいかないうえ、右クリックも利かないため、操作する職員は、以下のような操作を頻繁に強いられることになる。
１．検索画面から個人画面を展開
２．個人画面にてマウス操作で世帯番号をドラッグ→ctrl＋Cでコピー
３．検索画面に戻る
４．世帯番号をctrl＋Vでペースト
５．他の同一世帯員の個人画面を展開
マウスとキーボードを交互に操作しなければならないわけで（以下省略）。
あと、マウスを操作しにくい障害を持った人とか、アクセシビリティ面でも（以下省略）。
更に言えば、個人単位の検索にも難がある。
前々から口を酸っぱくして訴えているが、フリガナに関する諸問題を放置し、統一基準や規格を作成することを避けているためだ。
フリガナは住所地特例対象者の名寄せでも大きな問題となっているが、むしろ台帳に登録された後の方がはるかに大きな障害となりうる。
現実問題、「ジョン スミス」をフリガナのみで確実に検索するためには、以下の４通りを試さなければいけない。
１．ジョン スミス（濁音１文字、拗音小文字）
２．ジヨン スミス（濁音１文字、拗音大文字）
３．シ゛ョン スミス（濁音２文字、拗音小文字）
４．シ゛ヨン スミス（濁音２文字、拗音大文字）
仮に生年月日と組み合わせて、ワイルドカード等の正規表現検索が可能としても（しかしながら、これは住基ネットで散々批判を浴びたことを忘れてはならない）、１文字目が濁音であれば２通り試さなければいけない。
暴論を言えば、検索に２倍の時間がかかる＝人件費２倍である。
こんな状態でまともな事務が（以下省略）
ていうか、検索時に「゛」を入力しなければならないインターフェースって（以下省略）
真面目な話、各広域はこうしたフリガナの乱れや揺らぎを防ぐための対策を講じた方が良いだろう。
そんなに難しい話ではない。
市町村から提供のあった各種データにSQLをかけて、濁音２文字を１文字に、拗音や促音の小文字を大文字に置換するだけである。（あとはズとヅ、ヂとジ、オとヲなどの揺らぎをどう考えるか）
どこかのベンダが他に先んじてそういうモジュールを作れば、確実に全国の広域に売れるだろう（と煽っておく）。何しろ人件費２倍を防止できるのだから。
まあ、辛らつなことをいろいろ書いたが、ver1.0はα版という理解で、正式版では改良されていることを期待する。
気になる木さんは、現場の意見に真摯に耳を傾け、こうした細かい部分にも配慮していただきたいものである。
後期高齢者医療制度開始まであと211日！
このマークは当blogの記事部分に付けられたものです。
8月6日の会議でV2のリリースが遅れることが正式にアナウンスされた。
まあ、いろいろな方面で事前に情報は流れていたので、今更驚くべきことでもない。
「V2？ おまい未だにそんな都市伝説信じているのか？」
「下手するとV3は4月超えるかもねー」
「いやいや、V1の決定稿も年度内に出たじゃん。…3月27日だけど」
「大丈夫、今年の3月は100日まであるんだよ！」
SNS内では、こんな軽口も交わされているぐらいである。皆、肝が座っているのか投げやりなのか。
原因は開発方ではなく、国の政省令の遅れにあるのだが、会議で詫びの言葉の１つもでないのは、いかにも××省らしい。
遅れは遅れとして仕方が無いので、この間に各広域は全ての事務構築、即ち広域と市町村と業務分担切り分けや、事務フローの作成をすることを推奨する。
もちろん、「V2の仕様が分からないのに、仮定で事務フローを組み立てても仕方がない」という意見もあるだろう。
だが、それでは手遅れかもしれないのだ。
実は、既にお気づきの方もいるだろうが、
標準システム、どうしようもなく使えないのである。
操作性とかそういうレベルの問題ではない。
基本的な事務を行うために必須、通常は「できるかできないか」と疑問にすら思わない出来てあたりまえのことが、出来なかったりする。
現段階の仕様では、それ単体でまともな事務はまず出来ないと思った方が良い。
仮に（奇跡的に）20年4月に間に合ったとしても、現場は大混乱である。
もちろんこれは、何とか中央会や何とか省の要求定義のまずさに起因するわけだが、それを責めても仕方が無い。
以前の記事にも書いたが、現場の事務を知らず、それを真摯に吸い上げようともしない者に、まともな要求定義が出せるはずがないのだ。
分かりきっていたことである。
とはいえ、広域サイドでのカスタマイズも極めて制約されている。
ユーザー側でフォローしようとしても、そもそも出来ない可能性が高い。
ならば道は１つ、我々が要求を出して、標準システムを改善させるしかないだろう。
そもそも、それを用いて標準的な事務が出来ないものを「標準」とは呼ばないし、
４７都道府県が等しく必要とするカスタマイズは「カスタマイズ」ではない。
何とか中央会や何とか省にかわり、我々が正しい要求定義を出し、標準システムをあるべき正しい姿に変えていく。
そのための事務フロー構築である。
改めて事務フローを構築してみると、例外的な処理や特定条件での抽出の必要性が随所に発生するのが改めて認識できるだろう。
そういったことについて、逐一ヘルプデスクに確認すると良い。
「聞くまでもないだろう」と思うことでも確認した方が安全だ。
例えば、死亡対象者は住基異動情報から自動資格喪失処理がなされるが、その対象者リストすら出力されない。
多くの方は愕然とされるだろうが、今の標準システムはそのレベルなのである。
（一方で何とか中央会や何とか省の方々は「何でそんなもの必要なの？」と思っていることだろう）
何度もいうが、V2の遅れは開発サイドの問題ではない。
つまり、広域や市町村から要求を出して改善させるのは今のタイミングしかないのである。
もちろん「気になる木」にとってみても、「自社のソフトで後期高齢者医療制度がコケた」という悪評は出したくはないだろう。
とはいえ、開発方も全国から要求が殺到したら対応できるものではない。
提案であるが、「気になる木」は標準システムにEUCツールを搭載してはどうであろうか？
搭載しているDBを自由に参照し、任意にクエリがけをしてCSVとして抽出できる環境を提供するのである。
（DB更新もできれば超したことはないが、必ずしも必須ではない）
広域や市町村側の要求はこれでほとんど満たされるであろうし、CSVになればエンドユーザー環境でも自由に活用できる。
帳票も簡単に作成できるし、VBAを利用してちょっとしたバッチ処理を作成することも可能だ。
もちろん広域は各種統計や政策判断の資料作成にも活用することができる。
「気になる木」には是非とも検討していただきたい案件である。
後期高齢者医療制度開始まであと236日。
まあ、いろいろな方面で事前に情報は流れていたので、今更驚くべきことでもない。
「V2？ おまい未だにそんな都市伝説信じているのか？」
「下手するとV3は4月超えるかもねー」
「いやいや、V1の決定稿も年度内に出たじゃん。…3月27日だけど」
「大丈夫、今年の3月は100日まであるんだよ！」
SNS内では、こんな軽口も交わされているぐらいである。皆、肝が座っているのか投げやりなのか。
原因は開発方ではなく、国の政省令の遅れにあるのだが、会議で詫びの言葉の１つもでないのは、いかにも××省らしい。
遅れは遅れとして仕方が無いので、この間に各広域は全ての事務構築、即ち広域と市町村と業務分担切り分けや、事務フローの作成をすることを推奨する。
もちろん、「V2の仕様が分からないのに、仮定で事務フローを組み立てても仕方がない」という意見もあるだろう。
だが、それでは手遅れかもしれないのだ。
実は、既にお気づきの方もいるだろうが、
標準システム、どうしようもなく使えないのである。
操作性とかそういうレベルの問題ではない。
基本的な事務を行うために必須、通常は「できるかできないか」と疑問にすら思わない出来てあたりまえのことが、出来なかったりする。
現段階の仕様では、それ単体でまともな事務はまず出来ないと思った方が良い。
仮に（奇跡的に）20年4月に間に合ったとしても、現場は大混乱である。
もちろんこれは、何とか中央会や何とか省の要求定義のまずさに起因するわけだが、それを責めても仕方が無い。
以前の記事にも書いたが、現場の事務を知らず、それを真摯に吸い上げようともしない者に、まともな要求定義が出せるはずがないのだ。
分かりきっていたことである。
とはいえ、広域サイドでのカスタマイズも極めて制約されている。
ユーザー側でフォローしようとしても、そもそも出来ない可能性が高い。
ならば道は１つ、我々が要求を出して、標準システムを改善させるしかないだろう。
そもそも、それを用いて標準的な事務が出来ないものを「標準」とは呼ばないし、
４７都道府県が等しく必要とするカスタマイズは「カスタマイズ」ではない。
何とか中央会や何とか省にかわり、我々が正しい要求定義を出し、標準システムをあるべき正しい姿に変えていく。
そのための事務フロー構築である。
改めて事務フローを構築してみると、例外的な処理や特定条件での抽出の必要性が随所に発生するのが改めて認識できるだろう。
そういったことについて、逐一ヘルプデスクに確認すると良い。
「聞くまでもないだろう」と思うことでも確認した方が安全だ。
例えば、死亡対象者は住基異動情報から自動資格喪失処理がなされるが、その対象者リストすら出力されない。
多くの方は愕然とされるだろうが、今の標準システムはそのレベルなのである。
（一方で何とか中央会や何とか省の方々は「何でそんなもの必要なの？」と思っていることだろう）
何度もいうが、V2の遅れは開発サイドの問題ではない。
つまり、広域や市町村から要求を出して改善させるのは今のタイミングしかないのである。
もちろん「気になる木」にとってみても、「自社のソフトで後期高齢者医療制度がコケた」という悪評は出したくはないだろう。
とはいえ、開発方も全国から要求が殺到したら対応できるものではない。
提案であるが、「気になる木」は標準システムにEUCツールを搭載してはどうであろうか？
搭載しているDBを自由に参照し、任意にクエリがけをしてCSVとして抽出できる環境を提供するのである。
（DB更新もできれば超したことはないが、必ずしも必須ではない）
広域や市町村側の要求はこれでほとんど満たされるであろうし、CSVになればエンドユーザー環境でも自由に活用できる。
帳票も簡単に作成できるし、VBAを利用してちょっとしたバッチ処理を作成することも可能だ。
もちろん広域は各種統計や政策判断の資料作成にも活用することができる。
「気になる木」には是非とも検討していただきたい案件である。
後期高齢者医療制度開始まであと236日。
このマークは当blogの記事部分に付けられたものです。
