2011年3月27日日曜日

これ一枚で分かる SI事業者の課題と戦略


 「SI事業者の危機」が、叫ばれるようになって久しいのですが、それでもしっかりと業績を上げ続けている企業は、少なくありません。しかし、そういう企業でさえ、昨今は、収益率の頭打ちに悩まされています。それをリーマン・ショックに求める声も聞かれます。
 
 確かに、リーマン・ショックは、切っ掛けでした。ある意味、予期せぬ突発的な事故でした。しかし、その傷は、そろそろ癒え始めているようで、景気や経営の指標を見る限り、マクロには、回復の兆しが見え始めています。
 ただ、これをそのままIT業界に当てはめることは、妥当ではありません。事実、「仕事量は増えたが、収益が上がらない」という声を耳にすることが、多くなりました。つまり、IT業界にとっては、過去の延長線上にある回復ではないということです。
 
 今回の原子力発電所の事故でもそうですが、その事故が、深刻であればあるほど、人々の意識の深層に大きな影響を与えます。今まで当たり前と考えていたこと、あるいは、あまり真剣に考えていなかったことに、スポットライトがあたり、それを鮮明に意識するようになる。つまり、常識が変わり、意志決定の基準が大きく変わることを意味しています。
 
 ITにおいて、リーマン・ショックが、もっともスポットライトを当てたのは、IT部門の高コスト体質だったのではないかと思っています。
 ITコストの7~8割を占めるといわれている既存システムに関わる保守や運用などのコスト。何とかしなければと意識され、叫ばれ続けてきたことですが、改めてこの問題にスポットライトが、当てられたことは、間違えないと思います。
 
 会社の業績が、右肩に上がっている時は、この問題に対処するよりも、業績の上昇に伴う機能の拡張や能力の増強など、「体力の強化」に力点が置かれました。しかし、リーマン・ショックを切っ掛けとして、低コストで開発、運用するための「体質の改善」に重点が、移ったといえるでしょう。この変化は、視点を変えれば、「IT業界は、成長市場から成熟市場へと転換を図ろうとしている」と見ることができます。
 
 最近注目を浴びるクラウド・コンピューティングやITILへの対応、オフショアへの開発シフト、企業統合に伴うシステム統合プロジェクト、IFRSを切っ掛けとした基幹業務システムの再構築なども、このような「体質の改善」への取り組みと捉えることができそうです。
 
 このようなITビジネス環境におけるSI事業者の課題と、このパラダイムの変化にどう対処すべきかを、一枚のチャートにまとめてみました。いかがでしょうか?
 
 どう対処すべきかの戦略については、「競合優位戦略」と「顧客拡大戦略」のふたつの視点で整理してみました。
 
 市場が成熟化へ向かう転換期では、必ず「プレーヤー過剰」状態となります。従って、この状況に対処する方法は、これまでの常識を破壊するイノベーションを行い競合他社に圧倒的な競合優位を確立することか、顧客ベースを拡大し収益源を拡大することが必要になります。
 
 両者を同時に達成することができれば、それは理想的です。ただ、これは容易なことではありません。現実的には、どちらかに軸足を置くことが必要になるでしょう。
 ただ、どちらにしても、経営者が、従来の常識にとらわれない戦略を示すことです。そして、大胆に人材を登用し、組織や体制の変革を図ることだろうと思います。
 
 変化の兆しを感じ取り、ビジョンを提示すべきは、経営者の役割です。しかし、その方法論は、若い人にまかせてみてはどうでしょうか。時代は、それほどに大きく動き始めているようです。

■Facebookでお待ちしています!

 このブログのFacebookページを開設しています。ぜひ、Facebookページ「ソリューション営業プロフェッショナル」にアクセスいただき、「いいね!」をクリックし、ご参加ください。

 ブログでは、なかなかむつかしい、責任ある突っ込んだ議論ができればと願っています。ぜひ、そんな試みにご理解、ご協力いただければと願っております。

