2010年10月31日日曜日

売る側から考えたクラウドの定義

 現在、広く受け入れられているクラウド・コンピューティングについての理解は、米国NIST(国立標準技術研究所:National Institute of Standards and Technology)の定義に準じるものが多いようです。しかし、売る側の立場としては、どうもしっくりこないというのが、正直なところです。

 たとえば、NISTの定義にSaaS,PaaS,IaaSのサービス・モデルとプライベートとパブリックを区分する配置モデルがあります。しかし、厳密に考えれば、このサービス・モデルは、パブリック・クラウドのサービス・モデルであり、プライベート・クラウドには、当てはまりません。ちょっと、中途半端な気がします。 

 売る側のスキルや体制の視点から見ると、SaaSは、業務ノウハウを基盤としたビジネス・モデルです。もちろんプラットフォームなくして、サービスの提供はできませんが、現実の問題を考えると、この両方の能力を兼ね備えているIT事業者は、決して多くはありません。ですから、アプリケーションは自分で運営し、プラットフォームは他者に任せると言った仕組作りも可能なはずです。両者は、分離して考えることができます。 

 一方、プラットフォームに目を向けると、不特定多数を対象としたミドルウェアやインフラ環境を構築し、自ら運用するPaaS,IaaSの場合と企業内にシステムを構築し、特定のお客様のためにシステムを構築、運用する場合とでは、必要となる投資やリスク、体制やスキルは、大きく異なります。 

 サービス・モデルと配置モデル。このふたつが、別々の解釈軸で区分されているのは、売る側のスキルや体制、ビジネス・モデルを考える上では、どうも不便な感じがしています。 

 もうひとつ考えるべきは、我が国と米国とのビジネス環境の違いです。

 我が国では、ユーザー企業は、社内ニーズのとりまとめ役であり、システム構築や運用などのインテグレーションは、SI事業者に依存するケースが少なからずあります。しかし、米国では、このインテグレーションの役割、つまり、PM、調達、開発、運用などをユーザー企業が持つ場合が一般的で、不足のリソースを必要なときに外部から調達するという考え方が、一般的なようです。 

 従って、システムに関わるコストや効率は、完全にユーザー視点です。また、きめ細かくエンドユーザーの要望に応える自主開発も、日本ほどには積極的ではありません。コストや効率の観点から、パッケージ・ソフトウェアを導入し、パッケージ・ソフトウェアに業務をあわせることについても、割り切っているようです。  

 NISTの定義を改めて、この視点から眺めてみると、SaaSは、パッケージ・ソフトウェアの置き換えです。また、PaaSは、データベースなどのミドルウェアに関わるスキルを持つ人材調達の代わりであり、IaaSは、ハードウェア・リソースの低コストでの調達手段と見ることができます。米国の事情を考えると、実にわかりやすい利用者視点の区分であり、合理的な解釈と言えるでしょう。 

 SI事業者に大きく依存している我が国のユーザー企業には、この発想は生まれにくいかもしれません。また、SI事業者にとっては、このような考えは、自らの利益と相反する危険思想かもしれません。従って、このような合理的な考え方を採用することには、どうしても消極的になってしまうのかもしれません。 

 また、プライベート・クラウドの昨今の動向を米国のビジネス環境からみると、あることが分かります。それは、プライベート・クラウド構築の負担軽減です。 

 前述の通り、米国では、システム・インテグレーションの実行責任は、ユーザー企業側にあります。従って、プライベート・クラウドを構築するためには、自ら必要なハードウェアやミドルウェアを選定し、その組み合わせを自らの責任において、保証しなくてはなりません。これは、スキル的にも、人材的にもなかなか大変なことです。コストと効率に敏感な企業にとっては、これは大きな負担となっています。 

 このようなユーザーの課題を解決しようという動きが、「Cloud in a box」です。この言葉、オラクルのCEOであるラリー・エリソンが、Exalogic Elastic Cloudの発表の時に使った言葉ですが、シスコのvblock、マイクロソフトのAzure Appliance、IBMのz Enterprise 196など、基本的には同じ動きだと言えるでしょう。 

 言い換えれば、企業内にオープン・システムをプラットフォームとしたメインフレーム=汎用機を簡単に導入、構築するビジネスととらえることができます。 

 しかし、我が国の場合、これは、ベンダーやSI事業に任せるか、大きく依存している部分でもあり、ユーザー企業が、その必要性をそれほど強くは認識していないのではないかと思うのです。 

 このように、我が国と米国のビジネス環境の違いを考えると、NISTの定義をそのまま前提にして、ビジネス・モデルを考えるのはいかがなものかと思うのです。 

 そこで、ちょっと大胆な挑戦ではありますが、我が国の実情を前提に、売る側の視点でクラウドの定義を考えてみました。いかがでしょう。 

 ■ アプリケーション・サービス・クラウド

 ■ プラットフォーム・サービス・クラウド

 ■ エンタープライズ・サービス・クラウド

 

 ■ アプリケーション・サービス・クラウド

 特定の業務に特化したアプリケーションを、インターネットやWANを介して、サービスとして提供するビジネス・モデル。プラットフォームは必要ではあるが、必ずしも自ら運営する必要はない。

 ■ プラットフォーム・サービス・クラウド

 開発や運用に関わるリソースを、仮想化や運用の自動化の技術を前提に、インターネットやWANを介して、サービスとして提供するビジネス・モデル。  

 ■ エンタープライズ・サービス・クラウド

 企業内で利用するシステムを集約し仮想化や運用の自動化の技術を前提に、効率的なシステム利用環境を構築、運営するサービスを提供するビジネス・モデル。 

 まだ、荒削りではありますが、議論のたたき台になればと願っています。 

 この話題については、11月11日(木)に開催されるクラウドコンピューティングEXPOでも、ITソリューション・ベンダーの事業戦略と関連づけて、詳しく話をさせていただこうと思っています。

