IT部門は予算配分から変える必要がある

玉川憲氏(以下、玉川):聞いてて思ったのが、攻め9割って言ったときに、私も前職でいろんなIT部門長の方と会いましたけども、お金の配分もそうなってるんですよね。

攻めが1割、守りに9割使ってて、新しいことやりたいって言ってるんですけど、「あなたの予算はうちは1割ですよ」と。そもそもトップだったら、まずそのお金の配分を変えなきゃいけないんですよね。

お金の配分を変えると。守りにそんだけ使ってるんだったら、それっておかしいでしょと。そこをどうやって守りを小さくやって攻め側に移すかっていう、そういうビジョンっていうのが大事なのかなあと思いますね。

ジェイソン・ダニエルソン氏(以下、ジェイソン):ITもやらないといけないとおっしゃってたんですけど、ITのほうがやらないといけないと思ってますね。

ITのスピードが他の業界と比べてものすごく速い。サイクルも短いし、ITで攻めないともう負けちゃいますね。

自動車だったら守り9割とか、実際に人も命が関わってるようなものがあると、機械(のような)大きなもの、長いライフサイクルが守り9割。

もしかしたら長すぎるかもしれないですけど、それもいいんだけど、ITのほうが、インターネット時代が20年くらいしかないわけですから。

もうライフサイクルのケタが違うから、それで自動車と同じような扱いになれば、すぐ遅れちゃうんですよね。

八子:ITこそ今までの領域と違って、もっと攻めの考え方を活用したかたちで。たとえば組織の作り方もそうですし、玉川さんおっしゃられたようにバジェットの取り方もそうでしょうし。というのをメリハリつけてやってかないといけないと、そういうことですよね。

それがITを活用する組織という意味でいうと、今おっしゃられたように予算の取り方、もしくはもっと攻める。「攻めていない」っていうことがものすごく、今の日本にとっては脅威となりうる。

ジェイソン:そうですね。その脅威というのは、もしかしたら「今まで通りと同じ考え方でITをぶつける」ということですね。だからちょっと物が違うから、考え方も変わらないと、多分ちゃんとうまく使えないですね。

八子:考え方そのものが場合によっては脅威となる。これまでの古い考え方そのものがっていうことですよね。

ジェイソン:僕はそう思います。

八子:ありがとうございます。

玉川:ドヤ顔してましたけど(笑)。

競争環境の中で会社を変化させていく

八子:及川さん、考え方以外に何か脅威となり得ることってありますか?

及川:考え方以外ですか? 結構、考え方共感するっていうか、いくらでもコメントできるんですけど(笑)。

たとえば、僕が知ってるアメリカの会社だと、やっぱり皆むしろ変化を好みます。変化を積極的に起こるように、マネージメントは気を使ってますし、人材の流動性も気を使ってます。

最近流行りの言葉、ダイバーシティにも気を使ってます。要は従来のあり方を常に否定する、もしくは競争が激しくあることを望んでいます。

だから一般のビジネスだと、ちょっと日本的な考え方と逆の方向だと思うんですけど、ちょうど真逆のことをアメリカのトップは考えてる人がいます。

八子:変化すること、あえて競争が激しくなることを好むというふうに考えていいんですかね?

及川:はい。セールスフォースは始めたばっかりは、いわゆるクラウドベンダーの走りの一部ですけど、当初から弊社の会長は競合を歓迎してました。

むしろ「競合がないマーケットは魅力がないはずだから、競合がないとしたら、それは自分のビジネスの行方が心配だ」みたいなことを平気で言ってましたね。

八子:むしろマーケット、そうやって熾烈な競争環境の中にどんどん追い込んでいくことによって、変化をしていく。

及川:そうです。会社のビジネスとしてのマーケットもそうですし、同時に社会としての流動性も含めて、いろいろな多様性と変化を常に望んでました。

八子:ということですね。どんどんITを活用する、ITこそがどんどん物を変化させていく。もしくは新しい手段であるにも関わらずそれを使わないことが1つのリスク、脅威でしょうし。

今おっしゃられたように、変化をしないことに対して慣れてしまっているっていうのも、ものすごく大きな脅威っていうことですよね。

ITの活用における、グローバル企業と日本企業の差