2011年3月20日日曜日

ITトレンドの変化に抵抗する残念なマネージメントのみなさんへ

 このたびの震災は、お客様のITに関わる意志決定に、今後、様々な影響を与えることになるでしょう。
 
 先日、「デスクトップの仮想化」の事業推進をされている大手ITソリューション・ベンダーの方と話しをさせていただきました。いままでは、必要性を認めるもののコストが高くつくので逡巡されていたお客様も、コストを度外視してでも対応したいという意向を持たれるようになったそうです。
 
 また、前回のブログでも紹介しましたが、BCP(business continuity plan/事業継続計画 )への関心が高まる中、その視点からクラウドの採用を検討しようという動きも出てくるでしょう。
 
 さらに、この震災により、経済環境は大きく変化しています。例えば、急激な円高は、国内の生産や物流の拠点を海外に移す動きを加速するでしょう。また、ITリソースのグローバルな視点で再配置についても議論が活発になるでしょう。その結果、データセンターや開発拠点、あるいは、データのアーカイブのためののリソースを海外に求める動きも始まるものと考えられます。また、被害を受けた多くの企業は、投資の優先順位を変えることになるでしょう。
 
 震災だけではなく、IFRSへの対応、スマートフォンなどのクライアントの高機能化と多様化、HTML5などのweb標準の切り替えなど、かつてないほどに、変化を求めるドライブが、今、強くかかり始めているように思います。
 
 その一方で、多くの中堅中小のSI事業者が、この変化のトレンドに対応し切れていない、いや、対応をためらっているようにも見受けられます。
 
 ご存じの通り、ITサービス産業は、もはや成長市場ではなく、成熟市場へと移行しています。成熟市場の特徴は、市場規模の上限が限定されていることです。その一方で、プレーヤーも多く、受給コントロールの主導権は、お客様サイドにあります。
 
 結果として、従来型のスキルを前提とする受託開発業務では、単金は抑制され利益率の拡大は、期待できません。加えて、オフショアやクラウドの圧力が、この単金の上昇を抑える重石となっています。このような市場で案件を増やし、収益を拡大してゆくためには、もはやコモディティと化した人材力だけでは、競合優位を確保することはできません。
 
 「競合優位戦略」というと、「世の中にない新しいものを市場に提供すること」と、考えてしまいがちですが、決してそれだけではありません。むしろ、お客様が確実に求めているものであり、かつ、供給が不足している領域に、他社に先んじて参入することも、ひとつの戦略であり現実的なアプローチです。
 
 多くの大手ソリューション・ベンダーは、このようなITの最新動向を踏まえた事業戦略を積極的に展開しています。このような大手企業の下請けとして業務を行なっている多くの中堅中小のSI事業者にとって、このトレンドに追従できないということは、コモディティ化した技術スキルでしかサービスを提供できないということであり、結果として、単金競争に陥り、安い単金でしか受託できない状況となることは、避けられません。
 
 これまで、中堅中小のITベンダーの多くは、お客様との仕事を通してOJTとしてスキルを修得してきました。しかし、いまは多くの技術革新が、今まで自分たちが取り組んでいた業務の範囲外から、突然にやってきます。クラウドやOSSの普及、HTML5やモバイル対応への要請、サブスクリプションや従量課金などの収益形態変更への期待・・・これらを従来通り、OJTで学ぶことには、もはや限界があります。
 
 これまでの受託開発業で蓄積した「従来型スキルX誠実に働く人材」というストック(資産)をなんとか売りさばきたい。それが、多くのSI事業者の本音ではないでしょうか。そして、それを売るのが営業という従来型の常識にとらわれている企業は、これからの厳しい単金引き下げ競争と淘汰の嵐に立ち向かう覚悟をする必要があります。
 
 もし、このような状況を避け、今後とも収益を拡大してゆくためには、これからのお客様のニーズを先取りし、トレンドの変化がもたらす新たな需要に、積極的に対応してゆくべきではないかと思っています。
 
 このような話しをすると「うちにはそんな人材はいない」という嘆きが聞こえてきそうです。しかし、本当にそうでしょうか。このような嘆きの言葉を語られる方は、ベテラン、年配のマネージメントに多いようです。しかし、現場の若手は、お客様の現場でこの変化をひしひしと感じ取っています。また、新しい物好きの感性に秀でた人材は、どこにでも何人かは、いるものです。
 
 マネージメント諸氏に期待したいのは、そんなかれらを引き上げる度量です。もはやかつての自分の成功体験は、通用しないという自覚を持つことです。彼らを信じ、新しいIT技術戦略を策定するプロジェクトを立ち上げるというのはどうでしょうか。
 
 自分の基準に照らし合わせ、彼らを評価したところで、もはや世の中の基準が急激に変化している訳ですから、役に立たない、あるいは、あやまった判断をもたらすことになります。また、理解できない、自分の基準に合わないことを理由に、自分の考えややり方を押しつけることは、彼らの行動を萎縮させ、変化への対応の足を引っ張ることになります。
 
 マネージメントの役割は、彼らが誠実に、真剣に取り組める環境を提供することです。これは、マネージメントにしかできません。また、詳細はともかくとして、技術のトレンドつまり、世の中の常識を理解できる程度の勉強もしておくべきです。自分の無知を隠さんがために、その立場を利用して、今までの経験的常識を押しつけ、部下を押さえ込もうとすることだけは、是非やめていただきたいものです。
 
 変化の流れは、必ずしもカタストロフィカル(周期的な秩序だった現象の中から不意に発生する無秩序な現象)なものではありません。むしろ、ITの歴史を振り返るならば、これはひとつの必然と見ることができます。例えば、昨今話題のMVCモデル、データセンター集中型の運用(=クラウド・コンピューティング)、仮想化などは、1960年代のメインフレームの黎明期にも起こっているものです。
 
 昨今のテクノロジーの進化は、このような従来の考え方を一見違う形で表象しているだけのことです。
 
 つまり、ITトレンドをこの原点に立ち返って、捉え直してみる。そして、その本質を考えるならば、なにも目新しいものではありません。本質と表象を区別し、本質を見ることができれば、道を誤ることはありません。時代の表象である方法論としての技術トレンドは、若い人材にゆだねるべきなのです。
 
 これからの変化に求められるマネージメントの力量とは、そんなことかもしれません。
 
 少々、マネージメントのみなさんには、厳しことを申し上げました。しかし、だからこそ、こういう事態の変化に、時に無軌道になりがちな若手の人材を、うまく制御し、活かしてゆくことが、マネージャーのみなさんには、求められているのです。
 
 今回の震災を切っ掛けに、ITトレンドのベクトルは影響を受けることになるはずです。その変化の方向を読み取り、先んじて対応する。競合優位を確立するために、そんな取り組みが、必要なのではないかと考えています。

