座談対談 ソフトウェア産業はどこへ行くか ~迫る構造変化~

日時:2008年8月5日 18:30~ 於:経済産業省内において
◆語り手
経済産業省商務情報政策局文化情報関連産業 課長
村上 敬亮氏(写真中央)

◆聞き手
JASPA会長/中島 洋(写真左)
専務理事/横尾 良明(写真右)

2008年のJASPA新年会特別公演の席で村上敬亮情報政策課企画官(現 商務情報政策局メディア・コンテンツ課 課長)は「10年後にSlerは消滅する」と刺激的な見解を述べた。村上氏は旧通産省時代から情報産業、ソフトウェア産業にタッチしていて、経済産業省きっての産業通である。その後、会員会社の中から、もっと詳しく根拠を聞きたい、という声が絶えない。そこでJASPA中島洋会長、横尾良明専務理事が改めて時間をとり、直接村上氏と会って、ソフトウェア産業の現状と未来について議論した。

中島 l月の新年会の発言は非常に刺激的でした。私の聞き方に間違いがないとすると、10年後ぐらいには日本ではSlerはなくなる。そのロジックはというと、一つはユーザー自身で取り扱いやすいソフトウェアが出揃って、業務を知っている自分自身でシステムを開発していってしまう。そうすると、現場を知らないSlerの活動の余地が小さくなって、しまいには消滅する、というように私は間こえた。村上さん、このロジックの前提となる条件は何でしょうか。どういう理由でSlerにとって冬の時代が来るのか。