2つ目の討議、テーマに移りたいんですけど、そういった脅威がある中で、今までの皆さんのご経験で、及川さんも米国での経験のお話をされましたけど、グローバル企業と日本企業でITの活用にどんな差がありますかね? 

よく言われるのは、米国と日本だとIT部門の方々の人数が全然違う。日本はベンダーさんに7割いて、企業の中には全然ITに関する人たちがいないっていうような話が出たりとかしますけれども、それについてはどんな差がありますかね? そういった組織のあり方だけではなくって、活用のあり方。

ジェイソン:セールスフォースさんで言うと、多分そのままセールスクラウドを使う割合とかは、結構具体的な数字とか、例になると思いますけど、アメリカだと「せっかく物があるから、そのまま使いましょう」と。

「すぐメリットが出るから、そのままもう標準でいいや。とりあえず使ってみて、そのあと考えればいい」みたいな導入のやり方。

日本はそうではなくて、Platform Licenseのほうが、割合でいうとアメリカよりもずーっと売られてて、もう1回既存のシステムのまま作り直すとか、自分の会社のやり方通りに作り直すとか。標準で満足しないで、あえて新しい技術に関わらず、今まで通りもう1回やると。

八子:今までのような開発をプラットフォーム、(セールス)フォースドットコム上でやっちゃうということですか?

ジェイソン:それをするとせっかくのクラウドのメリットは全てなくなるんですから、もうクラウド使わなくてもいいくらい。そのままやり直すのであれば。

八子:でも一応、テラスカイさんもカスタマイズやられてますよね?

(会場笑)

ジェイソン:カスタマイズしてるんですけど、カスタマイズするだけでちょっといけないと思いまして、そのままコンサルとか入って、「こういう機能があるから、こういう標準機能をこのように使えばより効率よく導入できますよ」という相談も乗りますね。

八子:できるだけ標準機能に追い込んでいくわけですよね。

ジェイソン:その差分、どうしても必要なところだけを開発すれば、よりものすごく差が出ると思いますね。

八子:セールスフォースさんはそれで儲かるんですかね? 大丈夫ですかね?

及川:もちろんですよ。あとこう言ったら綺麗事に聞こえるかもしれませんけど、我々はやっぱりソフトウェアを売り切りじゃなくて、サービスを提供してる側ですので。

一般的なサービス業のイメージに近いわけですから、結局お客様側の、「使っててメリットを得ていただけないと、継続してお使いいただけなくなる=いずれ将来の需要がなくなる」なので、我々は常に「カスタマーサクセス」っていう言葉をスローガンにしてやってます。

どう作るかじゃなくて、「お客様が使って効果を得られる」っていう状態に持っていくのが、常に目標となってます。

システムをカスタマイズしすぎると継続性が損なわれる

八子:そういう意味で言うと、米国企業の場合には効果を感じているからこそそれくらい使われる、カスタマイズもせずに素早く効果を感じ取れるんじゃないかと思うんですけれど、日本の場合は効果がないんでしょうかね?

及川:ものすごい質問がきましたけど(笑)。効果が全くないかというと、多分そのあとのサステナビリティというか、コンティニュイティというか、継続性のビジネス。

どんどん自分で手を入れ過ぎると、やっぱり変化に、そのあとの変更に弱くなっていきますんで。

要はビジネスってバンバン毎年変わってく、成長企業であればあるほど、もしくは成長マーケットだと、ビジネスのやり方変わりますよね。

それに合わせてシステムの更新が入ると思うんですけれども、そういうビジネスにどれだけ追従できるかっていう点においては、あまり作り込み過ぎたシステムっていうのは、たいがいそれを失っていくものですから。

もしくはコストがどんどん上がっていくものですから、そのバランスをちゃんととれてる、理解されて使われてるお客様は当たり前のようにメリットを得られていますし、ちょっとやりすぎちゃったかなっていうお客様は、やはり苦労されてます。

八子:カスタマイズしたほうが利便性が上がるかも知れないけれども、継続的なユーザビリティであるとか、スピードについていく俊敏性っていうところが下がってしまうと。

及川:そうですね。カスタマイズの大部分は結局UI(ユーザーインターフェース)の変更だったりするので、UIの変更の最大のモチベーションがおおむね、従来のシステムをそのまま置き換えるイメージが近いので。

