IT業界で言われている「SIer系」と「Web系」それぞれ呼ばれる企業の違いがなんなのか説明できますか？
実は僕もちゃんと言語化できませんでした。。
この記事では
「SIer系とはなんですか？」
「SIer系とWeb系と呼ばれる企業の違いはなんなのか？」
「Web系ってWeb系言語を使ってたらそう呼ぶんじゃないの？」
というあなたとボクの疑問を解決するための内容になっています。
Web系のプログラミング言語を使うのは、SIer系でもWeb系でも関係なく使います。
たとえば、Web系エンジニアといってもとらえ方は人それぞれだったります。
Web系のプログラミング言語を扱えるエンジニアとしても、Web系企業で働くエンジニアとしても、どちらでも使われます。
「Web系」についてはすこし曖昧な表現になりがちなので、こんな意味もあるよ程度で読んでいただけたらと思います。
「Web系企業」も「アプリ系企業」や「ネット系企業」と呼ばれることもありますが、この記事では「Web系企業」に統一しています。
ちなみにIT業界からは少しベクトルが異なる「Web制作系企業」も存在します。
どちらかといえば、Webデザイナーが生息する業界ですが、合わせて簡単に解説しています。
あと「SES企業」もIT業界には存在しますが、簡単に説明するとクライアントにエンジニアを派遣する企業のことです。
Web系っていろんな意味が含まれててややこしいですがよかったら読んでいってください。
SIer系企業とWeb系企業それぞれの特徴
SIerはシステムインテグレーターを略してオシャレに表現したもので、システム構築を生業にしてる企業のことをいいます。
Webはそれだけだといろんな意味にとれてしまいますが、ここではアプリ系企業や、ネット系企業ともよばれるWeb系企業のことで、自社サービスをインターネット上で提供している企業のことをいいます。
SIer系企業とWeb系企業を以下の観点でそれぞれ比較しつつ特徴を説明します。
- マネタイズ（稼ぎ方）
- 具体的な企業
- 社風イメージやカルチャー
- エンジニアの呼称
- システム開発手法
マネタイズ（稼ぎ方）
- 発注元が存在する
- 発注元からシステム開発案件を受託して稼ぐ
- BtoBが一般的
- 発注元は存在しない
- 自社サービスをインターネット上で提供して稼ぐ
- BtoCが一般的
SIer系企業は、ベンダ企業とも呼ばれることもあり、発注元から業務システムなどのシステム案件を受託開発することで売上を立てている。
発注元は一般的には企業なので、BtoBのビジネスモデルが多い。
もちろんそうでない企業もあるが、大手SIerはほぼBtoBのビジネスモデルと思ってもらっていい。
Web系企業は、発注元は存在せず、自社でマーケティング等を行いニーズのある自社サービスを開発しインターネット上で提供し、その利用料や広告料などで売上を立てている。
そのため、一般的にはBtoCのビジネスモデルが多い傾向にあるが、企業をターゲットにしたインターネットサービスを提供しているWeb系企業も多くあるので、SIer系企業ほど偏ってはいない。
具体的な企業
- 富士通や日立システムズなどのメーカー系
- NTTデータや伊藤忠テクノソリューションズなどのユーザー系
- TISや日本ユニシスなどの独立系
- メルカリやZOZOなどのEC系
- サイバーエージェントなどのメディア系
- ガンホーや、DMM GAMESなどのゲーム系
SIer系企業は大きく３つに分類することができる。
富士通や日立などIT系メーカー会社から子会社化したメーカー系、NTTや伊藤忠などの商社や銀行などIT系以外の会社から子会社化したユーザー系、TISや日本ユニシスなど元からSIer企業として独立した経営をしている独立系に分類できる。
Web系企業は海外の企業だとAmazon、Google、Facebook、Netflixなどわかりやすい大手が多い。
国内だとEC系のサービスを提供するメルカリやZOZO、メディア系のサービスを提供するサイバーエージェント、パズドラで有名なガンホー、ゲームだけにとどまらず大人向け動画配信なども提供するDMMなどがある。
インターネットがここまで普及する前の名残で、PKG系企業とよばれる企業も存在する。
PKG系企業とはパッケージソフトを持つ企業のことで、たとえばサイボウズなどがわかりやすい。
他にも会計ソフトなどを扱っている企業もPKG系企業にあたるが、昨今ではパッケージソフトもクラウド化があたりまえで、Web系企業にまとめられる傾向にある。
社風イメージやカルチャー
- スーツスタイル
- 客先常駐
- 通勤必須
- 納期ストレス大
- ペコペコしてる
- 服装自由
- 社内開発
- リモートワーク
- 納期ストレス小
- キラキラしてる
この項は、僕の主観が大きく反映されてしまってますのでご容赦ください。
SIer系企業は、客先常駐などが多いイメージで、服装はスーツだし、通勤して現場で作業するイメージが強い。
また、クライアントから課された「納期」は絶対で、納期ストレスは半端なく大きい。
ITゼネコンといわれる2次請け、3次請けが多いので、システム開発する孫請け企業は、常にペコペコしている印象がある。
SIer系企業の社風や文化はIT業界以外の一般企業とそんなに変わらないよなと思う。
Web系企業は、服装自由だし、社内開発かまたは、リモートワークで通勤しなくても作業できるイメージが強い。
また、「納期」については基本的に社内できめられた納期だけで、納期ストレスはSIer系に比べると少ない。
Macブックを持ち歩いているイメージがあって、常にキラキラしたモダンな技術を使いこなす必要がある。
休暇や、勤務時間はSIer系企業にくらべると融通がききやすいイメージでもある。
エンジニアの呼称
- ITコンサル、システムエンジニア、プログラマー
- 給与は上流工程を担当するほど高給
- インフラエンジニア、バックエンドエンジニア、フロントエンドエンジニア、フルスタックエンジニア
- 給与はSIer系のエンジニアよりは低め
SIer系企業では、作業工程を担当するエンジニア単位で呼称が変わるイメージをもつ。
要件定義を行うITコンサル、設計を行うシステムエンジニア、開発・テストを行うプログラマーという感じ。
でも、システムエンジニアが全般要件定義から開発まで担うことができるエンジニアとして呼ばれることもある。
給与については、ITコンサル、システムエンジニア、プログラマーの順に下がっていくが、ITコンサルなど上流工程を担当するエンジニアは高給とりが多い。
Web系企業では、作業工程の粒が小さいので要件定義から開発まで得意分野をもつエンジニアが存在するイメージをもつ。
サーバー構築やネットワーク構築を担当するインフラエンジニア、サーバーサイドの開発を担当するバックエンドエンジニア、フロントサイドの開発を担当するフロントエンドエンジニアという感じ。
また、サーバー構築から、サーバーサイド、フロントサイドの開発も全部を１人で担当できちゃうフルスタックエンジニアも存在する。
ただ、呼称については、諸説あるので人によって意味が変わることもあります。
給与については、フルスタックエンジニアは高給で、それ以外は平均的な給与。
SIer系のエンジニアにくらべると、給与は低いこともある。
システム開発手法
- ウォーターフォール開発が主流
- ITゼネコンと呼ばれ孫請けの仕組み
- 不具合なく動いてほしいので堅実な技術（悪くいえば古い技術）で開発
- 非ウォーターフォール開発が主流
- 自社内での開発
- 効率良くシステムをスケールしたいので、モダン技術を使って開発
SIer系企業はウォーターフォール開発がまだまだ主流です。
要件定義→設計→開発→テストの流れで順番に前の手順に戻ることなく進めていく手法です。
SIer系企業はITゼネコンと呼ばれ、発注元から1次請負、2次請負、3次請負と3世代またはそれ以上の下請け文化が根付いているのがこのウォーターフォール開発の手法にマッチしているためでもある。
つまり、上流工程（要件定義）を1次請負企業が担当し、中流工程（設計）を2次請負企業が担当し、下流工程（開発・テスト）を3次請負企業が担当する仕組みができあがっている。
この仕組自体は別に悪くはないが、一部の企業がなにもせずピンはねだけして（システム開発はなにもしないで中抜きしてるという意味）、下請けに全部丸投げするだけを仕事にしてたためイメージを悪くしてしまっている。
また、各工程を別企業が行う傾向にあるため、ドキュメントの作成が重要とされている。
要件定義、設計（外部設計・内部設計）の工程で後戻りをゆるさないドキュメントを作成し、これをみるだけで下位工程が問題なく進むように作りこむ必要がある。
とはいえ、そんな完璧なドキュメントなんてできないんで、ドキュメント作成はほどほどにした方が効率よくないか？って疑問は生まれている。
また、SIer系企業の最終目的が、発注元に完成した成果物を提供することなので、不具合なく動いてほしいから堅実な技術、悪くいえば古い技術を使った開発が主流になる傾向がある。
Web系企業は非ウォーターフォール開発が主流です。
非ウォーターフォール開発の一番の例が、アジャイル開発手法です。
要件定義→設計→開発→テストの流れは基本的にウォーターフォール開発と同じだけど、１つ１つの工程の規模の粒が小さい。
出典：https://www.ipa.go.jp/files/000004753.pdf
新幹線を例にしてみます。
福岡～仙台まで福岡・広島・岡山・神戸・大阪・名古屋・静岡・東京・仙台の駅を経由して完成してほしいと要望があったとする。
ウォーターフォール開発は、全部の駅の要件を終わらして、全部の駅の設計を終わらして、全部の駅を建設して、全部の駅に線路を繋げ、最後に開通テストを行って全開通する手法です。
アジャイル開発は、粒を小さくするので大阪から東京を先にリリース対象にし、その部分だけの要件、設計、建設、開通テストを行って部分開通する。
そのあとに、優先度順に順次駅を追加して全開通させる手法です。
ちょっと極端ですが、大げさにいえばこんな感じになります。
ウォーターフォール開発では、ドキュメント作成を重要として、作業効率に関係なく作りこんでいましたが、アジャイル開発は作らないこともあるくらい、最低限のドキュメント作成にとどめるイメージにある。
アジャイル開発はとにかく動くものを作って、利用者に使ってもらって感想・指摘をもらい、それを改善するというスタイルをとっています。
Web系企業は、発注元がいないので、開発しながらもより良い方法・手法があればそちらを採用するし、効率よくシステムをスケールしていきたいのでモダンな技術を使った開発が主流になる。
また、Web系企業では、良くも悪くもITエンジニアの属人性に頼る傾向がある。
とはいえ、知っておいてほしいのは、IT業界全体で共通しての開発手法の方向性は、ウォーターフォール開発から、非ウォーターフォール開発つまり、アジャイル開発を推奨する流れになっている。
アジャイル開発を行うためにはマインドセットがまずは大切です。
そのマインドセットをまとめたのが、アジャイルソフトウェア開発宣言です。
わかりにくければ、成果物やサービスまたは働き方と読み替えて理解しましょう。
アジャイルソフトウェア開発宣言
出典：https://www.ipa.go.jp/files/000065601.pdf
引用：http://agilemanifesto.org/iso/ja/manifesto.html
アジャイルソフトウェア開発でも価値のある必要なドキュメントは作成するし、事前に計画を立てて作業を進めていく必要はあります。
もちろん、開発を効率的に進めるために有用なツールを活用することも重要です。
アジャイルソフトウェア開発宣言で伝えようとしていることは、「プロセスやツール、包括的なドキュメント、契約交渉、計画に従うこと」は大事なのはもちろんだけど、「個人と対話、動くソフトウェア、顧客との協調、変化への対応」の４つのマインドセットを前提として持ちましょうということ。
1.「個人と対話」
個人同士の対話を通じて相互理解を深めることで、よりよい成果を生み出す。
2.「動くソフトウェア」
動くソフトウェアを使って繰り返し素早く仮説検証をし、その結果（成功だけじゃなく、失敗も大事）から学ぶことがよりよい成果を生み出す。
3.「顧客との協調」
お互いの立場を超えて協調（英語で言うと「You」ではなく「We」のイメージ）することにより、よりよい成果と仕事のやり方を作ることができる。
4.「変化への対応」
顧客のニーズやビジネス市場の変化は事前計画を狂わすリスクではなく、よりよい成果を生み出す機会と捉える。
アジャイル宣言の背後にある１２の原則
出典：https://www.ipa.go.jp/files/000065601.pdf
引用：http://agilemanifesto.org/iso/ja/principles.html
01-顧客の満足を求め続ける
「顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。」
ビジネス側の人と開発者にとって、最も重要な活動は、価値のあるソフトウェアを素早く継続的に提供し、顧客に（QCDの達成ではなく）ビジネスゴールの達成の観点で満足してもらうことです。
日本の多くの企業は、近年の劇的な市場の変化への対応に迫られています。
ビジネスを支えるITシステムの構築は、企業の存続を左右するほど重要な要素になっています。ビジネス側の人と開発者は、ビジネスの実現を最優先に考えてITシステムを構築する必要があります。
ただし、ビジネスの成否はビジネスごとに異なります。したがってビジネス側の人と開発者は、常に顧客と同じ目線で、顧客の満足を高める価値の創出について考える必要があります。
まず、顧客の満足とは何かを定義することからはじめ、ビジネスの観点で十分に評価可能な動くソフトウェアを、素早く継続的に提供し、顧客の満足度がどのような状態なのか、明らかにします。
引用：https://www.ipa.go.jp/files/000065601.pdf
02-要求の本質を見抜き、変更を歓迎する
「要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。」
改善に繋がる要求は、新しい価値を見つけた証拠です。勇気を持って変更を受け入れることで、変化に強くなり、企業の競争力を高めることに貢献します。
従来は、定型業務の処理や記録を扱う基幹系システムなどのビジネスが多く、最初から作るものが明確なシステムが大半でした。しかし昨今、人とモノの繋がりを重要とする業務改善や変革を目的としたビジネスは、最初から要求に明確な答えがないことが多く、作るものが不明確な場合があります。
このような、特性が異なるビジネスのITシステム開発を、従来と同じソフトウェア開発プロセスで実施しても、成功確率は上がりません。
そもそも、顧客にとって価値のないシステムを作っても、意味はありません。そこでたとえ開発の後期であっても、要求の本質を見抜き、与えられたコスト・納期・スコープのバランスと要求の優先順位から、変更の受け入れを判断する必要があります。
引用：https://www.ipa.go.jp/files/000065601.pdf
03-成果物を短期間で、リリースし続ける
「動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。」
ビジネス側の人が積極的にビジネスの舵取りができるよう、ビジネス側の人と開発者は2-3週間の短い時間間隔で、成果物を定期的にリリースし続けます。
リリースするというと、比較的長期間(例えば半年から数年など)の開発の後に、顧客に納品することを思い浮かべるかもしれません。
しかし、長い開発期間中に当初顧客が望んでいたゴールが変わり、顧客が本当に欲しかった成果を得られなくなっている可能性もあります。
この原則03でいう短い時間間隔とは、2-3週間から2-3ヶ月です。
ビジネスゴールが変わって要求が変更になることが想定される開発の場合は、仮説検証型で進める必要があります。
成果物を頻繁にリリースすることで、顧客からフィードバックを得ることができ、結果として顧客が本当に欲しいものを作ることができます。
また、たとえ後戻りがあったとしても小さくすませることができます。
引用：https://www.ipa.go.jp/files/000065601.pdf
04-全員（顧客と開発者）で共通の目標に向かう
「ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。」
ビジネス側の人と開発者が共通目標に向かって一緒に働くことで、一連のリリースおよびフィードバックのサイクルが円滑になります。
不確実性の高いプロジェクトでは、状況が刻々と変化するため、共通の目標が見えないまま進めると、認識の齟齬などが発生する可能性があります。
ビジネスの価値を最大化するために、作るソフトウェアの価値やプロジェクトの状況について、常に共通目標に向かってベクトルを合わせながら働きましょう。
そのために、常にあるべき姿をビジネス側の人と開発者が共有し、必要に応じて改善し続ける必要があります。
引用：https://www.ipa.go.jp/files/000065601.pdf
05-人の意欲は信頼からくる
「意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。」
プロジェクトを成功させるため、開発者には意欲のある前向きな人々を集めて、彼らが働きやすい環境を整えることが求められます。
個人が十分に高い能力を備えていたとしても、お互いの関係がぎくしゃくしているなど、働きにくい環境では十分に能力を発揮できません。
もともと日本には「和」を重んじる文化、精神があり、経営やものづくりの局面にも活かされてきました。
「対立」を避け、相互にリスペクトし信頼し合うことで、ビジネス側の人と開発者、そして組織内の風通しがよくなり、ビジネス側の人と開発者全員が意欲的に活動できるようになるのです。
引用：https://www.ipa.go.jp/files/000065601.pdf
06-コミュニケーションは直接対話する
「情報を伝えるもっとも効率的で効果的な方法は、フェイス・トゥ・フェイスで話をすることです。」
お互いの本音をフェイス・トゥ・フェイスで汲み取り、直接対話することが大切です。
ビジネス側の人が開発者に伝えたい情報や開発者間で伝え合う情報の中には、仕様とは異なり、目的、希望、夢、心配ごとなど、正確に表現できないものもあります。
そのような情報は、言葉では伝わりにくかったり、伝える際に齟齬や誤解を起こしやすかったりします。
ビジネス側の人と開発者が、全員同じ空間に集まり、対面で双方向に対話することで、お互いの本音を汲み取りやすくなります。
もし齟齬が起きたとしても、対話を通してすぐに気づくことができます。
引用：https://www.ipa.go.jp/files/000065601.pdf
07-進捗も品質も動くソフトウェア
「動くソフトウェアこそが、進捗の最も重要な尺度です。」
進捗状況を正確に把握するためには、動くソフトウェアを確認することが、最も信用できるやり方です。
なお、この場合の進捗状況とは、求められている価値をどれだけ実現できているか、ということです。
また、この場合の動くソフトウェアは、計画通りに進んでいるかということではなく、市場にリリースできる程度の品質を満たしている必要があります。
設計書の完成度など、動くソフトウェア以外のもので測る進捗では、実際に動かしてみるまでは問題に気づけないことがあるため、どうしても表面上の進捗状況把握に留まってしまいます。
不確実性の高いプロジェクトでは、進捗状況を常に正確に把握し、適切な判断を行うことが重要です。
引用：https://www.ipa.go.jp/files/000065601.pdf
08-一定のペースでプロジェクトにリズムを持つ
「アジャイル･プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなければなりません。」
無理のない一定の開発ペースを保つことは、ビジネスの成功につながります。
往々にして開発者は、ゴールを目指して過負荷なパフォーマンスを求められることがあります。
無理をした状態では創意工夫をしたり、改善をしたりという意欲が起きません。
また、無理をして一時的に生産性を上げたとしても、その無理が祟ってその後の生産性が落ち、結果的にトータルパフォーマンスは低下してしまいます。
開発者の生産性を最大限に引き出し、価値あるものを提供し続けるためには、開発者だけでなく、ビジネス側の人も心身ともにベストな状態を保ち、無理のない一定のペースを維持することが、重要です。
引用：https://www.ipa.go.jp/files/000065601.pdf
09-モダンな技術、優れた設計、よりよい品質の追求
「技術的卓越性と優れた設計に対する不断の注意が、機敏さを高めます。」
新しいビジネスを支えるソフトウェアは、状況に応じて、いつでも素早く変更できることが求められています。
そのためには、優れた技術力に支えられた、優れた設計になっている必要があります。
よい品質には、高い保守性が欠かせません。
もし、設計やソースコードの可読性などについて、技術的な問題が蓄積されると、ソフトウェアの保守性が低下し、素早く変更できない状態に陥ります。
すると、市場の変化への対応が遅くなり、ビジネスを成長させる際の大きな阻害要因となってしまいます。
よりよい技術を追い求め、効果的にその技術を活用することで、素早く、品質よく、変化に対応し続けることができます。
技術は常に進化しています。
開発者は技術力を磨き、プロダクトへの適用技術と設計に対して、常に注意を払うことが重要です。
引用：https://www.ipa.go.jp/files/000065601.pdf
10-いかにシンプルにできるかを考える（無駄なことはやめる）
「シンプルさ（ムダなく作れる量を最大限にすること）が本質です。」
ビジネス側の人と開発者は、顧客が求める価値が何かを考え、その価値に直結しない作業や機能をムダと定義し、そのムダを減らすためにたゆまぬ努力をしましょう。
これは、アジャイルソフトウェア開発における本質の活動です。
ムダの中には、組織にとって現在必要なものも含まれるので、見逃しがちです。
これまでの常識や慣習にとらわれず、新鮮な目で現状を直視しましょう。
日々の作業の中からムダを見つけ、削減することは、身軽になり機敏性を高めるだけでなく、コスト削減と生産性向上にも貢献します。
引用：https://www.ipa.go.jp/files/000065601.pdf
11-よいモノはよいチームから
「最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。」
最良のアーキテクチャ・要求・設計は、最良のチーム(=自律型のチーム)から生み出されます。
自律型のチームとは、メンバー一人ひとりが自らの行動、作業に責任を持つとともに、お互いの連携により、チームとしての成果を最大限に発揮することができるチームのことです。
優秀なメンバーが集まったチームだとしても、お互いに連携や協調がなければ、チームの能力は、個々のメンバーの能力の和でしかありません。
あるいは、個々の作業が重複していたり、相反する作業をしていたりすれば、チームとしての成果に悪影響を与えます。
一方自律型のチームでは、メンバー一人ひとりが常に改善の意識を持ち、お互いの能力を高めながら共通の目的や目標に対しての取り組みが継続されます。
そこには相乗効果が生まれ、チームとしてメンバー個々の能力以上の成果を発揮することが可能になります。
その結果、自律型のチームから、ベストな成果が生み出されることになるのです。
引用：https://www.ipa.go.jp/files/000065601.pdf
12-自分たちのやり方を定期的に振り返り、最適化する
「チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。」
チームが成長し続けるためには、定期的に(長くても2～3週間、オススメは毎週)ふりかえり、自分たちのやり方を調整し続けることが大事です。
“ふりかえり”というと、プロジェクトの最後の反省会を思い浮かべるかもしれません。
しかしたいていの場合、次のプロジェクトは周りの環境もチームも異なることが多く、“ふりかえり”の結果を活かすことは難しいでしょう。
この原則で言う“ふりかえり”とは、プロジェクトの進行中に定期的に、短い時間で行うことです。
“ふりかえり”を繰り返すことで、よいやり方はどんどんよくなり、もし、失敗したとしても(うまくいかなかったとしても)影響を最小限に留めることができます。
定期的な“ふりかえり”の場があることで、チームメンバーは、プロジェクトにとって有用ではあるが言いにくいことを言えるようになります。
引用：https://www.ipa.go.jp/files/000065601.pdf
12原則をまとめると
「言われたことを、言われたまま成果物にすれば、売上があがる。」
そういうマインドから脱して、クライアントと一緒によりよいシステムにするために考えられた開発手法だということだと僕は思っています。
クライアントにもこのマインドがないとアジャイル開発手法は難しいです。
特に、お金の問題が一番難しい。
なのでSIerはいまだにウォーターフォール開発手法が主流なのは納得できる。
まとめ：SIer系とWeb系と呼ばれる企業の違い
なんでもするからフルスタックかな。
てことで、SIer系かWeb系でいえば、零細企業のSIerよりだけど、取引相手にSIerはほぼいなくて、クライアントからの直案件ばかりなんですよね。
Web系のようにスケールするサービスは提供してないけど、自社パッケージソフトは存在してるので（ぽつぽつ改善はしてる）。
最後に「Web制作系企業」「SES企業」についても解説しておきます。
Web制作系企業
Web制作系企業はクライアントのホームページ制作や、LP（ランディングページ）制作、フロントエンドのデザイン制作などを請け負う企業のこと。
SIer系企業や、Web系企業と大きく異る点は、インフラの構築や、サーバサイドの構築は専門外（既成サービスを使うことが多い）なところ。
たとえば、WordPressなどのCMSを使ったSaaSを利用するのが主で、必要なプログラミング知識もPHPのみなどのイメージです。
社風イメージやカルチャーはWeb系企業っぽく、クライアントが存在し、納期もきっちりしてるので社風イメージやカルチャー以外は、SIer系企業っぽいです。
ちなみに、エンジニアの呼称も、ITエンジニアというよりはWebデザイナーと呼ぶ方がしっくりくる。
SES企業
そもそもSESとはシステムエンジニアリングサービスの略で、クライアントに技術者を派遣することでITエンジニアの技術を提供するサービスのことをいいます。
ほぼ「Web系企業」「SIer系企業」「Web制作系企業」がクライアントになります。
このSESで利益を得ている企業をSES企業と呼びます。
業務内容は、派遣先によって変わりますし、「派遣業」とは契約形態がことなるので、この点でもグレーになりがちな企業ではあります。
契約形態についてはこちらの記事でまとめてます。
ユウキでした。
