案件規模の縮小 どう対処すればいいのか

「最近は、案件規模が縮小し、プロジェクト期間の短い案件が増えてきました。」

SIerの方に話を訊くと、いずれも同じような話が返ってきます。このような話が増え始めたのは、リーマンショック以降のことではないでしょうか。

ITバブル崩壊以降の低迷期を脱し、何とか明るい兆しを取り戻しつつあったまさにそんなときにリーマンショックが起こりました。プロジェクトの延期や中止が相次ぎ、SIerは厳しい状況に追い込まれます。

その後、リーマンショックのほとぼりも冷め、景気も持ち直しはじめましたが、一旦財布の紐を絞めてしまった以上、そう簡単に元に戻すことはできません。特に、企業にとって本業ではないITはコストであり、リーマンショックで緊縮財政が定着した企業にとっては、例え景気が回復したからといって、すぐに拡大する空気はありません。

また、そんな時期に起こった東日本大震災によって、プロジェクトは先送りされ、SIerは再び苦境に立たされます。

このようなIT投資の不連続な凍結や先送りのため、ユーザー企業の情報システム戦略は混乱し、適切な投資のタイミングを失ってしまったとも言えます。

そこで、ユーザー企業は、戦略的見通しのないままにプロジェクトをまとめてSIerに丸投げするリスクを避け、どうしても必要な最低限の業務を選び、分割して発注することで対処しようとしました。また、このような案件の規模の小型化は競合を容易にし、案件単価を下げることにもつながりました。

冒頭の言葉の背景は、このようなことなのでしょう。

また、昨今のクラウドや新たなテクノロジーの進展が、この流れをさらに加速しはじめています。それは、次のような3つの理由からです。

1.       クラウドを利用すれば初期投資を抑制でき、資産を増やすことなく経費として処理できるから

2.       SaaSの利用実績が増え、あえて自社独自の開発やカスタマイズをしなくてもアプリケーションを利用できるようになったから

3.       アジャイル開発の普及、高速開発のためのフレームワークやツールの充実により、短期間、低コストで開発できる環境が整ってきたから

SIビジネスは、もともと効率の悪いビジネスモデルといえるかもしれません。多くのエンジニアが従事していたプロジェクトが終了すると、そのエンジニア達は、次のプロジェクトに従事させなければ、なりません。しかし、そんなに都合良く全員が従事できるプロジェクトを確実に確保できる保証はありません。そのため、どうしても数週間から数ヶ月間、何も稼げないのに給与を払い続けなくてはなりません。このような仕組みが、SIerの利益率を低迷させる原因にもなっています。

この構造的問題に加え、上記にあげた案件規模の縮小と競合、クラウドやテクノロジーの進化は、SIビジネスを益々難しいものにしています。

このあたりの変化を整理したのが、次の図です。

これまでは、お客様の要求どおりの機能と品質を確実に実現することが求められました。プロジェクトも、1年から3年といった長期のものも少なくはありませんでした。しかし、今は、案件規模は小型化し、変更変化に迅速柔軟に対応し、短期間で開発することがこれまでにも増して重視されるようになりました。

システム資産は、自社で保有することが当たり前の時代から、クラウドを利用する選択肢が優先する「クラウド・ファースト」の時代へと変わりつつあります。

開発は、個別対応を前提とし、要件をあらかじめ明確にした上でウオーターフォール方式で開発し、契約は準委任や請負が一般的でした。それが、アジャイル開発の手法や高速開発のフレームワークやツールを駆使して内製化をすすめようという機運も高まっています。また、できれば開発せずに済ませたいということでSaaSを積極的に利用しようという動きも増え始めています。

運用業務は、ユーザー企業がそれぞれ個別に所有するシステムをITベンダーから派遣されたエンジニアによって対応してきました。それが、クラウドになれば、運用業務の一部がサービスに組み込まれています。また、データセンター事業者にシステム資産を預けることも一般化し、複数企業の運用業務にまとめて対応するマネージド・サービスも普及しはじめています。