■Facebookでお待ちしています!

 このブログのFacebookページを開設しています。ぜひ、Facebookページ「ソリューション営業プロフェッショナル」にアクセスいただき、「いいな!」をクリックし、ご参加ください。

 ブログの限界、そして、新しいコミュニケーション手段による限界の超越。いま、そんな可能性を探っています。是非、ご協力ください。

2011年3月16日水曜日

災害対策としてのクラウド:3つの可能性

 このたびの震災は、BC/DR(ビジネス・コンティニュイティとディザスタ・リカバリ [災害対策・災害復旧])の大切さを改めて教えてくれたように思います。今回は、このBC/DR対策におけるクラウド利用の可能性について考えてみることにしました。
 
 本来、BC/DRの目的は、災害時における業務の停止時間を極小化することにあります。そのために、データセンター設備そのものの災害対策に加え、設置されているハードーウェアや電源設備の冗長化により、システム停止を回避する対策がとられています。
 加えて、データセンターそのものの機能不全を前提に、別の地域に代替のセンターを構え、同等の機能を提供できる設備を用意する措置がとられます。そして、運用管理システムが、両者の切り替えを支援することになます。ただ、オープン・システムの場合は、それを完全に自動化することは、かなり困難なようです。
 
 これに対して、メインフレームでは、装置そのものだけではなく、部品レベルでの冗長化に加えて、ハード、OS、ミドルウェアの連携により、ハードウェアの計画外停止にとどまらず、アプリケーション・レベルの計画停止まで含めた「業務レベルの可用性」を実現する機能を実装しています。
 
 また、拠点内だけではなく、地域をまたがリ、ひとつのシステム・イメージを構築するクラスタリングの機能も、OSの基本的な機能として提供されており、ノンストップ運用環境が実現しています。
 IBMのメインフレームでは、並列シススプレックといわれる機能がこれに相当します。その機能の中で、地域をまたがった運用の切り替えを行なうのが、「広域分散並列シスプレックス(Geographically Dispersed Parallel Sysplex, GDPS)」といわれるもので、システムの拠点間切り替えを自動的に行ないます。

