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

  • 要求定義

  • Top
TAGWORD

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


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

自由利用マーク
このマークは当blogの記事部分に付けられたものです。
タグリスト:
 出力帳票とオンライン入力の仕様を少し変更するだけで無くなるはずの、毎日の無意味な(この部分自粛)作業とか、
 (この部分自粛)の中身を改変しないと動作しないバッチ処理とか、
 言い始めればキリがない。

 だが、もっとも深刻なのは連携の整合性に関連するものであろう。
 端的に言えば、市町村の住民基本台帳等の情報と、広域連合の保有する情報とに「ズレ」が生ずる可能性があるということだ。(影響範囲は推して知るべし)

 こんなものは概要設計時の問題である。
 (異動事由に「連携開始」「連携終了」の2つを付け加え、ロジックを工夫すれば解決できるはず)

 この段階からの仕様変更が困難なのは誰の目にも明らかであるが、連携を開始している広域も既にあり、最優先に解決してもらわなければならない案件だ。
 もちろん、個人情報の取り扱いに抵触したり、概要設計のミスをユーザーに押し付けるような解決法は、問題外である。

スポンサーサイト

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

自由利用マーク
このマークは当blogの記事部分に付けられたものです。
タグリスト: 住民基本台帳, 標準システム, 要求定義, 個人情報保護,
 8月6日の会議でV2のリリースが遅れることが正式にアナウンスされた。
 まあ、いろいろな方面で事前に情報は流れていたので、今更驚くべきことでもない。
 
「V2? おまい未だにそんな都市伝説信じているのか?」
「下手するとV3は4月超えるかもねー」
「いやいや、V1の決定稿も年度内に出たじゃん。…3月27日だけど」
「大丈夫、今年の3月は100日まであるんだよ!」

 SNS内では、こんな軽口も交わされているぐらいである。皆、肝が座っているのか投げやりなのか。
 原因は開発方ではなく、国の政省令の遅れにあるのだが、会議で詫びの言葉の1つもでないのは、いかにも××省らしい。

 遅れは遅れとして仕方が無いので、この間に各広域は全ての事務構築、即ち広域と市町村と業務分担切り分けや、事務フローの作成をすることを推奨する。

 もちろん、「V2の仕様が分からないのに、仮定で事務フローを組み立てても仕方がない」という意見もあるだろう。
 だが、それでは手遅れかもしれないのだ。

 実は、既にお気づきの方もいるだろうが、
 標準システム、どうしようもなく使えないのである。

 操作性とかそういうレベルの問題ではない。
 基本的な事務を行うために必須、通常は「できるかできないか」と疑問にすら思わない出来てあたりまえのことが、出来なかったりする。
 現段階の仕様では、それ単体でまともな事務はまず出来ないと思った方が良い。
 仮に(奇跡的に)20年4月に間に合ったとしても、現場は大混乱である。

 もちろんこれは、何とか中央会や何とか省の要求定義のまずさに起因するわけだが、それを責めても仕方が無い。
 以前の記事にも書いたが、現場の事務を知らず、それを真摯に吸い上げようともしない者に、まともな要求定義が出せるはずがないのだ。
 分かりきっていたことである。

 とはいえ、広域サイドでのカスタマイズも極めて制約されている。
 ユーザー側でフォローしようとしても、そもそも出来ない可能性が高い。

 ならば道は1つ、我々が要求を出して、標準システムを改善させるしかないだろう。

 そもそも、それを用いて標準的な事務が出来ないものを「標準」とは呼ばないし、
 47都道府県が等しく必要とするカスタマイズは「カスタマイズ」ではない。

 何とか中央会や何とか省にかわり、我々が正しい要求定義を出し、標準システムをあるべき正しい姿に変えていく。
 そのための事務フロー構築である。

 改めて事務フローを構築してみると、例外的な処理や特定条件での抽出の必要性が随所に発生するのが改めて認識できるだろう。
 そういったことについて、逐一ヘルプデスクに確認すると良い。

 「聞くまでもないだろう」と思うことでも確認した方が安全だ。

 例えば、死亡対象者は住基異動情報から自動資格喪失処理がなされるが、その対象者リストすら出力されない。
 多くの方は愕然とされるだろうが、今の標準システムはそのレベルなのである。
 (一方で何とか中央会や何とか省の方々は「何でそんなもの必要なの?」と思っていることだろう)

 何度もいうが、V2の遅れは開発サイドの問題ではない。
 つまり、広域や市町村から要求を出して改善させるのは今のタイミングしかないのである。

 もちろん「気になる木」にとってみても、「自社のソフトで後期高齢者医療制度がコケた」という悪評は出したくはないだろう。
 とはいえ、開発方も全国から要求が殺到したら対応できるものではない。

 提案であるが、「気になる木」は標準システムにEUCツールを搭載してはどうであろうか?

 搭載しているDBを自由に参照し、任意にクエリがけをしてCSVとして抽出できる環境を提供するのである。
 (DB更新もできれば超したことはないが、必ずしも必須ではない)

 広域や市町村側の要求はこれでほとんど満たされるであろうし、CSVになればエンドユーザー環境でも自由に活用できる。
 帳票も簡単に作成できるし、VBAを利用してちょっとしたバッチ処理を作成することも可能だ。
 もちろん広域は各種統計や政策判断の資料作成にも活用することができる。

 「気になる木」には是非とも検討していただきたい案件である。

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


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

