どうすればコモディティを武器にできるか

「御社の新しいデータセンターは、首都圏近郊では最もハイスペックです。しかし、ここからわずか数キロ離れたところにも同様にハイスペックなデータセンターがあります。この両者の違いと、なぜ御社のデータセンターが優れているかをご説明いだけるでしょうか？」

先日、あるITソリューション・ベンダーでの講演でこんな問いかけをしてみました。しかし、明確な回答を頂くことはできませんでした。

PCサーバーの違いを説明することはもっと難しいかもしれません。
HPとIBMとDELとNECと・・・どこが違うのでしょうか。プロセッサーはどこもIntel、OSはWindows、データベースはOracle・・・、違いを出そうと各社努力はしているものの、ユーザーからみれば甲乙つけがたく、「どれを買っても同じ」という状況です。

クラウド・サービスもIaaSについては、数年前までは、まだまだ進化の途上にありました。そのため、特徴や機能の違いは明確でした。しかし、今となっては、その違いは曖昧なものとなりつつあります。

これは、決して技術的に退化したわけではありません。それぞれが切磋琢磨し、高い完成度を目指した結果、技術的に飽和してきたこと、そして、普及が進むことで規格化がすすみ、どれも個性を失い、差別化できない状況になってきたのです。

例えて言えば、粟・稗などの「雑穀」と「白米」の違いから、どれも美味しい白米となり、「コシヒカリ」か「あきたこまち」程度の違いへと変わってきたのです。

しかし、その一方で、PCサーバーやクラウドの存在感は高まり、ビジネスや生活において無くてはならない存在となりました。

どれを買っても同じ、しかし、無くてはならない存在。これが、「コモディティ(Commodity)」です。

「コモディティをどう売るか」。ここにITソリューション・ベンダーの大きな課題があります。

まず、前提として、コモディティを使いこなす高い技術力が必要です。テクノロジーを理解し、そのトレンドを見極め、最適なものを選択できる目利き力や構築力が求められます。この技術力を基盤とすれば、３つの戦略を考えることができます。

まず、最初は、「コモディティ・イニシアティブ戦略」です。

コスト・パフォーマンスを徹底追求して、コモディティにおける競合優位を確保する戦略です。これは相当に覚悟のいる戦略かもしれません。それでも、この戦略に成功すれば、例えばAmazonのように、大きな市場を確保し、自らをデファクト・スタンダードとすることが可能になります。

次は、「コモディティ・ソリューション戦略」です。

お客様の業務や経営の視点からお客様に最適化されたコモディティの利活用を提案し、それを利用してアプリケーション・システムやIT基盤を高いコスト・パフォーマンスで構築することで競合優位を確保する戦略です。 

例えば、AmazonやGoogleを基盤として利用し、お客様に個別最適化されたアプリケーション・システムを構築します。場合によっては、その運用まで含めて受託するアプローチです。もし、自社で提供するクラウド・サービスやマネージドサービスなどのITO基盤があれば、そのITO基盤そのものを売るのではなく、お客様の個別の経営目標の達成や課題解決の方法を提案し、結果としてITO基盤が売れるというシナリオを描くことです。 

コモディティ化したものは、それ自身で明確な競争優位を見出すことは困難です。ですから、上流からアプローチして、結果としてコモディティを売るというシナリオを描くしかありません。ただしこれには、お客様の業務や経営、あるいは、システム全体の企画や戦略を描ける能力が必要となるでしょう。

最後は、「コモディティ・サービス戦略」です。

コモディティを積極的に活用し、蓄積した業務ノウハウやシステム・ノウハウを先鋭化して、魅力的なサービスを自ら提供することで競合優位を確保する戦略です。 

例えば、ERPの業務ノウハウを駆使し、AmazonのIaaSであるEC2上にERP SaaSを構築、これを自社のサービスとして提供するアプローチです。 

IT基盤は従量課金で手に入りますので初期投資リスクを抑えることがてきます。業務ノウハウが十分にあれば、そこで差別化することができるはずです。また、グローバルに標準化された基盤であれば、これまでの国内をお客様とするだけではなく、広く世界にお客様を拡大することが可能となるでしょう。飽和した国内市場に頼るだけではなく、グローバル・ビジネスを展開する術を手に入れることもできるわけです。

コモディティ化の流れを避けることはできはません。たとえ今はコモディティではなくても、それが「無くてはならない存在」となれば、いずれはコモディティ化します。