1.代替リソースとしてのクラウド
 
 さて、このようなBC/DR対策は、普段の業務で必要となるシステム・リソースの代替リソースを提供することです。まずは、その観点から、クラウドの可能性を考えてみましょう。
 
 既存の業務システムとの互換性を考えれば、自社のシステム構成に合わせることが容易なIaaSは使いやすいサービス形態です。Amazonのサービスのように従量課金であれば、システムの構成イメージをIaaS上に持っているだけであれば、費用は発生しません。ですから、BC/DR対策としてのコストは大幅に削減できる可能性があります。
 
 また、Amazonは、VMwareイメージ(KMDK)をAmazon EC2クラウドへ持ち込めるVM Importを昨年の12月に発表しています。社内システムをVmwareで仮想化しておけば、障害時にシステムの移行をスムーズにできる可能性があります。現段階では、コマンドラインで操作する必要があるようで、ライブマイグレーションによるリアルタイムな切り替えには対応していないようです。今後のサービス内容の充実に期待したいところですが、BC/DRの手段としては、有効な選択肢になるかと思われます。

 もうひとつ注目したいのが、Window Azure Platformです。Window Azure Platformは、企業内システムとして、ひろく普及しているWindows Serverとの高い互換性を売りにしたPaaSに位置づけられるサービスです。.Net FramworkとVisual Studioをそのまま使えることから、オンプレミスとクラウドをひとつのシームレスなプラットフォームとして、開発・運用・実行環境を提供するというものです。つまり、オンプレミスとクラウドをひとつの連続したシステム・リソースと考え、その運用を当初より設計するという考え方が生まれてきます。
 
 このような考え方は、オープン系のシステムでは、以前では、考えられなかったことです。ひとつの可能性として、検討に値するかもしれません。
 