自由利用マーク
このマークは当blogの記事部分に付けられたものです。
タグリスト: 後期高齢者医療制度, 標準システム, カスタマイズ, 要求定義, 政省令,
 システムは所詮道具である。

 行政の根幹として法規があり、それを具体化するために事務がある。
 事務を執行する上で(量、質ともに)支障があれば、費用対効果を検討したうえで、道具としてのシステムを導入する。
 システム開発を行うためには、要求を定義せねばならず、それには事務に習熟していることが必須である。

 それが本来の姿であるが、
 現在、全国ではシステム仕様を元に事務をリバースエンジニアリングすると言う、あまりに滑稽な試みが進められている。

 ジグソーパズルにもたとえられるこの試みは、介護保険という至上最悪の前例を踏襲し、各種の悪条件と役所特有のしがらみを巻き込んで、全国の担当者達を悩ませていることであろう。

 「事務が決まらないからシステム面での要求が決まらない」
 「お上は具体的な事務について、何ら具体策を示してくれない」
 そうした嘆きは詮無きことだ。

 厚生労働省の官僚殿、国保中央会、そして開発を請け負うベンダ。

 その中に、市町村の最前線の窓口で行われる住民相手の事務に熟知しているものはいるだろうか?
 そんな方々に一から十まで現場の事務を作ってもらおうなどというのが、むしろ虫が良い話ではなかろうか?

 事務とそれを行う上での問題点を熟知しているのは他でもない、我々、市町村職員である。
 そして最低限といえど、各種政令はあるのだから、
 道具ができるのを待つのではなく、まず我々で事務を構築し、それを取りまとめて要求定義を厚労省やベンダに突きつけるぐらいの気概が必要であろう。
 
 たかが道具に振り回されること無かれ。
 基本は事務である。


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

自由利用マーク
このマークは当blogの記事部分に付けられたものです。
タグリスト: システム, 事務, 介護保険, リバースエンジニアリング, 要求定義,
4.1 システム構成概要
 ずいぶん贅沢な印象を受けるが、システム構成自体はWebシステムに一般的に見られる三層構造(連携→AP→DB)をベースとしている。
 そして、インターネット利用や外部公開用のWebサーバはこの資料に含まれていないため、別途考慮する必要がある。

 なお、※1でにおわせているが、保険者と国保連合会がオンライン接続する「保険者レセプト管理システム」の構想が水面下で動き始めている。二重投資を避ける意味からも、この構想を視野に入れて、ネットワーク構築の要件定義やポリシー調整を行ったほうが良いだろう。

4.2 ハード
 Webシステム三層構造、SAN&ネットワークバックアップ+Ultrium3。聞くだけでも懐が寒くなりそうである。事実、笑えるぐらい金がかかる。
 広域のハード性能が市町村の窓口端末の台数に依存していることから、市町村窓口サーバは中継的な中身がスカスカのサーバであろう。

 で、件の窓口サーバ、シングルかクラスタかは市町村のポリシーに依存という完全責任放棄の書き方である。これでは事務局は困ってしまうだろう。
 ポリシー云々以前に、広域の事務の均一化という政治的な大義名分からすればクラスタ推奨とすべきであるし、負荷分散や費用対効果から大規模市町村=クラスタという観点ならば、その人口目安を書いておくべきだろう。
 余談だが「別添1の隠しページ」にはクラスタを参照しているセル=大規模と書いてある。要するにそういうことなのだろう。(そもそも小規模市町村は窓口サーバが不要な構成も可能ではないか?) 

 保険証については平成22年度にカード化&QRコード刷り込みが義務付けられることが分かっている。当然それを視野にいれたシステム構成にすべきであろう。
 わずか二年間しか使用しない公印印刷専用カラープリンタという発想は馬鹿げている。
 カード化が時期尚早ならば、公印刷り込みの紙に兼用可能なモノクロプリンタで印刷するほうがはるかに良い。

4.3 ソフトウェア
 2.2.2でソフトウェアの仕様については後日ということだが、現時点でどういったソフトウェアを想定しているかは「別添1の隠しページ」を見れば分かる。隠しページの出し方が分からない人は、blog左のメールフォームからこっそり尋ねられたし。

4.4 ネットワーク
 WANの選択(とりわけLGWAN)については余りに大きな問題であり、別の機会に詳しく触れることとしたい。
 オンラインウェイト5秒というのはWebでは珍しくないが、汎用機の操作性に慣れている窓口職員にとっては耐え難い苦痛であろう。
 WANの冗長化という発想はないのであろうか?(窓口サーバをクラスタにしても、ネットワークにトラブルがあれば意味が無いのだが)

4.5 構築作業及び運用保守
 市町村のウィルスパターンファイル更新はどうするの?

4.6 その他の見積項目
 認証サーバが良く分からないが、指認証用サーバのことであろうか?それともドメインコントローラーのことか?
 リモート操作やリモート保守は、LGWAN基本仕様ではできない。だから「リモート保守用ネットワーク回線」(意地悪く言えば「バックドア」)が別途必要なのである。

(続く)


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

自由利用マーク
このマークは当blogの記事部分に付けられたものです。
タグリスト: Webシステム, LGWAN, QRコード, 国保連合会, 要求定義,

ナビゲーション

特集記事

カテゴリー

ブログ内検索

RECENT ENTRYS

RECENT COMMENTS

RECENT TRACKBACKS

プロフィール

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

HSタグクラウド

Feed Me!

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

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





リンク

中の人

FC2カウンター


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

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

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