わいらが新卒採用に参入したのって、22年の2月ころ。
厳密には、採用/営業側（この記事書いているひとたち）が新卒採用活動業務を巻き取ったのは22年の秋ころっぽいんよね。なのでこの記事書いてる頃（23年8月）はまだ1年経ってない程度の経験なんじゃけど。

それでもワリとパターンと言うか、見えて来たものもあるので、こういうシリーズもやっていくかと。
んで、今日のはまあ、業界研究的な部分になるんかねえ。

1.ベンダー？事業会社？それってなんや

まず『ベンダー』『事業会社』とはなんのことかというところ。
ざっくりこう。

〇ベンダー

ざっくり、販売者のこと。　特にサーバとかネットワーク機器とかモノを売る会社だとわかりやすいんやけど、ITの場合はソフトウェアが売り物になってくるからねぇ...。あらかじめ作られたパッケージやソフトウェアを売るというケースはまだしも。

ＩＴの場合はいちからシステム開発を行うケースも多く。その場合も他社のハードウェアやサービス、ツールなどと一緒に導入する形になる訳で、純粋な『開発会社（開発だけをする）』というもののイメージがつきづらい。対エンドの想定が無い、純粋にプログラム開発をする会社。そのあたりが 『開発会社』なんだろうかね。

ITを軸にした就職活動においては、『IT関連のナニカをエンド企業に売って儲ける会社』と、雑に思えばよいかと。より深い定義は会社ごとに

〇事業会社

定義は『事業経営を行う会社』ですので、銀行などの一部の業態を除く、ほぼすべての営利企業がこれに当たります。　IT業界においては、前述のITベンダー群からみて発注者。エンドユーザーにあたる企業群と思っておけばOKでしょう。

現在はITが絡まない大手企業と言うものはほぼ存在せず、小売業に至ってはかなり多数が自社のECサイトや、その他IT技術を利用したサービスを顧客へ提供しています。
注意点として、Webサービス運営者も、こちらに含まれる会社が多いです。『IT関連のナニカを売って』儲けている訳ではなく、『サービスへの課金（もしくは広告費）』で儲けている業態になります。

じゃあSaaSベンダーはどうなんだという話になってきますと、これも定義や範囲が様々で、かなり話が混沌としてきますね...。

2.ITベンダー（開発会社）の価値観

ここでは、システムエンジニアを主力とした、システム開発・ソフトウェア開発/販売のあたりの話をできればと思います。（仕入れて売るだけだと営業会社の方に近くなる。）

〇エンジニア組織（花形部署）
建築で言えば職人。営業会社で言えば営業。フットボールクラブで言えば選手です。

この会社の主力の専門性をつかさどる部署となり、この部署の能力で、売れるものの規模や品質、利益率などが変化。直接利益に影響を及ぼす事になります。多くの場合、この部署が花形職種に当たります。（外部製品を仕入れて売る利益がメインだったりすると、営業の方が花形だったりすることも。）

このようなベンダーのシステムエンジニアの仕事は建築士に近いところがあり、エンドユーザーとの距離も近いです。エンドがベンダーへシステム開発を発注する目的は様々ですが、無目的と言う事はありません。システムエンジニアはそのエンドの目的の為にシステムを設計し、納品し、その結果、エンドからベンダーへ代金が支払われます。

なるべく安く作った方が利益は大きくなります（収益-費用＝利益）が、契約では、品質(Quality)、費用（Cost）、納期（Delivery）が定義されており、むやみに品質を落として納品と言うことはできませんし、品質が低いシステムを納品されたエンドユーザーは満足度が低くなりますから、同じベンダーへリピート発注をしてくれなくなります。

一般的に、リピート受注は新規営業に比べて営業コストが1/5で済むと言う話もありまして、顧客満足度（C/S：customer satisfaction）の確保は重要と言えます。また、顧客から信頼されている状態はほかにも多数の利益を産むことになります。

なにより、成果物が顧客から高い評価を得るという事は専門職として誉であり、専門家としての自負を持つエンジニアほど、自己肯定感の充足を強く感じることになります。

専門性の高いエンジニア組織ほどこのようなループにハマっていき、

顧客への成果。それを実現するための自分たちの専門性に対して強いこだわりを持つ傾向があります。

（営業組織ならば売上や利益、サッカークラブであれば試合結果やサポーターの満足などがそれにあたる）

なお、Q・C・Dは、それぞれトレードオフの関係性となっており、費用（Cost）、納期（Delivery）を維持したまま品質(Quality)を向上させるというのは、純粋に能力を求められる話でもあります。プログラム能力だけではなく、設計の質、プロジェクトマネジメントの質や、メンバーのミッションへの主体性など、様々な要素が問われることになります。

ただし、このエンジニア組織の特性は、多重下請けの階層構造によって、エンドとの距離が離れるほど希薄になっていく感じはあり、その点は注意が必要です。

