受託開発+αの可能性、コモディティからの脱出

斎藤昌義(さいとう まさのり) 2014-03-08 06:30:00

「何だか受託開発ビジネスに否定的な内容ですねぇ」

先週のブログをご覧頂いたSI事業者の社長からこんなコメントをいだきました。これについては、イエスでもあり、ノーでもあります。

多くのビジネスでコモディティ化は避けがたい必然です。受託開発ビジネスもまた、同じ歴史をたどってきたと言えるかもしれません。

以前、我が国の受託開発ビジネスの草分けを担った大先輩に話を伺ったことがあります。「そんなこと仕事になるのか」と言われながらも、新しいビジネスである受託開発に挑戦されました。高度経済成長に支えられ、事業は順調に拡大していったそうです。景気の浮き沈みはあったものの、受託開発需要の拡大は続き、参入企業の増大を呑み込んで事業は拡大していったそうです。その会社も今、利益の低迷に苦しんでいます。

アベノミクスが追い風になって受託開発需要そのものは増加傾向にありますが、利益率低迷の構図は変わりません。ひとり1.5人月分働いてもらって、かろうじて需要をまかなっているところもあるようです。しかし、このような状況が長続きするでしょうか。

黎明期は先駆者として市場を切り開き、安定した収益を確保できました。需要は供給を上回り、需要の拡大と共に受託開発ビジネスも拡大を続けてきました。しかし、供給の拡大は需要を追い越し、需要側であるユーザー企業に選択権が移りました。

「うちは技術力がありノウハウもある。他社とは違う。」とおっしゃる方もいるでしょう。しかし、既存技術だけであれば、各社の切磋琢磨によって需要側にとっては十分な水準を超えてしまいました。そのため、人月単価とその積算でしか評価しない情報システム部門も増えてしまい、これらが決定的な差別化要因にはなりにくい残念な現実となっているのです。

かくして、受託開発ビジネスもまたコモディティに到達したといえるでしょう。結局は、生き残りをかけた価格競争へと追い込まれ、仕事はあっても利益が出ないサイクルに、はまり込んでしまっているのが今の現実です。

コモディティとは、「需要はあるが、どこを使っても同じ」という状態です。本質的に需要が途絶えているわけではありません。問題は「同じ」であることをどう克服するかにあるのです。ここに受託開発ビジネスが、生き残るヒントがあるのではないでしょうか。

ではどうすればいいのか。3つのシナリオを考えてみましょう。

まずは、新しい差別化要素を受託開発に持ち込むシナリオです。例えば、ビッグデータや機械学習、IoTなど、供給が不足している先端テクノロジーの領域に取り組み、競合の問題を回避することです。先端テクノロジーは将来に大きな成長は見込めたとしても短期的には大きな需要は見込めません。しかし、尖ったテクノロジーで顧客を獲得できれば、その周辺にある既存テクノロジーで対応できる受託開発需要を取り込める可能性があります。また、これまで取引のなかった顧客を開拓できる可能性もあります。結果として、受託規模を拡大することができます。

Amazonなどのクラウド基盤での開発や本番運用を受託開発とセットにして提供するシナリオもこれに含まれます。さらには、マネージド・サービスやユーザーに対するヘルプデスク機能を提供し、受託開発とセットにして、開発から本番運用をワンストップで提供することも考えられます。

このやり方であれば、これまでの受託開発の人材を活かすことができます。ただし、新しいテクノロジーや方式などを取り込むための少数の専任者や組織を持つことが必要です。また、自分達だけではできない場合は、積極的に協業を模索し差別化を先鋭化させることも選択肢となるでしょう。

ここでの協業とは元請け、下請けの上下関係を前提とした垂直協業ではなく、役割を異にする水平協業です。もちろん、どちらかがイニシアティブを取るにしても、水平協業でシナジーを拡げ、新しい顧客価値を生みだす事が必要です。

既存テクノロジーでの受託開発だけではコモディティ化の洗礼を免れません。しかし、需要はあります。ですから、受託開発の周辺に差別化と収益拡大のメカニズムを組み入れることで、「同じ」ではないサービスを実現し、新たな需要を引き込むことができるのではないでしょうか。