2.非基幹業務のクラウド
 
 クラウドによるもうひとつのBC/DR対策の可能性として、コミュニケーション/コラボレーションの手段を当初よりクラウドのサービス(SaaS)として利用するという考え方です。
 
 電子メールやグループウェアは、企業個別の独自性は、それほどありません。従って、これをSaaSとして、日常の業務で使うことに、大きな支障はないもものと考えられます。実際に、クラウドに二の足を踏む金融系大手企業でも、このあたりであれば、問題ないとして、導入に踏み切る企業も増えてきました。
 
 個人的な体験ですが、今回の地震発生当日、電話がほとんど通じなくなりましたが、電子メールに加え、TwitterやFacebook、Skypeは、なんの支障もなく使えました。仕事相手や米国にいる家族と問題なくskypeで会話できたことに、驚き、感謝しています。また、TwitterやFacebookも、掲示板として、伝言メモとして、効果をあげています。スマート・フォンの普及と共に、使い勝手も進化しています。
 
 ビジネス・コミュニケーションにおけるBC/DR対策として、オンプレミスに依存する場合の対策負担を考えれば、簡単かつ低コストでの対応が可能と考えられます。
 
 もともとインターネットは、軍事用のネットワークとして開発されたもので、特定の通信ノードが破壊されても、自律的に迂回経路を見つけて、通信経路を確保する仕掛けです。また、クラウドのデータセンターについては、高度の災害対策が施されています。このような仕組をコミュニケーションのライフラインとして、普段より業務の仕組として組み込んでおくという考え方は、有効な対策です。
 確かに、セキュリティ上の懸念を指摘する声もあります。しかし、これについては、昨今、いろいろな手立てが考えられているようで、以前のような不安は解消されつつあるのではないでしょうか。

3.災害時の追加リソースとしてのクラウド

 もうひとつは、今回の震災で、IIJやIBMが発表した震災地域の自治体や企業へのクラウド・サービスの無償提供です。これは、単なる社会貢献という意味を越えて、災害対策のひとつの方法論として、注目すべきかもしれません。つまり、既存リソースの代替手段ではなく、災害対策の時にのみ必要となるリソースの調達手段としてのクラウドの可能性です。
 
 米国商務省の配下にある米国国立標準技術研究所(NIST: National Institute of Standards and Technology)の「クラウドの定義」は有名ですが、彼らが定めるクラウドの条件として、「オンデマンド・セルフサービス」、「広範なネットワーク/デバイスの利用」、「システム資源のプール」、「迅速な順応性」、「従量課金」があげられています。
 この条件を充足しているクラウド・サービスは、我国には、必ずしも多くありません。しかし、もし、この条件にかなうサービスであれば、BC/DR対策の手段として、十分現実的な選択肢になるはずです。
 
■ BC/DR対策としてクラウドを検討する際の課題
 
 ただ、課題も少なくないことを理解しておく必要があります。特に気になる課題のひとつと考えられるのが、コンプライアンスと法律・規制の問題です。データセンターが海外にある場合は、この点を考慮する必要があります。
 
 もうひとつ、海外の場合、遅延時間(レイテンシー)が大きな課題となるでしょう。
 
 データセンターが海外に設置されている場合、日本との間は海を隔てた遠距離になることから、パケットのやりとりに数百ミリ秒の遅延が発生します。TCP/IPのプロトコルの制約上、必ずシェークハンドという送受信の前に自分と相手の間で、送っていいかどうかの確認作業が行なわれます。データは、複数のデータフレームに分割して転送されるのですが、そのデータフレームを送ろうとするたびに、確認作業が必要となり、その間データフレームを送ることができない「すきま時間」が、挟まれてしまいます。
 
 拠点間の距離が長い場合、この送れない「すきま時間」が長くなってしまい、大量のデータを送る場合は、転送効率が著しく低下(スープットの低下)します。これは、データを大量にやりとりしなければならない業務システムにとっては、致命的です。
 
 この問題を解決する効果的な対策は、日本国内にあるセンターを利用するか、Windows Azureの場合は、マイクロソフトが日本国内に設置する「コンテンツ配信ネットワーク (CDN)」 にキャッシュを置くという方法が考えられます。

------

 これ以外にも課題はあります。ただ、クラウドは、もはやBC/DR対策の手段のひとつとして、「十分検討に値する」、そんな時代になってきたのではないでしょうか。

■Facebookで議論しませんか?

 このブログのFacebookページを開設しています。ぜひ、Facebookページ「ソリューション営業プロフェッショナル」にアクセスいただき、「いいな!」をクリックし、ご参加ください。

2011年3月12日土曜日