上図では、元請企業はエンドのC/Sを獲得する方向で努力しようとしていますが、2次・3次の受注者が見ている方向は、それぞれ自社の直接契約先である、元請・2次の企業です。このように目線が違う方向に向いてしまった場合、高い能力や主体性を有していたとしても、活かされる事はあまりありません。『下請け根性』とか言われて嫌われる傾向のある要素ですね。

『下請け根性』問題は、商流が深くなるほど発生しやすくなる傾向はありますが、すべての2次・3次がダメという事もありません。どちらかと言うと、技術部署のビジネス的な視座の高さが影響してくる印象です。

3.事業会社の価値観

要はほぼ全てのカイシャなので、実際にはいろいろなパターンがありますが。
エンジニアの組織に着目し、簡略化して話します。また、エンジニアの視点ですので、『売り物がIT以外の事業会社』の話と言う事でお願いします。

と言う訳で、その会社のメインの収益を稼ぐ部署。『〇〇事業部』などがＩＴ部門の他にあるとします。収益や費用が集計され、【収益-費用＝利益】の、利益を最大化する事が求められる部門。【プロフィット・センター】を担当する花形部署が、他にあるという事ですね。
これらは『ＩＴを利用する側の部門』という意味で『ユーザー部門』などと呼ばれる事が多いです。

項２で説明したITベンダー（開発会社）の場合は、エンジニア組織がプロフィット・センターを担当する花形部署でしたが、非ITの事業会社においては、エンジニア組織はプロフィットセンターをはじめ、他の部門をIT技術でもって支援する立ち位置の部署になります。

よくあるのは、情報システム部（通称：情シス）で、企業が業務で使用するネットワークそのものや、ルータやPCなどのIT機器、業務システムなどを構築、運用する部署となります。
売上を直接稼ぐ部門ではありませんから、業務にかかったコストだけが集計される、【コストセンター】という部門になります。（よく勘違いされがちだが、悪い意味の言葉ではないので注意。）稼ぐための部門ではない訳ですから、無限にコスト垂れ流したりしたら、経営や事業部門、営業などからボコスコに詰められること請け合いです。

しかし、IT装備率と労働生産性は相関性が高く、企業に取ってIT投資はとても重要になっています。非ITの事業会社のIT部署と言えど、【自社のＤＸ化を推進せよ】という重要なミッションを背負うことになっているのがこの情シス部門であり、意味のあるDX化/デジタル化を企画し、推進する事ができる（通称）DX人材は、採用・育成の面でとても重視されている存在となっています。

〇ITベンダー（開発会社）で求められるスキルとは別種である。

ベンダーは様々な顧客企業を相手にする関係上、1社の顧客の業務に特化した知識と言うのは求められ辛く。また、様々な状況に対応出来るＩＴスキルを要求されることになる訳ですが、事業会社のエンジニアは違います。ITスキルの他、【自社の業務に対しての高い理解度】が必要です。

ITによる業務の改善・支援は強力な効果をもたらすことがあり、ユーザー部門の収益を大きく上げたり、競合に対して優位に立てたりすることがあります。まさにこのような効果をもたらすシステムの企画、IT利用の提案への期待がDXバブルだった訳ですが。

これは『ただシステム作れます』では全く不足で、（それで出来たら外部コンサルやベンダーのSEの提案で十分って話。）事業部門の業務や構造をより良くする為の気づきが肝要。

その【気づきを得るための、深い業務の理解】【気づきをITで具現化する為のITの知識】どちらも必要と言う事になります。

気づきを具現化するのは、自身のプログラム能力である必要はなく、外部ベンダーのパッケージ・サービス・ツールの利用や、外部ベンダーによる新規システム開発でも実現できてしまいます。

下記の引用記事は、ニトリのIT内製人材採用における育成方針が、SNSで賛否両論出まくったという件の記事なのですが。

※2023.01.26 日経クロステック
SNSで物議のニトリIT人材「1年半」の現場研修、妥当性をHD社長とCIOに直撃
より引用。

SNS上で賛否両論が発生した理由は、まさにベンダーと事業会社、それぞれのエンジニアに求められるスキルや必要な育成・キャリアパスが違うという事を理解している人と理解していない人がいたという話にほかなりません。

事業会社のエンジニアは、花形部署ではありません。
花形部署ではありませんが、事業部署が競合に勝利し、会社が存続していく上で、非常に重要な役割をはたす部署と考える事業会社は少なくありません。

主役ではなくとも、他部門を支援し大きな成果をあげさせる。
目立たなくとも、自社のシステムの管理・IT機器の運用・保守・ヘルプデスクなど、会社にとって重要な役割を担当します。

4.いったんのまとめ

ベンダー・事業会社、どちらで働く方が自分に合うかというのは人によります。
自分がどちらに合っているかを考え、また、ちゃんと応募先の会社のエンジニア職の仕事内容を調べ。その上で応募しなくてはいけません。

このあたりがふわふわとした理解の求職者ですと、面接する採用担当者は入社後のアンマッチによる短期離職を警戒しなくてはいけなくなります。求人の充足状況にもよりますが、多くの場合は面接NGとなるのではないかと思います。

