2005年03月30日
みずほの二の舞だけは・・・
本日の日経新聞4ページには、『三菱UFJ 統合あと半年』と題したコラムの「下」が掲載されています。銀行統合というテーマで、我々の頭に一番最初に浮かぶことは、みずほの統合時に大問題となった、システムの統合でしょう。同コラムによれば、今回の三菱UFJの統合においては、システムの統合を二段階に分けているようで、最初の段階のいわば仮の統合は2005年中に行われます。以下にその概要を引用しておきましょう。
（引用始）
『焦点はシステム完全統合前の「Day１」と呼ばれる段階だ。東京三菱とUFJの二つのシステムを併存させたまま、中継器を使って預金・振込データを双方のシステムに振り分ける。』
（引用終）
この記述だけ読むと、なんとも危なっかしそうなシステム統合に見えてしまいます。企業の合併時のシステム統合トラブルにとどまらず、新システムを導入するときというのは、なにかとトラブルがつきもので、日経コンピュータという雑誌では『動かないコンピュータ』と題した連載が組まれていたほどです。私もかつて会計システムの構築に携わっていましたが、幸いにも本番稼動後にシステムが落ちたりエラーが発見されたり、という事態には至らず、本番稼動後のサポートにおいては手をもてあましたほどでした。
もちろんシステムにより難易度の高低は千差万別ですが、私の成功体験から語らせていただくと、システムの順調な稼動の鍵は、全てのモジュールが完成した後に行われる統合テスト（システムテスト）にあると思います。ここで大事なのは、統合テストにおいて本番環境のデータを使用して、機能面・パフォーマンス面の二面から、手を抜かずにしっかりと検証を行うということです。
なぜテストデータではだめで本番環境の生のデータを使う必要があるかといえば、生のデータには思いもしない意外なデータが含まれているからです。
システムの仕様を決める際には、その部門、ないしシステム担当者のインタビューに依存することが大きいですが、そうした会社のキーマンであるような方にも誤認識が必ずあり、それを実際のデータでつぶしていかねばならないのです。例をあげれば、私の経験では他部門から連携される会計データに、伝票内で貸借が合わないという、会計の常識では考えられないデータが存在し、統合テストでの発見により、本番稼動後のトラブルを未然に防ぐことができました。
システム構築に携わる側としては、過去の議事録をひっぱりだして「ユーザーさんがこうおっしゃったので、その通りにつくって、こういう結果になりました」と、もめごとになった場合は自己の防衛を考えることも大事ですが、今回のように特に社会的にインパクトの大きい案件においては、不具合でレピュテーションにダメージを受けるという点においては、ユーザーもシステムベンダーも利害をともにしていますので、システム統合のベテランであるSE側がリードして、トラブル回避を率先して行うべきでしょう。
もし、現職のSEの方が当サイトを読まれていたら、「そんな簡単のこと言われなくても分かってるよ！予算・スケジュールが足りねえんだよ！」と言われてしまいそうですが、ボトルネックが予算・スケジュールなら、その拡充を要求すればよいだけです。三菱UFJの統合がうまくいくことをお祈りしたいと思います。