すなわちそれは実際のエンドユーザーの意見を必ずしも反映してるとは言い難く、結果としてそういう時もあります。

ただユーザビリティに限っていえばそれは変化していくものですから、同じく、先ほどの話に戻りますけど、「変化を求め積極的に取り入れるか、そうでないか」っていう話と通ずるものがあると思います。

ビジネスの変化に合わせて働き方も変わってくる

八子:仕事のやり方もどんどん変わっていくっていうことですよね、そういう意味でいうと。

及川:はい。実際に会社にきてパソコンに電源入れるとこから始めるんじゃなくて、パソコン電源入れっぱなしなんてザラですし、蓋を開ければすぐ動きますし、モバイル、タブレット、常識になってきた。もしくはラップトップもですね。

要は、日本もオフィスの外で働くことがだんだん当たり前になってきたこの時代ですと、そもそもワークスタイルそのものが変わってるのが世の中の流れですので。

それに合わせてインターネットでビジネスをやって、インターネットを使ってビジネスをする、仕事をするっていうのが当たり前になった以上、仕事のやり方もまた変わってくるという変化も、また受け入れるものだと思います。

八子:ジェイソンさん、どうですか?

ジェイソン:カスタマイズすれば利便性が上がるとおっしゃってたんですけど、カットオーバーした瞬間上がるかもしれないですけど、カットオーバーするまでの時間を結構伸ばすんですね。

八子:長いですよね。

ジェイソン:そのあともう1回、何か変更があった場合は、もう1回その開発が入るから、利便性が上がったところはほんの一瞬だけですね。

だから標準でいけばよりいける。より利便性ではないですけど、より活躍できる。より結果が出ることですね。

八子:使い始める期間がだいぶ早くなりますもんね。そういう意味でいうと。

ジェイソン:もう瞬間ですよ、もう今日! パーン! OK!

八子:すぐですね、今のは(笑)。

ジェイソン:すぐ。

技術導入の遅れがリスクにつながる

八子:なるほど、玉川さんそれについていかがですか? すぐに使えるっていう。

玉川:その通りだと思いますね。結局私も今経営者でやってますけど、ランニングコストっていうか、会社を回してるときのコストがかかっていくわけですよね。

導入を半年遅らせるってことは、その間丸々、人件費であれ何であれどんどんお金がかかってるわけで。さらに企業というのは周りと競争してるわけですよね。

競争してる中で、あるいい武器があった時に、「それを使わないで半年間戦うんですか?」っていうところで。

よく日本企業であるのが、「事例がないから使えません」っていう話があるんですけど、それはおかしな話なんですよね。

事例があるってことは、「もう敵が使い始めて威力を出し始めてる」っていう段階になって使うっていうことを言っていて。

もしいい武器があるんだったら、それをいい武器だって判断するのがその人の仕事であり、判断をしたならそれを早く使えるように何とかするっていうのが仕事ですよね。

八子:そうですね。

ジェイソン:今ものすごくいいことおっしゃいました。

玉川:いいことしか言わないですから(笑)。

ジェイソン:共感。

日本人はシステムを自分色に染めたいだけ

小野:ちょっと僕も少しいいこと言いたい(笑)。「カスタマイズするのは利便性を上げるために」っていうのがさっきのお話であったと思うんですけど、本当かな? と聞いてて思ってて。

僕今もプログラマーで開発もしてるんですけど、基本的に日本人って「自分色に染めたい」みたいなのがすごい強いのかなと思ってて。

たとえば日本のエンジニアの傾向としてあるのが、人のプログラムをペアプログラミングとか引き継いで、自分が担当することになったときに、何かインデントとかタブとかを自分の流儀に直し始める人がいますよね。

とりあえず、機能追加とか利便性向上ではなくて、自分色にまず染めるんですよ。「よーし、自分色に染まった。じゃあ仕事するか」みたいな(笑)。「これまでのお前の作業は一体何だったんだ?」「いや、自分色に染めてて」と。

要するにお気に入りのテイストみたいなのがあって、たとえばクラウドなんかの、「ここに会社のロゴ入れたいんだよ」っていうのと結構似たようなもので。

