2020.3.23
1995年～2000年「アウトソーシングとは何だったのか」「インターネットとは何だったのか」
ベテランと若手の業界人が「平成の30年＝SIの30年」を振り返ることで、SIerとしての自らの立ち位置や発想・行動パターンの特徴を再確認し、「令和＝DXの時代」にいかに向きあうべきか、そのためには何をすべきかを考察する。
平成元年から語る
1995～2000年
～アウトソーシングとは何だったのか～
三谷- バブル崩壊後の超コストカット指向の中、EDS、ゼロックス、コダックなどのケースが出て、自社でやる意味がないものはアウトソースしてしまえという風潮が出てきました。アウトソーシングということによるSIerのインパクトは何だったのか、ご意見ありますでしょうか？
鹿島- コダックはIT部門を全部出してしまいましたが、その言い分が「コダックはフィルム会社で、IBMはIT会社である。だからITはIBMのほうがいいに決まってる」ということでした。こんな分業の一環で出していたので、突き詰めていけたなら、受けたほうも出したほうも得をしたかもしれないと思うんです。アメリカではY2K（2000年問題）のとき、スパゲッティコードを今更直せないということでERPがたくさん入りました。オフショアにもつながる話ですね。現実は受注側にとってはプラスだったかもしれませんが、発注側にとってはますます自分がプログラミングを組んで勉強する機会を取られちゃったというところがあったなという気がするんですよね。
- 三谷
- そうですよね。ユーザ企業自身がITリテラシーのレベルを落としてしまった。
宗平- 結局、ITエンジニアは会社の中でのローテーションが難しかった。だから子会社化やアウトソーシングはユーザ企業側の事情としてはあったような感じがしますね。このことは自治体の仕事をやっていたので、余計に強く感じました。自治体側でITの技術者を雇ったとしてもどうやって昇格させていくか等の道が作れないみたいなところがあったんです。
猿田- 結局そういうのがズルズルと続いてしまうと、SIerの中で本当に下支えしている人の立場はあまり向上しないなと思いますね。
- 三谷
- レガシー問題は、経産省の「DXレポート」が出てから話題になっています。企業を下支えしていた外部の人材がいなくなってしまって、ソースコードの内容について誰もわからないような状況になってしまった。ここにもつながりますね。
DXレポート ～ITシステム「2025年の崖」克服とDXの本格的な展開～（METI/経済産業省）
- 宗平
- さっきERPの話をされましたが、あれがまた知識があるところと、ないところで格差を作ったなと...。
- 鹿島
- ERPは真ん中に鎮座ましまして、ERPが必要とするデータをERPが必要とするデータフォーマットで、ERPが必要とするタイミングで持ってこいというんです。周りにあるカスタムメイドのソフトウェアは、バージョンアップされるたびに、常に仕事をやっていなければいけなくなってしまうので、ちっとも合理的じゃない。
- 宗平
- ちょうどERPが台頭したころ、カスタマイズすることが格好いいことだと思われていたんですよね。
- 三谷
- 当時のユーザ企業は、ERPをそのまま導入するのではなく、多くのカスタマイズを要求してしまった。これはベンダ側の目線からどう振り返りますか？。
- 鹿島
- ERPはEnterprise Resource Planningですから、エンタープライズに一個しか入っちゃいけないはずが、各ディビジョン、子会社が違うものを入れた。これを繋ごうねと言って、ERPのシステムインテグレーションというわけのわからないことをやっていました。ちなみにアメリカでも実は同じことが起きているんです。buy vs build（開発か購入か）というようなことが、アメリカでもずいぶん騒がれていました。
- 三谷
- 当時、Commercial off-the-shelf（COTS）、「市販されている製品をそのまま使う」という発想がありましたね。日本はそのままではなく、それを細かく丁寧に調整してしまうことが好きでした。ここがやはりだめだったんですかね。
- 鹿島
- フロントエンド側は価値の高い仕掛けが作りやすいのかもしれないんですが、バックエンドは複式簿記と全然変わらないですよね。
- 三谷
- なのにそこにこだわりを持ちすぎたということですか？
- 鹿島
- ええ。SAPを作ったのはドイツで、ドイツは上から一体で動くような企業体ですよね。企業文化を如実に反映したERPでは、アメリカのような分散型は入りにくかったと思います。
- 宗平
- 日本でERPを入れても、製造業は生産管理にはほとんど使っていなくて、経理と人事にしか入れていないですよね。
- 三谷
- 日本の工場内の業務は特にその傾向がありますね。A工場、B工場、C工場で業務内容はバラバラで、工場長が強い力を持っている。この状況で業務標準化を目指すなんてそもそも無理だという気がします。
- 鹿島
- ERPが流行ったときに入れたはいいのですが、カスタマーを向いてCRM、サプライヤー向けにあるSCMシステムまでユー ザーは入れようとしたんですよ。別にERPを入れたから、それに合わせてあれもこれも入れなくてはならないというものではないんじゃないですかと申し上げたことがあるんです。
- 猿田
- みんな入れていると、自分も入れなければいけないという不安に駆られたんじゃないかなと思います。今もERPが別のものに替わっただけで大差ないような気がします。
- 宗平
- ただユーザも賢くなったので「カスタマイズせずアドオンで」というように、だんだんアーキテクチャが良くなってきましたね。
- 三谷
- さすがにとんでもないお金がかかってしまいますものね。しかもバージョンアップごとに。
1995年～2000年 ～インターネットとは何だったのか～
- 三谷
- 当時私のオフィスは渋谷にあったので、ビットバレーに生まれたさまざまなネットベンチャーを見ていました。いずれもとてもインパクトがあった。インターネットの台頭ということについて、SI業界から見てどう感じられましたか？
- 宗平
- みんなeメールを使うようになってコミュニケーションが良くなりました！ あとネットで調べものをするようにはなったけれど、システム開発に適用するようになったのはしばらくしてからで、今はWebベースで開発するのが普通になりました。
- 猿田
- ECサイトができるようになったのは、もう少し後ということですね。
- 三谷
- 2000年前後でしょうか。
- 鹿島
- 我々の業界から見たときに、システムの作り方がどれだけ違っているのだろうと考えてみると、むしろメインフレームがクライアントサーバーベースのアーキテクチャに分かれたときのほうがインパクトが大きいような気がしますよね。
- 三谷
- この頃様々なインターネットビジネスが生まれ始めていました。そして大手のSIerも、みんな自らインターネットビジネスの主体になろうとチャレンジしていました。でも結局ほとんどの企業で撤退してしまいましたよね。
- 宗平
- フロントが上手くなかったということでしょうか（笑）
- 鹿島
- でも広めたという意味では、意味があると思いますよ。
- 三谷
- おっしゃるとおりです。ITがビジネスの真ん中に躍り出るという時期は、このときが初めてだったといえますね。ちょうど今のデジタルビジネスに近い状況です。
- 鹿島
- インターネットに替わってEDI等がなくなってしまった気がします。
- 三谷
- 一方、Raymondが『伽藍とバザール』を書いたのが99年。Linuxが出てきた時期です。オープンソースはどんなインパクトを業界にもたらしたかというのも一つの論点ですね。
伽藍とバザール (レイモンド エリック)
伽藍とバザール がらんとバザール The Cathedral and the Bazaar レイモンド エリック NDC 007 この論文ではまず、大成功したフリーソフト/オープンソース プロジェクト fetchmail を分析する。このソフトは、 Linux の歴史から導かれる、ソフト工学についての意外な理論を試すという意図で実施されたプロジェクトである。本論ではその理論を、二種類の根本的にちがった開発スタイルという形で論じている。一つは FSF やそのまねっ子たちの「伽藍」モデルで、それに対するのが Linux 界の「バザール」モデルだ。この2つのモデルが、ソフトのデバッグ作業の性質に関する、正反対の前提からそれぞれ生じていることを示す。（同論考の概要より）
- 猿田
- 私がオープンソースに魅力を感じたのは、テクノロジーが公開されているところだと言ったんですが、入ってから新しいテクノロジーをコモディティ化する役割を担ってくれるという魅力もあると気づきました。インターネットが開かれても、みんな使い方がわからない。そこにオープンソースのApacheなり、PostgreSQLなり、インターネットにアクセスしてビジネスができるための道具が開かれた。だからこそSIerがPostgreSQLとか、Apache等をインテグレートして、お客様にお届けするということに、もっと早い段階で目をつけていれば、もっと何かできたんじゃないかなと思います。
- 三谷
- 我々のように「1行いくら」でプログラムをつくってきた人間からみると、オープンソースの世界は、「おーっ」と声上げるくらいの驚天動地でした。逆にオープンソース側の世界からこちらを見て猿田さんはどう思われましたか？
- 猿田
- 例えば、OracleはOracleにしかできないことがあると思います。しかし、適材適所とリーズナブルということについて考えれば、例えばOracleでもできるかもしれないけれども、PostgreSQLでも必要十分だったら、PostgreSQLを入れてその費用を違うところに使えたり。そう考えを変えるべきだと感じています。
- 宗平
- インターネットがあったからオープンソースコミュティがあって、Oracleや、Microsoftとかに対して、あんな高いものではなくて俺たちが作っちゃおうぜという形で、オープンソースで作ってくれてきた。Oracleが何か出すと、俺たちも作ろうみたいな雰囲気がいいですよね。
- 猿田
- 結局のところ、オープンソースは「無料」というところは実はあまり本質ではなくて、自分たちが使うものを自分たちがコントロールできるところや、オープンになっているテクノロジーにアクセスするための道具である、というところが本質だと思います。
- 鹿島
- 当社もオープンソースは早くからやっていたんですが、オープンソースを売って儲けるのはとても難しい。PostgreSQLに関しては、Oracleの代替として人気があると思うんですが、Oracleを使っていて何かあったときには怒られないけれども、PostgreSQLを使っていて何かあったときには怒られてしまう。だから怒られるようなデータはOracleのほうに残しておいて、怒られないデータはPostgreSQLのほうがよっぽど安くていいですよね。
- 三谷
- ユーザー企業から怒られる、怒られないというのは、結局、私たちが、何を価値として提供しているかという話に直結しますよね。情報システムには"絶対安定"しか許さないといったような。オープンソースの世界を見ていると、そもそもソフトウェアを作って売るということ自体に無理があるのではとも思ってしまいます。言い過ぎかもしれませんが。
- 猿田
- そこまでは言わないです。プロプライエタリ製品じゃないとできないこともあるので領域によると思います。
- 宗平
- ユーザさんも使って大丈夫という保証が欲しいので、オープンソースのサポートビジネスという方向に行きましたよね。
- 三谷
- ということは、これからも一つのジャンルとして、オープンソースは見ていけばいいということなんですかね？
- 猿田
- そう思います。SIerの役割ではないかもしれませんが、オープンソースの普及も大切にしていきたいと思っています。
#DX#SIer#オープンソース#対談
- この記事をシェアする
- この記事はいかがでしたか？
