Contents
自社開発とは？ SES・受託との違い（定義と実務での差）
自社開発は企画から運用・改善まで継続的に関わる点が特徴です。ここでは業務範囲を明確にしたうえで、SES（システムエンジニアリングサービス）や受託（請負）との典型的な違いを実務観点で整理します。
自社開発の定義（企画→設計→実装→運用→改善まで一貫して関わる点）
自社企画のプロダクトを要件策定〜リリース〜運用〜改善まで継続的に担当する開発形態を指します。以下の用語は以降で使う定義です：KPI（主要業績評価指標）、MAU（Monthly Active Users：月間アクティブユーザー）、ARR（Annual Recurring Revenue：年間経常収益）、NPS（Net Promoter Score：顧客推奨度）、CTR（Click‑Through Rate：クリック率）、CVR（Conversion Rate：コンバージョン率）、TCO（Total Cost of Ownership：総所有コスト）、SRE（Site Reliability Engineering：サイト信頼性工学）、SO（Stock Option：ストックオプション）。
- 企画：ユーザー課題の仮説化と優先付け、ロードマップの策定。
- 設計：プロダクト要件・アーキテクチャ・UXの設計。
- 実装：機能開発、テスト、CI/CDを含むデプロイ作業。
- 運用：監視、障害対応、ログ・指標の収集。
- 改善：A/Bテストやデータ分析による反復改善。
自社開発／受託／SESの比較
下は一般的な傾向です。企業や案件によって例外がありますので、求人票や面接で確認してください。
| 比較項目 | 自社開発 | 受託（請負） | SES（常駐） |
|---|---|---|---|
| 裁量 | 高い。プロダクト方針や優先度に関与できる場合が多い | 中〜低。仕様に従うことが中心 | 低。派遣先の指示に従う |
| 責任範囲 | 広い。KPIやプロダクト品質に責任 | 納品物の品質・納期が中心 | 担当業務範囲に限定 |
| 成果の見え方 | 長期KPI（MAU/ARR/NPS等）で評価される | 納品ベースの短期評価 | 作業ベースの評価 |
| 常駐の有無 | 基本は自社勤務、リモート増加 | 顧客常駐やハイブリッド混在 | 派遣常駐が多い |
| スキル伸長 | 企画〜運用まで横断的に伸びる | 特定領域で深掘りしやすい | 実務経験は積めるが偏ることがある |
これらの傾向は業界調査や転職市場の報告にも現れています（参考：Stack Overflow Developer Survey 2023、Microsoft Work Trend Indexの報告など）。
自社開発で得られるやりがいの実像と、プロダクトのフェーズ別に変わる理由
自社開発では、自分の仕事がユーザー反応やKPIに結びつく点がやりがいになります。プロダクトのフェーズによって日々の業務と得られるインパクトが変わるため、フェーズを意識した転職判断が重要です。
代表的なやりがいの具体例
以下は現場で実感しやすいやりがいの例です。数値は事業や施策によって大きく異なるので、あくまで例示としてご参照ください。
-
ユーザー反応を直接見る
リリース後にNPSやリテンションが改善し反響を得られることがあります（例示：リリース後4週間でリテンションが+3〜12ポイント改善したケースがある、業種差あり）。 -
プロダクトへのオーナーシップ
企画から結果まで追うことで意思決定の影響を実感できます。 -
技術選定と効果の可視化
新技術導入でレスポンス改善やコスト削減ができ、その効果が定量で示せます（例示：レスポンス95パーセンタイルが数百ミリ秒改善、TCOが数％〜数十％改善する場合あり）。 -
改善ループを回せること
A/Bテストやログ分析で因果を検証し、数値的にPDCAを回す経験が積めます。 -
横断的なスキル習得
企画・UX・データ分析・運用など幅広いスキルが得られます（参考：開発コミュニティの調査報告等）。
立ち上げ（MVP〜市場適合探索）
立ち上げフェーズでは仕様検証とスピードが重視されます。プロトタイピングやユーザーインタビューの比重が高く、失敗と学びが速く回る点が醍醐味です。求められるスキルはフルスタック寄りの実装力やプロトタイピング能力です。リスクは不確実性の高さです。
成長期（PMF後のスケール）
成長期はKPI改善で事業インパクトを出しやすい時期です。データ分析、スケーリング、CI/CDの整備、チーム間調整が重要になります。スピードと品質の同時達成が課題です。
成熟期（安定運用・最適化）
成熟期は品質向上やコスト最適化が主要ミッションになります。SRE的な運用や大規模アーキテクチャ設計の経験を積めますが、日常はルーティン化しやすい点に留意が必要です。
やりがいを感じにくい典型ケースと対処法
やりがいが薄れる代表的な原因と短期対処法は次の通りです。
- 事業業績に強く依存している：KPIが停滞するとモチベーションが落ちる。→ 対処例：短期で狙える改善案件を提案する。
- 非開発業務が増えて実装時間が取れない：→ 対処例：役割を明文化し、業務配分を再交渉する。
- 役割が曖昧で学習機会がない：→ 対処例：上司と期待値（KPI・育成プラン）を擦り合わせる。
- 技術的負債に押され新規開発ができない：→ 対処例：短期リファクタ計画を作り、ビジネス効果を示す。
自社開発で求められるマインド・スキルと、向いている人／向いていない人
自社開発では技術力だけでなくプロダクト志向や対話力、改善志向が重視されます。ここではフェーズ別の優先度を踏まえ、適性の見分け方を示します。
必須マインドと実務スキル（優先度付き）
初期段階で特に重視されるマインドとスキルを示します。フェーズに応じて優先度が変わります。
-
マインド（常に重視）
ユーザー志向、プロダクト志向、継続的改善志向、クロスファンクショナル協業を楽しむ姿勢。 -
実務スキル（フェーズ別）
設計能力・コード品質（全フェーズで高）、プロトタイピング・フルスタック力（立ち上げで高）、データリテラシー・観測設計（成長期で高）、CI/CD・自動化（成長期で高）、インフラ・SRE基礎（成熟期で高）。
向いている人・向いていない人の具体的特徴
向いている人の特徴と逆の特徴を示します。
- 向いている人：裁量を好み、ユーザーや事業側と対話でき、長期価値創造にコミットできる人。
- 向いていない人：指示された範囲だけを淡々とこなしたい人、顧客折衝や企画を避けたい人、短期ローテーションや派遣環境を好む人。
セルフチェック（簡易）
次の問いに「はい」が多ければ自社開発は向いている可能性が高いです。
- 仕様を自分で決めたいか？
- ユーザーの声を数値で追うのは楽しいか？
- 企画や非コード作業に抵抗が少ないか？
- 長期のKPI改善にコミットできるか？
年収・待遇・雇用の実務ポイントと代表的なキャリアパス
待遇は企業フェーズ、地域、評価制度で大きく変わります。ここでは確認すべき項目と交渉の観点、代表的なキャリアパスを実務的に整理します。
待遇で見るべきポイント（業績連動・ストックオプション・評価制度・副業規定）
まずは次の点を求人票や面接で必ず確認してください。
- 報酬構成：基本給、業績連動報酬、賞与の比率。
- ストックオプション（SO）：付与数、行使価格、ベスティング（権利確定）スケジュール、希釈（dilution）リスク。
- 評価制度：KPIベースか行動評価か、評価頻度、昇給・昇格の基準。
- 雇用形態：正社員と業務委託では福利厚生・税扱いが異なる。
- 試用期間：期間と評価基準の明記を求める。
- 副業・兼業規定：可否と知財・競業避止義務の範囲。
- オンコールや稼働期待：頻度・補償の有無を確認する。
- リモートポリシー：出社期待と評価への影響を把握する。
また、年収の目安は地域・フェーズで大きく変わります。例示として日本市場の目安を挙げます（参考：求人サイトや開発者調査の集計をもとにした例示）。数値はあくまで参考です。
| レベル | 参考レンジ（日本・例示） |
|---|---|
| ジュニア | 300万〜450万円 |
| ミドル | 450万〜800万円 |
| シニア | 700万〜1,400万円以上（事業責任や採用力により上振れ） |
参考データの確認にはStack Overflow Developer Survey（開発者給与）や各求人サイトの年収レポートを併用するとよいです（例：Stack Overflow Developers Survey 2023）。
税務・法務に関する具体的な助言はここでは行えません。ストックオプション（SO）や雇用形態の税務処理については、必ず税理士や弁護士などの専門家に相談してください。
交渉時の実践例（面接・オファー時）
確認・交渉で使える表現例を示します。面接時は感情的にならず、事実と期待を明確に伝えます。
- 「試用期間中に評価される具体的なKPIを文書で共有いただけますか？」
- 「SOのベスティングスケジュールと行使条件を教えてください。ドキュメントで確認したいです。」
- 「オンコールの頻度と代替補償はどのようになっていますか？」
- 「初期6か月で期待される成果と評価基準を合意して書面化できますか？」
代表的なキャリアパス（IC→リード→アーキテクト／PM→CTOなど）と必要経験
代表的な進路と必要な経験例を示します。
-
個人貢献（Junior → Mid）
機能単位の設計・実装・テストを担当し、KPIへの寄与を示す。 -
シニア／チームリード
複数モジュールの設計、メンバー指導、リリース責任。技術選定やチーム運営経験。 -
アーキテクト／プリンシパル
全社的設計と技術戦略。大規模システムやクロスチーム経験が必要。 -
プロダクトマネジメント（PM）への横展開
ユーザー分析、ロードマップ設計、KPI管理の経験が重要。 -
エンジニアリングマネジメント（EM／CTO）
採用、組織設計、事業貢献の実績と事業側交渉経験が求められる。
各ステップで「担当した責任領域とKPIで成果が示せる」ことが重要です。
求人票の読み方と職務経歴書・面接で『やりがい』を具体的に伝える方法（テンプレ・チェックリスト）
求人票は「何を任せたいか」を示す重要資料です。曖昧な表現は具体化して質問する習慣をつけるとミスマッチを減らせます。ここでは読むべきポイントと面接・書類で使える実例を示します。
求人票のどこを読むべきか（プロダクトのステージ／チーム構成／裁量などのチェックリスト）
求人票で優先的に確認すべき項目は次の通りです。
- プロダクト説明とビジネスモデル（対象顧客、収益モデル）。
- プロダクトのステージ表記や資金調達状況（MVP／成長／成熟／資金余裕）。
- 業務の深さ（企画〜運用まで含むか）と裁量の範囲。
- チーム構成・人数・Reporting先。
- 想定KPIの明示（MAU／ARR／リテンション等の記載）。
- 技術スタックと開発体制（CI/CDの有無、テスト方針、SRE体制）。
- リモート／出社ポリシー・オンコール頻度。
- 選考プロセス（面接回数、課題提出の有無）。
曖昧な表現の読み替え例や質問を面接で投げると良いです（例：「企画〜運用のどの範囲を期待しますか？」「初期6か月の期待成果は何ですか？」）。
職務経歴書・面接での実践例（KPIで示す書き方、ユーザー事例の盛り込み、意思決定の貢献を説明する文例）
職務経歴書は「状況→役割→行動→結果（可能であれば数値）」の流れで書くと説得力が上がります。数値が出せない場合は割合や比較、ユーザー事例で補うとよいです。以下はテンプレ（数値は例示）。
- 例（機能開発）: 「プロダクトXの検索機能を要件定義〜リリースまでリード。ABテストによりCTRを1.2%→1.8%に改善（+0.6ポイント）、検索経由のCVRも向上し課金率が改善しました（例示）。」
- 例（UX改善）: 「ユーザー調査に基づきUX改善を実施。4週間後の保持率が5ポイント向上し、次期ロードマップに反映しました（例示）。」
- 例（技術改善）: 「レガシーAPIのリファクタを主導し、レスポンス中央値を400ms短縮、インフラコストを約20％削減しました（例示）。」
面接での説明は状況→課題→行動→結果→学びの流れで簡潔に語ると伝わりやすいです。
準備する出力物：ポートフォリオ（担当範囲明示）、GitHub/PRリンク（公開可能なもの）、1〜2ページの改善提案、主要KPIの推移を示す短いスライド。
機密情報・成果の表現に関する倫理的注意
職務経歴書や面接で成果を示す際は社外秘情報や顧客データ、契約情報を開示しないでください。具体的数値や事例は公開可能な範囲で記載・説明することが重要です。
転職のリスク管理・実行プラン（短期3か月／中期6か月／長期12か月）とQ&A
転職は期待とリスクが混在します。事前に確認事項を整理し、短期〜長期の行動計画を持つことでミスマッチを減らせます。ここでは実行プランと事例、Q&Aを示します。
事例と教訓（SES→自社開発の成功例・失敗例・教訓）
成功例（事例の要約、合成）
- 背景：SES出身の候補者が副業でプロダクト改善案を作成。
- 行動：面接で具体的な改善提案と試作を提示。
- 結果：入社後に機能のオーナーを任され、短期でKPI改善に貢献。
- 教訓：事前アウトプットで裁量を示し、入社前に期待範囲を明文化する重要性。
失敗例（事例の要約、合成）
- 背景：自社開発を期待して転職したが、実際は保守中心の業務が多かった。
- 教訓：面接で業務比率（企画：実装：運用）や期待されるKPIを深掘りすべき。
実行プラン（短期3か月／中期6か月／長期12か月）のチェックリスト
短期（0–3か月）
- 自己棚卸：役割・担当機能・KPI寄与を整理する。
- 職務経歴書を1本作成（成果の数値化、担当範囲の明示）。
- ターゲット求人を1〜3件選び応募する。
- 転職エージェントやメンターに相談する。
中期（3–6か月）
- ポートフォリオを拡充（改善提案、OSS寄与、技術記事）。
- 模擬面接で回答精度を上げる。
- 複数社と面談してオファー比較軸（裁量／待遇／成長機会）を作る。
長期（6–12か月）
- 条件交渉と入社条件の書面化。
- 入社後の初期成果プラン（最初の6か月の目標）を事前合意。
- 中長期キャリア計画を作り、必要経験を逆算して行動する。
よくあるQ&A（簡潔）
Q：未経験者は自社開発に行ける？
A：可能です。ただしプロダクトへの貢献を示すアウトプット（副業・ポートフォリオ等）が必要です。
Q：必要な経験年数は？
A：年数よりも責任範囲と成果量を評価されます。募集要件の責任範囲を重視してください。
Q：年収差の目安は？
A：企業フェーズや評価制度で差が大きいです。報酬構成とSO条件の中身を確認してください（具体的数値は求人と市場データを照合してください）。
Q：リモート＝裁量が大きい？
A：必ずしもそうではありません。裁量は職務設計と組織文化に依存します。進め方と評価方法を面接で確認してください。
まとめ：自社開発エンジニア転職で押さえるべき要点と初動の行動
自社開発は企画から運用・改善まで関与でき、裁量と長期的な成果追跡が特徴です。転職前に待遇・裁量・評価基準・SO条件・試用期間の評価基準を文書で確認することがミスマッチ防止に有効です。
- まずやること：自己棚卸（成果とKPIの整理）、職務経歴書の一本化、1〜3件への応募。
- 面接で聞くべき：初期期待成果、評価指標、SOの条件、オンコール・リモートポリシー。
- 交渉のコツ：評価基準・ベスティングスケジュールを文書化してもらう。
- 注意点：SOや税務・法務の具体的助言は専門家に相談すること。機密情報は職務経歴書や面接で開示しない。
参考として、開発者調査や働き方レポート（例：Stack Overflow Developer Survey、Microsoft Work Trend Index、各求人サイトの年収レポート）を併用すると市場感が掴みやすくなります。