5.おまけ。Webサービス運営・ゲーム

おまけです。

〇Webサービス運営

基本構造は他の事業会社とあまり変わりないかと思います。
サービスを作ると儲かるではなく、サービスを使わせると儲かるである為、本来の花形部署は営業やマーケティング部署かと思われ、エンジニア部門は【より儲けるための企画】を、顧客に近い営業部門やマーケティング部門から受けて、サービスを拡張していくようなイメージになります。

営業/マーケと、エンジニア部門の関係性は会社によって違うようですが、どちらも重要です。
Webサービスは多くの場合『パクるのは簡単』ですので、競合との差別化(超重要)を開発部門の開発能力に頼る事になりがちです。

しかし、追加開発を重視しすぎてシステムの品質が落ちていきますと、どんどん運用・追加開発のコストが増加していき、やはり競争に負けてしまうことになります。

逆に品質やエンジニア部門のホワイトさを重視しすぎた結果、営業面で他社に負けてしまいますと、やはり破滅の未来が待つことになります。（その前に、バカらしくなった営業の主力層が辞めたりしがち）

後者は、2010年代後半のスタートアップバブル期に『エンジニアファースト』なる価値観を掲げ、エンジニアに媚びる事で採用有利に立とうとした一部企業でよく見られる傾向です。資本調達オカワリを狙うベンチャー企業などは、エンジニア採用数が再調達のハードルだったりもした様で、まあ必死。
結果的にエンジニアファーストには上記の様な副作用があった訳ですが、副作用に気づいても、元の組織に切り戻すことは容易ではありません。（大量離職しそう）

いわゆる『エンジニアファースト』然とした企業を希望であれば、今でも採用トークや内部のホワイトさに関しては変わっていないはずです。それでよい。それが良いという方は、まだまだ狙っていけるのではないかと思います。

〇ゲーム開発

正直、あんましくわしくない領域。この記事を信じすぎてはいけないかも。

実際にはゲームパブリッシャー（販売元）とゲームデベロッパー（開発会社）が存在します。
パブリッシャーが企画し、デベロッパーが開発（請負の開発会社に近い）という形が多いはずですので、厳密には下記の図は間違っていることになりますので注意ね。

まあ、IT人材の話ですので、ゲーム開発者をイメージして単純化して話します。
そうなると、構造はWebサービス運営とあんまり変わらないんじゃないかなー。

コンシューマーも、ソシャゲも、作る段階では儲かりませんね。リリースして、売れて。ソシャゲならば、ユーザーがついて継続的に課金してくれて、初めて儲かる仕組みです。

最近はソシャゲの開発費も億単位。開発期間も数年とか当たり前。しかもお隣の国のパブリッシャーの広告費は青天井と言う事で、なかなか厳しい世界になっております。

〇ゲームが好きで作りたい人たち向けの世界。
開発の大変さもありますが、日本のゲームユーザー。レビューがやたらと辛口です。『そういうもんだ』というのがわかっているレベルのゲーム好きじゃないと、心折れます。そもそもゲームをプレイした経験自体が活きたりもするので、ゲーム好きじゃないとハマらない事が多そうです。

〇あんまりホワイトを求めてはいけない。
そんな、そもそもゲームが好きな人達が集まってる業界です。競争の激しさもありますが、面白いゲームを作ることへのモチベーションも高い訳です。ゆるーい感じでホワイトを求めていきますと、ギャップがあるかもしれませんね。

〇作ったゲームがそのまま経歴になる。
例えば、格闘ゲームとRPGでは全く違う作りになる訳です。
たとえば格ゲーにおいて『これは常識・当たり前』と言った仕様があるとして、格ゲーを作りなれている人にはそれはわかりますが、経験の無い人にはわからない訳です。と言う訳で、経験したゲームのジャンルがめちゃめちゃ重視されます。プログラム能力以前の問題な訳です。
業務系システム開発においての『業務知識』と似たような扱いと言えるかもしれません。

6.しめ

いかがだったでしょうか。
すべて『プログラマー』の募集の話となりますが、各業態でここまで違いがあります。

いずれもプログラム能力は必要になりますし、プログラムを学習する習慣や、学校で学習した経験なども武器にはなるのですが、『プログラム勉強すればそれだけでOK』と言うのはウソです。

人気のある企業ほど応募者が多く集まりますし、その中で競争となる訳で、どれだけ自社とフィットした求職者かという部分を問われることになります。そこを確認する作業が、『面接』という選考過程ですね。

アンマッチな求職者を採用するという事は、企業にとってはこういう事です。
【採用予算1名分。教育予算一名分。離職（成果ゼロ）までの期間の給与。マッチしていた人物を採用できていた場合にその人物が稼いだ利益全額。その人物が育成などで間接的に貢献した利益全額】を失う（機会損失含む）

人気のある企業・マトモな企業ほど、人物的な合う合わないをキッチリ見てくると考えて頂いて、差し支えないんではなかろうかと思います。業界や企業の研究。自分の分析は、しっかり行っておきましょうね。