GoTheDistance

ござ先輩と言われています。(株) クオリティスタートという会社をやっています。

アメリカにはSIerなんて存在しない

知人のmark-wadaさんのBlogからTB。

SIerなんてものは無い

米国と日本との大きな違いは、米国の企業は基本的に内製なのだ。すなわち、社内のIT部門に開発エンジニアを抱え、そこでシステムの開発から運用を行なう。

ですから、米国のベンダーはそこに製品を供給する役割であり、日本でいうSIerというのはほとんどなく、あっても企業でリソースが不足したらそれを補う役割でしかない。契約にしてもはっきりしますよね。提供されるプロダクトやサービスに対する対価を払えばよいわけで、かかった人月で支払ういう出来高払いのような形態は少ない。日本のようにベンダーやSIerに丸投げして、できてからこんなはずではなかったなんて事態にははじめからならない構造なのだ。

言われてみれば・・・、っていう感じですが改めて目が鱗です。ユーザー企業なんていう概念も存在しないのだろう。システム開発から運用まで自分たちでやるのである、外に頼るのは製品サポートぐらいなもんだと。ま、100%内製ってのは無理だろうから、何かしら技術者が何人か欲しいよっていうのはあるんだろうけど、その時のプライシング・契約スキームがかなり気になる。単価じゃないのなら、何なんだろう?

なんでSIerなんて出来たんだっけ

さらに、どうしてこうなってしまったという話題にも言及して、ひとつは、企業のIT部門の弱体化・人材不足ともうひとつはベンダーへのアウトソーシングの流れではないかというのが論点となった。

つまりリソースを外に出してしまったのがやはり大きな原因ではないか、というご指摘。これについては下記記事で書いてあることがすっぽりあてはまる。大変生々しく現実味がある。こちらの四倉氏の書かれているコラムは全て一読の価値があります。

これはある商社で実際にあった話であるが、その商社は自社の全てのシステムを何百億円もかけてERPに刷新したのである。

当時のコンサルは、“これで御社は情報システム部門が不要になりました”と、吹聴したので当時の幹部はこの言葉をまともに受けて、社内に百数十人いたIS 部門のスタッフを全員子会社に出向させてしまったのである。曰く、“外でもっと金を稼いで来い”。

当初、ERPはバージョンUpさえきちんとすれば最新のシステムにバージョンUpされるはずであったが(実はバージョンUpしたくらいで時代の変化に追随することはできないと思いますが、、、。)、その商社のシステムはERPそのままでは業務に合わないので、独自にカスタマイズして、ほとんど原型をとどめないものになっていたのである(その事実は当時の経営陣には知らされませんでした。なぜならERP導入にあまりに法外なお金がかかりすぎたからです)。

子会社に出向したIS部門はその後どうなったかというと、本社にいたときにできていた会社の戦略立案や企画がほとんどできなくなってしまって弱体化したのである。

うーむ、生々しくリアリティがある記述だ。色んな会社で、似たようなケースが起こっているのでしょう。

情報システム部門が不要になったのであるというのがトリガーが全てではないでしょうが、子会社にいったことで本来IS部門が担っていた情報戦略立案という機能がすっぽり抜け落ちてしまった、というのはよくある話です。受託開発型ビジネスでは、戦略もクソもありませんから。外に行って稼いでも、プライムが取れなくて本来あるべきIT戦略立案なんて出来なくて下請けを叩くノウハウばっかりたまったとか、そもそも親会社のビジネス範囲が狭い故に子会社のケイパビリティが広げられなくて、売上は上がっているけど外で稼げなくて微妙とか、結構そういう話を聞く。

私がいまだに理解できないのが、商社がSAPを入れている理由。ミステリーすぎる。そもそも商社という業種は日本と韓国にしか存在しない業種なのに、なんでドイツ産のパッケージを導入したのかさっぱり理解できない。

ちなみに、SAPが商社に合わない一番の理由が売りと買いが同時に立つこと。国産のERPパッケージはわかりませんが、多くのERPパッケージって普通は「購買」と「販売」は全く別の業務プロセスになっている。仕入れたものを加工して製品化して売る間にはタイムラグがあるし、購買と販売の段階で別々に勘定が立つ。仕入れたものを右から左へ受け流す、なんていうビジネスモデルは商社ぐらいしかない。だが、商社というのは基本的に右から左へ物を受け流す商売のため、売りと買いが同時に立てられないと数字が上がらない。根本的な所でズレていたりするわけです。

そもそもカルチャーが違う

もう10年くらい前から、SIerは提案能力が重要、みたいな話がずっとあってコンサルティング事業の強化とか言われてるけど、まーぶっちゃけ無理だと思うんですよ。曲がりなりにもコンサルティングファームにいた人間から見るとね、カルチャーが全然違うので見よう見まねでやってても根付かないと感じています。これは逆も真なりみたいなところがあって、コンサルティング会社がSIerの真似事をしてもやっぱり上手くいかない。結局は技術主体とする子会社とかを作ることになるわけです。

(中略)

要件定義は所詮中流工程だから。よその会社の事業企画とかをガンガンやるという感じではない。これは良し悪しとは別の話。

このエントリは非常に深いことをおっしゃっています。要件定義って中流工程だよね、っていうご指摘。これ、相当Deepだと思いますよ。至言だと思う。

端的に言うと、いわゆる上流工程というのは戦略策定工程のことであり要件定義というのは、その戦略を担保するための仕組みはこうだよねっていうブレイクダウンを行う工程なんですよ、っていう話です。なので、実はコンサルティング事業の主力分野とSIerの主力分野が全く違っているのにどうやってそれを飲み込もうとしてるんだっけSIerは、っていうアツい話なんですよ、これって。

IS部門にいた頃はいわゆる戦略策定を行っていたけど、子会社になったら中流〜下流しか出来なくなりましたってのもうなずける話です。

SQLを学習できるWebサービスを作りました。