そういう利便性っていうよりかは、自分色に染めたいみたいな、趣味みたいなところもあって。たとえばそれによって、社員の会社に対する所属意識が上がるとか、そうなってくると利便性だと思うんですけど、何かそれ「単に自分色に染めたいだけの、担当者の趣味なんじゃないの?」みたいな。

そこらへんの、ちゃんと経済合理性があるとか、機能的合理性があるようなカスタマイズと、単純に趣味でやりたい部分と。

システムの過剰カスタマイズをもたらす要因

小野:あともう1個あると思うんですけど、さっきの外資系的スタンスの話って、多分会場の中にも「え、トラウマなんだよな」と思った人多分いるんじゃないかと思ってたんですけど、昔、某ERPとかで、「このやり方が世界的に正しいんです。お前らダメだ」みたいな感じで。

「標準に合わせれば業務が変わって、そのやり方が正しいんで、お前らの古臭いやり方はダメだ」みたいな、そういうすごい上からなやり方で、ERP(Enterprise Resource Planning)とか入っていった時代があったじゃないですか?

ああいう、自分たちはあたかも原始時代の人たちで、俺たちの先進的なやり方を教えてやるみたいな、上からな感じの標準の導入みたいなのが多分あって、それに対するアレルギー反応みたいなのが多分、正直あると思うんですよね。

だからそのアレルギー反応と、過剰に自分色に染めたいところと、あと本当に効率が上がるとか、社員の満足度とか作業効率とか、そういうようなものっていうのを。

ちゃんと「これはアレルギー反応で、反応し過ぎてるな」とか、「ここは趣味だったな」とか、「ここは本当に効率が上がったな」とか、3項目くらいにちゃんと分けて整理してくと、過剰カスタマイズっていうのがなくなるんじゃないかなと思うんですよね。

自動化ツールを導入しても、自社開発力は必要

及川:あとはクラウドが台頭する前の、オーダーメイドのフルスクラッチ開発の時代がありましたから。それと同じようにして「1から自分の思うものが作れる」っていう状態を前提にクラウドを使おうとすると、期待値の整合性が取れなくなるのは、それは当然ですよね。

八子:「早くて柔軟で、しかもサービスモデルで安くて、それを使って今までと同じような開発ができちゃう」っていうような発想じゃないっていうことですよね。

及川:はい。

玉川:あと、もともと八子さんがおっしゃってた、グローバルはソフトウェア開発の人がユーザー企業にいて、日本はそうじゃないっていう視点があるじゃないですか? そこの視点と、カスタマイズするなっていうのと、結構ごっちゃになると危険だなと思っていて。

何を言いたいかというと、インターネットテクノロジーを活かして世界的に競争力を持ってる会社って、ほとんどその企業の中の大半は、本当にコードが書けるソフトウェアエンジニアにしようとしてると思うんですね。

それはAmazonであれGoogleであれ、FacebookであれNetflixであれ、そういった企業皆そうで。一方で、日本でそういう企業がどれくらいありますかっていう話があって、その大企業さんの中で、ソフトウェアエンジニアが大半を占めていて、皆コードを書けるっていうのって、ないですよね。

まあそれは鶏と卵どっちが先なのかっていう話ではあるんですけれども、非常に如実に表していると思っていて。ある意味、ビジネスでインターネットテクノロジーがコア・コンピテンシーである会社の場合は、その中の人材っていうのはものすごくソフトウェアテクノロジーに精通してなきゃいけなくて、ある意味「コーディングできる」っていうのが当たり前のことなんですよね。

一方で、クラウドであったりSaaSであったり、そういういろんなツールが出てきて、それを使いこなすことと、コーディングをしないっていうのはイコールじゃないっていうのは言いたいですね。使いこなして、コーディングするんですよ。

で、社員の自社開発はしないっていう、そこですよね。そこ、コア・コンピテンシーがあるところに対して、自分たちで自社開発するっていうその競争力の部分、外には絶対出さないところっていう話と、業務フローを回すための自動化ツールを使うとか、外の人事システムを使うとか、セールスフォースを使うとか、そのへんは分けて考えたほうがいいなと思いますね。

じゃないと変な話になって、全部外出しだと、全部SaaSでいいっていう話になると、余計日本からグローバルなIT企業が出てくる妨げになると思います。