コモディティは、必要があるからこそ存在します。つまり、市場は確実にそこに存在するのです。問題は、その中で自らの立ち位置を明確にすることです。

コモディティ同士をぶつけ合い、価格競争を強いられる状況から脱却するには、コモディティをどのようにすれば武器にできるかを考えなくてはなりません。ここに掲げた３つの戦略は、そんなシナリオを考える切り口とならないでしょうか？

*デージュール・スタンダードとは？

■　Facebookページに、皆さんのご意見やご感想を頂ける場所を用意いたしました。よろしければ、お立ち寄りください。

クラウドの都市伝説に思考停止している残念な人々

「クラウドでビジネスを再発明する」

米Amazon Web Service（AWS）が、先日ラスベガスで開催したカンファレンス「AWS re:Invent」のタイトルには、このような思いが込められているそうです。クラウドは、まさにビジネスの新たな道筋を生みだしつつあります。

クラウドの当たり前が、わずか一、二年の間に大きく変わっています。それにもかかわらず、この変化に目を向けることなく、旧態依然としたビジネス・スタイルを踏襲している企業は少なくありません。

それは、決して、売る側だけではなく、ユーザー企業もまた、これまでのやり方の延長線上で物事を解釈しようとしていることにおいては、何も変わりはないように思います。

• クラウドは信頼性が低いから
• セキュリティが保証されないから
• 運用管理が不透明で安心できないから

クラウドについて、こんな都市伝説が、未だまことしやかに語られています。そんな話を聞くと、勉強不足、新しいリスクを背負い込むことへの忌避、そして、これまで蓄積してきたスキルが使えなくなることへの不安であり、言い訳と聞こえてしまうのは、私の耳が遠くなったせいなのでしょうか。

以前にも紹介したクラウド・サービスのベンチマーク・サイト「Cloud Harmony / Availability Report for Last 90 Days」を見ると、主要なクラウド・サービスの多くが、uptime(最後にコンピューターが起動してからの経過時間) 100%を維持しています。

このベンチマーク・リストの上位には、我が国のクラウド・サービスも多数含まれています。また、大手SIerである新日鉄住金ソリューションズのクラウド・サービスであるabsonneのように、「99.999%保証する」としているサービスもあり、「クラウドの信頼性は低い」とは、もはや言い切れないでしょう。

また、Googleには、セキュリティ担当の専任技術者が300人いるそうです。それに比べて、我が国のユーザー企業の情報システム部門にセキュリティ専任のエンジニアは何人いるでしょうか。他の業務との兼任であり、専門的なことは、外部に任せているところも多いのではないでしょうか。

米国連邦政府のクラウド・ファースト・ポリシーやAWSが「金融機関等コンピュータシステムの安全対策基準」を満たしているとのレポートなどは、その裏付けとなるものです。

運用管理については、そもそも常識が違うことを念頭に置いて考えなくてはなりません。従来のように、専任の運用エンジニアを配置し、個々のアプリケーション毎に運用設計し、個別に運用管理するという常識は、クラウドにはありません。

あらかじめ用意された運用メニューから、運用パターンを選び、条件設定する。つまり、リソースとセットでパッケージングされた運用を調達するという考え方です。

運用はそれ自体パッケージングされた部品であり、機能の作り込みと品質保証がなされています。これを組み合わせて、運用を自ら組み立てるという発想が求められます。これは、運用管理をエンジニアの個人的なノウハウ、つまり暗黙知に頼るのではなく、高度に工業化された部品を組み合わせて利用することに相当します。従って、用意された運用内容や、サービス毎の運用思想を正しく理解しなければ、使いこなせません。その一方で、だれもが品質保証され、標準化された運用管理サービスを利用できることにもなるのです。

確かに、上記の要件を満たさないサービスもあることは確かです。だからこそ、それを見極める情報収集力と目利き力が必要になるのです。

「クラウド・サービスはエンタープライズ・プラットフォームとしての要件を満たしつつある」ことは、もはや常識です。

この現実に目を背けることなく、その得意不得意を見極め、最大限に活用することこそ、TCOの削減やITの戦略的活用を促すことになるのです。

ところで、SI事業者は、この現実をどのように受け止め、対処してゆけばいいのでしょうか。その戦略は、大手と中堅中小とは、異なると考えています。

大手は、自ら戦略的な取捨選択を行い、ミッション・クリティカルなSI案件と絡めつつ、その受け皿となるクラウド・サービスを提供する戦略で手堅く地歩を固めるか、Amazonに対抗する徹底したコモディティ戦略を推進するか、そのいずれかの選択ではないでしょうか。中途半端なSaaSや曖昧なポジショニングは、自らの存在感を放棄することに他なりません。

