「もう受託は嫌、自社SaaSをやりたい」という相談が増えるワケ
コメント
選択しているユーザー
受託かSaaSかというお金のもらい方の話というよりは、顧客とベンダーの関係性が特定期間で区切りがつくのか、利用する限りは継続するのか、リレーションのあり方や力関係の話の気もしますね。いつ契約切られるかわからない、という形だと発注側にモノも言えなくなってしまいます。
受託開発が嫌というより(ある意味)顧客の言うがままに振り回されるのに疲れてしまった、ということがタイトルにあるコメントの本質ではないかなと感じました。
企業課題についての上流設計からコンサルティング的にはいりこみ、単なる下流の開発委託先ではないパートナーとしての関係性が築けるようであれば別に契約そのものは受託であってもいい気がします。
SaaSも別に魔法ではないので、安売りして儲からないけど中途半端にお客さんがついて辞めるにやめられない、みたいなデッドロックも全然あり得ると思いますし。
自社プロダクトを開発するケイパビリティと上流工程に入り込むケイパビリティ、どっちが獲得しやすいのかはわかりませんが…
注目のコメント
解約可能な定期購入型のソフトウェアサービスであるSaaSは、利用者と提供者の利害が一致しやすい、美しいビジネスモデルです。
反対に、言われた通りに作ったのに、結局は役に立たないものを作ってしまっていると感じる受託型のシステム開発は、たとえ儲かるとしてもストレスは高いはずです。
これまで受託型の開発会社が、これからSaaSへとビジネス形態の転換を目指すという動機には頷けます。
ただ、「何をつくるのか」を導ける能力と「どう作るのか」の能力は、全く異なります。
現時点で、発注者の言われた通りに作って、役に立たないものができあがっているとすると、それは「何をつくるのか」を考える能力は自社には存在しないと考えるのが自然ですので、転換は簡単には実現できないことも覚悟しておく必要があります。自社サービスは、受託と比べてハイリスクハイリターン。
受託であれば、受託した業務に対して対価がもらえる(もちろん稼働率とか、炎上プロジェクトのリスクはあるが…)。自社サービスは、開発コストをかけても売れなければ意味がない。
また記事にあるように、組織カルチャー的な部分はあるだろう。営業組織も混在すること、要件に対してのソリューション提供ではなく、要件を自ら定義しにいくこと(握りにいく、ではないので、出してみないと成否が分からない)。
自分はエンジニアではないが、でも自社サービスだからこそ楽しいし、執着できる・やり続けられるということがとても好き。