≪ GoogleのAJAX Feed API Slide Show Controlとか |メインページへ戻る| 今月のInBody測定 ≫
2007年06月03日
【
「突き合わせには10年ぐらいかかる」という見解から思うのは 】
データベース化の話や、既存のデータベースから新しいデータベースへのプラットフォームの移行の話を持ち込まれる度にクチを酸っぱくして言うのが、「既存データや台帳とのつけ合わせと入力内容の確認を行うまでの覚悟がありますか?」と言う台詞。とうぜんに「それに伴う人件費などの出費もあり、相応の時間も必要ですますよ」と付け加える。
たとえ既にデータ化されているものを新規のデータベースに移行するにしても、既存データの入力時の誤謬適示が中途半端なものであればそれについても歯に衣をつけずに「そのデータすら怪しい」と言及し、原簿に遡ってのチェックを奨める。
これが私がこの手の仕事の話を持ち込まれた場合に「線を引く」最低限の条件だ。データベースやシステムまわりの仕事が副業の方になった今でも、このスタンスはかわっていない。それで顔をしかめるようなクライアントとは付き合う気はない。
もともと私は「データを利用する側」としての現場主義なので、システムを構築する側の立場より、データを使う側の視点に立って話をする。えてして、システム化や新規システムの移行を求める意見と言うものは現場ではなく、その「妙な」効率化を求める上層部から提言される場合が多い。その中途半端な「利点中心」の考え方に釘を刺し、自分で仕事を請けた際の自分のリスクを軽減し、必要となる予算を完全に可視化し、クライアントに「システム化によるリスクの存在」を伝えるために、こういう話をする。
そもそもクライアントに良いことばかりを伝えているから、互いの間にとんでもない誤解が生じる。先に伝えるべくは、新たに生まれるリスクの存在で、先に求められるべきものは、それらのリスクに対する適切な対処方法なのだ。そのリスクというのはシステムやその運用に関連した脆弱性だけではなく、データの入力と言う単純な作業の中に存在する瑣末なものまでを視野にいれるのが当然なのだ。
そしてタイプアップ以前の原簿に記載されている内容のチェックや、タイプアップ後のデータとの付け合せは100％でないといけないと思っている。システムの可用性では99.9999％と言う数字が挙げられるが、入力されたデータは例外事項の発生に伴う処理のワークフローも含めて、100％の完成度が要求される。
いま取りざたされている年金データの話は、けっきょくその程度のことが出来ていなかっただけの話。入力データがどのように軽視してきたかという結果を指し示す良い例だ。完全オンライン化されたのが1988年だと言うから、今から20年も前の話。キチンと当初から予算を組んで、完全オンライン前でも、それ以前に平行してでも地道に2重/3重のチェックを積み重ねてデータの完成度を上げることはできたはずである。データの完成度が低いということは事前にシステムを利用する側とのすり合わせすることが必要だが、妥当な策だ。
今回の問題の源流は、そうう地道な努力を念頭においていなかったから。予算の問題などがあったのかも知れないが、システムを納入する側の説明が足りなかったのだろうと言う気がする。「突き合わせには10年ぐらいかかる」という政府・与党の見解を聞いて思うのは、「結局20年間ほったらかしだったワケでしょ?」と言う意見だけだ。
結局は使う側の人間がキチンとリスクを理解していなければ今後もこの手の問題は勃発してくるだろうし、そして何よりもシステムを納入する側が全てのこういうリスクをクライアントに伝え理解してもらおうとしない限り、この手の問題はなくならないのだと思う。
何事もキチン（説明も含めて）とできていなければ、結局はどこかでボロが出るものである。
｜by Nagarazoku : 10:02｜コメント (0)｜トラックバック (0)｜
トラックバック・スパム対策のため、このBLOGへのリンクを持たないページから送られたトラックバックは自動的に拒否されます。悪しからずご了承ください。
また、このエントリと全然関係の無い内容のページからのトラックバックは、アタシ的な判断で勝手に削除します。これも又、ご了承くださいマセ。
■このエントリーのトラックバックURL ≫ http://www.nagarazoku.com/mvt/mt-tb.cgi/1145