中堅中小は、コモディティ化されたクラウド・サービスを最大限に利用し、これまで大手しかできなかった大規模インフラを前提とした開発や、本番実行環境のITO(IT Outsourcing)を受託するストック・ビジネスへのシナリオが描けるように思います。

これまで積み上げてきた現場や業務のノウハウを特定の領域に特化しSaaSビジネスを展開することも可能です。従来のように自ら資産を持つ必要はなく、拡大も撤退も容易です。そのためには、改めて自分たちの強みを再定義し、その価値をどのようにサービス化するかを考えることが必要です。そして、ユーザー企業にダイレクトにアプローチすることを考えるべきでしょう。これまで同様に、大手SIerの配下で受託、派遣に甘んじ、自らのリスクを回避しづける限り、この先はないと思います。

時代が大きくシフトしていることに、私達は真摯に目を向けなくてはなりません。例えそれが、既存の収益基盤を脅かすものであっても、それが時代の流れであれば、対応しなければなりません。ただ、現実に目を向ければ、「ああ、大変だ。どうしよう・・・」で思考停止に陥っている人たちが実に多いことを残念に思います。

■　Facebookページに、皆さんのご意見やご感想を頂ける場所を用意いたしました。よろしければ、お立ち寄りください。

人材が育たない・心の有り様を忘れた人材育成

「これまでは営業力なんて気にしなくても仕事はそれなりに回っていました。しかし、もうそんな時代ではありません。なんとか優秀な営業を早く育てたいんです。」

こんな相談を受けることがあります。しかし、数日の研修でそれができるわけもなく、二つ返事でお引きするというわけにはゆきません。

営業に限ったことではありませんが、優秀な人材を育てるには、まずはその環境を作ることからはじめなくてはならないと、私は考えています。

具体的には、「優秀な人材の採用」、「チャレンジさせる勇気」、「意欲のマネージメント」の３つが、人材育成を支える根底になくてはならないと思っています。

「優秀な人材の採用」が人材育成の起点であるかとは、論を待たないでしょう。残念ながら、「優秀じゃない人材」は、なかなか育たないのです。ならば、「育てれば育つ人間」をはじめから採用することが、人材育成の基本ということになります。

人材育成の視点から見た「優秀な人材」とは、「学習することを楽しいと感じることができる人材」と定義することがだきます。

スタンフォード大学の心理学者であるキャロル・S・ドゥエックは、人間には、「固定的知能観」か「拡張的知能観」かの、いずれかの心の有り様があり、それによって、その人の能力は決まってしまうというと主張しています。

固定的知能感(fixed-mindset)の持ち主とは、自分の能力は固定的で、もう変わらないと信じている人です。彼等は、自分の能力はこの程度だから、努力しても無駄だとみなします。また、自分が他人からどう評価されるかが気になり、新しいことを学ぶことから逃げてしまう心の有り様の持ち主です。彼等が学ぶのは、それが自分にとって利益になる場合です。つまり、これを知らなければ仕事がこなせない、収入が減るなどの場合です。

一方、拡張的知能感 (Growth-mindset)の持ち主とは、自分の能力は拡張可能であると信じている人です。彼等は、人間の能力は努力次第で伸ばすことができると信じ、たとえ難しい課題であっても、学ぶことに挑戦する心の有り様の持ち主です。彼等は、好奇心旺盛に自らテーマを作り、学ぶこと自体を楽しむことができます。

　このような、「自分の能力や知能についての心の有り様」＝「知能観（Mindset）」が、学習についての意欲を左右し、能力の獲得や育成に大きな影響を与えるという考え方です。

「これまで経験したことのない仕事だけど、チャレンジしてみませんか？」という問いかけに、「私には無理だと思います」、「自分はそういうことはあまり得意じゃないんで・・・」という答えが返ってきたとしたら、これは固定的知能感に支配されているか、あるいはそちらに偏っていると考えることができます。

また、「なんでこんな研修を受けなきゃならないんだ、役に立たないよ」、「どうせやっても無駄ですから」などと考えてしまう心の有り様こそ、固定的知能感と言えます。

ベテランの方のなかには、「もう自分はこれでいいんだ・・・」、あるいは、「自分のやり方を今更変えようとは思わない」など、豪語する方もいらっしゃいますが、これなども固定的知能感に支配されていると言えるでしょう。

