ポイント：市町村合併、システム統合、トラブル、データ、移行、検証、スケジュール
システム統合でのトラブルについて考える
市町村合併に伴うシステム統合でトラブルが急増しているらしい。日経コンピュータが実施したアンケートでは今年の４月以降に合併した自治体の約３割でトラブルが起こったそうだ。その原因の多くはデータ検証不足に起因する事が多いらしい。他にもハード障害、プログラミングミスなどもあるが、やはりデータを移行時に検証時間が足りなく確認不足になっているケースが多い。
実際にトラブルの発生した事例の検証時間をみて驚いた。私がSEの時に、企業の基幹システムを構築すると、規模にもよるが通常３〜４ヶ月は検証時間をとっていた。それでも、想定外のトラブルがおきて、本稼動が遅れるケースがあった。ところが、自治体の公共システムで企業のシステムとは社会に与える影響規模も大きいのに、データ検証の時間は、長くて半年、短いと１ヶ月、酷いところは１週間なんて自治体もあった。
ベンダーにも自治体にも言い分があると思う。市町村合併の日付が先に決まってしあうので、それにあわせてシステム開発スケジュールを組んだのであろう。当初は余裕があっても、トラブル等が発生して、本稼動（合併日）の延期は出来ず、結局見切り発進なんてこともあったのだろう。関係者の方の苦労を考えると私まで胃が痛くなってくる。それでも１週間の評価期間なんて異常である。
システム統合にも２通りのやり方がある。一つは、どこかの自治体のシステムをコアに据えて、それに合併する他の市町村の機能、データを寄せ集めていく方法である。もう一つは、全く新しく、システム構築をする方法である。どちらほ方法がトラブルが多かったかというと、圧倒的にシステムを寄せ集める方法である。新規で作る場合のおよそ倍以上のトラブルが発生している。
その理由は想像の範囲を出ないが、寄せ集める方は、コアとなるシステムがあるので少しデータ検証にも油断があったのか、もしくは、スケジュールに余裕がないので寄せ集める方法をとらざるを得なかったのかもしれない。一方、新規にシステム構築する方法は、スケジュール的に余裕がないと採用できない方法なので、必然的にトラブルが少なくなっているのだろうか。
先日も、東京三菱とUFJのシステム統合も「テスト内容に問題あり」とのことで延期になった。いかに業界での標準化が進んできているといっても、システム開発は設計者の思想、想いが入ってしまう。システムにはまた運用している間に利用者の自治体、企業の風土も入ってくるものだ。そのような違うものを統合する事がいかに難しいかは、システムに関与していない人でも容易に分かると思う。
合併する日を先に決めて、「システム統合をそれに間に合わせろ」ではなく、システム最高責任者の意見が合併する日の決定に反映されることを強く願う。
参考「日経コンピュータ８/８号」
業務拡大にともない情報システムでありがちなこと 2014年03月24日記述
消費税アップがシステムに与える影響 2013年10月07日記述
レビューが実施されない理由（後編） 2007年10月22日記述
レビューが実施されない理由（前編） 2007年10月08日記述
レビューの基礎知識 2007年10月01日記述
レビューが必要とされる理由 2007年05月14日記述
システム運用の大切な役割 2007年04月09日記述
ドキュメントコミュニケーションのポイント 2007年04月02日記述
ドキュメントコミュニケーションの必要性 2007年03月26日記述
不満ゼロの要求定義を目指すには 2007年03月19日記述
これからＳＥになるヒトへ 2006年04月10日記述
システム統合でのトラブルについて考える 2005年09月05日記述
システム再構築の留意事項 2004年07月26日記述
2005年9月5日 宿澤直正 記
Copyright (C) 2005 宿澤経営情報事務所