システム統合のアプローチ

何日か前に、みずほ銀行のシステム統合のエントリを書いたが、その続編というか考察の続き。
システムを統合するというのは、一つにするということだが、ではシステムが分散している状態というのは、どういう状態だろうか。

それは、似たような機能、同じものを示すデータが複数存在するということだと思う。(細かく言えば、物理サーバーがどうだとかいうのもあるが、とりあえず捨象)
これを一つにする際には、基本的には、機能をどうまとめるか、という検討をして、それに合わせてデータ項目の構造を決めていく。

通常のアプローチは上記のようになるが、今回のみずほ銀行の統合のようなケースでは、まずデータ構造を決めてしまい、その後で機能のまとめ方を決めた方がよいのでは、と思う。
機能をどうまとめるかという検討は、業務をどちらに寄せるか、ということとリンクしてくるので、対立が表面化しやすい。データ構造を決める際には、そこまでのイメージが湧かないので、比較的人間的な対立が少ない。まずデータ構造を決めてしまって、それを崩さないことをプロジェクトで共有できれば、機能統合の検討は比較的、対立を生むことなく進められるような気がする。

きっと、色々進め方を考えているだろうし、僕の考え以外にも色々やり方はあるのだろう。ただ、みずほのシステム統合は、システムの統合ではあるが、一番大きなリスクは人的対立にあることは明らか。それを回避するための体制や進め方を決めるのは、明らかに経営陣の仕事。「現場が何とかうまく調整してくれる」と思ってスタートさせてしまったら、間違いなく破綻する。