受託開発と自社プロダクトの違い
受託開発で経験を積んだ人が自社プロダクトの担当になると、最初の数か月でつまずくことがあります。逆も同じです。プロダクト畑の人が受託に入ると、進め方が噛み合いません。
能力の問題ではありません。ゴールの形そのものが違うからです。この違いを言葉にしておくと、どちらに移っても立ち上がりが早くなります。
■ 一番大きな違いは「終わり方」
受託開発には、終わりがあります。納品して、検収が通れば、そのプロジェクトは完了です。だから計画も、その日に向かって収束する形になります。
自社プロダクトには、終わりがありません。リリースしても続きます。つまり、「完成」という目標が存在しない。ここが一番の違いです。
この違いは、日々の判断に効いてきます。
場面 | 受託開発での判断 | 自社プロダクトでの判断 |
|---|---|---|
細かい不具合が残った | 検収に影響するかで判断 | 使う人が困るかで判断 |
後回しにしたい機能がある | 契約範囲なら外せない | 外してよい。次に回せる |
作り方が雑になってきた | 納品まで持てばよい場合も | 自分たちが後で苦しむ |
■ 受託の人がプロダクトで戸惑うこと
受託の経験者がプロダクト側に来ると、よくこう言います。「誰も決めてくれない」。
受託では、迷ったときに顧客に聞けば答えが返ってきます。プロダクトでは、聞く相手が自分たちです。営業は売りたい機能を言い、サポートは問い合わせの多い機能を言い、経営は数字が動く機能を言う。どれも正しく、誰も決めません。
ここで必要になるのが、やらないことを決める仕事です。
今回のリリースで動かしたい数字を1つだけ決める
それに効かない要望は、断るのではなく「今回は入れない」と置く
置いた理由を書いて残す（後で必ず聞かれます）
3つ目を省くと、同じ議論が毎月繰り返されます。
■ プロダクトの人が受託で戸惑うこと
逆のパターンもあります。プロダクト側の人が受託に入ると、「なぜこんなに手続きが多いのか」と感じます。
理由は単純で、お金と約束が紐づいているからです。範囲を変えると金額が変わり、金額が変わると契約を直す必要があります。だから、気軽に「こっちのほうが良さそうなので変えました」ができません。
ここで身につけるべきは、変更を止める技術ではなく、変更を正しく通す技術です。
やりがちなこと | 受託で通るやり方 |
|---|---|
良い案なので黙って直す | 変更点と影響を書いて、判断してもらう |
口頭で合意して進める | 議事録に残し、相手の確認を取る |
期日に間に合うから大丈夫と考える | 間に合っても、範囲外なら合意が要る |
■ 共通して効くこと
違いを並べましたが、どちらでも効く原則はあります。
決めたことを、決めた場所に残す（受託では契約の証拠、プロダクトでは判断の履歴になる）
今なにを優先しているかを、1行で言えるようにする
やらないと決めたことも記録する
この3つは、どちらの現場でもそのまま使えます。
■ まとめ
受託開発は約束を守る仕事、自社プロダクトは何をやらないかを決める仕事です。求められる判断の種類が違うだけで、どちらが上ということはありません。
もし今、どちらかから、どちらかに移ろうとしているなら、この違いを一度紙に書いてみてください。戸惑いの正体が見えて、動きやすくなります。