“納品のない受託開発”とは何か？―ソニックガーデン代表 倉貫義人氏が全貌を語り尽くす。

矛盾にしか思えない、「納品のない受託開発」というビジネスモデル。

納品をしない受託開発というビジネスが存在するらしい。一見すると、まったく相反する事柄が並んでいる。「食べられない、食物」「麺類のない、ラーメン屋」とほぼ同義だ。

この共存しえない二つの所作で、ビジネスを成立させているソニックガーデン。即日の対応が難しいほど、スタートアップ界隈から支持を集めているという。

ソニックガーデンは、エンジニア7名の小さな組織。代表を務める倉貫氏は、新卒で大手SIerに入社し、エンジニア、営業、マネージャーの経験を経て、社内ベンチャーを立ち上げた。クラウド型の社内SNSを製品化し、MBOで独立。自社サービスで充分なビジネスを確立するが、更なる発展と未来の企業継続に向けて受託開発を検討。SIerで手掛けていた受託開発とは違う形を模索した結果、納品のない受託開発に行きつく。

果たして本当に、納品をしない受託開発というものが存在し得るのだろうか。CEOの倉貫氏に聞いてみた。

「納品のない受託開発」を機能させる、バーチャルCTOの存在。

― そもそも「納品のない受託開発」とは何ですか。矛盾する言葉が並んでいますが、結局は受託なのでは？と思ってしまうのですが。

最初は、その矛盾点に興味を持っていただくことが多いです。私たちのビジネスの顧客は、新規事業の立ち上げやスタートアップが多い。中でも、新しいアイデアはあるけど、エンジニアがいないという会社です。この会社に対して私たちが、エンジニアのやる部分を全部まるっと引き受けます。ビジネスの検討から、ソフトウェアは何が必要で何が不要か、実際に手を動かして開発をして、運用することまですべてです。お客さんには、ビジネスのマーケティングだけに集中していただく。

これを、月々定額で引き受けます。お客さんに完成品を渡すことなく、ずっと面倒をみる。オーダーメイドだけど、渡さない。よくある「完成までに何カ月で、幾らかかりますよ」っていうのをなくしました。月々幾らがずっと続くんです。この契約は、顧客が倒産するか事業をやめるまで継続することが可能。そういう意味で、納品をしない受託開発なんです。

― なるほど。言葉の意味と仕組みはわかりました。通常の受託開発と比較して、顧客にはどのようなメリットがあるのでしょうか。

「納品のない受託開発」を導入することは、優秀なCTOを雇い入れることと同義です。CTOの役割といえば、ビジネスの検討から設計、運用まですべて。自社で採用しようとしても、優秀なCTOを見つけるのは至難の業です。ですが、当社には、各分野に精通したエンジニアだけが揃っている。私たちがCTOのいない会社に対して、派遣はせずに、バーチャルCTOという形でサービスを提供するわけです。

我々はクラウドをつかったアジャイル開発を行なうため、初期投資を抑えた早期スタートが可能になります。回収を早くすることで、利益に転化するのも早い。さらに作って終わりではなく、常にマーケットに即した最新の状態にアップデートし続けます。

つまり、スモールスタートが可能で、かつスケールアウトもしやすいわけです。また、当社として、永続的にお付き合いをすることが収益になるので、何としても、お客さんのビジネスを成功させたいと思っているのもプラスでしょう。納品して終わりのスタイルだと、お客さんがどうなろうと関係ないですからね。

そして最大のメリットは、これまでの受託開発で生じていた問題点がないという部分ですね。

リスクだらけの、誰も幸せにならない従来モデル。

― ズバリ、倉貫さんの考える受託開発の問題点とはどこにあるのでしょうか。

誰も喜んでいない、という事実ですね。この誰もという部分には、お客さんはもちろん、ベンダーやエンドユーザー、そしてエンジニアが含まれます。

受託開発の進め方といえば、まずは要件定義から入りますよね。でも、要件定義なんて、誰がやりたがっているのか。少なくとも、お客さんにとっては、どうでもいい物のハズなんです。求めているのは、ソフトウェアを使ってビジネスをすること。要件定義をするのは、ベンダーの都合でしかないんです。「こういうシステムを、幾らで、いついつまでにつくりますよ」と、発注時点ですべてを決めるためのもの。結局リスクヘッジでしかない。