この大震災に想う

 地震から一夜明け、自宅に帰れぬままにオフィースで朝を迎えました。家族の安否を確認しようと昨夜は何度か連絡を試みたものの一切つながらなかったのですが、今朝やっと連絡が取れました。
 
 都内に勤める娘は、電車の復旧が見込めないと知ると、職場近くの自転車屋にすぐに駆け込み自転車を買って帰宅したそうです。その機転の良さと行動力には脱帽です。無事、帰宅できたとの報告に安堵しました。
 
 インターネットのアクセスラインは、地震発生直後から幸いにして障害はなく、TwitterやFacebookで友人達の安否を確認できました。また、米国に住む娘からは、Skypeで連絡があり、話もできました。日本国内はつながらないが、米国とはつながるという皮肉。改めて、インターネットというメディアが、電話ではなしえないコミュニケーションの手段であることを実感しました。
 
 ところでこのような大災害があると、治安が乱れ、社会秩序が保てなくなる国もあります。幸いにして、我国では、礼儀と秩序がしっかりと保たれているようで、これは大いに誇れることだと思います。
 
 後は、多くのリソースを復興に向けて結集すべきです。このような事態に対応するため、子ども手当や高速道路無料化が廃止になっても、多くの国民は、受け入れてくれるのではないでしょうか。この際、見苦しい政局争いはやめにして、政治家もそちらにエネルギーを傾注していただけないものかと願う次第です。
 
 そして、自分に何ができるかです。まだ、その答えは見つけてはいませんが、その答えを探し始めようと思っています。
 
 いつもなら、営業やITに関わる記事を掲載しておりますが、さすがに今日は、そんな気持ちにはなれません。今は、お亡くなりになられた多くの皆様への哀悼と、被災されている皆様の早期の生活復旧を祈り、筆を置かせていただきます。

2011年3月6日日曜日