2010年10月24日日曜日

過剰品質という本物

 長年愛用したファーバーカステルのボールペンを先日なくしてしまいました。もう、10年近くは使っているものでした。使い込んだ濃い焦げ茶色の木製の軸は、いい具合に膏がなじみ照りがでて、新品とはまた趣の違うものとなっていました。持った感じは、ずっしりと重いのですが、それがなかなか手になじんでいて、なめらかな書き味は、極みでした。

 そんなボールペンを、いつもゆく多摩湖の四阿のテーブルに置き忘れてしまったようです。気がついて戻ってはみたのですが、友人にもらったBMWのロゴマークが入ったロディアのメモパッド・ホルダーとともになくなっていました。
 
 自分の粗忽にただただあきれるばかりです。あのときにいろいろと考え、メモしたアイデアも一緒に消えてしまいました。どうぞ、私のボールペンを手に入れた方は、是非大切に命をつないでやってください。
 
 私は、それほどものに愛着がある方ではありません。しかし、あのボールペンのなめらかなペン芯の繰り出し、クリップのしっとりとした弾力、うまく配分された重量のバランスは、作り手の思い入れと丁寧な職人技と愛情を感じさせます。「本当によくやってくれました。ありがとう。」そんな感謝の気持ちさえ感じます。
 
 営業として現役だったころ、三洋電機をお客様として担当していたことがあります。そこで、空調機を作っていたのですが、その製造コスト削減策として、組み立て作業時間をどうすれば、削減できるだろうかという検討を行ったそうです。その中に、配線の取り回しをもっと簡単にすればいいのではという意見があったそうです。
 
 わたしも見せていただいたことがあるのですが、その配線の取り回しはみごとと言うしかありません。実に整然と機器内の構造物と一体化していました。職人技とでも言うべきですが、乱れのない、そして、撚りのない配線は、美しささえも感じるものでした。
 
 しかし、このような美しい配線は、ベテランでも手間のかかる作業だそうです。もっと簡素に作業を行えば、作業時間を短縮できます。配線ですから、機能に違いがあるわけではありません。過剰品質ではないか・・・ということで、そんな検討がされたそうです。
 
 しかし、結局、その作業に手をつけることはなかったそうです。詳しい事情はわかりませんが、それはもう理屈を越えた常識であり、そうでないこと自体を受け入れられない、理屈を越えた空気のようなものがあったのではないかと思っています。

 工場の方が、「そんな日常の当たり前が、私たちのモノ作りの基本にあるんですよ。品質は、そんな現場の当たり前の結果であり、必ずしも厳しく管理されてできるものではないんですよ」とおっしゃっていました。なるほどと感銘を受けたことを記憶しています。
 
 少々手前味噌ではありますが、私もまた、自分の資料作りに、私なりのこだわりがあります。その最大のポイントは、「一瞬のわかりやすさ」です。
 
 細々と理屈を積み重ねて説明しなければ、わかってもらえない内容を、どうすれば、一枚のチャートだけで、瞬時にわかってもらえるようにできるか。パワーポイント上に配置されるボックスの形や色、左右上下の位置関係、それぞれの内容に応じた色分け、空間の均整と間の取り方・・・そんなことを考えながらの資料づくりは、必ずしも生産性の高いものとは言えません。
 
 一度書き上げても、もう一度見直すと、何かしっくりこない・・・改めて、全体のバランスを考えながら、配置や形、色を調整します。
 
 「そんなことに時間を割くなんて馬鹿なことはやめるべきだ。もっと中身を考えることに時間を割くべきだ」と、人に言われることもあります。しかし、中身とは、表現と表裏一体な存在です。表現をわかりやすくしようとすると、中身というか、本質というか、それは何だろうかと考えなくてはなりません。
 
 どうすればわかりやすく、こちらの意図を伝えられるかを追求してゆくと、伝えたい内容の要素を徹底的に因数分解し、ロジカルシンキングで構造を組み立ててゆくことになります。
 
 一見複雑で、漠然としていることを、相手にわかりやすく伝えようとすると、その内容の本質を考え、それをバラバラにして、自分なりにわかりやすいように並べてみる。そして、これをどう並び替えれば、相手は理解できるだろうかと考えます。
  
 何色を使い、画面のどこに配置すれば、思考に無駄な雑音を発生させることなく、すっと相手に伝わるだろうかを考えるわけです。資料の順序も大切です。自分は分かっているからこの順序で大丈夫・・・ではなく、分かっていない人の思考プロセスを想像し、その順序を考えてゆく。そうすると、なるほど!と思える展開が見えてきたりもします。
 
 私は、表現を追求することは、中身を徹底的に理解しようとする取り組みだと思うのです。
 
 あのファーバーカステルのボールペンも、三洋電機のエアコンも、そのものが持つ本質を追究してゆくと、もはやこうせざるを得ないというカタチになってしまったのだと思います。それが一番いいコトかどうかはともかくとして、そうでなければ自分が、納得できないんです。それは、結果として、見た目にも美しいものに仕上がってしまうのです。
 
 効率は悪いかもしれません。自己満足かもしれません、過剰品質かもしれません。しかし、その追求をやめることは、もはや気持ちが悪いのです。
 
 さあ、今日もこれから、二つのプレゼンテーション資料を作らなければなりません。「さあみていろよ。なるほど!と、相手をうならせる資料を作ってやるぞ」と燃えています。しかし、その一方とで、「どれだけ時間がかかるだろうか?今日中に間に合うだろうか?」と不安がよぎります。
 
 仕方がありません。気持ち悪さを残したままのプレゼンテーションは、迫力もなく、後味の悪いものになることは、目に見えていますから。