― 単純に考えると、いつまでにどんなシステムがいくらで納品してもらえるのかがわかることは、発注側にしてもありがたいように思えるのですが。

ソフトウェアをつくるという行為で完結するのであれば、そうかもしれませんね。でもソフトウェアというものは、出来上がった時点では資産じゃないんです。資産どころかマイナス。エンドユーザーにサービスを提供して、売上が固定費や変動費を上回ってから、損益分岐点を超えてからしか利益にならない。受託開発の進め方では、利益が見込めるころ、せっかくつくったソフトウェアは過去のものになっているわけです。これだけ変化が激しい時代ですし、先のことを見通すなんて不可能。受注段階ですべての機能を決めてしまうなんて、リスクでしかないんですよ。

SIerビジネスが成立する不思議。

― それを解決するためには、ウォーターフォールではなくアジャイルでの開発という話になりそうです。そうすれば、倉貫さんのおっしゃった課題は解決するように思うのですが。

確かにそうなのですが、困難です。ずっと考え続けて、あるとき答えが見つかりました。なぜウォーターフォールになるのか。これはSIerのビジネスそのものを否定することにもなりかねないのですが…。

受託開発を行なうために、要件定義を行なうのは先ほど述べた通りです。なぜならベンダーとしては、何をつくるかを決めて、それに必要な人員を確保する。エンジニアを派遣や人月で考えて、リスクをきちんとヘッジするならば、スタートとゴールが決まっていることが条件となるわけです。

でも私は、アジャイル開発の本質は「当初に想定した機能を全部つくらないこと」だと考えています。そうすることによって、変化に柔軟な対応をしながら開発できる。しかしSIerの発想でいくと、ウォーターフォールこそが現実的で最適の手段だから、ずっとその仕組みでビジネスをしているんです。

このモデルでうまくいけばいいけど、実はお客さんは満足していない。更に不幸なことに、ベンダーも満足していない。なぜかというと、やると決めたものがあるから、開発がスタートしたら、途中でいらない機能・追加したい機能が出ても、決めた通りに進めなくてはならないんです。お客さんもエンジニアも、変更することが正しいと思っていても。

だれも納得していないものをつくらなきゃいけないって、すごくモチベーション下がりますよね。かといって、決めたことをやらないで別の機能を追加しようとしても、契約したのでやってもらわなきゃ困る、と。じゃあ、追加はどうするか聞くと、やったほうがいいけどお金がないので…。「そちらの持ち出しでやってくれるなら」なんて言われますが、やるわけがないじゃないですか（笑）結果、誰が一番損をするかというと、ひどいシステムを使うエンドユーザーなんです。

― 発注側としてビジネスを成功させるためには、余計なお金がかかる、と。

そうです。直すためには、仕様変更。見積もりが発生して追加費用が発生します。最初からすべてを決めたら安くできるかというと、結局、追加・追加で高くつく。

ベンダーはベンダーで、ビジネス上どう利益を出すかというと、売上に対して人のコストを下げるしかないわけです。顧客の要望をすべて飲んでいたら、利益を圧迫するだけ。極端な話、お客さんに対しては何もしないように、言わないようにする。最初の提案では、リスクを伝えてバッファをとるのが普通です。そのリスクが起きないようにするという利ザヤで商売していますからね。けど、結局は圧迫されて、ギリギリの利益か赤字というプロジェクトが増える。

結果として、お客さんは嬉しくない、ベンダーも嬉しくない、エンドユーザーも嬉しくないという開発が行なわれることが往々にしてあるんです。

（つづく）
▼ソニックガーデンCEOの倉貫義人氏へのインタビュー第2弾
プログラマは職人、力なければ淘汰されて然るべき―ソニックガーデン倉貫氏が問う、プログラマの覚悟。

［取材］松尾彰大　[文] 城戸内大介

編集 ＝ 松尾彰大