中小ITベンダーの成長戦略

IT業界の方向性

将来、規模の大小を問わず、多くのユーザー企業が現在以上にシステム開発の内製化を推し進める可能性があります。

そう考える背景には次の2つがあります。

  1. ハード/ソフト両面での開発環境の充実
  2. ITと経営の融合

1.ハード/ソフト両面での開発環境の充実

まず、情報システムの開発環境の充実があげられます。

  • クラウドサービス(PaaS,SaaS,Kintone,Salesforce,BRMS)
  • ビジュアルプログラミング(Scratch,Blocky,Apply.ly,MoonBLOCK,Viscuit,プログラミン,etc)
  • プログラミング人材の増加(プログラミングは義務教育の時代に)

このような、ハード・ソフトの両面における環境の充実が、ユーザー企業自身による情報システム化をますます推し進めると考えられます。

2.ITと経営の融合

次にITと経営の融合です。

現代ではITと経営は分離不可能、不可分の関係です。強いビジネスを構築・維持するにはITは不可欠です。

  • ITと経営の関係の変化(経営戦略>情報戦略 → 経営戦略=情報戦略)
  • ITの役割の変化(コストダウンの手段 → 競争力の源泉)
  • IT部門の役割の変化(コストセンター → インベストメントセンター)

経営におけるITの重要性が高まっていることがわかります。

ITベンダーに対する期待の変化

この結果、ユーザー企業のITベンダーに対する期待も変化しつつあります。

いわゆる、おまかせ・丸投げは無くなるでしょう。ユーザー企業に対する期待は次の2つに整理されます。

  • IT専門家としての知見・技術の提供(新しい役割)
  • 情報システムの提供(従来通りの役割)

これからのITベンダーにはこれらの期待に応えるべく、自社のビジネスモデルを再構築(リビルド)することが求められます。

中小ITベンダーのビジネスモデル

中小ITベンダーは必ずしも受託開発だけを行っているわけではありません。

中小ITベンダーのビジネスはフロービジネスとストックビジネスの2つに分類されます。

  • フロービジネス(受託開発、パッケージソフトの販売)
  • ストックビジネス(サポートサービス、データセンター、クラウドサービス)

このような広がりをもつのですが、多くの中小ITベンダーは受託開発ビジネスに依存しています。

受託開発ビジネスの特徴

下請としての受託開発ビジネスには次のような特徴があります。

  • 工数(=エンジニアの頭数と期間)で売上が決まる
  • 元請Sierのプロジェクトマネジメントに従う
  • 顧客先や元請へ常駐する(ことが多い)
  • 人材派遣ではないが、人材派遣の色合いを帯びる
  • (しかし)成果物に対する責任を負う
  • 自社への持ち帰り開発は困難

受託開発ビジネスのビジネスモデル

ビジネスモデルキャンバスのフレームワークで整理してみます。

image

このようになります。

尚、これを4つのカテゴリにわけて考えることもできます。

image

中小ITベンダーの成長戦略

中小ITベンダーが「脱下請け」を目指す場合、逆説的に聞こえるかもしれませんが「受託開発ビジネスでしっかりと利益を出す事」が最重要事項となります。

「脱下請け」を掲げるだけではいけません。その先を見据えなければ目的地にはたどり着けません。

「脱下請け」の先には「元請けとしての受託開発ビジネス」や「新規ビジネス」があるはずです。

そして「元請ビジネス」や「新規ビジネス」をスタートさせるにはそのための施策・活動が必要であり、それには相応の資金が必要となります。

また「元請ビジネス」や「新規ビジネス」がキャッシュを生み出すまでは「下請ビジネス」だけで経営を支えねばなりません。

いずれにせよ「お金が必要だ」という事です。

助成金などの制度を利用するにせよ、既存のビジネスでしっかりとキャッシュを稼ぐことが、新規ビジネスに取り組む前提となります。

つまり、

①下請けビジネスでキャッシュを稼ぐ
②稼いだキャッシュで新規ビジネスを生み出す

というアプローチになります。

①下請ビジネスでキャッシュを稼ぐ

では下請ビジネスでしっかりとキャッシュを稼ぐにはどうすればよいか?

先にあげたビジネスモデルを見てみましょう。

「収益の仕組み」に、

  • いかに、より高い見積工数を認めてもらうか
  • いかに、より低い原価で業務を遂行できるか

と、あります。

いかに、より高い見積り工数を認めてもらうか

より高い見積り工数を認めてもらうには、次の2点がポイントです。

  • 他社にはないスキル・ノウハウをもっているか?
  • 元請Sierにとっての「ブラックボックス」をもっているか?