2010年10月17日日曜日

売れないことのいいわけ:「営業力不足」

 「営業は、新規のお客様を見つけてくればいいんですよ。その後は、私たちデリバリー部門が引き受けますから。うちの問題は、その営業が、お客様を引っ張ってこれないことにあるんですよ。営業力不足。そこに問題があるんです。」

 ある中堅SI事業者のデリバリー部隊を統括する役員のコメントです。私は、彼にこんな質問をしました。
 
 私 :「ところで、既存のお客様の深掘りは、だれの責任なんでしょうか?」
 
 役員:「それは、私たちの責任です。マネージャーやリーダーが、その責任を担っています。」
 
 私 :「なるほど・・・ところで、それはうまくいっていますか?」
 
 役員:「・・・。実は、こちらも必ずしもうまくいっていません。以前は、そんなことはなかったんですが・・・。」
 
 営業が新規顧客開拓に責任を持つ、そして、事業部が、既存顧客の深掘りに責任を持つ。この役割分担は、多くのSI事業者で、昔から採用されています。どうも、この仕組が、最近うまく機能していないように感じています。
 
 お客様の業績が伸び、それに軌を一にしてSI事業者の仕事も増えていった時代。デリバリー部門のマネージャーやリーダーは、デリバリーを確実に仕上げることで、お客様の信頼を得る。するとお客様は、社内の事情も、気心も知れた同じ会社(=人)に任せた方が楽です。頼むべき仕事もたくさんあります。それではと云うことで、リピートする。SI事業者は、そうやって仕事を継続し、拡大することができました。
 
 この時代の案件獲得の手段は、「デリバリー業務において、QCDを確実に達成すること」だったわけです。つまり、デリバリー部門のマネージャーやリーダーの本来の業務と一致しているわけで、余計な仕事(=営業活動?)は、しなくても、自分の仕事をきちんとこなすことで、既存顧客からの案件獲得/拡大は、可能な時代でした。
 
 しかし、今はどうでしょうか?お客様の業績が伸び悩み、ITもそこそこ行き渡りました。そんな中で、SI事業者にお願いする仕事が、かつてのようには増えません。また、景気動向に神経質になっている企業は、内部留保を拡大する経営施策をとり、新規開発案件を押さえています。また、コスト削減は、リーマンショック以来、我が国企業の基本に位置する意志決定基準となり、経営の意志として、競合によるコスト競争を当然と考えるようになりました。情報システム部門の現場にしてみれば、これは面倒な話です。「よろしく!」-「はいわかりました!」以上・・・ですまなくなったのです。
 
 また、お客様は、恒常的に低コストで運用できるシステムを模索しています。これには、「これしかない」という答えが用意されていないです。お客様もどうすればいいのか、答えを探しているのです。
 
 このような現実を考えてみると、既存顧客から案件を継続的に増加させるためには、目の前にあるデリバリーを成功させるだけは、不十分なのです。競合に勝つための方法を考え、提案しなくてはなりません。しかし、単金だけに着目しても、クラウドやオフショアという新たな競合の出現に対抗しなければなりません。
 
 もはや、「デリバリー業務において、QCDを確実に達成すること」だけでは、リピート案件の獲得/拡大は、容易なことではなくなったのです。
 
 「営業が新規顧客開拓に責任を持つ、そして、事業部が、既存顧客の深掘りに責任を持つ。」は、お客様の業績も右肩上がりで、それにうまく対応することで、業績を上げることができた時代は、効果的な体制だったように思います。
 
 しかし、時代は変わりました。今となっては、この方法は、必ずしもうまく機能しないように思います。
 
 このブログでもたびたび取り上げていることですが、営業職と技術職、あるいは、営業部門と技術部門の役割を、この時代の変化に即した仕組に変えることを考えてみてはどうでしょうか?
 
 「営業力強化は、営業職の能力強化」という、単純思考を捨てるべきです。会社の文化や風土、組織の役割分担まで踏み込んで、営業という仕事をとらえ直す時期にきているのではないでしょうか。技術者も技術力やプロジェクト管理能力を高めることだけではなく、広い意味での営業力を身につけさせるべきではないでしょうか。
 
 確かに、今までのやり方のほうが、経験的にわかっていることですから居心地がいいのはよくわかります。しかし、過去の栄光は、遠い昔の輝きであり、そのときの「常識」は、もはや「非常識」となっているということ。そういう時代になったということを謙虚に受け止めるべきでしょう。
 