時間をかけて専門的な知識や能力を身につけても、新しいことに興味を持てなくなったとき、その人の成長は止まったと考えることができます。つまり、固定的知能感を持つようなったとき、それ以上の成長は期待できない・・・残念なことではありますが・・・。

採用の段階で、このような質問を投げかけ、同じような答えが返ってくるとすれば、これは採用に慎重にならざるを得ません。その人を成長させることには、相当な労力をかけることになるでしょう。あるいは、徒労に終わるかもしれません。だからこそ、「優秀な人材の採用」が人材育成をすすめる上での起点となるのです。

「もう採用してしまった人材を今更入れ替えるにはゆきませんよ・・・」そういう反論も返ってきそうですが、確かにその通りです。

そこで、次に取るべき態度が、「チャレンジ」させることであり、それを奨励し、失敗を受け入れる環境を作ることだと思います。

失敗を恐れるあまり、決まり切ったことしかやらせないとすれば、当然、本人は、最低限の能力獲得にしか意欲を持たないでしよう。「これで十分」と考えることこそ、固定的知能感そのものです。

本質的には、拡張的知能感の持ち主であっても、仕事の現場では、固定的知能感の持ち主として振る舞う。そんなこともあるかもしれません。

「チャレンジさせる勇気」、そして、それを奨励し、失敗に対しても真摯に向き合い、解決策を共に考えてゆく。そんな、組織のメンタリティがあれば、新しいことを学ぼうとする意欲が育まれます。そして、成功体験を通じて、そこに成長の喜びが生まれます。そんなサイクルを回すことが、「意欲のマネージメント」です。

「この技能が不足しているから、こういうことを学ばせよう。そのためにはどのような研修プログラムを組み立てればいいだろうか？」

人材育成を考えるとき、このような議論がよく行われます。それはそれとして、大切なことではあるのですが、これだけでは不十分です。

むしろ、「学習に対する心の有り様」をどのように育んでゆくのかを考えるべきでしょう。それがあって、はじめてツールである研修は、効果を発揮します。

「啐琢同時」ということばがあります。これは、雛が卵から生まれようとするとき、雛は殻の内側から卵の殻をつついて外に出ようとします。これを「啐」といいます。そのとき、親鳥もまた同時に外側から卵の殻を破るためにつつきはじめます。これを「琢」といいます。この親鳥と雛が、同時に殻をつつき合うことで、雛は生まれることができるという禅のたとえ話です。

研修だけではなく、心の有り様を育てる。人材の育成とは、まさに「啐琢同時」でなくてはなりません。

■　Facebookページに、皆さんのご意見やご感想を頂ける場所を用意いたしました。よろしければ、お立ち寄りください。

内製化支援というパンドラの箱

「そういうソリューション・ベンダーさんとは、ぜひ戦略的パートナーとして、積極的に組みたいですね」

先日、社員一万名ほどを擁するある大手企業の情報システム部門長との会話で、こんな言葉か飛び出しました。

今、多くの情報システム部門は、内製化を模索しています。これまでのように、開発を外部に丸投げするのではなく、自分たちでシステム開発を手がけようという動きです。

それは必ずしもコスト抑制のためばかりではありません。自らの存在意義をかけた取り組みです。

グローバル化の進展、ビジネス・ライフサイクルの短期化、顧客嗜好の多様化といったビジネス環境の変化は、スピードや俊敏性を経営に求めています。ITは、その手段として、これまで以上に戦略的価値が高まっています。

こんな時代の要請に、情報システム部門が応えられないとしたら、それは経営的に見れば、存在意義のない組織と言われても仕方が無いのです。

情報システム部門が、この変化に対応するためには、クラウド化と開発の内製化は、必須の要件となりつつあります。

既存のIT基盤の統合集約とクラウド化は、プライベート、パブリックの使い分けはあるにしても、これまでのような、ひとつひとつ見積もりを取って、外部に依頼する手間を省きます。そして、リソース調達や変更の自由度と生産性を大幅に向上させることができますし、スピードと俊敏性は、格段に向上します。また、需要の変動に応じてリソースの大きさをダイナミックにスケールできることも、大きな魅力となります。

開発も同様に、これまでのような個別に見積もりを取り、仕様を決めて外部に任せるウォーターフォール型の外注方式では、対応できません。自らの手で、アジャイルに、超高速に開発してゆく手段を持たなくてはならないのです。