「他社にはないスキル・ノウハウ」は技術面でも業務面でもどちらでも構いません。

それらのスキル・ノウハウが日本一・世界一である必要もありません。

「他社にはない」かどうかは、元請Sierがアプローチできる範囲の競合他社との相対で決まります。

元請Sierにとっての「ブラックボックス」をもっていると、元請Sierは提示された工数の妥当性を判断しづらくなります。

こうなると元請Sierとの工数交渉において優位に立つことができます。

いかに、より低い原価で業務を遂行できるか

ローコストオペレーションを実現できるか?という事です。

汎用性の高い機能については部品化しておくとかフレームワークを使うとか、継続的インテグレーションのプラクティスをとりいれるとかオンラインミーティングを活用して間接コストを削減するとか、いろんな方法があります。

この点は改めて言う必要はないでしょう。

しかし、ポイントはコスト削減の手段そのものではありません。

上述したとおり、顧客先常駐型のプロジェクトになるとプロジェクトマネジメントの方法、開発環境やプラクティスは、元請Sierが決めることになります。

そうなると効率的なオペレーションができなかったり、仮にできたとしてもそのメリットは元請Sierが享受することになります。

持ち帰り開発となると、稼働状況に応じてエンジニアを融通することも含めて、工夫の余地が大きくなりますが、持ち帰り開発をすること自体が困難です。

結局、ローコストオペレーションの実現可否はエンジニア個人によるところが大きくなります。ポイントはここです。

尚、これは評価制度とも関係してくる話です。(ここでは、これ以上は掘り下げません。)

②稼いだキャッシュで新規ビジネスを生み出す

新規ビジネス創出は「やれば必ずモノになる」という類のものではありません。

投資というくらいですから相応のリスクがあります。

ですのでアイディア(というか思いつきやインスピレーション)だけで新規ビジネスの方向性を決めるのは危険です。

成長戦略にはセオリーがあります。下の表は、成長マトリクス(別名:アンゾフの成長マトリクス)というものです。

image

市場浸透戦略

既存市場×既存商品の象限にあるのは「市場浸透戦略」です。

これは先ほど述べた「①下請ビジネスでキャッシュを稼ぐ」ということです。

従って「(市場浸透戦略の)次にどこの象限に進むべきか?」ということを考えなければなりません。

成長戦略のセオリーでは「一足飛びに『多角化戦略』へ進むのはリスクが高すぎる」としています。

見慣れぬ市場にはじめての商品をもっていくのです。成功確率が高いとはいえません。ましてや、相対的にリソースに乏しい中小企業であれば、ハイリスクの勝負は避けたいところです。

残るは「市場開拓戦略」か「商品開発戦略」ということになります。

商品開発戦略

先に「商品開発戦略」について説明します。

「商品開発戦略」とはつまり「元請Sier」に対して「受託開発」以外の商品を提供するビジネスです。

次のことが考えられます。

  • 業務領域の拡大(例:「人事」の分野から「給与」の分野へ)
  • 開発工程の拡大(例:「下流工程」から「上流工程」へ)
  • フローからストックへ(例:サポートビジネス(運用・保守))

留意事項もあります。

それは、新しい業務・技術・スキルを習得するための機会はあるか?そのためのコスト負担ができるか?サービスを提供する体制の確立や設備投資をできるか?という事です。

これに加えて、元請への依存度をますます高めることになりかねないか?ということをよく考えなければなりません。

市場開拓戦略

「元請けとして受託開発ビジネスを行う」という事が考えられます。

上述したとおりITベンダーに求められていることも変わってきています。

ただシステムを開発・納入するのではなく、ユーザー企業の情報戦略の立案と実行をサポートするビジネスパートナーとして振舞わなければなりません。

そのためには、

  • 特化分野を作る。
  • 特化分野で攻める。(これまであまりやらなかったマーケティング活動が必要に)
  • 特化するかわりに商圏を広げる。(「地域のIT何でも屋」から「全国を相手にする特化部隊」へ)

という事をヤル必要がでてきます。

多角化戦略

ここまでの施策は経営基盤の強化施策ともいえます。

基盤強化の先に「多角化」が見えてきます。

「多角化戦略」として何をするか?

一概には言えませんが、例をあげるなら、パッケージソフトウェアビジネス、クラウドサービスビジネス、コンサルティングサービス、マネージドサービスなどがあります。

あるいは、それまでに培ってきた開発ノウハウをフレームワーク化し、同業他社にむけて提供することも考えられます。

どんなビジネスにチャレンジするかは、これまでに蓄積してきたスキル・ノウハウ、そして企業・エンジニアの理念・ビジョン次第です。