開発チームを社外に持つのは間違い

小野:ちょっと言っていいですか? 玉川さんの言う通りで、開発のコア・コンピタンスのすごい重要なところは、自分たちが開発チームを持たないと、要求する事業部門が作りたいって言ってるものと、できるものが違くなるとかスピードが遅くなるとか、それは絶対やるべきだと思ってて。

日本のITの産業構造上の今までの経緯って全く逆で、どっちかっていうと外に出していこうとか、たとえば事業会社でも、ITの部門を別会社に作って、情報システム会社作ろうとか、その流れの中でできたセゾン情報システムズっていう会社もあって。うちですけど。

八子:自己否定につながるような(笑)。

小野:いや、まだ否定してないですよ(笑)。だからその流れって、基本的に間違えてたんじゃないかなと思ってて。特に重要じゃない事業、どうでもいいところだったら別ですよ。

ただやっぱり情報システムの機能を1個にまとめるっていうのは、当時はよかったのかもしれないけど、今やっぱり新しいテクノロジーがどんどん出てきてるし。やっぱりテクノロジーの変化っていうのは、深く広くイノベーションに関わってきてるじゃないですか?

それであればITの開発もできて、事業もよく理解してるっていう人たちに戻すっていう流れ。今いろんな会社がその流れになってきてますけど、それをドラスティックにやってって。

もう全部外出しにするとかいう、丸投げにするっていうのやめて。何をやるべきか、事業もよくわかってるしITのトレンドもわかってるし、もうバリバリのコードも書けるし、仕様書だけ書いてるとかじゃない人たち。

そういう人たちがドライブしていかないと、本当のスピードって出ないと思うんですよね。それでいろいろやっていこうと思ってるんですけど、その流れでいくと、すごくいろいろ楽しくなるなとは思ってます。

クラウドサービスの正しい活用法

八子:及川さんも何か。

及川:いやいや、一応ここ聞かれてる皆さまに一言お断りしておきたいのが、カスタマイズっていって、話が何か混ざってますけど、実際セールスフォース、無茶苦茶カスタマイズできるんで、やりすぎちゃうお客様がいらっしゃるというだけで。

「クラウド=ただあるものを使えばいい、カスタマイズするな」っていう安直な、ストレートな話ではないことをご了承ください(笑)。

八子:よりコンピタンスがあって、コア・コンピタンスが明確になっているところは、わざわざそれをコピーして、クローンしてまで使いにいこうという発想ではなくて、あるものを使って別の領域を開発するっていう、そういう発想でいいんですよね?

及川:はい。実際アメリカのシリコンバレーのスタートアップで大きくなって、株式公開したような会社でも、実は裏でセールスフォース使ってたりして。

その背景は何があるかっていうと、あそこ人件費高いですから、彼らは皆、自社のサービスのために貴重なエンジニアを全部投入するんであって。そのために、いろんな業務のために必要なツールは、あるものをバンバンそのまま使おうっていう発想がすごく多いですね。

スタートアップは特に人が少ないですから、彼らは実際の運用の人間を雇うのももったいなくて、コードが書ける人間が欲しいからっていうだけで、AWSすら使わずに……間接的に使ってるんですけど、代わりにPaaSであるHerokuを一番最初は使って。

言ってみればAWS側の運用は全部とにかく誰かに任して、「ひたすらサービスの開発に力を注ごう」みたいなところがごく普通にまかり通ってますので、そのへんからあるものをちゃんと使い、うまく組み合わせようぜっていう。

玉川:そういう、すごく大変で絶対誰かやらなきゃいけないんだけど、そこってコアじゃないよねっていうのを、英語で言うとヘビーリフティングっていうんですよね? ヘビーリフティングワーク。

そういうのをAWSのクラウドで置き換えたり、セールスフォースで置き換えたり、そうしてその上の付加価値が高い、コアのコンピテンシーに関わるところにリソースを投入する。ソフトウェアのエンジニアであったり、そういうのを投入するというのはやっぱり正しいのかなと。

八子:メリハリをつけるということですよね。そういう意味で言うと、エンジニア、もしくはITに従事される方々もコードが書けたりであるとか、よりプロフェッショナルとして求められる領域があると思うんですけれども。