しかし、情報システム部門にとって、これは容易なことではありません。そもそも、これまでは、このような仕事の多くを、外部に依存してきたわけですから、スキルを持った人材が内部にはいないのです。

そこで、この状況を裏返して考えて見れば、ITソリューション・ベンダーは、これらができる人材やスキルを抱えているわけです。ならば、そのスキルを使って、お客様のクラウド化や内製化の支援を積極的に行えば、それはまさに、お客様のニーズに合致することになるはずです。

これは、自分で自分の首を絞めるような話かもしれません。しかし、お客様のニーズがそこにある以上、それに応えるべきでしょうし、ビジネスのチャンスがあるはずです。

確かに内製化が進めば、全体としての外部への開発需要は減ることになります。そのために、これまで開発に従事していたベンダーは切られることになるでしょう。しかし、だからといって、全てを内製化できるわけではありません。むしろ、内製と外注の役割の分化が最適化され、全体としての生産性を高めてゆくことになるはずです。

そのときに、切られる側に立つか、残る側に立つかです。内製化支援は、情報システム部門が、まさにそんな意志決定を行う上で、大きな判断基準になるのではないでしょうか。

我が国では、IT産業は、もはや成長産業ではなく、成熟産業といえるでしょう。かつてのように、全てが生き残れる時代ではなくなりました。競合が常態化し、淘汰される時代へと変わりつつあります。

「そういうソリューション・ベンダーさんとは、ぜひ戦略的パートナーとして、積極的に組みたいですね」

この発言は、「内製化支援に積極的に取り組んでくれるソリューション・ベンダーがいたら、どうでしょうか?」という、私の質問への答えでした。

お客様が何を求めているかに目を背けていては、ビジネスのチャンスはありません。例え、それが、これまでの収益基盤を脅かすことであったとしても、対処しなければならないのです。そして、この需要の変化をどのようにビジネスにしてゆけばいいかを考え抜き、自らを変革する決断を下さなくてはなりません。

開発～保守～運用のサイクルを自ら回してきたこれまでの収益モデルから、お客様自身にこのサイクルを回していだくために、何をすべきか、何ができるかを考える。わたしは、これからのビジネス・チャンスは、こんなところに潜んでいるように思っています。

■　Facebookページに、皆さんのご意見やご感想を頂ける場所を用意いたしました。よろしければ、お立ち寄りください。

SIビジネスは、今後どうなるんでしょうね？

「SIビジネスは、今後どうなるんでしょうね？」

最近、よくこんなことを聞かれます。残念ながら、こうだと言い切れる答えはありません。ただ、「SIビジネス=受託+請負+派遣」という頭しかなければ、未来はないと断言する事だけはできます。

SI(System Integration)という言葉の歴史的意味をご存知でしょうか。私たちは、今改めて、この言葉の原点に立ち返り、自らの役割を見直すべきではないかと思うのです。この本来の意味にこそ、これからのSIビジネスの「あるべき姿」があるように思うからです。

1978年のVAX11/780の登場は、ミニコンやオフコンの登場を促す事になります。また、1981年のIBM PCの出現は、PCのビジネス利用のきっかけを作りました。

それまでコンピュータと言えば、高価なメインフレームしかありませんでした。そこに、安価に導入できるミニコンやオフコン、PCが登場し、ダウンサイジングの流れが始まったのです。その結果、ひとつの企業で、様々なメーカーのコンピュータを使うマルチベンダーの時代を迎えたのです。

その一方で、コンピュータ本体の価格低下は、台数の増加とメーカーの異なるコンピュータの混在を加速する事になりました。その結果、相互の接続や互換性の確保、バージョンアップやトラブルへの対応など、運用管理に伴う負担が増大する事になりました。

それ以前は、IBMなど特定メーカーのメインフレームによる集中システムであり、その組み合わせはすべてメーカーに任せる事ができました。しかし、膨大な数の分散システムを自らの責任で組み合わせ、運用管理することになったユーザー企業は自ら大きな負担を背負い込む事になったのです。

当時、未だ一社完結主義を貫いていたＩＢＭは、この時代の流れに出遅れました。その結果、初めての減収減益を経験したのです。

そんな時代の1993年、当時RJRナビスコのＣＥＯであったルイス・ガースナー氏が、初めて外部からIBMのCEOとして招聘されたのです。

かれは、この現状を見て、これまでのIBMの基本理念であった一社完結主義を捨て「メーカーや機種を問わず、その組み合わせに責任を持つ」ことを宣言したのです。そして、これをソリューションと称したのです。つまり、IBMの製品だけではなく、他社の製品を含めてシステムの構築やサポートを行うビジネスに参入することにしたのです。