もうひとつのシナリオは、あたらしい収益モデルへの挑戦です。これについては、以前のブログにも掲載しましたので、詳しくはそちらをご覧下さい。ここで申し上げたいことは、販売や工数積算だけではない収益モデルに取り組むことです。サブスクリプション、レベニュー・シェア、成果報酬などが考えられます。全ての受託開発で新しい収益モデルへ移行せよという話ではありません。ただ、その可能性を模索すべきであるという提案です。安定した収益をもたらすためには、対象となる業務領域の適・不適もあるでしょう。そのビジネスを運用するノウハウも必要です。

何が本命と言いきれるものではありませんが、これまでの工数積算型の収益構造だけでは、限界は見えています。だからこそ、新しい収益モデルでの受託開発をお客様に提案し、経験を蓄積してゆくべきでしょう。

三つ目のシナリオは、開発生産性を徹底して追求した受託請負のビジネス・モデルです。開発生産性を追求することは、工数を拡大することがビジネス目的となっているSI事業者にとっては、利益相反です。準委任であればなおのこと、工数を維持することがビジネス目的となります。例え単金は小さくても安定して収益を確保するためには、開発生産性を追求すべきではないのです。

しかし、これではお客様との間に利益相反が生まれてしまいます。そこで、受託開発を請負にして成果を保証し、徹底して開発生産性を高め原価を低減し、利益の拡大を図ることです。その手段として、アジャイル開発に取り組んでみてはどうでしょうか。アジャイル型請負開発については以前の記事で詳しく取り上げましたので、そちらをご覧下さい

アジャイル型請負開発が、契約手続きやお客様の理解を得ることの難しさなどで容易ではないという指摘もあります。ただ、アジャイルを手法として捉えるのではなく、品質の高いシステムを無駄なく短期間に開発するための思想であることを正しく理解し、お客様と共にその方法を模索する提案をしてみてはどうでしょうか。

新しい収益モデルのところでもご紹介のように、全てのケースに当てはまる保証はありません。だからこそ、お客様に積極的に仕掛け、お客様を巻き込みながら、一緒になって共通の利益を生みだす新しいやり方を模索してゆくべきなのです。

これらに共通する原則は、お客様との直接取引と専任者を置いた社内での取り組みです。外部との協力はあるにしても、自分達のノウハウとして蓄積してゆくことが大切です。

MP900178714

今後も受託開発の需要がなくなることはないでしょう。しかし、「同じ」であることが収益拡大を難しくしています。だからこそ、徹底して顧客価値を追求し、付加価値を高め「違う」魅力を組み込むことです。

受託開発を辞めて他のサービス・ビジネスへ転換することもひとつの選択肢に違いありません。しかし、そのハードルは決して低くはありません。ならば、既存の受託開発の延長にあるこのようなシナリオに取り組むことも選択肢となり得るでしょう。

ここに紹介したシナリオ以外にも選択肢はあるはずです。それを見つけ出すためにも、どうすれば顧客価値をもっと大きくできるかを追求し「違い」を求め続けなくてはなりません。そうすれば、コモディティのジレンマから抜け出すことができるかもしれません。

第1回 ITACHIBA会議[無料]を3/18(火)@東京

580px-A

今、問われるIT部門・SI事業者の存在意義

IT部門は必要なのか?SI事業者は何をすべきか?

ITACHIBAとは、ユーザーとベンダーの立場や利害を超えて、これからのITとの係わり方を考え、議論し、共有する「場」として、有志たちがボランティアで立ち上げたコミュニティです。

その第一回目の会議を来る3月18日(木)に開催します。当初予定した2月14日(金)が大雪にて中止となり、改めて開催することとなりました。

IT部門の変革に取り組む大手製造業の情報システム部門長、受託請負会社からクラウドやOSSを活かしたサービス会社への転換を果たしたベンダー企業の社長が、その取り組みの生々しい現実をお話し頂きます。そして、彼等の話を切っ掛けとしてグループ・ディスカッションをおこない、新たな気付きや今後への取り組みについて考えていだこうという企画です。よろしければ、ご参加ください

会員制ドキュメント・ライブラリー 増殖中!

■ 月額500円の定額制
■ 最新ITトレンドのプレゼンテーションを
■ 著作権フリー・加工編集が自由なファイル形式で

libra_banner_275x150

  • 「仮想化とSDx」を改訂しました。
  • 「SDN (Software-Defined Networking)」を新たに追加しました。

を追加致しました。

*ドキュメントの中身は全て閲覧できます(一部作業中でご覧頂けないものもあります。)

※このエントリはZDNetブロガーにより投稿されたものです。朝日インタラクティブ および ZDNet編集部の見解・意向を示すものではありません。

SpecialPR