「納品」をなくせばうまくいく

ソフトウェア業界の受託開発といえば、顧客から注文を受けて開発を行い、できあがった製品を「納品」することで対価を受け取るビジネスなのに、「納品がない」ってどういうこと???

そうだよね、確かにこの受託開発の常識からすれば「納品のない受託開発」という言葉はずいぶんと不思議だよね。

なんで、あえて「納品」をなくしたと思う?

うーーーん。。。”納品すること”で何か都合の悪いことがあったとか?

なかなかいい線いってるね。ではなぜそんなことをやっているのか、そしてなぜそんなことが実現できるのか?その秘密について書かれているのが「納品をなくせばうまくいく」なので内容を紹介していくね。

読んでもらいたい方

  • ソフトウェアを受注する立場の方
  • ソフトウェアを発注する立場の方
  • ソフトウェアを導入する企業の経営者
  • 新しいビジネスモデルやワークスタイルを検討する起業家やスタートアップの方

当記事の目次

  • 「受託開発」の問題点
  • 「受託開発」の問題点の根っこは納品
  • 「納品のない受託開発」とは?
  • 「納品のない受託開発」をなぜ実現できるのか?

受託開発の問題点

①最初につくるものを決めてから作る

一括請負契約ではまず最初にどのうようなソフトウェアにするのか機能を決める必要があります。それがきまらないと開発会社としても開発要員のアサインもできないし、見積りも出せないので最初に何を作るのかをしっかりと決める必要があります。しかしながら、それらが決まって開発を始めてサービスが始まるまでに市場環境や顧客の業務が変わり、実際の業務とソフトウェアの機能でアンマッチを引き起こす可能性もあります。しかし受託した開発会社は機能が変わるとそれに対応するとなると設計を見直すなど想定外の工数(≒コスト)がかかるため受け入れることはできません。

②リスクを見越した見積りにより高額になる

これは①で述べたような現象は必ずと言っていいほど発生するのが開発会社側も経験値としてわかっているので、見積りの段階で「こんなことを言ってくるかもしれない」や「なんかあった時のために」という理由で”余分な工数(≒金額)”を見積りに入れてきます。ただしもちろん見積書にはそんなこと書けませんから、各工程に按分するなどして見積りに計上するわけです。(もちろんその金額をどれくらいにするかというのは各社の考えや案件の難易度にもよって変わってきます)

③ディフェンシブな開発

これは実際に開発会社で働いているエンジニアの方ならはがゆい想いをして実感されているかもしれませんが、いったん機能が合意され開発がはじまってしまうと”納期”と”金額”は決まってしまっているので、利益を出すには工数を低くするしか方法がありません。したがって開発途中での仕様変更(仕様変更の依頼が顧客からあると最終的に開発しないと判断された場合でもそのための調査や見積りに工数を使うことになります)などは予算オーバーの原因になるためプロジェクトマネージャーはなるべく仕様変更が起きないように努めるようになります。ただし実際には最初に決めた要件に従うよりも現場の反応を見て臨機応変に直していく方がよいでしょう。エンジニアとしても発注側としてもビジネス要件に対して柔軟に対応したいが、納期・コストの制約のため柔軟な対応ができないのは不本意なはずです。

※このほかにも書籍中には数多くの問題が書かれていますがここでは割愛します※

「受託開発」の問題点の根っこは納品

「納品」をなくすことこそがこれまでの受託開発で起きていた問題の解決策だと考えました。

1章 常識を覆す「納品のない受託開発」とは より

先述した問題に対して筆者たちが考えたのは上記の仮設でした。

納品(≒要件どおりに納期までに納品する契約)があるから、現実的でない将来変わる可能性のある要件を定義しなければならないし見積りも必要になる。見積りを出すにあたっては赤字にならないように余分な工数を積む必要もある。問題の根っこは「納品」である。

ここまでで、現在主流の一括請負契約(=受託開発)の問題点やそれに対する原因(仮設)が「納品」であることはわかったけど、でも納品をなくして見積りもしないで顧客は納得するのかな~?

うん、筆者が経営する会社では工夫に工夫をこらしてこれらのことを実践しているんだよ。具体的には”月額定額”の料金にすることで実現したんだよ。

へー

それでは早速みていこう!

「納品のない受託開発」とは?

シンプルに言うと、”月額定額の料金体系(毎月の決まった金額の中で「できる範囲」で精いっぱいの「開発と運用」を行う)です。

これによる効果は以下の3つです

①わかりもしない要件をすべて決める”ことをしなくてよい。システムの全体像や最終的な方向性は時間をかけて発注側と受注側で決めて共有しますが、そのあとは部分的に要件や機能を決めていきます。

②見積りをしなくてよい。定額なので見積りを行う必要がいため見積りの時間そのものもいらないですし、余分な工数をのせる必要もありません。※著書が代表をつとめるソニックガーデンさんが営業もいないらしいです

③ビジネス要件の変化に合わせた柔軟な対応をすることができる。もちろん最初からきまった要件がないのでいくらでも機能の追加や変更は可能です。ただし定額の範囲内ではもちろんやれることは限られますのでやることの優先順位付けは必要になり提供できる時期も変わってくるということになります。

なぜ、「納品のない受託開発」をできるのか?

なるほど。でも「できる範囲」ってお客様は契約段階で納得してくれるのかなー?

エンジニアの能力によってできる範囲も違うしクレームにならないのかな?

これはSierで20年近くSEと営業を経験した私が思ったことなのですが・・・「できる範囲で精いっぱいの開発と運用」の”できる範囲”というのに引っ掛かりました。お客様の立場からすると月額で毎月コストは発生するけど納品は約束されておらず、しかもできる範囲ってどのくらい?と感じるのではないでしょうか?

ソニックガーデンさんではそこもちゃんと顧客が納得して契約いただけるような仕組みになっているようです。どうなっているのか私が思うに以下の2点が大きいと思います。

①採用に時間をかける:これは他の会社とまるっきり違う採用方法を取られています。簡単に申しますと、通常みられる履歴書・経歴書プラス2~3度の面接ではなく、コーディングや考え方のテストがあったり入社前に一緒に働くなど本当の実力や働くことに対する姿勢などがわかる採用の仕組みになっています。これにより悪い言い方ですが採用したけど外れだった!を防いでいられるようです。また入社後もメイン担当として顧客をもつまでは先輩社員と一緒に覚えるなどOJTにも力を入れ得られています。

②お試し期間:お客様と正式に契約をする前にお試し期間として無償で有償期間と同じように対応されているようです(※書籍には期間は1か月間とありますが出版当時であり現在の最新の状況はわかりかねます。ご了承ください)

上記のとおり徹底した採用、採用後の教育、正式契約の前のお試し期間 にて顧客も安心して契約をできるような仕組みを実現されています。

最後に

私が新卒でSierに入社してから、いわゆる受託開発というものはこういうものなんだといういわばあきらめというか当たり前のものととらえていましたが、この書籍を読んでなんだか希望が広がり一気に最後まで読み進めました。私のブログでは抜粋して内容を紹介させていただきましたが、本書には納品のない受託開発の実際の契約やプロジェクトの進め方やエンジニアの働き方に対する考えなども書かれています。現場のSEの方やもっと上の立場で社の方針を決める立場の方、Sierへの委託を行う立場の方にぜひおすすめしたい書籍です。