■ iSUC新潟大会で話をさせていただきます。
 
 以上のような変化の中で、私たちは、どうすればいいのでしょうか。そんなこれからの営業のあるべき姿を考えようと、私たちは、「ソリューション営業モデル研究会」を立ち上げました。
 
 この研究会は、いまだ定まらない「ソリューション・ビジネス」の正体をまずは、きちんと定義しようとしています。そして、お客様に認められ、感謝されるソリューション営業活動とは、どのようなものなのかを体系化して、モデル化しようという取り組みを始めました。また、営業現場の実践に使える「ソリューション営業実践マニュアル」も作ろうと思っています。
 
 既に30社を超える大小のソリューション・ベンダーの皆さんが、ボランティアとして、名前を連ねています。

 「営業の仕事とは、お客様の価値を最大化することを、最大のコストパフォーマンスで実現すること」と、私たちは考えています。

 そんな営業の仕事の「あるべき姿」とそれを実践するための具体的な方法を「個人の能力」、「組織の成熟度」、「営業活動のプロセス」という切り口から体系的に整理しようと考えています。
 
 ご興味があれば、どうぞお問い合わせください。また、10月20日(水)(15:15-16:15)に新潟で開催されるiSUC(IBMユーザーの研修会)にて紹介させていただきます。よろしければ、おいでください。