ユーザーが使うデバイス(エンド・ポイント)は、これまではPCが前提でした。PCは、比較的画面スペースに余裕があります。そのため、クライアント・アプリケーションやウエブの画面は、効率の良い機能の配置が優先されるユーザー・インターフェィス(UI)が求められました。

しかし、スマートフォンやタブレットなどのスマート・モバイル・デバイス(SMD)の普及により、新たなアプリケーションは、SMDにも対応することが求められるようになりました。SMDは、もともと個人利用を前提としたデバイスです。そんなこともあって、機能が使えるだけでではなく、美しいデザインや使うことが楽しくなり、もっと使いたいと思わせることができるインターフェイス(UX)が求められます。また、画面が小さいこともあり、機能を絞り込み、使いやすさにもこれまでに無い配慮が求められるようになりました。ならば、PCを前提にするのではなく、まずはSMDのインターフェイスを作り、PCはその後対応しようという「モバイル・ファースト」の考え方が生まれてきました。むしろこちらの方が、結果としてPCの画面もシンプルで使いやすくなります。

このような変化が生まれつつあるのです。

それでは、ITベンダーは、この変化にどう対応すればいいのでしょうか。こちらについては、次週説明させていただきます。

■　Facebookで、是非ご意見をお聞かせください。

新規事業はモノとノウハウに因数分解して考える

「新規事業を考えろと言われても、そう簡単に儲かるビジネスなんて思いつきませんよ。いったい何から手をつければいいのか・・・」

こんな愚痴とも、相談ともつかない話を伺いました。彼は、四月から、新しい組織の責任者を任され、社長からこのミッションが託されたそうです。

この会社は、あるERPパッケージ・ソフトウェアの販売、導入には定評がある会社です。しかし、大手企業での導入は一巡し、同じ商品を扱う参入企業も増えたことから競合が厳しくなり、例え受注できても利益率は、どんどん下がる傾向にあるそうです。

同席したメンバーからこんなアイデアが示されました。

「これまでのお客様を深掘りして、適用範囲を拡げ、追加の仕事を増やしてゆくというのはどうでしょう。」

「これまで、お客様の関連会社にはアプローチしてこなかったので、そういうところに話を持って行くのはいいかもしれませんね。」

「中小企業にも使えるようにテンプレートを整備して、導入のコストを下げて、売りやすくすると言うのは、どうでしょうか。」

このようなやり取りを聞きながら、少し口をはさませて頂きました。

「なるほど、皆さんのおっしゃっていることは、確かに売上増加に貢献するかもしれません。でも、それって、皆さんに期待されていることでしょうか。それは、そのパッケージを担当している事業部が、当然やるべきことであって、皆さんの役割ではないと思いますよ。」 「皆さんの役割は、これまでにお付き合いのないお客様を、新しいサービスや商品で開拓することじゃないんでしょうか。」

自分たちが扱っている「モノ」にこだわり、その延長線上で考えれば、どうしてもこんな議論に陥ってしまいます。

「こう考えてみてはいかがでしょうか。皆さんは、この製品については、たいへん多くの導入実績をお持ちですよね。そして、ERPに関するノウハウも相当に持っていらっしゃるはずです。そこで、この製品とノウハウを切り離して考えてみませんか。」 「今扱っている製品は棚に上げ、これまで蓄積したノウハウをビジネスにすることを考えてはどうでしょうか。」 「例えば、中堅あるいは中小なら、今の商品は高すぎて導入をためらうはずです。ならば、オープン・ソースのERPを担ぎ、そのサポートを皆さん自身が保証してはどうでしょう。それをAmazonなど、実績のあるクラウドサービスで動かし、その運用も一括して引き受けてあげればどうですか。そのノウハウは全てあるはずです。」 「既存のお客様でも、費用の面で関連会社には導入できないというところがあったんじゃないでしょうか。ならば、そういうところの取りこぼしもなくなる可能性がありますよね。新規ばかりでなく、既存のお客様からのビジネス拡大にも貢献できるはずです。」

