遅ればせながら書籍『「納品」をなくせばうまくいく』を読んだので考えた妄想について書く。Kindle版を割と前にセールで購入してたのだが、いろいろと他の本を読むのに忙しくて後回しになってしまった。電子積読は難しい（あと4冊くらい積んでるけど）
さて本書はソフトウェア開発のビジネスモデルとして既存の開発会社とは一線を画す「納品のない受託開発」を掲げるソニックガーデンの倉貫さんの本である。考え方は倉貫さんのブログでもたびたび説明されているけど、一気に読めるというところがポイントかと。ただ、まとめて読んだらいろいろ気になる点も出てきた。
ブランディングは重要
そもそも論なのだけども、ソニックガーデンさんは実際は「受託開発」をしていない（と思われる）。だから、言うまでもなく納品なんて概念も無い。でも、ブランディングのためにあえて「納品のない受託開発」と呼ぶことに大きな意味があるのだと思ってる。
- 基本的には「受託開発のようにオーダーメードできるオプションつきサービス委託契約」なんだと思う。もしくは「開発基盤一式のクラウドサービス利用契約＋オフサイトコンサルティング」かもしれない。
- ただ、これをストレートに表現すると差別化しにくいというか、わかりにくいのであえて「受託開発」というキーワードを使用しているのだと思う。
- ターゲットが「オーダーメード開発が必要だけど資金やリソース的に開発発注できない（スタートアップなどの）企業」に絞っているというところもポイント。
関連していろいろ調べてたらこんなブログ記事を発見。興味深い。
何と競合しているのかについて考えてみる
（実際は違うのかもしれないけど）「納品のない受託開発」は受託開発じゃないとすると、本当に競合するのは何なのかについてちょっと考えてみた。
- 既存のベンダの一括請負ビジネスモデルとは競合していないことは本書にも書かれている通り。ただ、住み分けているのかというとちょっと違う気もする（土俵が違う）。むしろ、通常のコンサルティングビジネスや、技術者派遣とは競合しているんじゃないかと思う。
一括請負を求める世界とは明らかにマーケットが違うため、私たちが「納品のない受託開発」について説明を続ければ続けるほど、その解決方法にマッチしない人は集まってこないし、そのニーズにフィットする方は顧客になってくれます。私たちの場合、マーケティングはしても営業はしないため、よりその傾向が強く、これまでのような一括請負の受託開発をする会社とは、うまく住みわけができているように思います。
- 「納品」をなくせばうまくいく 7章 「納品のない受託開発」をオープン化する / 一括請負と競合はしない
- 受託開発の枠を外してみると、一種のPaaSビジネスのような気がする。例えば、Salesforceのようなプラットフォームとそれを用いたコンサルティング、運用サービスを提供している事業者がいればそこと競合するのではないだろうか。
- 「納品のない受託開発」はAWS推しのようだけれども、別にどのクラウドサービスを利用するかの問題はないはず。差別化、特化することでの差別化、費用面などを含めて絞り込むことが重要なんだと思っている。
- スケールするプラットフォームをベースにして、スケールするサービスを目指さないという点も重要なポイントだろう。
気になったこと
あと本書を読んで、今後以下のようなケースが悩ましいんだろうなぁ、などと考えたりもした。
- 顧客企業が、技芸で凌げる以上の成長、今風に言えばグロースしてしまった場合にどうするか？
- 技術的負債をあえて負って、質より量を選択しなければならない局面など
- 顧客企業がMAされるようなケース
- 割とハードコアな文化の企業に買収されて、一括受託的な所作を求められた場合
- ブラックスワン的なトラブルが発生した場合
- ディフェンシブな開発だろうとオフェンシブな開発だろうとトラブルは起こり得るわけで、体力勝負となるリスクは常にあるはず
- 個人情報絡みとか、決済サービス絡みとか。まあ、この領域はうまく避けてるのかもしれないけれど
- ソニックガーデンさん自身がピボットを迫られるような魅力的なサービスを発明してしまった場合
- 自社都合でサービスクローズする必要に迫られたらどうするんだろうか
いろいろと妄想を書いたけど、ソフトウェア開発の方法として多様性があることは良いことだと思っているし応援したい。
