受託開発でPjMやリーダーを経験してきて、SaaS企業に転職（or 副業で参画）した人に向けて書いています。「マネジメントならできる」と思って入ったら全然違った、という実体験ベースの話です。
はじめに
自分は長いこと受託開発畑にいたんですけど、あるタイミングからスタートアップに関わるようになりました。
受託時代にPjM（プロジェクトマネジメント）はそこそこ経験していたので、正直PdM（プロダクトマネジメント）も似たようなもんだろうと思ってたんですよね。QCDを管理して、スケジュール引いて、関係者調整して…みたいな。
全然違いました。
受託開発で染み付いた「お客さんの要望に応えるのが正義」という感覚、これを自社開発にそのまま持ち込むと結構キケンなんですよね。しかも受託開発が長かった人ほど、この罠に気づきにくいと思っています。
なぜかというと、受託ではそれが正解だったから。成功体験がそのままバグになるんです。
受託と自社開発、何が違うの？
受託開発のメンタリティ
- お客さんが「これ作って」と言ったら作る
- 要件通りに作れば納品完了、お金がもらえる
- 「お客さんの要望を叶えるエンジニア＝優秀」
これ、受託では100%正しいと思います。
じゃあ自社開発（SaaS）は？
- ターゲットとなるお客様に広く使われる機能を作る
- 特定のお客さん1社のためじゃなく、市場全体を見る
- 「この機能はA社が欲しいと言っている」だけでは作る理由にならない
ここまでは、受託から来た人でも意外と理解していると思います。
「SaaSなんだから汎用的に作らないとね」くらいの認識はある。
問題はこの先なんですよね。 客層の違いは分かっていても、マネタイズの構造が全然違うことに気づいていない人が多い気がします。
マネタイズの構造が根本的に違う
受託開発って、1機能作るだけで何十万〜何百万をもらえるんですよね。しかも1社から。作った時点でペイする。だから「お客さんが欲しいと言っている＝作る」で正解なんです。
SaaSはそうはいかない。
1機能作るのに同じく何十万〜何百万かかるとして、月額1万円のSaaSだったら、その機能があることで何十社〜何百社が新規契約してくれるのか？ ってことなんですよ。もしくは、その機能がないことで解約されてしまう顧客がどれだけいるのか。
受託： 機能の開発費 ≦ その顧客からの受注額 → 作ればペイする
SaaS： 機能の開発費 ≦ 月額利用料 × 獲得（or 維持）ユーザー数 → 作っただけじゃペイするか分からない
つまりSaaSでは、「作る」と決めた瞬間に投資判断をしていることになります。受託脳のまま「お客さんが欲しいって言ってるから作ろう」をやると、回収の見込みがない機能をどんどん積み上げることになる。
これが本当にヤバいポイントだと思っていて、受託の感覚だと「作れば作るほど売上が上がる」んですけど、SaaSでは「作れば作るほど赤字が膨らむ」可能性がある。
「サクッと作れるからよくない？」の罠
エンジニアあるあるなんですけど、「ペイしなくてもすぐ終わるからよくない？やりたいし隙間時間でサクッと実装できるし」ってパターン。
これ、受託だったら確かにそれでいいんですよ。納品して終わりだから。
でもSaaSの場合、作った後のコストが永遠に積み上がるんですよね。
- 問い合わせ対応コスト — 「この機能の使い方がわからない」がCSに来る
- ライブラリのアップデート対応 — 依存しているライブラリに脆弱性が出たら対応が必要
- 除却できない問題 — ごく少数のお客さんが使い始めちゃうと、もう消せない
受託は「作って納品したら終わり」だけど、SaaSは「作った瞬間から維持コストが発生する」。しかもそのコストは機能が存在する限りずっとかかり続ける。
受託： 開発コスト → 納品 → 終わり
SaaS： 開発コスト → リリース → 問い合わせ対応 → メンテナンス → アップデート対応 → ...（∞）
「サクッと作れる」のは開発コストだけの話で、トータルコストで見るとまったくサクッとじゃないんですよ。
なぜ誰も止められないのか — 評価の問題
ここまで読んで「いや、そんなの分かってるよ」と思った人もいるかもしれません。でも実際にはこの構造を分かっていても止められない組織が多い。
なぜかというと、エンジニアの評価がアウトプット偏重だからだと思っています。
- 「今期はこの機能とこの機能をリリースしました」→ 評価される
- 「今期はこの要望を検討した結果、作らない判断をしました」→ 評価されにくい
受託だとアウトプット＝売上なので、たくさん作った人が評価されるのは当然なんですよね。でもSaaSでそれをやると、「たくさん作ったけど誰も使っていない機能の山」ができあがる。
本来は「作らない判断をして、その分のリソースをもっと重要な機能に振り向けた」という**アウトカム（成果）**で評価されるべきなんですけど、アウトカムって計測しにくいし見えにくい。
アウトプット評価（受託向き）： 何を作ったか？いくつ作ったか？
アウトカム評価（SaaS向き）： 作ったものがどんな成果を生んだか？
結果として、エンジニアは「作った方が評価される」と思って作るし、マネージャーも「作らせた方が仕事してる感がある」と思って止めない。誰も悪意はないのに、組織全体で不要な機能を量産するサイクルが回ってしまう。
これ、全部「プロダクトマネジメント不在」の症状です
ここまで書いてきたことを振り返ると：
- お客さんに言われたから作る
- サクッとできるから作る
- 作った量で評価される
全部「何を作るか」の話ばかりで、「何を作らないか」を誰も決めていないんですよね。
受託開発にはこの問題が発生しにくい。お客さんが「これを作ってください」と言って、お金を払ってくれる。作るものは最初から決まっている。だから「作らない判断」をする役割がそもそも必要ない。
でもSaaSでは、作れるものは無限にあるのにリソースは有限です。「何を作るか」と同じくらい「何を作らないか」の判断が重要になる。
この「作らない判断」をする役割が、プロダクトマネジメントです。
受託： お客さんが作るものを決める → 作る → 納品
SaaS： ??? が作るものを決める → 作る → 運用し続ける
この「???」を埋める人がいないと、セールスが聞いてきた要望がそのまま開発に流れる。エンジニアが面白そうだと思ったものを勝手に作る。誰も止めないし、止める権限を持った人がいない。
自分が受託からSaaSの世界に入って一番驚いたのがここで、受託では当たり前に存在していた「発注者」という存在がSaaSにはいないんですよ。お客さんは月額料金を払ってくれているけど、個別の機能を発注しているわけじゃない。じゃあ誰が「これを作る・作らない」を決めるのか。
その答えがプロダクトマネジメントであり、PdM（プロダクトマネージャー）という役割なんだと思います。
スタートアップだと社長がPdMをやりがち問題
初期スタートアップだと、PdMの役割を社長が兼ねていることが多いです。これ自体は全然悪いことじゃないんですけど、実際に現場で見てきた感覚だと「社長の思いつきで開発が始まる」ケースが結構多い。
「これ面白くない？作ろうよ」が社長から降ってきて、それがそのまま開発に流れる。社長＝発注者みたいな構図になるんですけど、受託と違って社長はお金を払ってくれるお客さんじゃなくて、あくまで仮説を持っている人なんですよね。その仮説が正しいかどうかの検証なしに作り始めてしまう。
自分はまさにこういう現場に入って、最初は受託脳で「社長が言ってるならやりましょう」と動いてしまっていました。受託の感覚だと、発注者の意向に沿うのが正解だから。
でも実は、ここで「本当にそれ今作るべきですか？」と問える人がいるだけで、開発の方向性がまったく変わる。受託から来たエンジニアがこの観点を持ち込めたら、それだけでチームにとってめちゃくちゃ価値があると思っています。
PjMとPdMは全然違った
今ならPjMとPdMが全然違うものだと分かります。
PjM：「決まったものを、どうやって作るか」を管理する
PdM：「そもそも何を作るか（作らないか）」を決める
受託開発ではPjMがいれば回る。作るものはお客さんが決めてくれるから。でもSaaSではPjMだけでは足りなくて、その手前の「作るかどうか」を判断するPdMが必要になる。自分はここを完全に見誤っていました。
まとめ
受託開発の経験は自社開発でも間違いなく活きます。技術力も、お客さんとのコミュニケーション力も、プロジェクトを回す力も。
ただ、自分が一番つまずいたのは 「お客さんが言ったから作る」というメンタリティをそのまま持ち込んでしまったことでした。
SaaSでは「作る」こと自体が投資判断で、作った後も維持コストがかかり続けて、作った量で評価される組織文化があると誰も止められなくなる。自分はそれに気づくまでに結構時間がかかりました。
振り返ってみると、受託から来た自分に最初に必要だったのは、コードを書くことでも新しいフレームワークを覚えることでもなくて、「プロダクトマネジメントってなんだ？」を知ることだったなと思っています。
周りに直接「それ本当に必要ですか？」と言えるかどうかは、状況によっていろいろだと思います。でも少なくとも、自分の中で「この機能、本当にいる？」と一回立ち止まる習慣を持つこと。これだけで全然違うと思っています。
偉そうに書きましたが、自分もまだまだ模索中です。
参考書籍
この記事で書いたような「作ることが目的化してしまう」問題について、体系的に学びたい方にはこちらがおすすめです。
-
「プロダクトマネジメント ビルドトラップを避け顧客に価値を届ける」（メリッサ・ペリ著）
- まさにこの記事で書いた話がそのまま「ビルドトラップ」として解説されています。受託から来た人が最初に読む一冊としてかなり良いと思います。
-
「INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント」（マーティ・ケーガン著）
- PdMという役割が何をする人なのか、全体像を掴むならこちら。