「モノ」にこだわるあまりに発想を縮めていないでしょうか。「モノ」と「ノウハウ」あるいは、「モノ」と「スキル」を一体と考えず、個別の価値と考えてはどうでしょうか。

こんな例もあります。

その企業は、品質の高いシステムの開発には定評がありました。そのための開発標準や手順は、しっかりと整備されています。しかし、SIの案件単価は下がり、利益率も下がる中、新規事業についての相談を受けました。そこで、こんな話をしました。

「自分たちの開発標準を商品にしてはどうですか。つまり、そういう開発を内製化したいというお客様にスキル・トランスファーするビジネスです。」

自分で自分の首を絞めるような話ですが、お客様が求めているのなら、需要はあるわけです。しかも、こちらに売り物があるわけですから、ビジネスは成立します。

SIに固執するなら早晩ビジネスは厳しくなるのは目に見えています。ならば、SIとノウハウを切り離し、それを商品化するという発想を持てば、新たなビジネスになるはずです。

内製化と言ってもお客様のエンジニアの絶対数は少なく、全てを内部でまかなうことはできません。だから、内製化を支援すれば、そのノウハウがお客様の標準となり、結果として、スキルを提供した会社に優先的に仕事をお願いすることになるはずです。

新規事業と言っても、全く何もないところから考えることは、容易なことではありません。しかし、今のビジネスを「モノ」と「ノウハウ」に因数分解し、「ノウハウ」を起点に新しいビジネスを考えるならば、現実的な答えが見えてくるかもしれません。

■　Facebookで、是非ご意見をお聞かせください。

「そうなったらいいなぁ」が「事業戦略」と呼ばれる不思議

「海外への進出を考えているんですが、まずは国内企業の海外進出を支援することからはじめようと思っています。」

「でも、同じようなことを考えている企業も少なくないと思いますよ。結局は地場の企業を顧客として取り込んでゆかなければ、海外事業は、頭打ちになるんじゃありませんか。」

「ええ、私達もそう考えています。でも当面は、仕方がないと思っています。まずは、進出して、走りながら考えて見ようと思っています。まあ、はじめてのことでもありますし、やってみなければ分かりませんよ。」

本当にそれでいいのでしょうか?

地の利も分からず、人脈がない状況にあっては、最初は仕方のないことだと思います。しかし、海外進出となれば、大きなリスクを冒しての先行投資です。それが、「当面」の戦略だけで、実行に移していいのでしょうか。いずれ訪れるであろう未来が分かっているにもかかわらず、当たって砕けるというようでは、なんとも心許ない話です。

「海外の顧客を取り込むためにこういうことをやる」という具体的イメージを仮説として持たなければ、本当にそのやり方が妥当かどうかは分かりません。情報も入ってこなければ、人のつながりも生まれないでしょう。何が必要なのかも見えてこないはずです。

• 当面は日本企業の海外進出を支援し、3年後は地元企業の顧客比率を3割りまで引き上げる
• 現在のパッケージ・ビジネスから、3年後には、SaaSビジネスへの転換を図る
• 現在、グループ内企業の売上比率が8割りだが、5年後にグループ外の比率を8割に引き上げる

どのように実現するのですか?

担当者曰く「そうでも言わなければ、上も納得しませんしねぇ。」

経営者曰く「それぐらいの高いハードルを掲げておかないと、何もやりませんよ。まあ、正直なところ、本当にできるとは思っていませんけどね・・・」

なんて、本音が聞こえてきそうです。

