「自社開発」と書かれた求人を見つけても、それだけでSaaSのプロダクト開発職とは判断できません。顧客から受託したシステムを自社内で開発する募集もあれば、自社が提供するサービスを継続して育てる募集もあるからです。

SaaSは、業務用アプリケーションやコミュニケーション機能をサービスとして提供する形態です。転職先を選ぶときは、技術スタックより先に「誰が製品の方向を決めるか」「リリース後を誰が支えるか」を見ます。この2点が分かれば、ソフトウェア・通信業界の大分類からSaaSへ進むべきか、顧客ごとの構築を担うSIerへ進むべきかを切り分けられます。

自社で作ることと、自社プロダクトを持つことは別

受託開発は、顧客の情報システムを受託し、要求に応じて既存製品と個別開発を組み合わせ、設計・開発・納品する仕事です。一方、プロダクト型のWebサービスでは、新規開発だけでなく、提供中のサービスを改善する仕事があります。

求人票では「SaaS企業」「自社開発」というラベルを結論にせず、次の差を読みます。

| 比較軸 | 自社SaaSのプロダクト側で確かめること | 顧客向け受託開発で確かめること | | --- | --- | --- | | 要求の起点 | 利用者の課題を誰が集約し、製品の優先順位を決めるか | 顧客の要求を誰が要件として確定するか | | 成果の区切り | 製品・サービスのリリース後も改善を続けるか | 契約上の納品、受け入れ、保守をどう区切るか | | 個別対応 | 標準機能、設定変更、個別開発の境界はどこか | パッケージ利用とオーダーメイド開発をどう分けるか | | 意思決定 | 製品の方向、バックログ、リリース可否を誰が決めるか | 顧客と開発側が変更範囲、費用、納期をどう決めるか | | 稼働後 | 障害対応、問い合わせ、機能改善をどの組織が担うか | 納品後の運用・保守が同じ契約や部門に含まれるか |

SaaS会社でも導入支援や顧客別の設定があり、受託会社でも自社製品を持つことがあります。会社全体を二択にせず、応募職種が関わるサービスと契約を単位に比べるのが現実的です。

このサイトでは、SaaSを業務機能をサービスとして継続提供する形態から見ます。一方、インターネット・Webサービス業界は、ポータル、メディア、ECなどを含むWeb上の事業・提供チャネルを起点にします。これは公的な排他的分類ではありません。Webで提供されるSaaSのように両方へ重なる求人は、提供機能、主な利用者、応募職種が担う成果と責任を確認し、二つの記事を比較してください。

職種横断の違いは、会議名より決定権で読む

Webサービス開発では、プロダクトマネージャー、デザイナー、エンジニアが同じ製品について検討し、要件、画面、実装、テストをつなぐ形があります。ただし、職種名だけでは誰が最終判断をするか分かりません。

面接では、直近の機能追加を例に出してもらい、利用者の要望が開発項目になるまでを聞きます。要望を整理する人、優先順位を決める人、仕様を固める人、品質基準を満たしたと判断する人が見えれば、募集職種の裁量も見えてきます。

アジャイル開発という言葉も、裁量の保証にはなりません。外部委託の開発では、利用企業のプロダクトオーナーが方向性と内容に責任を持ち、開発会社が技術的なリスクを説明する分担もあります。求人票に「プロダクト開発」「アジャイル」とあっても、プロダクトオーナーが自社か顧客側か、募集職種がバックログへ関与するかを確認しましょう。

リリース後まで持つと、仕事の制約も変わる

サービスは公開して終わりではありません。テスト、情報セキュリティ、リリースに加え、公開後の不具合対応や保守を担う仕事があります。ただし、開発と運用が同じ会社・同じチームとは限りません。

一つのサービスを長く改善したい人は、次のリリースまでの開発だけでなく、稼働中の責任も確認します。

  • 障害の一次対応と原因修正は、募集チームの担当か
  • 夜間・休日の当番がある場合、頻度、交代人数、手当はどう定められているか
  • 品質やセキュリティの基準を誰が持ち、リリースを止める権限は誰にあるか
  • 問い合わせと利用状況が、次の開発優先順位へどう渡るか
  • 開発、運用、導入支援の間で異動や兼務があるか

運用まで関われることを成長機会と見るか、勤務時間の制約と見るかで、同じ求人の評価は変わります。オンコールや障害対応が記載されていなければ、ないと推測せず選考中に確認します。

共通製品を育てたいのか、顧客ごとの正解を作りたいのか

同じ製品を継続して改善し、利用者から寄せられた問題や要望を次の仕様へ戻す仕事を選びたいなら、自社SaaSのプロダクト側は候補になります。ただし、複数の利用者へ同じ標準機能を提供する場合、特定顧客だけの要望をそのまま実装できない場面もあります。

顧客ごとに業務を深く理解し、個別要件をシステムへ落とす方を重視するなら、SIer業界も比較対象です。経営・業務上の課題を整理し、開発前の意思決定支援へ軸足を置きたい場合は、ITコンサルティング業界の役割境界を先に読むと候補を分けやすくなります。

収入は「SaaS業界の相場」で埋めない

確認できる情報サービス産業の統計は、SaaSだけを同じ職種・地域・雇用区分で切り出した給与レンジではありません。エンジニア、プロダクト企画、運用などを一つの幅へまとめると、応募条件から離れます。

収入は、公式求人の基本給、固定残業代、賞与、株式報酬、待機手当を分け、職種、等級、勤務地、雇用区分をそろえて比較します。会社の平均年間給与があっても、それを個別求人の提示額やSaaS職種の年収レンジとして扱いません。確認できない項目は、推定値で補わず「情報なし」のままにします。

応募前に、一つの機能が改善される流れを聞く

求人票を読んだら、最近リリースした一つの機能について、要望の把握から優先順位付け、設計、テスト、公開後の対応までを質問します。抽象的な組織図より、誰がどこで判断したかを聞く方が、職種間の分担を確かめやすいからです。

そのうえで、担当する製品名、主な利用者、標準機能と個別対応の境界、リリース頻度、障害対応、評価指標を求人票と面接回答で照合します。「自社開発」ではなく、自分が持ちたい意思決定と稼働責任があるかを基準に選びましょう。