村上 まず、優れたITユーザーが今何を議論し、どこに向かおうとしているのか、をよく見極めることが大切だと思いました。経済産業省では、07年11月から08年5月にかけて有名な大手企業CIOの皆さんに集まっていただき、今、ITユーザーが考えるべきことが何かを徹底的に議論してもらいました。そこで、有力企業の事例紹介と分析を行った結果、さまざまなことが明確になり、その成果を「IT経営ロードマップ」としてとりまとめることができました。
(注: http://www.met1.go.jp/press/20 080625001/20080625001.ht miからダウンロード可能)

中島 なるほど。Slerの方向性はユーザー企業のものとずれてしまっている。

村上 ちょっと刺激的なまとめ方をしますと、CIOの皆さんはこう仰る。「Slerのコンサルは無駄だ。 高い料金を取って、きれいな絵を何枚も描いてくれるが、結局のところ、何をやるべきかという結論(what)は至極当たり前のことだ。それをどう実施するか、howの方がはるかに大事なのに、それは、コンサルの仕事ではなく、顧客自身の仕事だとコンサルはいう。何のためにお金を払っているのか。」ならば、「何がIT経営のやるべきwhatかについては、国で書いて公開してしまえば良いではないか」という発想となって生まれたのが、実は、このIT経営口一ドマップです。

中島 IT経営のための戦略ロードマップね。

村上 そう。ロードマップは提示しましたので、ちょっと大げさな言い方ですが、もう「ユーザーは、余計なWhatの議論はせずに、この道を行け」ということですよね。

中島 大胆なものを打ち出しましたね。

村上 経営とITがうまくいっていないユーザー企業の話を聞くと、ベンダを頼ったら動かないシステムができた。現場とベンダの意思疎通をどう図ればよいのか、パッケージ導入の際にパッケージに合わせるという指針があったため、逆に現場がシステムのことを考えなくなった。メインフレーム時代のほうが、技術的制約があったのでシステムのことまで考えながら業務設計していたので良いものができた。

SOX法が全社的なシステム見直しのきっかけになると思っていたが結局、作業が増えただけで、実態は何も変わらなかった。そんなような話が、頻繁に聞かれます。しかし、実は、IT経営のうまくいっている企業に話を聞いてみると、この疑問に答えることから取組を始めて成功した企業って、ほとんどいない。

むしろ成功している企業を見ると、例えば、リコーのケースでは、赤字転落の危機に「恵まれ」、アナログ複合機では,駄目だという認識が全社的に共有されたところから始まった。それまでは、営業が工場を、工場が営業を、互いのことを悪く言い合っていたが、とにかく会社は、アナログ複合機からデジタル複合機に移行しなくては、もう駄目だという現実を突きつけられた。しかし、デジタルになると、部品のライフサイクルが短くなる。例えば、部品業者に電子部品を6か月かけて試作してもらう。ところが、この世界は、6か月もすれば、メモリが一世代古くなっていましたというようなことが頻繁に起きる。開発したばかりのはずの部品がもう古いという話になる。そこで、取引先業者の集約化とあわせて、取引先の部品業者と先を見据えた情報共有を徹底的にやることにしようと。そういうところからやらざるえないということになった。今では、リコーさんでは、グローバルにオン・デ・マンドのサプライチェーンができあがっている。極端に言えば、グローバルに個品受注生産することが可能になっている。これは膨大な情報が上流から下流まで十分に共有されていなければできないことです。しかし、これだって、一朝一タにできあがったわけではない。部品業者との情報共有DBを皮切りに、必然性のある事項に順々に取り組んでいって、l5年間かけて、結果としてグローバルな全社SCMにたどり着いたわけです。こうした取組の軌跡について、実は、今、リコーの遠藤副社長は、全部すすみ隠さずしゃべってしまっている。でも、おそらく、ライバルは絶対にまねできません。こうした改善活動の階段は一発では絶対に上がれない。各企業が、一つ一つ、実際の課題に即して積み上げていかなければならない。けれども、Whatは同じでも、Howは、個々の企業の置かれた状況や体質、文化、そのときどんなタイプの人がどのポストにいたかなどによって、非常に状況依存的であり、それぞれが全く異なるパスを通る。だから、結果のWhatだけみても、Howはまねできない。結論がわかっていたとしても、その会社の実情にあった形で、階段を順に上ったからこそ、誰にも真似できないことができた。そここそが、改革を成し遂げた企業の強みになっているのです。

中島 赤字転落という危機に至ってそこから製品戦略の転換に迫られ、夢中で取り組んでいたらIT経営になっていた、というわけですね。製品戦略の転換という経営の意思決定が出発だった。

村上 スナック菓子の力ルビーさんも、分かりやすい例です。カルビーは生産履歴管理などITの活用で成功を納めていますが、では、何故、生産履歴、生産管理に突っ込んでいったか。 別に、生産管理のシステムの性能が満足のいく水準にあがったと思ったからではありません。単に、検疫規制で生ジャガイモを海外から輸入できなくなったからなんです。 lヘクタール当たり3万トンしか収穫できない日本の畑に対して、世界は4 万5000トン収穫できる、100円前後のスナック菓子で、原材料費に2割も3割も差がついたら、アジアのポテトチップスマーケットではとても勝てない。でも、カルビーの商品の8割はジャガイモで、そのうち半分は生ジャガである。となれば、地元の農協と反目しようが、生産農家の側に抵抗があろうが、徹底した生産管理による収穫高と質の向上に取り組まざるを得ないわけです。

中島 経営環境に変革を迫る危機があって、その解決手段の一つにITを使える機会があった。

村上 松下さんの例もわかりやすいと思います。 家電量販店の台頭やアジア新興国企業の台頭などから、流通・販売が徹底的に弱っている。何とかせざるを得ない。例えば、新製品が、世界できちんと同時発売できるかどうか。それだけとっても、これだけ新製品の価格下落が急速になった時に、どれだけきちんと同時発売でき、価格の高い期間をl力月でも2ヵ月でも長くしておけるかどうかというのは、先行投資を回収するに当たって死活問題になるわけです。このように、みなさん、本格的に取り組み始めるときの、経営戦略上の課題やメッセージがきわめて明確。こうした形で、まず、経営者のビジョン、明確な方針が打ちだれていなければ、IT経営の試みも、まずうまく行っていないのが現実です。

中島 経営目標を経営層がきちんとつくることが第一歩ですね。

村上 そうです。この視点からやる、という決意。流通における競争力回復のためにやるとか、生産管理によってヘクタールあたりの収穫高を上げるためにやるとか、デジタル複合機でこういう競争力を得るとか、そういうある種、経営からバイアスをかけてもらわないと、経営上の成果につながるようなIT投資は、動きはじめない。


もちろん、単にインターネットを使いましょうとか、メインフレームをダウンサイジングしましょうとか、そういう取組についての目標は、経営戦略抜きでも作れます。しかし、それだけでは駄目だということです。全社的な経営課題と、個々のIT投資の関係がきちんと説明できないといけない。

実は、うまくいっている会社には、こうした経営からのメッセージという点に加えて、もう一つ、大きな特徴があります。 それは、わが社の業務をlつの絵に落としてみるとどうなるか、という全社の業務アーキテクチャーがきちんと一枚の紙に落とされているということです。

中島 目標がはっきりした後、2番目にアー キテクチャーづくり。成功したユーザー企業はこうした手順でIT経営への道を歩んだ、というわけですね。

村上 はい。その通りだと思います。ただし、全社業務を一枚に落とすに当たっても、経営からの明確な指針はきわめて重要です。何故、そのフレームの視点から社内の業務を見るのか、そこがしっかりセットされていないと、ただ書けばいいといわれても、各社の業務の全体像の説明方法なんていくらでもある。 ここは非常に微妙な難しいポイントです。では、どうやって、こうした議論が出来るような成熟した段階にとどりつくか。IT経営ロードマップでは、「見える化」、「共有化」、「柔軟化」とい三つのステップでその道筋を議論しています。

まず、「見える化」というのは、ITはきちんと経営課題の役にも直接立つということを最初に経営者にちゃんと見てもらうために、どこでもいいから何かまず、IT投資で実績をつくろうよという段階です。今や、マーケットのグローバルな急変によって、比較的細かい課題でも事業部門をまたぐ話が多い。となると、細かくても、部門役員の権限を越えてトップの判断を得ることが重要だったりするのですが、トップから見れば単なる細かい話に見えてしまって、関心を持たない。だから結局、IT経営は、その入り口にずっと留まり、本質的な業務改革を置き去りにしたまま、ただ技術に投資をせざるを得なくなる。これが多くの企業の現実です。

そこで、トップに決断をもらうためにも、まずは、どこかで、経営者の納得するような結果を、小さくてもいいから、まず出してみようよ、と。これが「見える化」の段階です。その次にくるのが「共有化」の段階です。ここからが本当に、IT経営のメリットが出てくる段階です。典型的にはコンビ二業態のシステムのようなイメージです。取引や商品管理に関する様々なシステムをしっかりと社内外で結合し、とにかくいろいろな形で、業務の共有化、情報の共有化をやりましょうということです。正直、名前はどうでもいいと思いますが、業界的に分かりやすい表現でいえば、サプライチェーンマネジメントとか、そういう世界です。

その次に 「柔軟化」 の段階があります。 例えば、あるコンビニチェーンがどうしても取引にしたい相手が、その企業のSCMシステムのEDIフォーマットにはのれないと言われたときにどうするか。きれいに共有化されたシステムができてしまうと、l力所フォーマットの違う顧客を取り入れるために、全システムのフォーマットを変更しなくてはならくなくなってしまう。そのリスクが高まると、業務をモジュール化しておいて、外部環境の変化に対して、最小限のモジュールの変更で柔軟に対応できるように、業務プロセスの設計思想を変えておこうとなるわけです。そこで初めて、SOAが出てくる。こうして柔軟化になるわけです。

ちなみに、モジュール化とは、同時にモジュールの中を「見えない化」することにもつながります。ある意味、見える化、共有化とは基本的に逆行する。これも、かなり先進的な企業で出てくる課題ですが、おもしろい議論の一つでした。

中島 モジュール化は部分単位では確かに「見ない化」の方向ですね。 SOAの本質は部分単位は見えなくなっても、大きな結果を求めるということですか。しかし、大きなリスクを伴いますね。

村上 そこまでのリスクを冒してでもSOAを実践していたのは、事例を紹介をいただいた中では、唯一、日産さんだけでした。日産は、ルノーはもとより、様々な企業と手を組みつつ、アフリカ圈や中東など新たな地域で生産を開始しようとしている。しかし、そういう地域まで出て行つて工場を造るとなると、必ずしも日産WAYを強要できない工場が出てくる可能性も高まってくる。 そうすると、工場のシステムも、あまりコチコチに作ってしまうと、何が起きるか分からず、システムがぐちゃぐちゃになる「リスクも高い。そこで、実際効果が大きいことが数字でも実証できたので、SOAをやってみることにした。ちなみに、経営陣を説得できるような実証のために、数年掛けて、地道に数字を集めて検討を積み上げたそうです。

では、なぜ日産だけがそこまで出来たか。もちろん、いろいろな理由があると思いますが、一つの鍵は、先ほどの全社業務アー キテクチャーができていたということではないでしょうか。これが早かった。何で日産に早い段階からそれがあったかというと、ルノーが先行して作っていた業務フレームをそのまま使うことができたからです。ルノー のフレームがあったから、そこまでの作業を迅速に積み上げることが出来た。普通は、まず、このアーキテクチャーを全社で共有するところで大きく躓きます。

自動車製造の場合は、中国でこのプラットフォームをいつ合弁で造るか、単独で造るか。そのときに中国側の合弁相手が何を言ってくるか。そのとき、マーケットがどう変わるか。そのときに他社が何ドルと言ったから、急にもっと価格を下げた設計にしなくてはいけない。そのときに工場のラインはどうする。常にそういったグローバルな変化の流れの中で製造されています。そのたびに、工場用の生産管理システムを全部それに合わせてつくり直してはいられない。だからこそ、日産としても早い段階で業務のモジュール化に取り組む意味があった。

中島 トヨタではなぜできないのですか。

村上 僕の想像ですが、トヨタみたいにもう完全にトヨタインサイドで力イゼンのための処方箋から工場の設備の作り方まで全部、トヨタウエイで通す。そういうやり方だったら、それはそれでやっていけるのではないでしょうか。また、それだけの力も、ToyotaWayに対する信認もある。

村上 加えてもう一つ、成功した企業に共通する特徴で、強調しておきたいポイントがある。それは、経営サイドからのメッセージの明確化、全社業務の一枚絵と並んで、IT経営がある程度出来ている企業では、現場業務のデータモデリングも自社でやっているという点です。例えば、受注・生産管理情報というのは、営業部門が最初にお客さんからつかんで来て、その情報をその後、社内では誰がどう使って、その後を誰がどう使ってというのが、社内の情報の流れ方がある。それが完ぺきに見える化しているのです。

中島 そういう流れが、モデル化されて見えていると。

村上 ちょっと変な表現ですが、そもそも、情報システムは別にコンピュータを使わなくても、紙のやりとりも立派な「情報システム」です。そういう意味では、こういう意味論ベースのデータモデリングは、情報システムを設計する作業そのものなわけですけれども、これを外部のアウトソース企業でやらせてうまくいっているところは、IT 経営先進企業にはほとんどない。結局、データモデリングの意味論の解析の部分は、「それはお客さん自身がすることですね」 ということになる。結局、ユーザー自身で行わないといけない。

中島 経営戦略問題もそうなら、データを処理する現場の仕組みの問題についても、Slerはタッチできないと。

村上 経営戦略にコミットできないコンサルって、せめて適切な技術の選択をアドバイスする、コスト面を中心に合理的な調達仕様を考えることくらいしか意味がないのです。でも、ベンダ系のコンサルは、自社の技術を進めないといけないから、それもない。

では、将来は、というと、時間がたてばでも、Slerに経営プランが書けるようになりますか?情シス部門以上に全社の業務戦略を知らないわけですから、まず書けない。ではせめて、Slerは、データモデリングをやっているのですかと聞くと、やっていない。個人的には、モデルイングは、どうしても内製しなくてはいけないものとは思えないのですが、結局、放っておくと、ユーザーもベンダも、双方が誰もまじめにやっていない。強いていうと、最終的に動くシステムを書かなきゃいけない現実を突きつけられた下請のエンジニアさんが、仕様と帳尻をあわせなければならないので、その時点でやっている。要するに、下請けのそのまた下請けの協力会社のところで、実際にソースを書いている連中が、「使えねえ仕様書だな、何なんだよ」とか言いながら、そこではじめて現場の人の話を聞きながら、システムを組み上げてつくっている。金融の勘定系のような例外はあると思いますが、多くのシステム開発の現場で、そういうことが起こっているのではないか。

中島 大きな改革ビジョンが届かない協力会社の現場技術者が担当している。

村上 その通りだと思います。でも、そうなりますと、現場には、全体の改革ビジョンは描けませんし、今のことしかわかりませんから、業務改革のない、現状どおりのビジネスを前提としたシステムしかできない。システムが、全社業務改革をリードするっていうことがなかなかできない。

今、システム導入作業の中で付加価値はどこにあるかというと、基本は経営層の意思決定と目標の明確化、そのアーキテクチャー デザインにある。だから、経営戦略自体にさわれない、当たり前のwhatしか書けない上流コンサルには、将来的には市場はなくなってしまうのではないかと思うのです。ただし、現実の市場を見ると、実際には、そこまでわかっているユーザーさんは少ないわけですから、ベンダには、何も決まっていない状態で客からシステム開発の商売が来てしまう。そうするとベンダは何をやりたいのか分からないものに対して、取りあえず仕様書を書く。その結果、実際に現場でつくる作業になったときに、初めて「おい、どうするんだ」という話になって、現場の方で、本当のシステム設計作業をやる。そんな変なことになっているわけです。

中島 モデリングをその現場、しかもその下請け、2次、3次の下請けでやっている。

村上 だから、経営戦略以外に、情報サービス全体で本当に付加価値があるのは、ソフトを書き起こしている部分だと僕は思います。ここは必ずある。もちろんパッケージを使ってもいいのですが、とにかくそのソースをつくっている部分は付加価値がある。 実際にソフトを書く人は、誰か必ず必要になる。

だけど、Slerは、実際には、上流になりきれないコンサルと、実際にコーディングに取り組む業者の真ん中で、インテグレーションしているとか仕様書を書いている。お客の話を丸受けしてそれができそうなところに仕事を投げる、そういうある種の周旋屋稼業みたいにな立場に追い込まっている。しかし、そういう稼業は、お客さんがもし成長して、ここまで全部自分でやれるようになってしまった瞬間に、存在価値がなくなってしまうのではないかと思うわけです。

中島 Slerが消滅する、というシナリオがここから出てくるわけですね。

村上 はい。そうです。もうデータのモデルはできているので、あと欲しいのは、せっせとそのポリシーに従ってコーディングしてくれる人か、そのコーディングをしなくても間に合うようなプロダクトやサービスを提供してくれる人だけなのです。だから、今まで、経営とソフト作りの間でやっているSlerが一番付加価値が高いと思っていたら、実は、今やSlerが最も付加価値のない谷間の底になっているのではないかと。もしそこまでひどいことになっているのなら、それでも何故今のこの業態が残るのか。今でも引き続き、東京の大手ベンダは売り上げを伸ばしているのか。そういう疑問がわいてくる。

が、理由は簡単です。実は、大企業でも、7割方の企業はこうした上流管理がきちんとできていない。何が何だか分からない、丸投げしているマーケットが残っている。しかし、もしも、多くのユーザー企業がそのことに気がついて、自分でしっかりと上流管理をやり始めて、その上で、技術的にはSaaSでも何でも、借りるのでももっと安くて良いものはいくらでもあるではないですか、という話になると、Slerという業態は本当に要らなくなってしまうのではないでしょうか。その瞬間が、10年後か5年後かl5年後に来るのかは、よく分かりませんが。これはすごくシンプルに置き換えると、要するに使えるソフトがあって、それを入れればいいという状態にお客さんの熟度が上がってしまえば、Slerは要らなくなりますという話なのです。

中島 なるほど。非常によく分かりました。村上さんの指摘はユーザー企業とSlerの関係を軸にしていますが、中堅、中小ソフト会社にとっても実に重大なものを含んでいますね。日本の現状を言うと、中堅、中小のソフト産業は、インドや中国、あるいはベトナムなどにコスト競争力がなくなっている。 その上にSlerも要らなくなる。しかし、ユーザー企業は、このコーディングする部分においては今までSlerの下請けをやっていたところに直接頼めばいいということになりますね。 中堅、 中小のソフト会社には突破口がみえそうだ。

村上 そうなります。実は現職のコンテンツ課に来てみて思ったのですけれども、広告業界と構図が実によく似ている。広告代理店というのは何をやっているか。例えば、テレビなどあらかじめ使える広告リソースを押さえておくのです。Slerも一緒で、あらかじめ使えるSEリソースを押さえている。 極端な言い方ですが、そのSEリソースを押さえて、「私がやっています」ということにして、それを維持するために、膨大な無駄な作業と、使われない紙を途中で量産している。そんなことになっているのではないか。こんな意味のない業態であるのが本当だとすれば、業態として生き残っている方が不思議だと思ってしまいます。

米国留学帰りの若い課長補佐が 「IT業界に就職する意味が、日米で大きく違うのは何故だと言われて、はっとさせられたことがあります。「アメリカでソフト業界、IT業界に行くというと、まさにソフトをつくっているイメージだけれども、日本でIT業界に就職するというと、大手SlerでしがないS Eかコンサルをやっているイメージだ。全然ITっぽくない。何でこんなに違うのか」。ある種、 日本的な業態が来るところまで来たということだと思います。これは揺り戻しが来るだろうと。経略が書けないとすれば、この市場の付加価値は、ソフトを書いているところ自身に戻って来るだろうと。そもそも、最近は、ソフトプロダクトを作るのがミッションのはずの大手Slerのソフトウエア事業部ですらコーディングをアウトソースしている。おかしい。アルゴリズム一つが分からないで、合理的なプログラムが書けるわけがない。ハードにこれだけ余裕が出てきて、仮想化技術もこれだけ出て、まさにプラットフォームフリーになりつつある中で、アルゴリズムを書いて、メモリの使い方や仮想化技術をどのレイヤにどのような形で導入するか考えて、その中に、客がやりたい業務フローがのるかどうかが判断できるのが付加価値のはず。やはり、その足下の課題に業界としてきちんと戻っていかないと変だと思います。

中島 ユーザーの経営の意思決定のところで一緒に考える能力はない。現場でソフトウェアを造る作業もなくなって、その能力が喪失している。Slerには厳しすぎるほどの指摘ですね。

村上 すいません。でも、そう言う議論が必要かなと。ちなみに、IT経営ロードマップをまとめるに当たって、ユーザーの中でもまだ、はっきりしないところ点が一つだけ残りました。それが業務改革推進組織をどこに置くべきかという議論です。IT部門と一緒なのか、経営企画なのか、各業務部門にあるべきなのか、優秀なCIOがよってたかって議論しても答えが出なかった。

これは、実はシステムやその会社の業務の性格にも関係するだろうと。例えば、コンビ二業態みたいに、日々のオペレーション=予算の収益モデル=事業戦略みたいな企業は、もう会社を立ち上げたときから、週にl回、経営会議でITの話をしている。こういうところはIT戦略が経営戦略そのものになっているし、情シス部隊の作業と業務改革作業は、既に社内で一体的な業務となって業務フローとして定着してしまっているのです。だから、議論の余地なし。逆に、その対極は、たとえば基礎素材産業系の一部。工場ベースであらかじめ取引商社が張り付いていて、マーケットもフローもできてしまっている。工場がうまく動いていさえすれば、本社・へツドクオーターは、法務や会計などだけをやっていればいい。

中島 工場主導ですね。

村上 そう、工場が「見える化」していればそれでよくて、全然、経営とITは密着していない。一生懸命、業務とIT部隊と一緒にしているけれど、事実上、そのITのイニシアチブも含めて、みんな、工場が現場に対応して情報をさばくところをは持ってしまっている。 今更どうしようもないのです。

中島 トップ経営層は、今更どうしようもない。

村上 IT部門が業務改革部門として実動しやすい別の類型は、インフラ系事業です。通信とか金融などは、そもそも業務フロー自身が安定している。大体、業務フロー自身、法律・業法がほとんど決めているようなところがある。そういうところは、業務の中身もある意味単純で、情報システム部門自身も現場業務に通暁し得る。むしろ例外処理をどれだけ減らすかが勝負、みたいなことになる。ですから、IT部門が業務改革をリードできる。実際、電力会社の改善サイクルなどは、IT部門と一緒のところがモニタリングする体制になっているところも多い。通信事業も全社共有システムでいけるところは基本的にそれで回っている。< br />

ところが、そういうインフラ系事業ですら困るのが、営業系の業務です。営業部隊は、そもそも自分が何の情報を使って営業しているのか、実は理解していない。 客の名前はよく覚えているし、客の癖や好みや行きたい店はよく知っている。だけど、「営業という業務って、そもそも何の情報を使って、どういう業務プロセスで、何しているのか書いてみろ」と言われた瞬間に、うまく書けない。大手企業の、立派な大学卒の営業ですら、あのお客といつ飲みに行こうかということは一生懸命考えていても 「業務、書いてみろ」 と言った瞬間、 実は紙に落とせない、そういう現実があるのです。

だいたい、当の経済産業省も分かっていない。例えば情報政策ユニットと称する事業所が本庁舎の西側にズラッとあるけれど、情報政策ユニットには何の情報があって、その情報をどう使って商売しているのかと問われると、全員、アドホックなある意味属人的な仕事の仕方をしていて、全然、体系化されていないのです。

中島 これは深刻な話ですね。

村上 これを改善しようとする人たちが今、悩んでいるのは何か。ここで、情報のオーナーシップという議論が出てきます。つまりその情報を自分で見つけだして、体系立てて使おうとすることに対して、現場がどういうインセンティブを持つか。これは俺の情報だ。こういう風に大切に使って、こういう形できちんとデータの信頼性をメンテナンスしていこう。うまくっているフロント系は、そういう循環というか、現場の空気ができあがっている。

それをシステム部門の側で設計しようとしても、現場以上に現場のことが分かっていないと駄目なのです。これは普通の情シス部門ではとても無理です。ましてやその向こう側にいるベンダは分からない。

中島 分かるわけがないですね。

村上 その点、むしろ、下請け協力会社で実際に現場に入っているS Eのエンジニアの方が、よく知つているわけです。ただし、そこはスポット的だという条件が付きます。 協力会社レベルでは、やはり全体像は描けないわけです。それが先ほどのモデリングがアウトソースしてうまくいかないという部分と通じていて、業務系とか基礎共通系のシステムのところは実は書ける。書けるし、IT部門で業務改革もリードできる。でも、フロントの業務部門系のところは、情シス部門には難しい。顧客管理システムをどうする、営業管理のシステムをどうするなどという話になると、現場しか分からないのです。しかもその現場も、経営戦略から「こういう方針で走れよ」という指針が出てこないと、何をどうまとめればいいのか。「やっている業務、全部、ただ書いてみろ」と言われてもどうしようもない。そこがボトルネックになっていて、いわゆる情報系のシステムあというのは、なかなかうまく動かない。ただSFAのシステムだけ作って現場に落としても、オーナシップ感がないものには、使うインセンティブも働かないわけです。では、経営企画が引っ張れば動くかというと、必ずしもそういうものでもない。何の制約もなしにただ業務部門に「やってみろ」と言ったところでただぐちゃぐちゃになるだけ。 では情シス部門が引つ張れるかというと、業務のことを知らない情シスが引っ張れるものでもない、これは難しい課題です。

中島 これはしばらく模索が続きますね。

村上 そういう問題に深入りする議論がベンダ側から出てくると、ユーザーも飛び付くはずです。でも、実際のやりとりを伺っていると、少なくとも、昼間は、そういう風にはなっていない。

また、少なくともSierの役員会は、ユーザーに対して、丸ごとお客さんごとにお金を頂いてきて、その売り上げの中でいかに高コストリスクが出ないようにプロジェクトを管理するかという視点でしか議論ができない。実際、それでもなお、大手ベンダとして一 部受注残を抱えている状態ですから、それ以上、現状を変えるための議論をする必要もない。このために逆に、この業態転換にどう対応していくのだという議論が起き得ない構図になってしまっているのです。

中島 仮想化技術、高速ネット、SaaSなどの新しい技術の影響はどうですか。

村上 大胆に言えば、それ自体は議論の切り口として重要ではないと思います。 技術は何であっても解決すべき事態は同じ。むしろ技術提供側に大事なことがあるとすれば、バーチャルマシンにしても、SaaSにしても、それ自身の技術が大事なのではなくて、もうちょっとフィジカルな方の、物理限界で放熱処理がどうしたとか、本当にCPUの性能が上がるとかそういうのがあるのだったら、そちらはまだ僕は需要があると思うのです。ある意味、ハード技術回帰みたいな話ですね。

中島 ITを使う企業の勝者と敗者を分けるポイントはどこにあると思いますか。

村上 ちょっと話が飛びますが、SaaSみたいなことになってきますと、結局、これはどのくらいの規模や範囲で情報や情報処理の実需を束ねることができるかというゲームではないかと思います。

産構審の情報経済分科会というのを、この冬から春にかけてやっていたのですが、IT 市場の問題を議論していたら、結局、あるl点に議論が収斂されていった。抽象的ですが、情報を山のように束ねることに成功した企業が勝っているGoogleが世界中のホームページをグローリングして蓄積しているのは、その典型だと覆います。しかし、日本企業の場合、束ねきらないうちに、みんな、挫折しているのです。これはTo Bで考えると難しいので、To Cの消費者向けで考えて下さい。例えば異なる病院のカルテ情報など、医療情報を、我慢して束ねる。一度、束ねきってしまうと、みんな、それに付いていかざるを得ないのです。 例えばAma- zonのブック・リコメンド機能。最初はその評判は散々だったのですけれども「何か最近、いいじゃん」みたいになった瞬間に、もう誰も追い付けない。例えばiPodも、そうです。個別にきれいに丁寧にラベル管理して、テープやMDを管理できる人には要らないのですが、iPodの場合、ひたすら機械的にコピーするだけで、自動的にC Dの背表紙の向こう側にあったいろいろな楽曲が、手のひらサイズに収まって携行できてしまう、これは人によっては、妻いインパクトがあると思います。だから、やはりiPodに流れるのです。

では、この情報の束ねはじめのコツは何か。プラットフォームだけ作ってあげて、さあみなさんどうぞ、とはならないのか。僕は去年、前の担当の時、中小SaaSのプロジェクトをやって経験しました。そのプロジェクトは今も進んでいますが、このプロジェクトは従業員数20人以下の小規模企業を何とかIT化しよう。そのために、SaaSのプラットフォームをもちこんで安価なITサービスを提供しよう。そこに、電子申請の促進といったとか公的な色彩との妥協もあって、財務会計+電子申告を最初のアプリケーションとして普及活動をまず展開することにしました。ところがそういう議論をしていると、そういうことなら「給与計算もやろうよ。社保庁も0Kしているのだから7月l日の申請にちゃんとつなげようよ」となりました。こうした横展開をやっていると、次から次へと課題の連鎖が見えてくるところがあります。例えば、4月決算の企業が、株主総会決議の決定を経て法人登記の変更申請をすると、その変更登記の承認にちょうどl力月くらいかかるので、実はその承認が下りるまでの間に、申告期限の7月l日が過ぎてしまう。登記変更申請が承認されないと電子署名が無効なままなので、その期間、法人税の電子申請はできない。ならば、法人登記の変更申請の電子化もかみ合わせて一体的に課題解決をすることとしてはどうか。こんな風に、電子申請系の話の横展開も、次から次へと数珠つなぎにニーズが来るのです。

中島 ニーズの横展開ですか。

村上 例えば給与計算アプリをこのSaaSインフラに取り込もうみたいな話がある。一部の金融機関と話をしているのですが、金融機関にとって、中小企業の従業員の給与口座データは非常に貴重な情報源です。給与口座は会社の信用状態が一発で分かるからです。そこをうまく情報共有できるように、SaaSプロジェクトの普及戦術上、手を組むことができるのであれば、是非、手を組みたい。そういう話になる。さらに、そこから決済ビジネスに横出しをしていくとか、会社のバランスシートをもし月次で生で見せてくれるのだったら、貸出利率をちょっと勉強してあげますよなどというような形で、サービス競争ができるのだったら、また、SaaSプロジェクト自身としても多面的な展開が期待できるわけです。ニーズが横に横に、一つのキラーができると次々と広がってくる。

その時にとても大事なことがあります。何かというと、広がった後の世界を勝手に念頭に置いて、IT業界の側で事前にデータセンターを設計しても、絶対にうまくいかない。ということです。

中島 最初から全体像は分からない?

村上 例えば、今、財務会計アプリについてアンケートでニーズ調査をしてみた結果、ーつの普及条件は、財務会計アプリの料金が月3000円以下かどうかという点が見えてきた。では、月3000円でオンラインサービスを提供するに当たって、Saasインフラ側のコストは幾らだと。
素直に大手データセンターを使うとするとl500円という数字が出てきてしまう。3000円のうちl500円をデータセンターに持っていかれたら、商売にならない。では、幾らならいいのかという発想に立つと、「300円だったらぜひ使いたい」ということになる。「300円は無理だ。もうちょっと勉強してよ」と言うと、何が起きるかというと、まず99.999(ファイブナイン)なんて絶対に無理。例えば99.6%の可能性でいいと割り切るのです。それでも恐らく、アプリベンダがそのコストでデータセンターをつくって自分でやってもなかなか、その水準までは到達しない。国民に提供できるサービスとしては、ずっとましなわけです。

中島 利用者の立場からビジネスを考える。

村上 でも、セキュリティーの専門家とかデータセンターの専門家に言わせれば、「99.999 もなくて、異地点でのバックアップもなしに、国がやるサービスをやるなんてことはあり得ない」みたいなところから始まる。普通に考えれば確かにそうだと思います。しかし、そう言ってしまうと、現実のマーケットで、今度は何の変化も生み出せない。 もっとシビアだなあと思ったのは、最初に、SaaSインフラを担うデータセンタを2000ユーザー単位で管理しようと思っていた。ところが、今の財務会計パッケージ会社の体力では2000ユーザー向けのリソース単位でデータセンターの利用をコミットしろと言われると、この時点でもうプロジェクトが赤字になって立ち上がれない。だから、サーバーはl000ユーザー単位で貸してくださいということになる。ところが1000人単位か、2000人単位で管理するのかで、準備するサーバーの機種が違う。そこまで具体的にサービス内容を積み上げて議論していかないと、データセンター側のスペックも決まっていかない。そこを考えないで、データセンターを大型でどんどん作る話をしてしまうから、結局、それらは不良IT資産化する、どうもそういうことらしい。

中島 少し話は飛びますけれども、長い情報サービス産業の歴史の中で、今ほど、みんな、危機感を持っている時期はないのではないか。派遣事業にいろいろな東縛が出てきている。多重派遣の実態は継続できない。下請けなのか派遣なのかよく分からない業態もあって、それを明確にしてくると、またいろいろなところで法律上の問題が出てきたりする。そうなると、今までの派遣法自体がこの業態に合わないというところもある。あるいは、この業態自体が特殊に発達してしまったために、 時代に合わなくなっているのかもしれない。 一時期は一万数千社のソフト会社があった。机と電話さえあれば開業できると言われて、ものすごくたくさんの企業あったと言われていたけれど、最近のこのような状況では将来はなさそうだと皆感じを持ち始めている。 打開する方法はないか。 私よりずっと村上さんの方がこの業界を専門的に見ておられるので、どうですか。村上さん、今のイメージからすると中小IT企業はどうしたらいいとアドバイスをしてくださいますか。

村上 ちょっと大胆な発言ですが、中小IT企業の場合、実力若しくはあまりITに興味のないSEは、転業を考えた方がいいかもしれない。今のこの業界の動務実態は、やや異常だと思います。逆に、実力のあるSEは、何らかの形でシステム開発・運用需要は絶対にありますから、何があっても生き残れると思います。それが個人向けのメッセージだと思います。 「つまんないけど、取りあえず今の食いぶちが」といってSEを辞めるか辞めないか悩んでいるのだったら、早く辞めて次の道を探したらどうか。厳しい見方をすると、下請協力会社の側は、「このSEをl人使いたいなら、この3人をセットで使え」といった形で、セット販売しているという感じではないですか。それでキャッシュを確保している。でも本当は、セットにされる2人の方は早く辞めた方がいいのです。l人は自信を持って生き残ったらいいのです。逆にその人たちが生き残りやすいようなビジネスをどうつくるかということを考えなくてはいけない。そう思っています。槽意味で、優れた個人に着目して、直接、仕事を紹介するというのは、かなり優れたアプローチのように思います。 ただこれを正面からやりすぎると、3人抱き合わせ販売をして仕事を融通し合っている現存する多数の中小IT企業を敵に回すことになるので、その立ち位置と守り方というのが難しいですね。非常に冷徹な見方をすれば、最後はその人たちの商売もなくなって、どこかのチーム事業に組み込まれることになることが脱出口ではないでしょうか。今の情報システム業界における下請協力会社の仕事の紹介し合いは、付加価値の低い技術者斡旋業に終わってしまっている懸念がある。

中島 なかなか耳の痛い指摘ですね。

村上 これを解決するには10年20年の長い時間軸が必要だと思います。そのスパンで語ると、実は建築も広告もITも全部同じで、エンジニアリングと裏表の関係にある。ソフト開発管理にせよ、広告制作管理にせよ、建築プロジェクトマネージメントにしても、エンジニアリングがきっちりしてこないと、工数が事前に予測できず、常に変動が激しくなって、期間工のマーケットが必要不可欠にならざるを得ない。どこまで需要変動予測ができるかというところです。派遣型の下請協力会社にビジネス機会が残るかどうかはそこにかかってくる。実際、やっかいなのは、実はこの世界も、最後、セロにはならない。例えば自動車の世界で、期間工は絶対要るのです。どんなに現場を大事にするトヨタだって、期間工ゼロは絶対に無理なのです。世界中のマーケットの需要変動がある。それは、実は学者先生の世界だって、非常勤講師は絶対になくならない。大学の教員を全員専任化するのは相当難しい。すると、非常勤講師の生活が結果として支えられるようなマーケットというのをどうつくりますかということになる。SEについても、それと同じことがいえると思います。あとは、7割方非常動講師の状態をいいと思うか、やっばり非常勤講師はl~2割がいいところだと思うか。その辺のバランスに、エンジニアリングの進捗などが絡んでくるんだと思います。

中島 需給の調整の仕組みの一つとして不可欠な要素はありますね。

村上 今はSEを期間工として非常勤で残さざるを得ない人たちをどこまで絞り込むことが出来るのか、見えない。その状態の中で、非常勤を周旋している人たちが利益を上げているという不自然な状態になっている。これはやはり早くl回再構築しないといけない。

ただしそれは、単純な再委託禁止や下請規制の強化で正面突破できるかというと、そういう問題ではない。やはり解決の本質は、ユーザー側が発注の時点で工数が正確に見積もれるような、何をしたいのだということがはっきり分かっているということが恐らく一番大事である。そこが契約時点ではっきりできるようであれば、業務系の大半は、実は相当程度持っているパッケージを持ち込んだ上で、そのパッケージのソースを書いた人が自分でその現場に合わせてカスタマイズの話を聞きながらしてやれば済むというレベルなことが多い。実際、ベンチャ一系などでパッケージを持っていて、そういうサービスで既に大手ITユーザーのところに入り始めている企業が出始めている。特に情シス部門を介さない、業務部門直接受発注のところで起き始めているところがおもしろい。僕は多分、その業態の方が、先に行ってしまうと思うのです。

中島 現行の技術会社とは違う形態ですね。

村上 はい。ですから、地域のTTベンダということで言えば、「ソフトを書くことが好きだから」といってソフト屋として生きていくか、ローカルで、ITコーディネーターみたいな立場をきっかけにしながらユーザーに入り込む形で上流工程に直接関わるか、いずれの生き方をとるかを選択するようになるのではないかと思っています。

今後は、 ITユーザー企業の方でも、 中小・中堅企業は、l社単位で経営改革を進めることが難しくなっていくと思います。ITの利活用戦略も、取引里の連携を含めたバリユーチェーン全体を見渡した改革が必要になる。大企業の場合でも、l事業部門の一つの課で、ITの利活用を考えろといって難しい。それと同じようなことになってきている。取引先まで含めて複数社をネットワーク化した状態で、ITと経営の戦略を考えなくてはいけない。だから、そこをつなぐようなつなぎ手として、ITと経営の架け橋になれる専門家の実需が今後拡大する。ITコーディネーターにもいろいろいらっしゃるとは思いますが、経営とITの架け橋役に本当になれるITコーディネーターのマーケットは、今後必ず拡大します。

そういう意味では、中小ITベンダも、大手Slerと同じで、本当に経営とITの戦略がこなせるITコーディネーターのような経営側のスキルを目指すか、「とにかく僕はソフトを書くのが好きだから、おれのソフトを書く腕を買ってくれ」というソフト屋としてのスキルを磨く方向に持っていくか、どちらを選ぶのかを、いずれ迫られるようになるのではないかということです。

中島 そういう能力のある、力のあるSE、技術屋さんは、インドや中国と戦えますよね。

村上 戦えます。特に、僕が最近、危機感を感じているのはインドなのです。今、インドに出す意味と、中国に出す意味とが、少し変わってきているように思います。中国は、いい意味でも悪い意味でもちょっと日本の下請けなのです。人足オペレーションになっているので、極端なことをいえば、コスト削減が目的で中国下請市場が拡大するのは、あまり怖くない。コスト合理的だったらどんどん使えばいい。日本語は上手だし、むしろ日本の非効率な下請協力業界に業界改革を迫るいい機会かもしれません。

ただし、インドは少し事情が違います。大連のように日本に向いたサービス精神旺盛な部分は全くないので、ユーザーや大手ベンダから見れば使いにくいのですが、実は、非常に本質的な動きをしているように思います。インドはエンジニアリングの国です。インフォシスが何をやっているかというと、上流のことは分からないけれど「こういうふうにソフトをつくりたいのだったら、こうしないとソフトになんないよ」とか、そこまで厳しく言い返してくる。本当に合理的な祖父府と作りをしてきます。そのため、プロジェクト後に着実に知見をためて、どんどん上流に来ているのです。

中島 情報を束ね始めている、知識を束ね始めているわけ。

村上 そう。しかも、日本の優秀なITユーザー企業の中には、「よくわからないSlerに出すよりも、自分でしっかり上流管理をした上で、インフォシスに直接出せばいいではないか。」、そういう風に考えはじめている企業が着実に出てきています。インドの成長、やはりこれは、国の伝統なのだなと思いますけれども、やはりかの地は数学の国。 競争力という意味で、本当に怖い相手だと思
います。

中島 「ゼロ」を発見した国ですからね。

村上 そういう意味では、インドを直接使えるユーザーが増えるとするならば、逆に日本の下請け業態が抱えている業界問題をインドが一足先に一挙に解決してしまう可能性があります。

彼らには有利な条件がある。インドにはほかにまともに給料を稼げる業態があまりないから、優秀な人材が集まる。正直なところ、地頭(じあたま)がいい。そこに日本の情報産業は圧倒的に負けている。そういう意味では、地頭総合力とエンジニアリング文化でインドに負けるという可能性はある。中国に関しては単なる下請けだから、そんなに気にしなくてもいいし、まあ、日本の下請改革効果としても、良くも悪くも、漸進的で、基本的には、似たような土俵にいると思っていていいと思います。

中島 それこそ為替が変動すれば、それでまた競争条件が変わる。

横尾 私はl個だけ質問をさせてください。では、どうすればいいのか。もし役に立たないなら、このIT業界をそのまま生き残す必要もないが、しかし、より良くする方法はあるのではないか。IT業界だけではなくて、日本の国をよりよくするためには、やはりITは避けては通れません。だから、どうすればいいのか。先ほどの話を聞いていて痛感するのは、ほとんどの問題を解決する方法はもう基本法の立法しかないと言うことです。現場でしっかりモデリングし、コーディングしてゆく、絶対にこういうものは残しておかなければならない。その技術者がきっちりつくる。現場はこうしっかりしている。それをちゃんと経営者に見せる。そうすると、「おまえ、どこまでできているんだ」となる。

村上 いきなり基本法ということかどうかは分からないですが…。

横尾 いきなりやらないと、この国は無理だと思います。

村上 それは、システムの領域に限りません。経済でも金融でも全部そう。それを言い出すと、全部、基本法からつくり直しという、そういう議論になってしまいませんか。

横尾 ただ、ソフトウェア産業には、もともと法律がなかったのだから、他の分野で基本法をつくるのに比べてはるかにつくりやすいはずです。経営者は戦略的にやらなくてはいけないとか、目的は何なのかということを実践してゆくには、最初にそれを律する基本法でIT産業の足腰を固めることが、やはりなくてはいけないという話ではないですか。

村上 ちょっと横尾さんがおっしゃられるスケール感を矮小にしてしまうようで恐縮ですが、いま、「重要事項説明」のようなものをもっときちんと普及させるべきではないかと考えています。要するに、その時点でこのシステムは何をやりたいのか。何をつくりたいのか。どういう手順で、何をどうなのかというのを、ちゃんとユーザーとベンダの間でお互いに約束し合えるようにする。そういう手続き的なものです。その手続きがない状態で取引するのはいかがなものか。そこをきちんとやらせるための仕組みを、今、考えているのです。

横尾 もっと踏み込むと、そのときに「義務化」 することです。その書類をちゃんと残しなさい。情報がいつでも見られる形に残しなさい。それだけなのです。それが義務化。それがなくて、文句を言っても駄目なんです。

村上 そうですね。義務化かどうかは議論があると思いますが、最初はそこからだと思うのです。そうすると、いかに出来の悪い書類で契約をしているかというのが白日の下にさらされるから。 そうすると、当然、批判が始まるはずです。

横尾 それがなければいけません。なければいけないというのを必ずつくっていくと、それにすぐ枝葉がついていきますから。

村上 「天下の何とかだといっても、こんなもんか」みたいな、それが白日の下にさらされてしまえばOKということですかね。

横尾 今の話はここから始まるわけではないですか。

中島 全体として何をやりたいのか。経営者が何をやりたいのかと。重要事項説明ということの義務化によって、ユーザー経営者が何をしたいかをも明確にしてゆく。その合意事項の策定過程で経営者のITへの取り組みに変化が起こるかもしれない。

村上 いかに不明確な内容で契約を始めたか、商品を購入するときは商品内容をよく確認しましょうと、一言でいえばそういう話なのです。

村上 「IT経営ロードマップ」に話を戻すと、次のような指摘の一説があります。 IT経営計画は、長期でなければ駄目だと。要するにl年で結果を求めたら絶対にうまくいきません。3年から5年はかけるつもりに経営者自身がならなくては駄目だということです。ただし、ここが肝心なのですが、だからといって、無理に高いレベルで広く全社標準化のようなところから入る必要もない。これをやると間違える。必然性を丁寧に積み上げ、予算も、その取組の進捗にあわせて段階的に順を追って落とすように言っているのです。

この長期の覚悟と、短期の契約というこの論点が、いつも混乱しているように思います。結果が出たことに対して順を追って金を出すという契約の仕方に、実務を変えなさい。でも、物事を考えるのと満足のいく結果を追い求めるのは、長期で考えなさい。この両者の話は別だということを混乱しないようにしないといけない。5年単位で考えるけれども、契約は短く区切っていく。この辺が混乱すると、単純な再委託禁止契約とか、上流と下流は何が何でも違うベンダでなければいけないと行った無理筋な話にすり替わってしまう。成果が出ていれば、5年間、同じベンダでいいと思います。ただ、カネとプロジェクトは、ちゃんと順を追って段階的に進めていく。その関係をどう理解させるかなのです。まあ、経営者にとっては、従来より正確に中身を理解することが求められる負担の増える話なので、なかなか大変だろうとは思いますが。

横尾 こうした変革を通じて、ユーザー企業のIT経営への進展とそれを支える日本のIT産業に突破口が出るかもしれません。それをさらに加速させる意味でも「IT産業基本法」がぜひとも必要だと、思いますが。

中島 今日はどうもありがとうございます。非常に厳しいご指摘の中に、またまた、 IT 産業の未来を切り開く突破口にヒントもたくさんあったと思います。