BLOG2020.02.02コストを徹底的に削減する:5長期的な視点(構造改革(デリバリーモデル、情報システム))構造改革は、流行りがある。最近はなくなって来ているものの、IBMのオフコンを使っている人がいたり、大企業に多いが、バリバリのメインフレームを使っていたりもする。Windows7でシステムを動かしているような会社もある。いうところが、いきなり今の最新を導入したらいいかというと、そうでもない。一方で「仮想化は終わってます、AWSたくさん使ってます、中国や地方に開発センター持ってて、そことリモートでやれるようにできています」というところもあり、条件が全然違う。自分たちが今置かれている条件から、業務改革が終わったところ、つまり若手中心の世界になったところで、やっていいストレッチ分だけきちんと構造を変えていく。お客様のステージ次第なので、一概に「今どれがいいんです」というものはないと思っているが、考えたほうが良いところはデリバリーモデルのところだ。自分たち、ベンダー、作る場所、この3つの関係性をいじったほうが、良くなるのではないか。最近は早く作れ、ということが多くなっていて、ベンダーに頼むという発注行為がある。発注行為があると、どうしてもコンプライアンスの世界が入ってきて、ちゃんと手順を踏んで発注しないといけない。いう発注をするよりは、社員に業務命令・依頼でやったほうが早い時代に今はなりつつある。ベンダーから内製という方向がむしろいいかもしれない。一時オフショアが流行った。今は中国よりも富山県とかのほうが人件費が安くなっていることも出始めているので、富山県なんかに振っていったほうがいいかもしれない。いう、拠点の入れ替えとかも当然ある。逆に、今東京で作っているので、富山に持って行って、将来的にベトナム、ということもあるかもしれない。自分たちの組織体制を見てどういう風な形がいいのか、外に振りすぎていれば中へ、中で持ちすぎていれば外へ、というその線をきちんと分ける。一か所にまとまりすぎていれば分散、分散しすぎていればまとめて、そのちょうどいいバランスというものを見つける。それはまずやらないといけない。これがデリバリーモデルを変えるということ。一つは、情報システム自身の構造改革。カスタムで作っているのであれば、世の中ERPは当たり前なんだから、ERP導入。これは20年前にやってきたこと。ERPと言っているところで、逆にやりすぎていることがあったりするので、それはERP専業にさせて、そうじゃないところは逆にカスタムに戻す。データベースもまとめすぎてしまって、パフォーマンスが悪くて使えないデータベースになっているならば、細分化してしまい、よく使うものとそうじゃないものに分け、よく使わないものは単純にどんどん捨てていく。捨てるわけではないが、ローパフォーマンスのデータにしても構わない。いう風に変えるという手もある。インフラストラクチャーもクラウドにしたほうが良いのか。最近はクラウドがどんどん発展しているので、クラウド側に寄せていったほうが良い、というのがベースだが、中にはまだまだ寄せちゃいけないものや、寄せるコストのほうが高くつくこともあるため、最適なバランスを考えて構造を変えていく。いうことを順繰りに、今の自分たちのシステムのステージに合わせて変えていく。大事なのは、やり続けること。いっぺんにやろうとするとうまくいかないので、長い目線で変えていく。ここまで来て、進める時に必要になるものを「都市計画」という言い方をしている。10年前と比べると、東京の風景は変わっている。丸の内に●●ビルができて、東京駅の前が変わり、汚かった街がどんどんきれいになっている。最近の情報システムは平安京ではない。あるところに都があるわけではなく、城壁に囲われてどうだこうだではなく、どこからどこまでが東京なのかよくわからないが、とにかくきれいにしなければいけない。複雑で絡み合っている。良くしていかなければいけない。それをやっていこうとすると、1年でどうこうなるものではない。色々なことを変えていかなければいけない。すると、「都市計画」というものが必要になるので、エンタープライズアーキテクチャというものを持っていなければ、ちゃんとやる必要がある。いうことを、構造改革というフェーズになったらちゃんと考える。MiyamotoBA参画前は、某外資系ファームで統括を務める。17業種のNo1/No2企業を経験した異色のIT戦略コンサルタント。