「人月・受託の限界を超えよ」SIerでSaaSを立ち上げる：特集：岐路に立つIT技術者たち（5）（1/2 ページ）

「人月による受託開発には限界がある」――SI企業で働いているエンジニアが考えた末に見出した「SaaSの新事業を立ち上げる」という道。社内SNSを開発、新規事業として社内ベンチャーを立ち上げた倉貫義人氏が「エンジニアとして自身が望む道」を語る。

[倉貫義人，SonicGarden]

社内ベンチャーという道

　「社内ベンチャー」という言葉を聞いたことがありますか？

　社内ベンチャーとは、新規事業の立ち上げや新規市場の開拓といった目的で、企業の中で擬似的に作られるベンチャー組織のことです。多くの場合、既存事業の延長線上では実施しにくい事業を推進するために作られます。つまり、社内ベンチャーは「イノベーションを期待された組織」といえます。

　筆者が所属するSonicGardenは社内ベンチャーです。本体の会社は、TISというシステムインテグレータ（以下SI企業）です。

　TISは、お客さまの要求を満たすシステムを作って納品する、という受託開発のビジネスが中心です。一方、SonicGardenは受託開発を行っていません。受託開発をTISの既存事業だとするならば、SonicGardenは既存事業の延長線上にないビジネスモデルを確立することを期待されています。

　SonicGardenでは、SaaS（Software as a Service）事業を中心に展開しています。企業向けの社内SNSであるSKIPや、企業間やプロジェクトで使えるコラボレーションツールのyouRoomをクラウドで提供しています。

特集：岐路に立つIT技術者たち バックナンバー

• 第1回 「環境変化に対応した技術者」になる道を探して
• 第2回 【転職市場動向】あふれるPGとSEはどこへ行くのか？
• 第3回 「SI⇒Web」転職は可能？ 技術者に必要な能力と思考
• 第4回 現場の技術者が考える「1〜2年後の自分の姿」
• 第5回 「人月・受託の限界を超えよ」SIerでSaaSを立ち上げる

　特集：岐路に立つIT技術者たち インデックスページ

受託開発ビジネスとSaaSビジネスの根本的な違い

　受託開発を行ってきたSI企業にとって、なぜSaaS事業は「既存事業の延長ではない」のでしょうか。

　受託開発事業でもSaaS事業でも、エンジニアが扱うのはいずれも「IT」です。エンジニアからしてみると、プログラムを書くこと、ソフトウェアを運用することは変わらないように思えるかもしれません。しかし、ビジネスとしては大きく異なります。

　受託開発は、顧客の要求に応じたシステムの開発を請け負い、構築して納品します。そこには納品責任や瑕疵（かし）担保責任があります。「1点ものを作る製造業」と考えてよいでしょう。

※後述しますが、請け負いで開発をしているにもかかわらず、労働集約型の人月で見積もり、価格を決めないといけないという矛盾こそがいまのSI業界の問題点だとわたしは考えています。

　一方、SaaS事業はビジネスとして「サービスを提供」します。顧客はシステムを「所有」するのではなく「利用」するという形を取ります。自社で所有するわけではないので、顧客は検収した製造物に対して報酬を支払うのではなく、利用したサービスに対して料金を支払います。

　大前提となるビジネスが違うので、SI企業にとっては、いっそ新規事業としてとらえた方が自然でしょう。わたしはこうしたSaaS（クラウド）こそ、ソフトウェアの提供方法として最適ではないかと考えています。

「人月による請負開発」が抱える問題にどう対応するか？

　わたしはもともとはSI企業のエンジニアとして、プログラム開発からプロジェクトマネジメントまで、いろいろな経験を積んできました。しかし、「人月による請負開発」というビジネスが抱える問題に対して、どうしても納得できずにいました。

　こうした思いをつづった「ディフェンシブな開発」と題したブログエントリで、次のような仮説を立てました。

　「エンジニアにとって、受託開発の中で人月で消費されるよりも、システムを発注する側のユーザー企業か、あるいはWeb企業のエンジニアになった方が幸せなのではないか」

　この仮説から出発して、わたしは自社内向けにシステムを作ることにしました。このシステムは、いまSonicGardenで扱っている社内SNS「SKIP」の前身となるものでした。

「社内ベンチャーを立ち上げる」という選択肢

　2年半ほど、技術本部で社内向けにSNSの開発と運用・運営を行ってきたのですが、直接売り上げをあげる事業部門ではないということから、常に人員や予算の削減に対する危機感がありました。コスト削減自体は営利企業として正しいことではあります。しかし、自分が開発に携わった社内SNSが埋もれてしまうことは、エンジニアとして残念でなりませんでした。

　そこで、わたしは2つの企画書を作って会社への提案を開始しました。1つは「開発した社内SNSをオープンソースソフトウェアとして公開する」というもの。もう1つは「社内SNSを使って新規事業を立ち上げて、自らの存続費用を捻出（ねんしゅつ）する」というものでした。

　社内SNSを事業化するにあたって、事業計画を立てる中で、ソフトウェアをサービスとして提供する「SaaS」という概念を学び、採用することにしました。 TISがそれなりに大きな会社だったこと、わたしにとって初めての経験ばかりだったことが重なり、半年以上の時間がかかってしまいましたが、なんとか社内で承認を得られました。SaaS事業は、前述のとおりSI企業にとって新規事業であるということを踏まえ、社内ベンチャーという形で始めることにしました。TISには社内ベンチャー制度がなかったのですが、わたしたちの取り組み自体を社内ベンチャー立ち上げの実績として、制度は後追いで作ることにしました。