羊飼いのシステムに翻弄される哀れな農耕民族

 「営業効率の向上や現場力の強化を考えて、SFAを導入したのですが、いっこうに効果が上がりません。どうしたものでしょうか?」
 
 先日、あるソリューション・ベンダーの営業本部長が、そんな愚痴をこぼしていた。かなりの費用をかけ、いろいろと検討も重ねて導入したにもかかわらず、こんな結果となってしまったことに、本人も少なからず責任を感じているようだった。
 
 そんな彼に、失礼を承知で、私は次のようなことを申し上げた。
 
 「SFAは、本来、営業の効率化や現場力強化のための道具なんかじゃありませんよ。そもそも、その目的や前提が、間違っていたんじゃありませんか。」彼は、納得いかないという顔をして、「じゃあ、なんのためのSFAなんですか?」と質問を返してきた。
 
 「SFAとは、経営者や管理者が、営業の進捗状況や売上げの見通しを、タイムリーに把握するための道具です。言い換えれば、営業組織やその活動を管理統制するための道具であって、現場のための道具ではないと言うことです。」
 
 ソフトウェア・パッケージに限った話しではないが、製品には、必ずその製品を開発する前提となるビジネス・プロセスや思想、目的がある。当然、それを使う人たちの習慣や文化、ビジネス・スタイルに大きく依存している。その本質を理解しないままに、表面的な機能性能だけを見て、使える使えないの議論をしても、適切な答えを見いだすことはできない。
 
 例えば、ある業務の効率を上げるために、ソフトウェア・パッケージの選定するとしよう。○×△をつけて、使えそうな機能が、他社の製品に比べて多いからという理由で、そのシステムを導入する。しかし、その前提となるビジネスプロセスや思想が、その業務とかけ離れていたとすれば・・・
 最初はカスタマイズで何とかつじつまを合わせることができたとしても、そのパッケージは、その思想でどんどんとバージョン・アップや機能の強化を進める。一方、適用した業務もそれとは関係なく変わってゆき、両者の乖離は、ますます大きなものとなってゆく。仕方がないので、その都度カスタマイズで対応する。
 そのうち、カスタマイズも限界となり、結局、そのシステムは「塩漬け」となる。そして、「使えないシステム」の烙印が押され、導入の責任者は、その失敗の責めを負うことになる。

 欧米の経営者と従業員の関係は、羊飼いと羊の関係に似ている。彼らは、伝統的に、膨大な数の人的資産を効率よく統制し、自分たちの事業目的の達成に向けて、確実に動かす仕組を構築してきた。当然、経営者は、現場の末端に至るまで、迅速正確に情報を収集する術を必要としていた。SFAとは、そのための道具なのである。
 
 そこに働く営業も、日本的には、個人事業主に近い独立した専門職である。従って、雇用者に対して、自分の成果を迅速正確に報告しなければ、報酬(コミッション)を得ることができない。従って、両者の利害は、完全に一致している。営業は、当然のことではあるが、効率化や現場力強化の道具などとは、考えていないのである。
 
 また、欧米では、「横へのキャリアパス」が、受け入れられており、むしろ高く評価される傾向にある。この「横へのキャリアパス」とは、ある会社で経験を積みスキルを身につければ、他の会社へ転職して、さらに高い地位を手に入れることは当然であり、評価するという社会的コンセンサスである。
 従って、営業は、高い報酬と地位を得るために会社に尽くす一方で、その機会が満たされなくなれば、いつでも他の会社に移り、さらに高い地位と報酬を求める。これは、何も悪いことではないと考えている。一方、経営者もそのことは承知しているわけだから、きめ細かく徹底した管理統制を行ない、適正に業務を行なっていること、併せて、会社への不正や不利益が生じないように、組織の末端まで、監視しなくてはならない。

 SFAとは、本来そんな思想の元で開発されたものである。これは、SFAだけではない。ERPも同じ思想の上に成り立っている。
 
 一方、日本はどうか。日本の組織は、伝統的に家族主義的である。社長は親父さんであり、従業員は家族である。経営者は従業員を信じ、彼らは、その信頼に応えようとする。これは、地域でお互いに助け合い、田畑を耕さなければ、生きてゆくことのできない農耕的文化が、背景にあるのかもしれない。
 
 従業員が、経営者について不満を語ることがある。そして、経営者もまた従業員について不満を述べる。そんな光景を目にすることがあるが、よくよく話を聞いてみると、「このまではこの会社がダメになる、何とかしなければ」と言う不満であり、その目的は共通していることが多い。これは、コミュニケーションの問題であり、経営者と従業員の本質的な対立とは言えないように思う。むしろ、経営者も従業員も、「自分の会社という意識」を持ち、その上で考えているのである。これは、単なる報酬のみの主従関係ではない。
 
 また、日本では、「横へのキャリアパス」は、あまり快く思われない。昔ほどではないにしても、あまりよろしくないという空気が、未だ大勢を占めている。従って、日本の企業では、「縦へのキャリアパス」が重視される。つまり、同じ会社の中で、出世してゆくことが唯一のキャリアパスと考える風潮である。従業員は、会社を我が家と考え、会社のために貢献することを当然と考える。だから、失敗は許されない。何事も「ミニマム・スタート」でリスクを最小限に抑え、失敗を許さず、確実にキャリアを重ねて行くことを大切に考える。経営者は、そんな社員を信頼している。だから、現場が使えないというものを、経営者は、無理矢理使わせることができない。「現場の判断にまかせる」ことを大切にする。
 
 このような思想的背景にある日本の経営者も欧米の経営者と同様に組織の動きを迅速、的確把握したいのは、同じである。従って、SFAやERPを導入し、これに対処しようとする。しかし、欧米方式の製品をそのまま持ってゆくと、「こんなインターフェイスや機能じゃあ使えない現場の業務に合わない」と現場の反発に遭う。家族思いの経営者は、ならば現場に使えるようにと、現場の業務プロセスに対応させるべく、徹底したカスタマイズを許容する。
 
 先日、ある大手欧米系ERPベンダーの営業部長から聞いた話では、日本ではパッケージ導入に当たり、膨大なカスタマイズを要求されるのが一般的だが、欧米では、それがほとんどないという。これは、現場の主体性に大きく依存し現場を信頼する日本と、現場は、統制・管理の対象と考える欧米との文化・思想的な違いが、根底にあると考えるべきだろう。欧米では、管理統制の道具なので、経営者にとって都合がよい機能があれば十分である。従業員は、被雇用者であり、主従の関係は歴然としている。従って、いちいち現場にお伺を立てる必要はなく、宛てがい扶持を強制的に使わせるだけのことだ。現場もそれを当然のこととして受け入れている。
 
 これは優劣の問題ではない。質的な違いなのだ。この違いを理解せず、システムの選定を進めることは、結果として大きな失敗を招くことになる。
 
 冒頭の話しに戻るが、件の営業本部長は、「現場に使ってもらうためにユーザー・インターフェイスを徹底的にカスタマイズをしたのだが・・・」と話しをしていた。やはり、本質的なところを検討していなかったようだ。
 
 昨今、欧米の有名SFAを導入したがうまく活かされていないという話しに、リッチなユーザーインターフェイスやモバイルからの利用など、「使いやすさ」を売りにしてSFA製品を出している企業がある。しかし、これだけでは、問題の本質を解決することにはならない。
 
 むしろ、正直に「これは、現場に負担を強いるが、経営判断の迅速化や効率化のためには不可欠なものであり、会社としての体質を強化してゆくために、是非とも協力して欲しい」と現場に説明し、納得の上で使ってもらうべきなのである。
 
 現場をだまして・・・とまでは言わないが、現場に阿(おもね)るあまり、その本質を議論せず、膨大なカスタマイズで現場に合わせるものの、結局は役に立たない。しかし、導入した以上は、その責任もあり、無理にでも使わせようとする。そのために、「SFA活用委員会」のようなものを作り議論するも、前提が違うままにすすめても解決することはないだろう。なんと無駄なことだろうか。
 
 だからといって、現場の生産性や現場力の強化について、何もしなくていいと申し上げているわけではない。私が、申し上げたいのは、SFAやERPの導入と現場の生産性や現場力の強化は、別の次元で議論すべきではないかということである。もちろん、SFAやERPが、それに使えないわけではない。しかし、製品に依存するだけでは、解決することはできないだろう。
 
 また、このような製品を提案する営業も、製品の持つ思想的、文化的背景を考えもせず、ただ採用してもらいたいがために、この製品を導入すれば、現場力の強化や生産性が向上するなど、本来の目的ではない話しをし、その機能や性能の自慢話をするのは、やめてもらいたい。結果として、お客さまに大きな迷惑をかけることになる。率直に、目的や思想の話しをすべきである。
 
 たびたび申し上げているが、この議論は、日本と欧米のどちらが優れているかというものではない。私たちは、それぞれの文化や社会的コンセンサスの違いを冷静に理解し、うまく使いこなしてゆく必要がある。表面的な機能や性能で、判断するのではなく、その背景にあるビジネスの習慣や文化、思想の違いを学び、うまく活かしてゆくためには、どうすればいいのか。そのガイドをするのが、ITベンダーの責任ではないかと思う。
 
■Facebookで議論しませんか?

 このブログのFacebookページを開設しています。今回の考えには、納得できないという方もいらっしゃると思います。そんな方も含めて、是非ご意見をいだければと思います。また、このような日本と欧米の比較文化論については、優れた先達達の研究があります。そんなこともさらにご紹介したいと思います。
 
 ぜひ、Facebookページ「ソリューション営業プロフェッショナル」にアクセスいただき、「いいな!」をクリックし、ご参加ください。