2010年10月9日土曜日

「危機感」という幻想:期待しても何も変わりません

 「いくら、営業の育成をしても、中堅管理職がこのままでは、営業力強化といっても、無理ですよ。」

 あるSI事業者の役員が、ため息混じりに話してくれた。

 がんばっても、なかなか受注を伸ばせない。だから、営業力を何とか強化しなくてはという思いは、この会社だけではない。営業研修にも熱心だ。しかし、数字に現れてくれない。そんな、焦燥感を募らせている。

 経営者からみれば、彼ら中堅管理者の努力不足を問題と考える。一方、管理者は、経営の無策が原因だと考えている。デリバリーに責任を持つエンジニア部門は、営業が新規顧客や案件をとってこないのが悪いという。営業は、既存のお客様の深掘りに不熱心なプロマネやリーダーたちに原因があるという。
 
 なぜ、こんなことになってしまうのだろうか。
 
 「危機感が足りない。意識改革が必要だ!」というが、本当にそうだろうか?私は必ずしもそうは思わない。危機感が強まれば、意識が変われば、状況は改善されるのだろうか。そんな簡単なものではないだろう。
 
 少なくとも、この会社では、「このままでは、だめだ・・・何とかしなくては!」という思いは、みんなが持っている。
 
 では、どうすればいいのだろう。
 
 私は、「危機感を持つ」ということを否定するつもりはない。しかし、その持ち方が問題だと思う。感情的に、感覚的に危機感というものをとらえても、それだけでは、解決の方策が見いだせない。大切なことは、この危機の本質や業績に及ぼす影響を丁寧に分析し、論理的、数値的に危機の事実を明らかにすることだろうと思う。
 
 前回のブログで紹介のとおり、SI事業は、大きなパラダイム変化の波にさらされている。この変化の行き着く先は、単金の低下、競合の拡大、低コスト・システムへの転換である。
 
 かつては、お客様の景気がよければ、仕事は、お客様の業績の伸びとともに、ついてきた。その頃の営業の役割は、お客様との人間関係の維持と迅速で適正な価格での人や物の調達である。デリバリー部門は、そんな営業のオーダーに応え、QCDを確実にこなし、その実績を武器に次の仕事をとってくることで、仕事を継続的に得ることができた。
 
 製造業の仕事にたとえるなら、デリバりー部門は、工場である。営業は、さしずめ生産管理部長といったところだろうか。
 
 しかし、継続的成長が期待できない今、お客様は、かつてのような「体力強化型」のシステムを求めていない。低コストでも確実にこなせる「体質強化型」のシステムを今まで以上に模索している。クラウドやオフショアは、そんなお客様の期待をかさ上げしているともいえる。
 
 このような「体質強化型」への対応は、単純にモノやヒトといったリソースの調達だけで対応できるものではない。お客様も、何がほしいのかがわからない。営業も最適な答えを持ち合わせていない。言い換えれば、何を売ればいいのかが、わからないのだ。
 
 いや、そんなことはないという人もいるだろう。ERPがある、仮想化がある、低コスト・サーバーもある。しかし、競合が当たり前の時代だ。それぞれに機能や特徴の違いはあるだろうが、お客様からみれば、一長一短。製品とて、同じモノを売っていることもある。そうなると、価格勝負、体力勝負しかない。
 
 お客様が求めているのは、「体質強化のための設計図」だ。お客様と一緒になって、お客様の必要とされているモノの図面を描き、その最適な組み合わせを創造しなければならない。お客様は、営業にその役割を期待している。
 製造業にたとえれば、従来の生産管理部長ではなく、研究開発部門のプロデューサー役を営業に期待している。
 
 このような役割を担う営業に、アメとムチ、叱咤激励、「こんなところで何やってるんだ!机に向かっている時間があったら、さっさとお客様のところに行く!それが営業ってもんだ!」という精神訓話は、役には立たない。「そう言われても、どうすればいいのですか?」の答えが見いだせないビジネスに、このようなやり方は、害にこそあれ、モチベーションを高めることにはつながらない。
 
 お客様と一緒になって、これからの設計図を描く。これを営業だけにやらせることは難しい。マネージャーも、エンジニアも、一緒になって知恵を出し、その役割を営業と分担し、チームとして作り上げてゆく。エンジニアにプログラミングやプロマネの能力も必要だが、お客様の業務を分析し、体系化し、テクノロジーと結びつけてゆく。そんな、広範な知識と能力が求められている。ここは、まだまだ、オフショアやクラウドのサービスに勝ち目がある領域だ。
 
 営業という仕事が、営業職の仕事である限り、このような、取り組みはできないはずだ。もはや、営業の概念が、大きく変わってしまったということを受け入れることだ。かつての常識が非常識となってしまった事実を受け入れることが、起点である。
 
 危機感とは、「従来」と「現在」とが、どう変わったかを対比することである。そして、あるべき姿の「現在」と今そこにある「現在」のギャップを冷静に捉え、受け入れることである。
 
 感覚の問題ではなく、論理の問題ととらえること。それを共有すること。危機感とは、そうやって意志づけられるのだろうと思う。
 
 感覚的言葉だけで、危機感をあおってみても、混乱を招くだけである。また、それぞれの都合のいい解釈により、自分たちの組織や仕事の変化を最小限に食い止めようとする。それが、先ほどのような混乱を招く原因となっている。
 
 危機感を論理的、合理的にとらえれば、あるべき姿は何か、何を目指すべきかは、共有しやすくなるだろう。また、手段をどうするかについての利害の対立は、なくなることはないにしても、あるべき姿を実現するためには、どうすればいいかを合理的に判断できるだろう。気に入るか、気に入らないかの感情論は、その地位を下げることになる。
 
 精神論、宗教論として、危機感を醸成するだけでは、危機の本質を見誤ることになりかねない。また、営業力も、従来当たり前とされていた営業職の力としての営業力ではなくなってしまったことを真摯に受け止めること。会社、組織としての新たな営業力を定義しなおし、その上で、営業やエンジニアを含め、役割や能力をどうするか、考えてゆくべきなのだろう。
 
 かつての営業としての成功体験を持つ人たちが、いま営業の中堅管理者となっている人は多い。そういう人にはおしかりを受けるかもしれないが、あえて申し上げたい。
 
 「世の中、変わったんです。滅私奉公、お客様は神様といった気持ちで成し遂げたあなたの成功体験。そこで身につけた方法論は、今の若者たちにとって、役にも立たないんです。同じことをやらせると失敗します。むしろ害です。
 “滅私奉公、お客様は神様です”は、今の若者たちには、カッコワルイの象徴です。そのことを受け入れましょう。
 過去の栄光は、お客様のお役に立てた喜びがいかにすばらしいものかを伝えるたとえ話としては役に立ちます。それまでです。“何でできないんだ!こうすればいいんだよ”というような方法論まで指図しない。やり方は任せ、それをサポートする。それが、今マネージメントに求められていることなのです。」

