こんにちは。倉内です。
DX化の流れに後押しされ、自社内に開発組織を立ち上げて外注を内製に切り替えた、もしくは切り替えたいと考えている企業が以前より増えてきたように思います。
日経クロステックの記事でもその点について触れられており、また旧来の受託開発の多重下請け構造を改めて問題視し、エンジニアの生き残る道として、ユーザー企業への転職もひとつの案として書かれていました。
そういった背景もあってか、特に未経験や新卒からエンジニアを目指す方は、自社サービスを開発する企業に行きたいという方が多いようです。
一方で、「ユーザー企業の内製化で受託開発企業の仕事がなくなる」と言われ続けながら、受託開発という業態をとる企業がいまだに日本のIT業界の大きな割合を占めているのも事実です。
ただ、まったく変わっていないように見えて、少しずつその実態は変化しています。そこで今回は、生き残る企業・淘汰される企業の特徴と、これからの受託企業の在り方について考えてみたいと思います。
これまでの日本のIT業界事情
すでにエンジニアとして働いている方は、肌感としてIT業界やIT企業の現状を理解していると思いますが、これから業界へ入ろうとしている方には感じにくい部分もあると思います。
そのためまずは総務省の発表している「情報通信白書」などを参照しながら日本のIT業界を知っていきましょう。
日本の情報サービス業の多くを占める「受託開発」
以前別の記事で、日本は受託開発企業が多く、エンジニアもユーザー企業よりベンダー企業に多く属しているとお伝えしたことがあります。
令和3年版の「情報通信白書」を見てみても受託開発ソフトウェア業の企業数は大きな割合を占めており、売上高も増加しています。
（出典）総務省「令和3年 情報通信白書」第4章 ICT分野の基本データより
また、IPAが公開している「DX白書2021」では、日本企業はパッケージソフトウェアを利用する場合もカスタマイズするケースが多いという特徴についても述べられています。受託開発企業側としては、そのままの利用ではなく、顧客ごとにカスタマイズが発生するほうが高い見積もりを出すことができます。
資本金規模で変わる元請け・下請けの割合
受託開発が批判される大きな要因は、冒頭でも挙げた多重下請け構造です。
システム開発の発注をユーザー企業から直接受ける企業を元請け、それ以降を一次下請け、二次下請け……と言い、みずほ銀行のシステム統合プロジェクトでは、七次請けまで存在したとの噂もありました。
「情報通信白書」では、「資本金規模が大きくなるに従い、元請けの割合が増加し、下請けの割合が減少している」と述べられています。
（出典）総務省「令和3年 情報通信白書」第4章 ICT分野の基本データより
元請け企業は顧客との要件調整、プロジェクト管理に費用や人員を割き、マージンを取って下ろしていくわけなので、当然元請けよりも下にいくほうが機能が細分化・単純化され、かけられる人件費が安くなっていきます。
よってユーザー企業から遠い位置にいればいるほど、ITエンジニアとしてのスキルがつきにくい環境になりがちです。
前述のみずほ銀行の件もそうですが、銀行はもちろん電気・ガス・水道、鉄道やバスなどの公共交通、警察や消防・救急、そして官公庁など、システムには大規模かつ24時間の稼働を前提とした「社会インフラ」に関わるものが多くあります。
そういった複雑な開発案件を1社で請け負うのは非常に難しく、このような構造が作り上げられていったと言えます。
なぜ受託開発がここまで存在感を増したのか
受託開発企業が多い理由はさまざまだと思いますが、ここではふたつの理由に触れておきたいと思います。
１．顧客のシステム導入理由は「効率化」「コスト削減」
かつてユーザー企業のシステム導入の目的は、既存業務の効率化やコスト削減でした。もし開発のために人を採用したとしても、システムが完成してしまえば人員の大半は不要になってしまうため、一時的に利用できるリソースを求めていました。
また、さきほど日本は米国に比べるとIT人材がユーザー企業よりベンダー企業に多く属していることに触れました。
ご存知のとおり、日本では特に新卒の場合、ITエンジニアという職種であっても大学での専攻を問わず採用します。もちろん、即戦力採用や研究・開発など例外もありますが、米国のようにコンピュータサイエンスを学んでいなければ入り口にも立てないといったことはほとんどありません。
つまりプログラミングをやったことのない人にも、ある程度の教育をおこなえば開発業務を任せられる分業体制がとれるとも言い換えられます。
分業しやすいというのは、下請けに仕事を出しやすいことにもつながります。大規模なシステム開発であっても、機能別に（ときには複数の企業に）外注ができるからです。
なぜこういったことが可能だったかといえば、顧客の既存業務をシステムで実現すればよかったからにほかなりません。
そして何よりも発注側にITに明るい人材がおらず、ベンダー企業に一任する（悪く言えば丸投げする）しかなかったという事情もあるでしょう
２．比較的軌道に乗せやすいビジネスである
もうひとつは、システムの受託開発が比較的成功する算段が立てやすいビジネスモデルであることが挙げられます。
案件さえ取って来ることができれば、顧客が必要としているシステムを作るという点で費用回収の見込みがあります。また、決まった要件と納期を実現するために必要な人員は……と逆算しての見込みも立てやすい。
逆に言えば、自社サービスで利益を出すのは非常に難しいということでもあります。
「革新的で斬新なアイデアだ！」と思ってもひとつも似たようなサービスがないというのはまれだと思います。あるいは唯一のアイデアだったがユーザーニーズがないというケースもあります。世に出しても利益が出せず、短期で事業をたたむITスタートアップ企業も数多くあります。
誰もが知っているサービスやアプリを開発している企業も、最初は受託との並行で事業を安定させていたところもあります。
受託開発企業を取り巻く環境の変化
かつて「キツい・ツラい」と言われたIT業界も変わりつつあります。
受託開発の企業、とりわけ大手SIerなどでは、ワークライフバランスやダイバシティを推進し、ひと昔前に比べると随分働き方も変わりました。同時にユーザー企業も事情が随分変わってきています。
ここでは主題である環境の変化で淘汰される受託開発企業・生き残る受託開発企業とはなにかについてお伝えします。
IT化の目的は「新たな価値創出」へ
さきほど述べた通り、以前はユーザー企業がITシステムを導入するのは既存業務の効率化やコスト削減が目的でした。
しかし、現在は新たなビジネス価値創出、いわゆるDXを目的としたケースが非常に多くなっています。
新たな価値を生むには、既存業務を単にシステム化するだけでは物足りません。IT技術やデータを活用した新規事業の立ち上げやビジネスモデルの抜本的改革などを実現するために、システム導入にあたって求める要件は大きく変わってきます。
わたしは以前SIerに勤めていましたが、そのときすでに長い付き合いでシステム開発に口を出したことのないユーザー企業が、「費用が安くて動きが早い、さらに新しい提案もしてくれるベンチャー企業にお願いすることにした」と態度を一変させた例がありました。
それはユーザー企業にITに明るい人材（世代と言ってもいいかもしれません）が増えてきたことも一因です。取引きのあるベンダー企業になんとなく任せ続ける時代は終わりつつあるのかもしれません。
受託開発企業の明暗を分けるのは何か
ユーザー企業の内製化は簡単ではない
そうは言っても、受託開発がいますぐなくなる、もしくは将来に渡ってみても完全になくなるわけではないと考える理由があります。
それはユーザー企業がシステム開発を内製に切り替えるのは簡単ではないからです。すでに社内に情報システム部門（情シス）があったとしてもその役割はまったく異なります。
まず、自社内に開発を担う部署もしくは人材が存在しない場合、パッと思いつくだけでも以下のようなことを実行していかなければなりません。
- 内製化を進めるリーダー（CTOなど）を置く
- 自社内で開発ができるエンジニアを育てるもしくは採用する
- 開発を担う部署・人員が継続して仕事をできる仕組みをつくる
- エンジニアの給与テーブルや評価制度、キャリアパスを整える
受託開発をやめるということは、これまで外に任せきりだったことを自分たちで考えて答えを出すということでもあります。ほとんど「社内改革」と言ってもいいくらい大きな変化が求められます。
しかも実務経験のあるエンジニアは市場価値が非常に高く売り手市場で、採用難度が高いのが現状です。（参考：【2022年1月】ITエンジニア採用のための最新動向情報！新規求人倍率・転職者の応募状況まとめ）
そのため、まずは自社用の独自仕様をなくし既存ツールやパッケージを適用する、社内システムの開発だけでも自社でやってみる…など外注の割合を減らす方針をとるのが現実的だと言えます。
paizaが運営するエンジニア組織づくりの情報提供メディア「Tech Team Journal」でも、当時のセガ エンタテインメントをM&Aし、内製化に取り組んだCTO（現、CPO）のインタビュー記事を掲載しています。その道のりが平坦なものではないことが分かっていただけると思います。
新しい受託開発への適応が「生き残る企業」の条件
顧客の事情が変化しているということは、その変化に合わせて仕事を請ける側も変わっていく必要があります。
もっといえば、多重下請け構造の中に組み込まれたまま、従来どおり仕事を続けていき、うまくいかなくなったら従業員を切り捨てるような考えの受託開発企業には未来がないということです。
一方、すでにユーザー企業に入り込みITを活用してビジネス課題を一緒に解決していく、もしくは内製化にあたって必要なノウハウを売るといった仕事にシフトしている受託開発企業もあります。この場合は「DX請負」や「内製化請負」といったほうが正しいかもしれません。
さきほど挙げたとおり、ユーザー企業が外注をやめて内製に切り替えるのは簡単ではありません。そこでシステム開発だけを請け負うのではなく、トータルして内製化を支援する役割を担うことで、新たな価値を提供します。
たとえば、株式会社ゆめみはこれらを体現している企業のひとつです。
別の例として、SIerが下請けの管理業からユーザー企業のIT化のコンサルティング業へ転身しているケースが挙げられます。大手SIerの業績が非常に好調だということも合わせて見ておきましょう。
（参考）大手SIer上方修正相次ぐ上期決算 “DX投資”は向こう数年続く見通し - 週刊BCN+
いずれにしてもこれまでの発注側・請負側の上下関係を脱して、顧客がIT化/DX化によってビジネス的な価値創出を試みる上でのパートナーになることが重要です。
受託開発のエンジニアが考えるべきこと
旧態依然とした仕事のやり方を続けている企業はいずれ淘汰されてしまいます。もし現状に不安があり、環境を変えたいのであれば転職に踏み切るのもひとつの手です。
paizaはITエンジニア専門の転職サービスを運営しています。まずは求人票を眺めるだけでも視野が広がります。生き残る企業を見極めるのは簡単ではないかもしれませんが、そういった視点を持つことが大切です。
そして、これからIT業界を目指す方は、「自社サービス開発だからいい、受託開発だから悪い」という考えではなく、
- 自分はエンジニアになって何をしたいのか
- 自分は仕事をする上で何にやりがいを感じるのか
という視点を持って企業選びをしてみてください。
さきほどお伝えしたとおり、受託開発企業は「決められた要件に沿ってシステムをつくる」から範囲が広がり、よりユーザーとのコミュニケーションをとることや技術的スキル以外を求められるようになっています。
自社サービス開発企業でもユーザー視点やサービス理解は求められますが、高い技術的スキルが必要とされるところも多いため、ハードルは高めです。
ただ、言えるのはITエンジニアの仕事としてイメージする「コードを書く」というのは、業務の一部であるという事実です。
まとめ
ここまで日本のIT業界について理解しながら、ユーザー企業の変化やそれに伴う受託開発企業の在り方について考えてきました。
わたしは新卒でSIerに入り、その後今のpaizaへ転職しました。数多くあるIT企業のすべてを知るわけではありませんが、受託も自社サービスもそれぞれにやりがいや大変さがあると思います。
これからIT業界を目指す学生の方や、業界未経験からがんばってエンジニアを目指している方にとって、「自分がエンジニアという仕事を通して何を成し遂げたいか」という視点で就活や転職を考えるきっかけになれば幸いです。
paizaは若手・未経験者向けのエンジニア転職サービス「EN:TRY」、新卒学生向けの「paiza新卒」も運営しています。
EN:TRYには、開発経験がない人・少ない人でも応募できる若手チャレンジ求人を中心に掲載しています。スキルチェック問題を解いて、スコアが一定基準を超えれば、事前の書類選考なしで複数求人へ応募できます。
EN:TRYについて詳しくはこちら
paiza新卒について詳しくはこちら
また、「paizaラーニング」は、未経験者でもブラウザさえあれば、今すぐプログラミングの基礎が動画で学べる学習サービスです。
詳しくはこちら
