前回書いたようにその頃からこれまでの単体経営重視から連結決算、グループ経営重視に舵が切られていた。会計監査ももちろんそういう見方になった。すなわち、親会社の損失を子会社につけまわすなんてことができなくなったのである。

これは、大きなインパクトで、親がちゃんと子の面倒をみなくてはいけないということなので、それまでは、論功行賞的な人事で子会社の社長を充てていたのを、きちんと経営できる人材を送り込まなくてはいけないというふうに変わっていった。実務的にも親会社のリソースやノウハウを子会社にトランスファーすることが求められるようになった。

情報システムに関しても、前回書いたようにグループのアウトソーサーとして振舞うことが重要になった。アウトソーサーというと、どちらかというとインフラを考えてしまうが、インフラだけではなく、アプリケーションの領域まで拡大する必要があった。そうなると、共同利用になるわけだから、標準のアプリケーションを設定して、それらを各社が使いまわすことが効率的である。

当時は、一部親会社のメインフレームの業務システムを子会社が使うことをやっていたが、それをこれから拡張するわけにはいかないので、新たな共通システムをもってこなくてはいけなくなった。

さて、それをどう調達するのかである。それというのは、基本的には製造業なのでサプライチェーンの仕組みである。選択肢としては、手組みで作るか、パッケージを買うかである。もちろんまだ、SaaSという形態はなかった。その当時の雰囲気はもう手組みの時代ではない、パッケージを使って安く早く作る方が得策であるということであった。

そして、ある中堅ベンダーのパッケージを決めてそれらをカスタマイズして使うことにした。しかも、Javaで走るWeb対応のもので、ASP型のサービス提供である。おそらくこんなことをやっていたところはほとんどなかったのではないだろうか。案の定、大変苦労して何とか動かした。苦労はパフォーマンスの問題が大きかったが、開発で各社の要件をどこまで入れ込むかといったことも難しい問題であった。

連結重視のグループ経営といってもまだまだそれぞれの会社の固有性や“癖”みたいなものを無視するわけにはいかないし、どうしてもカスタマイズが発生してしまう。

このあたりが非常に難しいところで、標準と固有のバランスをどうとるのか、標準に寄せるときのガバナンスをどう効かすのか、ずいぶんと悩んだものだ。

で結局、そのパッケージは数社に入れたあと、もっと自分たちの融通が利くようにするため、自前のパッケージを作ることにした。もともとそうした技術力はあったが、コストとのかねあいでパッケージ導入に踏み切ったのだが、変更が多くなるとそのための期間とコストもばかにならなくなるため、かえって自前のものにしたほうがよいという結論になった。

これは、モチベーションの問題にも関係していて、お仕着せのものから自分たちで作り上げることで意欲も上がることが大きかった。

そんなわけで、開発フレームワークを作り、それをもってグループ会社へ展開したのである。