そして、このソリューションを提供するサービスをシステム・インテグレーションと呼ぶことにしました。

それ以前から、ソリューションやシステム・インテグレーションという言葉は、使われていましたが、そこに明確な定義はなく、各社各様にキャッチフレーズとして使っていたにすぎません。そこに新たな定義を与えたのです。

この辺りの事情については、「ソリューションの本質　その歴史的背景」に詳しく書かせていただきましたので、よろしければ合わせてご覧ください。

「システム・インテグレーション」の出自を改めて考えてみると、今の時代に必要なものが見えてくるような気がします。

• お客様の必要としていることに真摯に目を向けこれに対応しようとしている
• お客様のニーズに応えることを優先し、最適な組み合わせを自社製品・サービスにこだわらず提供しようとしている
• お客様の経営や業務に関わるシステムの企画や設計など、上流行程に関わることからビジネスのチャンスをつかもうとしている

クラウドの時代になり、また、サービスの時代になってもこの基本はかわりません。ここに立ち返ってこそ、自らの果たすべき役割が見えてくるのではないでしょうか。

さて、改めて、この視点で、今のお客様のニーズを見れば、次のようなキーワードが浮かび上がってきます。

• ITプラットフォームの統合と集約
• ITプラットフォーム資源と運用のアウトソーシング
• ITガバナンスの強化
• 内製化の拡大
• 情報システムの戦略策定能力の強化

仮想化やクラウドの普及、セキュリティへの関心の高まり、文化や言葉の違う海外との緊密な連携、SaaSやカスタマイズしないパッケージの利用などの環境の変化が、このようなキーワードを浮かび上がらせています。

もはやこれまでのような「受託+請負+派遣」のスキームにビジネスが収まる時代ではありません。新たなお客様のニーズを先取りし、積極的にチャンスを広げてゆかなくてはなりません。

今あるスキルセットを大きくかえなくてはならないでしょう。あるいは、自分で自分の首を絞める事もあるでしょう。

「イノベーションは創造的破壊をもたらす」とは、経済学者シュンペーターの言葉です。ＩＴは、その繰り返しによって市場を広げてきました。これもまた、歴史の教える教訓です。

この流れから逃れられないのであれば、自らその流れに飛び込むしかないのです。ただ、それができる余裕は、そう長くは続かないように思います。

■　NeoCoreサミット2012にて講演させていただきます。

「注目のNoSQLデータベース：XML DBとは？」

ビッグデータの時代を迎え、何でもRDBの時代からNoSQL DBを適材適所で使い分ける時代へと変わりつつあります。本講演では、このNoSQLとは何かを概観し、その中でXML DBとはどのような位置付けにあるかを説明いたします。また、その可能性についても解説します。

■　Facebookページに、皆さんのご意見やご感想を頂ける場所を用意いたしました。よろしければ、お立ち寄りください。

クラウドはだれのためにあるのか

「クラウドは、ITエンジニアの72%がユーザー企業に所属するアメリカで生まれた、ITの“デリバリーモデル”」

日経コンピューターの中田敦氏が、日米のITビジネス環境の違いを紹介しながら、クラウドの価値や可能性について紹介されています。ちなみに日本のITエンジニアの75%はITベンダー側にいるそうです。

この事実を踏まえ、中田氏は次のように解説しています。

クラウドは、リソースの調達や構成の変更など、ITエンジニアの生産性を高め、コスト削減に寄与するものです。とすると、ITエンジニアを多く抱える米国では、クラウドはユーザー企業の生産性を高めることになります。

ところが我が国では、そのような仕事はシステムの構築や運用を受託しているSIerなどのITベンダー側に任され、そこにITエンジニアがいるわけですから、彼等の生産性向上に寄与することになります。

一方、これはITベンダーにとっては、案件単価や単金の減少を意味します。また、調達や構成の変更はリスクを伴う仕事です。米国では、そのリスクをユーザーが引き受けることで、自らの生産性の向上を享受できるわけですが、我が国ではITベンダーが背負わされることとなります。

そう考えるとITベンダーにとってクラウドは、案件単価や単金が下がりリスクも大きくなることを意味し、利益相反の関係となります。

この話を私なりの解釈も交えながらまとめたのが以下のチャートです。

中田氏の考察を踏まえ、我が国のクラウド・ビジネスの課題を整理してみました。

