Web系の求人を選ぶとき、フロントエンドかバックエンドかだけでは仕事の進め方を決められません。先に見たいのは、サービスを持つのが自社か顧客か、契約相手と実際の利用者は誰か、公開後の運用をどこまで担うかです。
自社サービスでも企業向けと個人向けでは、要望を集める相手が違います。受託開発でも、納品後に運用から離れる案件と、改善や保守を続ける案件があります。この3つの軸を分けると、同じ「Webエンジニア」という募集でも、自分が関わりたい意思決定と避けたい勤務条件を見つけやすくなります。
ソフトウェア・通信業界の仕事マップから来た人は、このページでWebサービスの提供主体と運用責任まで絞り込んでください。
公的分類と、転職で使う「Webサービス業界」は同じ範囲ではない
公的な産業分類では、インターネットを通じた情報提供やサーバ機能の提供を行う事業の一部が「インターネット附随サービス業」に置かれています。検索サービスやショッピングサイトの運営は例に含まれますが、インターネット広告やインターネット銀行は別分類です。
したがって、「Webで提供しているから同じ業界」と会社単位で決めることはできません。このサイトでは、本記事を、ポータル、検索、メディア、ECなど、Webを利用者との接点・提供チャネルにする事業の企画・開発・運営を読む入口とします。一方、ソフトウェア・SaaS業界は、業務アプリケーションやコミュニケーション機能などをサービスとして継続提供する「提供形態・製品」から読みます。
これは転職判断のための編集上の切り分けであり、互いに排他的な公的分類ではありません。Webで提供する業務SaaSのように両方へ重なる求人は、提供機能、主な利用者、応募職種の三つを確認します。共通の業務機能を製品として改善する職種ならSaaS記事から、ポータル・検索・メディア・ECなどの利用者接点や提供チャネルを企画・運営する職種なら本記事から読みます。一つに決められない場合は両方を読み、製品の標準機能とWebサービス運営のどちらに責任を持つかを面接で確かめます。
自社か受託かで、要件を決める相手が変わる
Webサービス開発の仕事には、必要な機能の検討、要件定義、設計、実装、テスト、公開、公開後の問題解決までがあります。自社サービスでは社内のプロダクト担当などと改善を決め、受託では顧客と開発対象を検討するのが基本的な違いです。ただし、社内外の誰が最終決定するか、採用職種がどこまで提案できるかは求人ごとに異なります。
| 提供の形 | 仕事の区切り | 求人票・面接で確かめること | | --- | --- | --- | | 自社サービス | 一つのサービスを公開後も改善する | 優先順位を決める部署、利用状況を受け取る方法、本番運用の担当 | | 受託開発 | 顧客と決めた範囲を設計・開発し、受け入れへ進める | 顧客会議への参加範囲、成果物と受け入れ条件、変更時の調整役 | | 受託後も保守 | 納品後も障害対応や改修を契約範囲で続ける | 開発と保守の担当分け、契約外の要望を誰が調整するか |
「自社なら自由」「受託なら指示どおり」とは限りません。自社で営業、法務、カスタマーサポートなどの関係部門と合意する範囲は、組織と変更内容によって異なります。受託でも要件整理や改善提案を任される職種があります。比較すべきなのは看板ではなく、要件を決める会議に誰が参加し、自分がどの判断を持つかです。
B2BとB2Cは、自社・受託とは別の軸で読む
B2BかB2Cかは、サービスの契約相手を知る手がかりです。自社サービスにも受託案件にも、企業向けと個人向けがあります。ここを自社・受託と一緒にすると、「誰の要望を受け、誰が導入を決め、誰が毎日使うか」を読み違えます。
| 確認する相手 | B2B求人での問い | B2C求人での問い | | --- | --- | --- | | 契約・購入を決める人 | 経営、情報システム、事業部門の誰か | 個人が直接選ぶのか、広告主など別の顧客がいるか | | 実際の利用者 | 管理者と現場利用者は同じか | 想定する利用場面と利用者層は何か | | 開発へ要望を渡す人 | 営業、導入支援、サポートのどこから届くか | 問い合わせ、利用データ、検証結果を誰が判断するか | | 導入後の責任 | 権限設定、外部連携、問い合わせを誰が担うか | 不具合対応と利用者対応をどの部署が分けるか |
B2Bだから開発が遅い、B2Cだから反応が早いとは決められません。契約、利用者数、法令、品質基準によって優先順位は変わります。求人票に顧客区分だけが書かれている場合は、購入者・利用者・開発判断者を面接で分けて聞きます。
リリース後の運用を、開発職の外側だと決めつけない
Webサービスの公開後には、不具合の原因調査、改修、監視、問い合わせ対応、継続的な改善が残ります。開発者が運用・保守まで担う求人もあれば、別部署や別会社へ引き継ぐ求人もあります。職種名からは判断できません。
本番対応がある求人では、責任の有無だけでなく、実際の持ち方を確認します。
- 監視とアラートの一次対応はどの部署が担うか
- 障害時に開発者が呼ばれる条件と時間帯は何か
- 当番制がある場合、頻度、代休、手当はどう定められているか
- 問い合わせを直接受けるか、サポート部門から技術課題だけが届くか
- リリース判断と、問題が起きたときの切り戻しを誰が決めるか
- 開発チームが改善まで持つのか、保守チームへ引き継ぐのか
「運用あり」という一語だけで夜間対応を想定する必要はありません。一方で、「開発職」とだけ書かれていても本番当番がないとは限りません。勤務条件と責任範囲を同時に聞くことが必要です。
改善の優先順位と公開後の結果を持ちたい人は、自社サービスが向いている
同じサービスに継続して関わり、利用状況や問い合わせを次の改善へつなげたい人は、自社サービスを候補にしやすいでしょう。向いているかを決める条件は、会社が自社サービスを持つことだけではありません。応募職種が優先順位の検討へ参加でき、公開後の結果を開発へ戻せることが必要です。
複数の顧客業務を経験し、契約された成果物と期限の中で設計・開発を進めたい人は、受託開発の方が望む仕事の区切りに近い場合があります。その場合も、案件変更の頻度、顧客業界、担当工程、保守への移行条件を確認します。
納品で仕事を区切りたい人は、運用一体型の求人に向いていない
公開後の監視や障害対応を避け、期間のある開発工程に集中したい人は、開発と運用を同じチームが持つ求人には向いていません。受託というだけで納品後に離れられるとは限らないため、保守契約の有無と配属後の担当を確かめます。
反対に、一つのサービスを育てたい人でも、優先順位が顧客側だけで決まり、案件ごとに担当が替わる受託職種では期待とずれる可能性があります。自社・受託という名称より、誰が改善を決め、いつ担当が終わるかを選択条件にします。
求人票は7項目を一つの行にして比べる
候補ごとに次の7項目を一行へ書けば、技術名だけでは見えない違いを比較できます。
- サービスの所有者は自社か顧客か
- 契約相手、購入決定者、実際の利用者は誰か
- 改善の優先順位を最終決定するのは誰か
- 採用職種は要件定義、設計、実装、テストのどこを担うか
- 受け入れ・公開の条件を誰と決めるか
- 監視、障害対応、問い合わせ、継続改善をどこまで持つか
- 本番当番、勤務時間、出社条件はどう定められているか
この7項目をそろえた後で、勤務地や雇用条件を比較します。仕事の責任範囲が異なる求人を、技術名だけで同列に置かないことが大切です。