2010年10月2日土曜日

「こうすれば受注できる」という常識が、もはや通用しない時代

 「クラウドへの取り組みや新しいパッケージの販売など、いろいろと手を打ってはいるのですが、どうしても数字に結びつきません。営業力の強化が急務です。営業の育成を何とかお願いできないでしょうか。」
 
 あるSI事業者の社長から、そんな相談を頂きました。しかし、ことは、そんなに簡単なことではないように思うのです。
 
 以前、このブログでもご紹介した「第二の変化」について、いろいろなところでお話をさせていただきましたが、まさにそうだというコメントを多くの方から頂きました。今日は、このテーマと営業力について、もう少し深く掘り下げてみようと思います。
 
 今、我が国のSI事業者は、「今までの常識」を崩壊させるほどの、ふたつの大きな波にさらされています。特に、中堅、中小のSI事業者にとっては、経営をも揺るがす力を持っているほどです。

 まず、第一の波は、「ニューノーマル」の波です。日本のSI産業は、上流工程を握る一部大手SI事業者と1万社ほどの中小SI事業者による下請け構造によって成り立っています。
 
 リーマンショックにより、お客様の新規開発の意欲が大きく減退しました。その結果、従来からの元請-下請けの産業構造は維持されたままに、元請、下請けともに、業務量が大幅に減ってしまったのです。そして、中小規模のSI事業者は、元請、および、お客様のコスト削減要求に応えるという名目で、単金を大きく引き下げてでも受注しようというサバイバル合戦が始まったのです。

 また、お客さまも、今までのように「従来からの付き合い」だけで、特定の事業者に業務を委託することは、もはや許されない状況となりました。経営の方針として、大幅なコスト削減が求められる情報システム部門にとって、乾いたぞうきんを縛ることを求められました。また、経営の意思として競合/相見積もりは必須となったところも少なくありません。その結果、見かけ上の案件や引き合いは増えても、成約になかなか結び付かないといった事態を招いてしまいました。

 この競合に勝ち残れないSI事業者は、大手SI事業者に買収されるか、倒産を余儀なくされてしまったのです。大手SI事業者による中小SI事業者の買収は、グループ内製を推し進めることとなり、独立系SI事業者に仕事が回りにくいといった新たな構造も作り上げてしまったのです。

 加えて、とりわけ大きな課題は、お客様が、「この金額でもなんとかできるではないか」と思い始めていることです。つまり、中小SI事業者は、仕事の確保を優先するために、お客さまからの値引き要求に応えざるを得なかったわけですが、業務内容の実態は、大きく変わるものではなかったのです。そのため、「安い単金でも同じ仕事ができるではないか」という新たな常識(ニューノーマル)をお客様の意識に植え付けてしまったのです。これが、第一の波です。

 この第一の波は、新規開発が中止または白紙となるなかで、まずは開発業務に顕著な影響を与えました。そして、すぐには業務内容を変えることができない運用や保守などのストック・ビジネスにも、順次影響を与え始めました。

 今、リーマンショックが、ひとつの区切りを迎える中、景気指標が改善し、大手金融機関など、一部業種においては、新規開発需要が盛り返しつつあります。また、大手銀行などでは、このリーマンショックをきっかけとして、より低コストかつ、変化への柔軟性を模索した体質強化のためのシステム再構築プロジェクトも立ち上がりつつあります。しかし、その恩恵が、なかなか、中堅、中小のSI事業者に波及してこないというのが現状でする。
 
 その理由は、大手SI事業者によるグループ内製の優先、ニューノーマル意識の定着による受注金額の頭打ち、そして、第三の選択肢であるクラウドやオフショアとの競合です。これが、第二の波です。

 つまり、エンドユーザーのITシステム需要は回復しても、それが、リーマンショック以前のように、中堅、中小のSI事業者の需要に、直接つながらないのです。
 
 リーマンショック以前の産業構造、すなわち、大手が元請/中小が下請けで成り立っていたSI産業構造は、もはや崩れ始めているのです。これは、派遣型、あるいは、業務委託型を主要な事業の柱としているSI事業者にとっては、大きな影響を与えることになります。
 
 また、お客様は、システム規模を大きくするための投資に積極的ではありません。いかに低コストで、かつ柔軟に運用できるかに関心が高いわけで、中長期的に見れば、IT投資抑制に向けた取り組みを始めようという訳です。

 お客様の仕事が好調なときは、お客さまもシステム事業者に何を求めるべきかが、明らかでした。例えば、サーバー、開発要員の工数やスキル、運用・保守作業など、拡大する業務に対応するための「体力強化」のためのリソースを求めていたのです。

 しかし、第二の変化がもたらしたものは、これとは質的に異なるものです。いかに低コストで、効率よく、柔軟に世の中の変化に対応できるかという「体質強化」のためのシステムです。需要の拡大も、単にリソースを増やすという単純志向での解決策は、許されないのです。
 
 従来からの「こうすれば受注できる」という営業活動の常識が、もはや成り立たたなくなったのです。

 つまり、景気回復に伴う需要の増大に対処する手段は、従来のようにオンプレミス型のリソース、例えば、サーバーや国内の開発、運用の要員を増やすことだけではなく、「クラウドという仕組み」や「国境を越えた事業者」という選択肢をも前提に考えなくてはならなくなったのです。その結果、選択肢は多様化し、複雑さを増しています。
 
 どの組み合わせが、自分たちにとって、最もふさわしい手段の組み合わせ=ソリューションなのか、それ自体に絶対の正解を見出しにくい状況となり始めているのです。

 言い換えれば、お客さまもSI事業者もともに、何が最適解なのかがわからず、両者が一緒になって、その最適解を考え、創造してゆくといった取り組みが、求められる時代を迎えたのです。

 私たちは、この新たな常識を真摯に受け止める必要があります。

 この事態に立ち向かうためには、営業という仕事についての従来から常識も見直す必要があります。
 
 いままでの営業は、お客様とのコミュニケーション能力や信頼関係を構築、維持することが強く求められてきました。また、お客様のリソース調達の要求に適正なコストで迅速に答えることが求められてきたのです。それをできることが優秀であり、業績にも貢献していたのです。
 
 しかし、第二の変化は、この営業の常識を変えようとしています。クラウド、オフショアを含む多様な選択肢の中から、お客様の課題解決に最適な組み合わせを創造する。そのプロデューサーとしての役割といえるでしょう。
  
 決して、お客様との信頼関係や人間関係は不要という訳ではありません。ただ、それだけに頼っていると、仕事は手に入らない。そんな状況が生まれてきているのです。
 
 ますます競合が厳しくなる中で、競合他社を超える魅力的な組み合わせ=ソリューションを創造する。それは、営業一個人の力量では、限界があります。
 
 営業は、会社の力、組織の力、あるいは、社外のサービスや商材をお客様の課題解決のために結集する。その全体図を描き、戦略を立て、リソースの組み合わせを設計する。今求められる営業には、そんなクリエーターとしての能力が求められているのです。
 
 そのためには、営業力を営業職の能力とらえるのではなく、会社や組織の仕組みととらえ、エンジニアもサポートスタップが、ともに営業活動を理解し、その役割を担う必要があるのです。
 
 第二の波は、確実にSIの産業構造を変えてゆくことになるでしょう。それに対処するために「営業職を増やし、その能力を育成する」というだけでは、対処しきれません。営業力を営業職の力ではなく、会社の力ととらえなおし、その力を高めてゆく、そんな根本的な構造改革が、求められる時代が、到来しているのです。

 ■ ソリューション営業プロフェッショナル養成講座 が開講します

 営業職の仕事ではありません。エンジニアもまた、営業という仕事にかかわっています。そんな皆さんのために、営業という仕事をエンジニアリングします。詳しくはこちらをご覧ください。