クラウドにおけるソースの調達や構成の変更は、「セルフ・サービス・ポータル」と言われる画面を使って行われます。必要なシステムの構成や条件を入力することで、仮想リソースを直ちに手に入れることができます。

従来、このような作業は、業務要件を洗い出し、キャバシティ・プランを行い、システム要件を決め、それにあわせたシステム構成と選定を行い発注します。そして、物理マシンの調達、キッティング、据え付け、導入作業、テストを行っていました。

このような作業が、物理的作業を必要とせずWeb画面から簡単に行うことができるわけですから、生産性は大いに向上します。

しかし、我が国のユーザー企業は、このような作業の多くをITベンダーに依存してきました。従って、今更自分でやれと言われても、仕事が増え、リスクも背負わなくてはならないわけですから、モチベーションは上がりません。

ITベンダーも受注単価が下がり、人もいらなくなるわけですから積極的にはなれません。このような双方の利害の一致が、我が国のクラウド普及の足かせとなっていると見るのは、少々うがったものの見方でしょうか。

また、これは以前のプログでも紹介しましたが、我が国にはITスペシャリストとしてのCIOが少なく、リスクを取っても情報システムを戦略的に利用してゆこうという企業が少ないという現実があります。これもまた、クラウド普及の足かせになっているともいえるでしょう。

人件費についての日米の意識の違いについても考えなくてはなりません。米国における人件費は変動費です。クラウドによる生産性の向上は、情報システムに関わる人材を削減することになり、コスト削減に貢献します。一方、我が国の人件費は固定費です。従って、生産性が向上しても埋没コストの削減にしかならず、直接的な人件費の削減にはつながりません。これもまた、クラウド普及の障害となります。

米国のユーザー企業において、ITスペシャリストであるCIOは、多くのITエンジニアを抱えています。また、パッケージ・ソフトウェアもカスタマイズすることなく利用することが当然と考えています。このようなビジネス環境においては、クラウドの利用は、大きなメリットをユーザー企業にもたらすことになります。

残念ながら、我が国において、米国と同じシナリオでクラウドの価値を訴求することは困難といえるでしょう。

では、我が国では、クラウドは価値がないのでしょうか。いいえ、決してそんなことはないと思っています。米国とは価値の置かれている重心が異なっていると私は考えています。

我が国は、今、グローバル化の急速な進展、ビジネス・ライフサイクルの短命化、顧客志向の多様化と言った、大きな産業構造の変革にさらされています。

このような事態に対処するためには、ITを戦略的に活用することが有効な手段となり得るはずです。そのためには、経営環境の変化に合わせ、迅速に(=スピード)、俊敏・柔軟に(=アジャイル)、そして、必要に応じてリソースを容易に拡大でき、不要となればすぐに手放すことができる(=スケール)システムが必要とされるでしょう。まさに、クラウドの価値は、ここにあるのではないでしょうか。

「クラウドは生産性向上の手段でありコスト削減につながる」という「効率・コストへの期待」は、残念ながら、我が国においては簡単に受け入れられません。むしろ、経営環境の急激な変化に対応できる「戦略価値への期待」を訴求し、そのためのソリューションを提案してゆくべきです。

ITのトレンドは、米国発祥のものが圧倒的であり、その流れを止めることはできません。だからといって、私達は、その奔流に唯々翻弄されるだけでいいのでしょうか。むしろ、我が国のIT活用を大きく進化させてゆくチャンスとして、この流れを利用してゆくべきです。

ITベンダーはもっと真剣にこの視点を掘り下げ、事業戦略に活かしてゆくべきです。それが、淘汰の時代に生き残るために必要なことではないでしょうか。

*** 「中田敦」氏のお名前を当初「田中敦」氏と記載しておりました。ご指摘を頂き訂正いたしました。中田様にはお詫び申し上げますと共に、訂正させていだきました。

■　日経コンピューター主催　「ソリューションビジネス力養成講座」を開催します。
もう時間がないのですが、未だ席には余裕があるそうです。こちらで講義させていただきます。よろしければ、お申し込みください。

■　NeoCoreサミット2012にて講演させていただきます。

「注目のNoSQLデータベース：XML DBとは？」

ビッグデータの時代を迎え、何でもRDBの時代からNoSQL DBを適材適所で使い分ける時代へと変わりつつあります。本講演では、このNoSQLとは何かを概観し、その中でXML DBとはどのような位置付けにあるかを説明いたします。また、その可能性についても解説します。

