#192 「受託開発」から「プロダクト開発」への移行の難しさ
こんにちは。ITベンチャーエンジニアのこへいです。
「受託開発」と「プロダクト開発」はいずれもシステムを開発することに関しては同じですが、これらは「目的」において大きな違いがあります。
私が所属する会社は受託開発を得意としており、ある業界の大手企業の9割に顧客になっていただけています。
大手の顧客はそれぞれが強いこだわりを持っており、オーダーメイドで開発する受託開発の相性が非常に良いです。
近年、多くの大手企業のシステムを開発してきて蓄積した業界特有の課題やニーズなどの知見をベースにした中小企業向けのプロダクトの開発も始めました。
中小企業の顧客は大手と比べると特有の強いこだわりは比較的少なく、フルオーダーメイドで開発するよりも安価なプロダクトを導入し、必要に応じて個別のカスタマイズをしていく方が相性が良いです。
プロダクトは順調に導入先が増えるものの、慣れないプロダクト開発によって課題が山積みです。
というのも、受託開発とプロダクト開発には大きな隔たりがあるため、受託開発からプロダクト開発へとパラダイムシフトを起こしていかなければならないはずが、受託開発の延長のような形で進行してしまっているがために課題が生まれています。
ということで今回は、受託開発のプロダクト開発の「目的」の違い、プロダクト開発への移行の難しさについて考えます。
〇受託開発とプロダクト開発の違いをざっくりと
受託開発とプロダクト開発の違いをざっくりと表すと、それぞれに以下のような特徴があります。
受託開発の特徴
1つの顧客と向き合うため、1対1のコミュニケーションである
顧客ごとのシステムを開発する
顧客の課題を解決する機能開発（アウトプット）に対して対価を得る
ちなみに弊社は納品したらおしまいではなく、システム開発後の運用も対応するため、納品したら終わりではありません。
プロダクト開発
1対多顧客のコミュニケーション
1つのシステムを開発する
プロダクトを利用することで得られる価値に対して対価を得る
〇受託開発は作る。プロダクト開発は使う。
受託開発は顧客に対してシステムを作ります。
要件定義、設計、開発、テスト、納品までを顧客と合意したスケジュールで対応します。
作ることに責任を負う一方で、作ったシステムを使った顧客のビジネスの成果に責任を負いません。
そのため、沢山作ることにインセンティブがあります。
一方で、プロダクト開発は作ったシステムを使ってもらうことで、顧客のビジネスで成果をあげる必要があります。
プロダクト開発も先に作ることになるのですが、作ることに対して費用はいただけません。
代わりに顧客からはシステムの利用料をいただきます。システムを使って成果が出なければ解約されるため、開発コストを回収し売り上げを上げるためにはより多くの顧客により長く利用していただく必要があります。
また、利用顧客の要望に対して新しい機能を作っても費用はいただけません。（弊社のプロダクトは費用をいただき個別対応をすることもあります。）
そのため、使ってもらうことにインセンティブがあります。
顧客の要望に対して新たな機能を作るのでなく、プロダクトを使った解決策を提案し使い続けていただくことにインセンティブが働くはずです。
しかし、長く受託開発をやってきて組織は不思議とそのインセンティブが働きません。
受託開発のノリで個別要望による機能をプロダクトに実装し、その開発費をいただこうとしてしまいます。
受託開発と同様に開発費で稼げるのであればいいのでしょうか？
いえ。だめです。
受託開発のように、個別の顧客ごとにシステムを作るのとは違い、プロダクト開発は一つのシステムを複数の顧客に提供するため、特定顧客の個別機能が増えるほどに、システムの複雑性が増します。
プロダクトの運用コストが増え、プロダクトの成長のための機能追加の難易度が跳ね上がります。
プロダクトは作ることに対価を得られないだけでなく、作ることがコストになるということを理解しなければ、いつか痛い目にあってしまいます。
〇パラダイムシフトを起こすには成果の指標を変える
では、受託開発の「沢山作る」という考え方から、プロダクト開発の「作らずに使う」という考え方へとパラダイムシフトを起こすにはどうすればよいのでしょうか？
成果の指標をアウトプット量からアウトカム量にシフトすることが有用です。
機能を作る量で評価するのでなく、機能を使って解決した顧客の課題の量を評価するのです。
機能を使って課題解決をした場合は売り上げが作れないのでは？という声があがります。
機能を作らなくても、プロダクトの導入先を増やすことや、機能の使い方と顧客の業務改善の提案をしてコンサルフィーをいただくことも可能です。
評価指標を変え、ビジネスモデルも変えていくことで、パラダイムシフトを起こせるはずです。
これが難しいのですが。
受託開発とプロダクト開発のどちらが良いという話ではありません。
それぞれ目的が異なるため、その目的を達成するための適切な手段もことなります。
それを理解せずに受託開発の成功体験をプロダクト開発に持ち込むと痛い目を見るという話です。
ということで今回は、受託開発のプロダクト開発の「目的」の違いから、プロダクト開発への移行時に陥りがちな問題、その解決策についてお伝えしました。
開発組織をつくる際の手助けになれば幸いです。
最後までお読みいただきありがとうございました。