• 海外顧客を取り込むための訴求点はなんですか。どのような価値を地元企業に提供できるのでしょうか。なにが地元企業や他社にはない強みなんでしょうか。どのようにチャネルを開拓し顧客ベースを拡げるべきなのでしょうか。
• SaaSシステムの具体的な機能やサービス内容のイメージは描けているんですか。 SaaSとなれば、顧客ベースも収益構造も変わります。ではどうなるのでしょうか。現行のパッケージ・ビジネスから移行するシナリオは描けているのでしょうか。SaaSへの移行は、ひとつのプログラムをマルチテナント対応させなくてはなりませんが、それに伴う変更点や運用上のリスクを明確にできているのですか。
• 今はない顧客ベースを新規に開拓しなければなりません。これまでそういうことに取り組んだ経験は少なく人材もスキルも不足しています。それをどうやって補うのですか。自分たちにできないとすれば、外部との協業を模索しなければなりませんが、かれらが協業することにメリットを感じてくれなければうまくゆくはずなどありません。どのような協業のスキームを実現するのですか。

「何をすべきか」

あるべき論の追求がないままに、「そうなったらいいなぁ」という「期待表明」が、いつの間にか事業戦略や事業計画という名前にすり替わっていることはないでしょうか。

戦略や計画は、まず「何をすべきか」を描くことからはじめるべきです。つまり、何をゴールにするか、また、そこへ至る筋道を具体的に、鮮明に描いてみることです。

「そんなことを言われても、新しいことですからねぇ。事業部としては収支が問われますし、無い袖はふれません。「何をすべきか」と言われても、現状を無視するわけにはゆきませんよ。」

現状の積み上げだけで、新しく掲げた事業戦略を本当に実現できるのでしょうか。正解のない問題に挑戦し、現実との妥協を積み上げ、気がつけば、できなかった理由で武装する、なんてことになりませんか。

現状を前提として、今の自分たちは「何ができるか」を議論すれば、発想は縮まり、お客様が求めるものからは、どんどんと遠ざかってゆくような気がします。

じゃあ、どうすればいいのでしょうか。まずは現状を棚に上げ、理想のあるべき姿を描くことからはじめなくてはなりません。その上で、現状を棚から下ろし、そのフィット・アンド・ギャップを明らかにします。そこには、いろいろな課題があるはずです。これをどうすればこれを埋められるかを実行計画として描き出します。たぶん、こういう手順が基本なのでしょう。

走りながらゴールを求めるのではなく、仮のゴールを地図の一点に定め、そちらに向けて走り出すことです。そうすれば、その過程で様々な情報が手に入ります。そして、目の前にあらわれた課題を解決すること、あるいは、ゴールそのものを変更しなくてはならないこともあるはずです。それらは全て、ゴールに向かうからこそ、できることなのでしょう。

変化のない時代など、過去にはなく、未来にも訪れることなどありません。だから私達は、常に変革してゆかなければなりません。

ただ、そんな時代の流れの中でも、時に「時代の節目」と言われる大きな転換点が訪れることがあります。ITビジネスで考えるならば、クラウドやグローバルが時代の流れとなっている現在は、大きな節目のひとつだと、私は考えています。

「時代の節目」への対応は、これまでの常識の延長線上に求めることはできません。単なる改善では限界があります。大きな変革、すなわちイノベーションが必要なのです。

お客様の価値観、事業構造、収益モデル、テクノロジー、求められるスキルなど様々なビジネスの構成要素が、これまでの常識を大きく変えてしまいます。

経営者は、こういう時代の節目に気付き、危機感を持てと言います。しかし、その議論は精神論に終始し、現場にしてみれば、「そんなこと、わかってますよ。でもね・・・」と、現実感のないもやもやとしたフラストレーションだけが溜まってゆくなんてことには、なっていませんか。

危機感を持つとは、あるべき論を明確にし、次に現状を直視する。そして、両者のフィット・アンド・ギャップを具体的に描くことからはじめます。そして、そのギャップを埋めようと計画を練ると、それが容易に解決のできないことに気付くはずです。このような過程を経て、危機感は、はじめて現実感となるのです。

変革を、お経のように唱えても実現することはありません。ここに紹介したような行動があって、はじめて危機感は醸成され、行動を促します。それでも、行動が起こせないとすれば、これはかなり深刻な事態だと、考えなくてはならないでしょう。

■　Facebookで、是非ご意見をお聞かせください。