■　Facebookページに、皆さんのご意見やご感想を頂ける場所を用意いたしました。よろしければ、お立ち寄りください。

「あいつは頭が悪い」と言う前に・・・

「あいつ、頭が悪いんですよ。こっちがちゃんと話しているのに、全然分かっちゃいない。困ったもんです。」

困っているのは、相手の方ではないでしょうか？伝わらないのは、相手のせいではありません。こちらの伝え方が悪いだけのことです。

「言った」、「言わない」の議論になることがあります。「あのとき言ったよね」、「そんな話聞いちゃいないよ」。たぶんどちらも本人にとっては真実なのでしょう。

　お互いが100%わかり合えることは不可能です。コミュニケーションとは、これを前提に考えなくてはなりません。

コミュニケーションは、「聞く」、「尋ねる」、「伝える」の3つの要素の組み合わせです。

「聞く」とは、相手の伝えようとしていることに傾注し、その言葉によって、何を伝えようとしているのか、自分にどのような行動や気持ちの変化を起こさせようとしているのか、その意図や目的を知ろうとする行為です。けっして、相手の発する単語を記憶する行為ではありません。

そして、相手の意図や目的について、自分なりに解釈し、それを自分の言葉に置き換えてみることです。そして、その解釈が正しいかどうかを相手に「尋ねる」ことで、正しいのか、間違っているのか、修正すべき点はどこにあるのかを確認します。その繰り返しによって、相手の伝えようとする目的や意図に近づくことができます。

しかし、どれだけ相手の意図や目的に近づくことができても、100%ではありません。そのギャップを思い切って飛び越えなくてはなりません。それが、「共感」です。

「共感」とは、相手の「痛い」経験を自分の中に再現し、自分も「痛い」と感じることです。相手の悲しみを自分の中で再現し、涙を流すことです。「共感」とは、言葉だけでは伝わらない相手の意図や目的を想像力で乗り越える行為と言えるかもしれません。

「尋ねる」るとは、自分の解釈を相手に確認する行為です。つまり、自分の仮説を示し、相手の回答によって検証する行為です。

「きっとこういうことだろう」、「こういうことに興味があるはずだ」、「こういうことに困っているに違いない」など、自分なりの仮説を組み立て、「私はこのように考えて見たのですが、それで正しいのでしょうか」と尋ねる行為です。

「何かありませんか」、「何でもいいから教えてください」、「何か言ってください」では、尋ねたことにはなりません。

「伝える」とは、相手に情報を伝達する行為です。ここでいう情報とは、感情、意思、思考、知識などです。そして、このような情報を伝達することで、相手の共感を引き出し、さらには相手が行動を起こすように相手の意識を制御することまで考えなくてはなりません。

そのためには、相手の興味や趣味、関心事、立場や状況などを知り、相手が理解し、行動しやすい条件はなにか、相手にとって理解しやすい単語や表現とは何かを想像しなくてはなりません。

そして、自ら描いたシナリオで、相手に言葉を放ってみる。そして、その反応を受けてシナリオを修正し、また再び言葉を伝える。そんな行為の繰り返しによって、情報を伝え、共感や行動を引き出す行為が、「伝える」ことなのです。

自分の「聞く」、「尋ねる」、「伝える」の３つの行為に、相手も対応する。この相互の行為が、コミュニケーション活動です。

コミュニケーションとは、そんなお互いの行為の結果であり、一方の行為だけでは成り立ちません。

しかし、現実には、お互いがこのようなコミュニケーションの構造を理解し、適切に行動することなど、なかなかありません。

だからこそ、私達は「聞く」、「尋ねる」、「伝える」の３つの行為を意識し、相手をこの行為に巻き込むことが大切なのです。

こちらの伝えたいことだけを伝え、満足をしてしまっては、それは伝わったことにはなりません。相手の共感や行動の変化を確認し、はじめて伝わったと言えるのです。

「伝えた」という自分の満足ではなく、「伝わった」という相手の真実が大切である。

以前ブログで書いた言葉です。コミュニケーションの本質は、ここにあります。

改めて自分を振り返れば、時に自分の言葉に酔いしれ、話したことに満足し、相手の共感や行動の変化に関心も払っていないことがよくあります。改めて、コミュニケーションとは何かに思いをはせ、自戒を促したいとここに書かせて頂きました。

■　Facebookページに、皆さんのご意見やご感想を頂ける場所を用意いたしました。よろしければ、お立ち寄りください。