はじめに
私は開発部門の部長職として、自部門のエンジニアの中途採用にも携わっています。
現職に新卒入社して現在14年目なので、自分自身は転職エアプなのですが、色々な方と採用面談してきた経験から、IT業界で転職を考えている方向けに、IT業界の用語や概念を整理したうえで、より解像度高く応募先企業／部門のことを理解するための確認ポイントを、本記事で考えてみようと思います。
ちなみに、IT業界の全体像を把握しきれていない若手向け、かつ、私自身の経歴から、主にクライアントワークについて深掘りします。
また、言語やフレームワークなどの技術面を確認すべきであることについては、皆さんご理解されているでしょうから、業態や働き方を主眼とした内容になります。
きっかけ
採用面接のなかで、「御社はSES企業ですか？」「受託が多いですか？」といった質問をいただくことがあるのですが、単純には答えにくいというか、ニュアンスは分かるが聞きたいことを正確に聞けている質問とは思えない感じがしていました。
IT業界には、意味ありげで実は大した意味も定義も無いような言葉が少なくありません。
上述の「SES」や「受託」も、多くの人が抱くであろうニュアンスは分からなくはないのですが、実際は大した意味はありません。そういった曖昧な言葉を使って質問しても、本質的には応募先企業を理解することができないので、勿体無いなと思ったのが、本記事のきっかけです。
特に若手エンジニアの方は、言葉の意味や業界の実態など、まだ頭のなかで整理ができていないために、そういった聞き方になるんだろうなと推察するので、まずはいくつかの概念やキーワードを私なりに整理してみます。
事業会社とクライアントワーク企業
IT業界のビジネスモデルとしては、事業会社とクライアントワークに大きく分かれると思います。
（そのほかで言うと、フリーランス向けの営業エージェントなどでしょうか。）
- 事業会社は、自社でプロダクトの企画〜開発〜運営を行います。
- クライアントワークは、後述の受託開発や SES 事業を通して、顧客にITサービスを提供します。
ここまではイメージできると思いますが、ポイントは２つあります。
- 自社プロダクト事業とクライアント向け事業の割合
- 業務における裁量の度合い
自社プロダクト事業とクライアント向け事業の割合
自社プロダクト事業かクライアントワーク事業のどちらかに絞って展開している企業もあれば、どちらもミックスして経営されている企業もあります。
さらに会社の見せ方についても、事業会社的な側面を強くアピールしつつ実態はクライアントワークも少なくない場合もあるでしょうし、本記事投稿時点の弊社 ARI のように、クライアント向け事業を名実ともにメインに据えつつ自社プロダクト事業も育成中、的な場合もあります。
そのため、ホームページの記載内容だけで応募先を理解したつもりになるのは早計です。
どちらもやっている企業でも、部門は分かれていることが多いはずなので、応募先の企業だけでなく部門も含めて、具体的な業務内容を確認しましょう。
業務における裁量の度合
事業会社だから裁量が大きいとか、クライアントワークだと融通効かないとか、そういったイメージをなんとなく持たれている方はいらっしゃらないでしょうか？
もちろんエンジニアとしての裁量が大きい事業会社もあるでしょうし、元請けの指示通りの開発しかできないクライアントワークもあるでしょう。
一方で、事業会社でも、社長がワンマンだったり、パワーバランス的に企画・営業部門が強かったり、既存プロダクトの制約が多かったりして、エンジニア側の裁量が決して大きくない場合もあるでしょう。
（私自身が経歴を通してクライアントワークを経験してきたので、事業会社のことは詳しくは語れません。ただ、採用面接でお話を聞いたり、お客様の様子を伺ったりすると、事業会社も色々あるんだなと感じます。）
そしてもちろん、クライアントワークでも元請けであれば裁量も大きい場合が少なくないでしょう。
つまり、「事業会社だから」「クライアントワークメインなら」こういう会社のはずだ、とイメージで決めつけずに、具体的な業務内容などを確認していく必要があります。
いずれにせよ、記事冒頭で記載した通り、以降はクライアントワークについて深掘りしていきます。
請負契約、準委任契約、派遣契約
IT業界における契約形態に関しては、理解しておくことは重要ではあるものの、解説記事がネットに山ほどありますし、ChatGPT がうまくまとめてくれると思いますので、ここでは説明は割愛します。
派遣会社でない限りは、契約形態としては請負か準委任が多く、派遣契約は場合により無くはない、くらいじゃないかなと思います。少なくとも弊社はそんな感じです。
ウォーターフォールとアジャイル
これらについてもそれ自体の説明はここでは割愛しますが、ポイントは、開発手法（ウォーターフォール、アジャイル等）、開発対象（業務系、プロダクト系等）と契約形態は関連する、という点です。
業務系システムの開発は、主に既存の特定業務をシステム化する活動なので、（少なくとも理論上は）開発スコープが明確化させやすいです。そのため、ウォーターフォール × 請負契約と親和性が高いです。
商用プロダクト・サービスの開発においては、ユーザーの反応を見ながら進めたい場合が多く、開発スコープを事前に明確化させづらいため、アジャイル開発と親和性が高いでしょう。たとえば今後１年での開発内容を詳細に確定できるプロダクトチームは多くないと思います。つまり開発を外部委託する場合は、請け負う対象が確定できないので、プライム＝一次請けであっても準委任契約になりやすいでしょう。
（実際に私のチームではこういったプロジェクトが何件か存在します。）
しかしながら、これらはあくまで一般論なので、「業務システム × 請負 × アジャイル」とか、色々パターンは考えられます。
ここで何が言いたいかというと、請負だから／準委任だから、またはウォーターフォールだから／アジャイルだから、良いとか悪いとかいう話ではなく、契約形態にせよ開発手法にせよ、各プロジェクトにおいて、何をどう作りたいかによって組み合わせを考えるべきツールに過ぎない、ということです。
転職を検討されている方のなかには、開発形態に明確なこだわりがある方（スクラムマスターになりたい！とか）もいらっしゃるでしょうから、そういう方はしっかり開発手法やその運用方法まで確認されるとよいと思います。
受託開発 とは？
まずは一般的な説明を ChatGPT に聞いてみましょう。
受託開発（じゅたくかいはつ）とは、クライアント（依頼主）から依頼を受けて、その要望に応じたシステムやソフトウェア、アプリなどを開発する形態のことです。
■ 受託開発の特徴
- クライアントの要件に合わせて開発する
- 開発の責任範囲が明確
- 開発会社は請負契約が多い
クライアントワークである以上、依頼主の要望に応じたシステム開発になるのは当然でしょう。また、請負契約が「多い」と書かれています。
SES との違いも ChatGPT に聞いてみました：
受託開発とSESの違いは、「成果物に責任を持つか（受託）」 と「作業時間を提供するか（SES）」という点に集約されます。
つまり、受託 ≒ 請負開発（成果完成型の準委任も想定してるのかな？）ということでしょうね。
ただ、、、
- 2次請け、3次請けでも請負契約はあり得ると思いますが、その場合は受託開発と呼ぶのでしょうか？
- プライムベンダー（元請け）としてアジャイル開発を準委任で請けた場合は、受託と呼ばないのでしょうか？
結局、「受託開発」という言葉に「請負開発」以上でも以下でもない定義しかないので、例えば元請けが実施した要件定義に基づいて、エンドクライアントとの接点も持てずに設計以降の工程を実施する場合でも、請負契約であれば受託開発と言えなくもないということになります。
また、「受託開発」の関連で「持ち帰り開発」という言葉もあります（ありました）が、受託だろうが SES だろうがリモートワークが浸透した現代において、死語、つまり存在意義を失った言葉でしょう。
SES とは？
こちらもまずは ChatGPT に聞いてみましょう。
SES（System Engineering Service）とは、エンジニアのスキルや作業時間を企業に提供するサービス形態のことです。受託開発が「完成した成果物の納品」を目的とするのに対し、SESは作業の遂行そのものを提供します。
■ SESの特徴
- エンジニアを企業へ常駐・派遣する形態
- 契約は「準委任契約」が基本
- 時間単価で報酬が発生
まず、「エンジニアを企業へ常駐・派遣する形態」については、前項の繰り返しになりますが、リモートワークが浸透した現代においては、やや時代遅れの定義なのではないでしょうか。
準委任＝時間単価の報酬、なので、結局 SES とは準委任契約のことでしかありません。
SES というと、自身の意向も聞き入れてもらえず、会社の言われるがまま、独り現場に売り飛ばされて常駐させられる、みたいなイメージをお持ちの方もいらっしゃると思うのですが、そういった定義は SES という言葉自体には特に無いわけです。
おそらく、、、
顧客 ─(請負)─> 元請け ─(SES)─> 2次請け ─(SES)─> 3次請け...
といった、オールドスクールな開発モデルを前提に、そういったイメージが実態とともに形成されていったのでしょう。
ただ、アジャイル開発も当たり前になった現代においては、「元請けでアジャイルチームを提供しているけど準委任だから SES と言える」場合もあり得ます。
つまり、
- 受託＝請負契約
- SES＝準委任契約
- 契約形態は使い分けするもの、それ自体に良し悪しは無い
- 受託だから SES だからといってそれだけでは実態は正確には判断できない
ということです。
また、どうやら「SES企業」「SESエンジニア」という言葉もあるようです。
基本的には請負契約しか認められない会社もあるらしいですし、まだ元請けになりきれない会社は、準委任がメインになりがちでしょう。ただ、それ以外のIT企業については、請負契約と準委任契約の割合は会社や部門、さらにタイミングによりけりだと思います。
さらに言うと例えば：
- 10件に1件の割合でプチ受託案件があって、他の9割は多重下請け構造のなかでの SES をやっているような企業は、SES 企業と呼ぶんでしょうか？
- アジャイル開発専門のITサービス（アジャイルコーチなど含め）を提供している会社は、準委任契約が基本になろうかと思いますが、そういった会社は、SES 企業と呼ぶんでしょうか？
つまり、「SES企業」はイメージ先行の、定義が曖昧な言葉だと思います。
「SESエンジニア」については言うまでもないでしょう。
SIer とは？
SIer も、分かるようで分からないような言葉ですね。
例によってまずは ChatGPT の出番です。
SIer（エスアイアー / システムインテグレーター）とは、企業や組織に対してシステムの企画・設計・開発・導入・運用までを一括して提供する会社のことです。“System Integrator（システムインテグレーター）” の略称です。
エンジニアリソースを個別に提供するのではなく、アプリやインフラなど各領域のエンジニアをチームで提供し、少なくとも要件定義から設計・開発〜リリースまで一括で担当できる会社、という感じでしょうか。
それ以上でもそれ以下でも無いですし、例えば前述の「10件に1件の割合でプチ受託案件がある会社」は SIer と呼ぶのか？と言うと、、、少なくともその会社自身は SIer を自称するでしょうね。いずれにせよ、そこまで明確な定義までは無さそうです。
SIer＝元請けとも言い切れないし、元請けであってもメーカー系で親会社からの限られた領域の仕事しかなかったり、一概にどういう会社、という理解はできないと思います。
上流工程とマネジメント
「上流工程に携わりたい」「マネジメント（PM）もやっていきたい」、、、これらも採用面接でよく伺うお話です。
向上心があるのは素晴らしいことですし、私の部門でもそういった上昇志向のあるリーダー候補の方々を積極採用しています！
ただ、必ず私からも質問させていただくのは、
「あなたにとって上流／マネジメントとは何を意味しているのか？」ということです。
あなたにとって上流工程とは？
まず「上流工程」について。
そもそも上流工程とはウォーターフォール開発が主流であった時代の用語であって、厳密にはアジャイル開発においては上流とか下流とかいう区別は無い認識です。ウォーターフォール開発においても、要件定義から設計工程までは上流と言えるわけです。
また、「上流」に何を期待しているのかも、人それぞれでしょう。
- エンドクライアントとのコミュニケーション（外政）
- 技術的な面、アーキテクトとしての役割
- チーム開発の牽引、ルール整備など（内政）
つまり、「上流工程に携わりたい」と一言で言っても、なんとなく向上心があることは伝わりますが、具体的に何がしたいのかはより深掘りしないと伝えられない、ということです。「御社では上流工程に関われますか？」という質問についても同様です。
あなたにとってマネジメントとは？
次に「マネジメント」について。
こちらも同様で、マネジメントスタイルは色々とあるわけです。
例えば：
- 大規模ウォーターフォール案件を率いる所謂昔ながらの専任PM
- 中小規模の案件において自身も手を動かしながら顧客とコミュニケーションをとり、チームをまとめる、プレイングマネージャー
など。
当然、良し悪しではなく、自身が何がやりたいか？が重要です。その点をより深掘りしてイメージできれば、応募先に対して、より解像度の高い質問や確認を作っていけるでしょう。
選考プロセスにおいて確認すべきこと
いくつかの概念やキーワードを整理してきましたが、総じて言いたいこととしては：
『出来合いの曖昧な言葉を使って質問／確認したつもりになるのではなく、まずは自身の希望を自己分析〜言語化したうえで、業務の実態を具体的に把握できるような質問や確認事項を作るべき』
ということです。
とは言え、おそらく多くの転職活動をしている方が聞きたい事項は、以下にまとめられるのではないでしょうか：
- 自社プロダクトなのか、クライアントワークなのか
- 何をどう作っているのか（業務系／プロダクト系、ウォーターフォール／アジャイルなど、いずれも二者択一ではないので、割合や傾向を確認）
- プロジェクトにおける裁量 ≒ 商流
- どのようなリーダー像、マネージャー像を目指せるか
- チームアサインか、個人アサインか（SES だとしてもチームで参画させる意向なのかどうか）
- 外部委託（BP／ビジネスパートナー）の活用方法
- リモートワーク等の働き方
ここで何点か補足します。
プロジェクトにおける裁量 ≒ 商流
受託か SES かとか言うのは、結局は、どの程度の裁量を持って開発に携われるのか、というニュアンスなのだろうと思います。
エンドクライアントとコミュニケーションが取れるのか、技術的な決定権を持てるのか、同じ会社の仲間と一緒に働けるのか、など。
これまでのお話からもご理解いただけるかもしれませんが、裁量の度合いと受託／SES とは、必然的な関連性はありません。
裁量の度合いを確認するためにはむしろ、プライム＝元請けの割合がどの程度かを確認したほうがよいです。元請けであれば、エンドクライアントとコミュニケーションが取れるし、技術的な決定権を持てるし、アサインの裁量も持てるので、同じ会社の仲間と一緒に働ける可能性も高くなります。
ちなみに、2次請け等でもポジションによっては一定の裁量を持てるケースもあります。
例えば、私のチームはWebフロントエンド領域が強みなので、元請けがバックエンドを担当して我々がフロントエンドを担当する、みたいな案件も過去には実際にありました。フロントエンドチーム内の技術・アサインについてはある程度裁量を持てました。
この辺りは応募先が技術的にどのような特徴があるのか（無いのか）によりますね。
つまり、単に商流を一問一答で聞くだけで大丈夫かというと、そうでもない場合もあるので、「元請けの場合はだからどうなのか、御社では何が嬉しいのか」「2次請け以降の場合は御社ではどういう関わり方が多いのか」と深掘りして会話できるととても良いと思います。
（一問一答では応募先の解像度を高めることはできません、というのが本記事の趣旨であります。）
外部委託（BP／ビジネスパートナー）の活用方法
このテーマは若手の方はあまり馴染みが無いかもしれませんが、応募先のプロジェクトの扱い方を理解するヒントになると思います。
自社のメンバーだけで開発チームを完結させない（できない）場合は、他社もしくはフリーランスのエンジニアリソースで補完するか、もしくはまるっと他社に委託します。
例えば、プレイングマネージャー的な将来像をイメージしている方であれば、基本的に要件定義のみ社内で実施し、設計以降の開発工程は他社に丸ごと委託している会社は、マッチしないでしょう。このように、外部委託の活用方法から、思い描く環境なのかを判断できることもあるわけです。
技術面について
冒頭で技術面は割愛すると記載しましたが、業態や働き方に関するところで補足すると、「技術面の一貫性と多様性」は確認すべきだと思います。
- ある程度一貫性のある技術選定で働けないと、エンジニアとしての経歴は積み上がらないでしょう。数ヶ月おきに異なる言語で開発、とかだと、経歴に散らかり感が出てしまいます。
- 一方で、あまりに特定の技術しか触れられないようだと、どこかで経歴に頭打ち感が出てきてしまいます。昨今はフルスタックという言葉もありますが、得意分野を軸に領域を広げられる余地はあったほうが好ましいと感じる方が多いのではないでしょうか。
ここに関しても、一問一答形式で「御社には技術面の一貫性と多様性がありますか？」と聞いても、「はい」と答えられて終了です。「御社では、なぜ、どのような」一貫性や多様性があるか、を会話して聞き出す必要があります。
おわりに
以上、IT業界のいくつかの用語や概念を整理しながら、より解像度高く応募先企業／部門のことを理解するための確認ポイントを考えてみました。
本記事に記載した内容は、もしかしたら「それくらい聞かなくても教えてほしい」と感じるものもあったかもしれません。確かにそれもそうで、私はなるべく情報共有に努めています。ただし面接スタイルはそれぞれですし、受け身で必要な情報を全て得られるとは限りません。
転職活動をしている、または検討している若手エンジニアの方にとって、より良いマッチングのヒントになれば幸いです。
私の部門、ビジネスイノベーションサービス部でも、Webエンジニアを絶賛募集中です。ご興味持っていただいた方は、ぜひご応募ください！