SIerと事業会社の違いを、受託か自社サービスかだけで決めると粗くなる。境界を見よう。自社サービスを持つSIerも、開発を外部委託する事業会社もあるため、会社名より実際の案件と役割を比べる。
見るべきなのは、誰の課題から開発が始まり、誰が技術を選び、公開後の責任をどこまで持つかだ。ここで差が出る。本記事では、SIerと事業会社のどっちを選ぶかを求人ごとに判定する。
SIerと事業会社は、開発の起点と契約構造から比べる
SIer求人では、顧客要件や契約条件が開発の起点になる案件かを確認する。まず分けよう。顧客、元請け、協力会社のうち、誰から要件を受け、誰へ仕様変更を提案するのかを見る。
事業会社求人では、事業課題、自社サービス、社内システムのどれを扱うか確認する。対象が違う。利用者の要望、事業計画、障害履歴、運用コストのうち、何を開発順位の材料にするか聞く。
会社の分類だけでは、顧客や利用者との距離を判断できない。経路を見る。直接ヒアリングするのか、営業や企画を介するのか、外部委託先へ要求を渡すのかを確かめる。
最初に比べる軸
| 比較軸 | SIerで確認すること | 事業会社で確認すること |
|---|---|---|
| 開発の起点 | 顧客要件と契約条件を誰が整理するか | 事業課題と社内課題を誰が優先するか |
| 契約・発注構造 | 直接契約か、元請けや協力会社を介するか | 内製か外部委託か、委託先を誰が管理するか |
| 成果の区切り | 納品、検収、保守移行のどこまで持つか | 公開後の分析、改善、廃止まで持つか |
| 判断相手 | 顧客、元請け、協力会社の誰と調整するか | 事業責任者、企画、営業の誰と決めるか |
| 配属単位 | 案件と担当工程を誰が決めるか | プロダクトや社内システムを継続して持つか |
技術の裁量は、提案・承認・運用責任をセットで見る
求人票の「技術選定に参加」だけでは、裁量の範囲を判断できない。段階を分けよう。候補を調査する人、構成案を作る人、最終承認する人を面接で確認する。
SIer求人では、顧客標準、調達条件、保守条件、既存環境との接続が選定条件に入るかを見る。制約も仕事だ。その中で比較案や非機能要件を誰が作るかを聞く。
事業会社でも、開発チームだけで技術を変更できるとは限らない。手順を聞こう。セキュリティ審査、予算承認、データ移行、運用部門への引き継ぎを誰が担うか確認する。
決定権だけを魅力として見ない。責任が続く。採用した技術の移行計画、障害時の切り戻し、保守、廃止まで同じ担当者が持つのかを確かめる。
求人票の「技術選定」を面接で確かめる
- 直近で採用または廃止した技術は何か
- 候補を提案した人と最終承認者は誰か
- 性能、費用、保守性のどれを比較するか
- 顧客指定や社内標準から外れる提案は可能か
- 検証環境と試行の申請を誰が行うか
- 移行、切り戻し、保守、廃止を誰が担うか
「現場に任せる」という回答だけでは足りない。実例を聞こう。直近の技術変更について、提案、承認、移行、運用の担当者と、採用されなかった案の理由まで確認する。
担当工程と関係者を比べると、日々の作業が見える
SIer求人では、要件調整、設計書作成、進捗報告、受け入れ支援のどれを担当するか確認する。実装だけではない。仕様と納期を調整する相手も聞く。
事業会社求人では、プロダクト管理、デザイン、営業、サポートの誰と優先順位を決めるかを見る。経路がある。利用者の声へ直接触れるのか、企画部門が整理した要望を受け取るのかを確認する。
同じ「要件定義」でも、担当作業は求人ごとに異なる。名前を外そう。ヒアリング、業務フロー、仕様確定、見積もり、受け入れ条件のうち、本人が持つ範囲を聞く。
開発以外の作業も比較する
| 作業 | 確認する内容 | 働き方への影響 |
|---|---|---|
| 調整 | 顧客、事業部、協力会社との会議 | 実装以外に使う時間が見える |
| 文書 | 設計書、議事録、申請書、運用手順書 | 成果物として求められる文書が分かる |
| レビュー | コード、設計、セキュリティ、契約条件 | 承認者と公開までの手順が見える |
| 障害対応 | 一次対応、原因分析、説明、再発防止 | 当番と勤務時間外対応の有無が分かる |
会議の多さだけで良し悪しは決まらない。目的を見る。技術判断へつながる会議なのか、進捗報告が中心なのかで、自分が使える経験と伸ばせる工程が変わる。
リリース後の責任と評価制度が、働き方を左右する
SIer求人では、検収後に保守チームへ渡すのか、開発担当が障害対応や追加改修を続けるのか確認する。区切りを聞こう。問い合わせ、契約更新、追加見積もりの担当者も見る。
事業会社求人では、公開後の監視、問い合わせ調査、利用分析、改善、機能廃止を誰が持つか確認する。範囲は会社次第だ。開発チームと運用チームの引き継ぎ条件も聞く。
評価制度は勤務先の分類だけでは読めない。項目を聞こう。納期、品質、顧客評価、サービスの信頼性、技術改善、チーム支援のうち、何が昇格や報酬へ反映されるかを見る。
働き方を左右する運用条件
- 障害対応の当番と勤務時間外の連絡方法
- リリースや変更作業を行う曜日と時間帯
- 顧客先、オフィス、在宅勤務の使い分け
- 案件やプロダクトを変更する条件
- 保守と新規開発へ割り当てる時間
- 評価面談で参照される成果物と指標
技術の裁量を求めるなら、障害時の説明責任も比較する。ここを忘れない。顧客、利用者、経営、運用部門のうち、誰へ報告し、復旧判断を誰が持つかを確認する。
比較表と面接で、自分に合う勤務先を選び切る
SIerと事業会社のどっちが合うかは、現職と応募先を同じ軸で並べて決める。表にしよう。希望する技術、調整相手、運用責任、働き方との差を残す。
| 比較項目 | 現職 | 応募先 | 判断基準 |
|---|---|---|---|
| 開発の起点 | 顧客要件か事業課題か | 案件やプロダクトでの決まり方 | 向き合いたい課題と重なるか |
| 契約・発注構造 | 直接契約と協力会社の位置関係 | 要件の受け手、提案先、配属の決め方 | 希望する相手へ技術提案が届くか |
| 技術選定 | 提案者、承認者、運用担当 | 選定、移行、保守、廃止の担当 | 決定権と責任範囲を引き受けられるか |
| 担当工程 | 要件から運用までの範囲 | 入社直後と将来の担当工程 | 経験を使い、伸ばしたい工程へ進めるか |
| 関係者 | 顧客、協力会社、事業部との接点 | 会議、報告、調整の相手 | 受け入れられる調整内容か |
| 運用責任 | 監視、障害、保守の担当 | 当番、引き継ぎ、改善の担当 | 希望する働き方と両立するか |
| 評価制度 | 現在評価される成果 | 昇格や報酬に反映される項目 | 自分が出したい成果と重なるか |
利用する求人サービスの掲載職種も確認する
求人を比較する際の対象範囲として、当社ユナイテッドワールドが掲載するITエンジニア領域には、次の傾向がある。
⚠ これはユナイテッドワールド1社の在庫であって、ITエンジニア業界全体の求人構成ではない。記事で使う際は「人材紹介会社が扱う求人の傾向」として書き、業界全体の話にしないこと
これはユナイテッドワールドが預かる求人だけの傾向であり、ITエンジニア業界全体の構成を示すものではない。範囲は限られる。また、このデータからSIerと事業会社の比率や働き方は分からない。
当社の取扱求人は専門職・技術職に限られ、テストやヘルプデスクなどのサポート職は含まれていない。検索先を合わせよう。サポート職を希望する場合は、別の求人サービスの掲載職種も確認する。
面接では直近の案件や改善をたどる
- 要件や優先順位を最終的に決めたのは誰か
- 顧客または利用者の声をどう受け取ったか
- エンジニアの提案で変更された仕様はあるか
- 利用技術を変更するときに必要な承認は何か
- 障害時に復旧と説明を誰が担当したか
- 入社後に最初に任されるコードと文書は何か
抽象的な制度説明ではなく、直近の実例を工程順に聞く。比較しやすい。回答を表へ入れ、不明な項目は追加で質問し、会社の分類ではなく実際の役割で応募先を選ぶ。