今こそ見直したい多重下請け構造—DXで内製化シフトは実現するか

あらゆる業界でデジタル化・DXが本格化するなかで、日本のIT開発における下請け構造が問題視されています。
つい先日も新型コロナウイルス陽性者との接触を知らせるアプリ「COCOA」において、2020年9月から接触通知が正しく機能していない状態を4ヶ月放置していたことが発覚。
発注元である厚生労働省から委託を受けた企業が別の企業に再委託していたことが判明し、多重下請け構造に原因があると、多くのメディアや有識者が指摘しました。

なぜ多重下請け構造が問題なのでしょうか。これはアプリ開発に限らず、多くの企業のデジタル化やDXにもつながっています。

そもそも、IT業界の下請け構造とはなにか

---

多重下請け構造によるシステム開発の一例を紹介します。

発注主はシステムベンダーにシステム開発一式を発注し、開発自体には一切関与しません。
対して、受注した一次請けのシステムベンダーは開発費用からマージンを確保したうえで別会社に発注。
場合によっては機能や役割ごとに複数の開発会社に再委託します。
さらにその二次請けのベンダーが必要に応じて別の会社に再委託するという仕組みになります。一次請けの企業は発注を請けた要件と納期に向けて、二次請けに委託した業務の進行と品質を管理するのが主な役割です。

開発フェーズにおいては一次請けがシステム開発の上流工程とされる要件定義や基本設計を担当し、詳細設計からコーディング、テストは二次請け以降の企業が担当するという分業で開発します。
下請け企業は自社で対応できる範囲のみ開発し、できない部分はさらに別会社に委託することで、低いリスクで経営できる利点があります。
ただ、途中階層にいる企業が管理コストだけを差し引いて下請け企業に丸投げするケースもあり、末端の企業は限られた予算で開発せざるを得ないといった問題も起きています。

こうした分業はモノづくりの伝統的な手法であり、製造業で例えれば工場を持たないメーカーから生産委託を受けたX社が自社でカバーできない範囲の工程を下請けに委託、電子基板はA社、外装はB社、ソフトウェアはC社が担当し、最後の組み立て・箱詰めはX社といったかたちで生産するケースも珍しくありません。

日本のIT業界は建設業や製造業のような下請け構造ではありますが、ITは完成したら終わりではなく、その後もバグの修正や改修を繰り返す必要があります。
つまり、システムの稼働初日からが真の本番なのです。その点において、完成後は修理やメンテナンス業務が中心となる建築業や製造業のモノづくりとは大きく異なる点は認識しておくべきでしょう。

多重下請け構造による開発の問題点

---

日本固有のウォーターフォール方式の多重下請け構造には、さまざまな問題が指摘されていますが、主に以下の２点に集約されます。

1.トラブルが起きた際の責任の所在が曖昧

冒頭で挙げたCOCOAが最たる例ですが、トラブルが発生した際に発注元は「開発会社側に問題がある」と言い、開発会社側は「このバグは当社の責任ではない」と反論するケースがあとを絶ちません。
こうした構造は問題の本質的な解決ができないだけでなく、トラブルの対応が遅くなる要因にもなります。

また、先に挙げたように開発実務を担う企業が受け取る報酬は、途中階層の企業が何重にも管理コストを差し引いている場合には、限られた予算でしか開発ができません。
そのため、トラブルが起きた際の人員追加ができず長時間労働を強いる原因に繋がる場合や、経験の乏しいエンジニアが投入されることによって、品質が下がりバグの温床になるといった構造的な問題もはらんでいます。

2021年初頭に大手金融機関の業務システムのソースコードが、委託先企業に勤務するエンジニアによって流出したという報道がありましたが、多重下請け構造では開発上の規約が遵守されず、モラルを欠いた行動によってトラブルが発生するケースもあとを絶ちません。

2.優秀なエンジニアが育ちにくい

多重下請け構造において、実際にコーディングを行うのは末端のエンジニアです。

三次請け、四次請けのエンジニアが二次請けの開発現場に送り込まれます。彼らが主に開発を担当するのは細分化されたモジュールや一機能の部品単位の案件が中心です。そのため、スキルアップがしづらく優秀なエンジニアが育ちにくいことが指摘されています。

また、多重下請け構造によって、末端のエンジニアが所属する会社への報酬も微々たる額になるため給与も上がりにくく、結果的に低待遇・低スキルの環境から抜け出せない点も課題です。
一方で一次請け、二次請けのエンジニアは管理業務が中心になるため、スキルのアップデートがしにくいことから、あらゆるレイヤーで業務を通じた技術力の向上が見込みにくい状況が起きやすくなります。

DXを進めるにあたっては、こうした外注依存体制は大きなボトルネックとなります。
効果的にDXを企業内で進めるためにはシステム開発に留まらず、業務改革や社員教育、部署間の横断的な連携を並行して進めながら、その過程で発見したインサイトや課題をシステムに反映するというサイクルが不可欠です。

その際、システムを外部委託していると、サイクルをスムーズに回せず、システム開発部分がネックとなって、DXが進まないという事態になりかねません。

Topへ

日本は海外と比較しても、ITベンダーへの依存度が高い

---

こうした多重下請け構造は先進国共通の事象なのでしょうか。

内閣府が2020年に発表した経済財政白書によれば、日本、アメリカ、イギリス、ドイツ、フランスの5カ国でIT人材が従事する産業を比較したところ、日本はIT人材がIT産業に偏在しているという結果になりました。

日本はIT人材の72.3％がIT産業に雇用され、非IT産業に雇用されている人材は27.7%に留まっています。
一方で欧米4カ国は半数以上が非IT産業に雇用されています。
ここから推測できるのは、日本では多くのIT人材がSIerで受託開発に従事する一方で、ユーザー側企業である非IT産業にはIT人材が圧倒的に不足しているという現状です。

経済財政白書ではIT人材が雇用される非IT産業の日米間比較においても、行政機関や教育機関の差を指摘しています。
日本では公務に従事するIT人材が0.5％に対し、アメリカでは5.6％。小中学校や高校、大学などの教育機関や塾などの「教育・学習支援」に属するIT人材は日本が0.3％、アメリカは5.1％とその差は歴然です。2000年以降、欧米を中心に行政サービスのデジタル化（GaaS：Government as a Service)が進み、日本でもGaaS実現に向けた実証実験や試験導入が進んでいますが、その役割を中心で担うIT人材がユーザー側の組織に不足したまま、質の高いサービス提供が実現できるのかは甚だ疑問です。

システム開発を外部に依存し、多重下請け構造が日本で起きやすい要因として、アメリカやイギリスのような雇用流動性がないことを指摘する声もあります。
しかし、米英と比べて雇用流動性が低いとされるドイツやフランスでも、ユーザー企業に雇用されるIT人材が多いことをデータは示しています。日本が欧米や中国のようなスピード感で社会全体のDXを実現させるには、ユーザー企業側のIT/DX部門への投資は欠かせないでしょう。

Topへ

多重下請け構造からの脱却はできるのか

---

IT業界側も将来を見据えたアクションを起こしています。
コロナ禍で日本でも企業や官公庁において、DXを意識したシステム開発が始まっていることを背景に大手ITベンダーが内製化やスキルアップを支援するアプローチを開始しているのです。

日本マイクロソフトはユーザー企業に3日間のハッカソン形式研修プログラム「Azure Light-up」や、数ヶ月単位でアジャイル開発を実践する「Cloud Native Dojo」を提供しています。
いずれも、ユーザー企業のシステム部門の内製化を支援する内容で、同社が提供するクラウドコンピューティングサービス群の「Azure」やソフトウェア開発プラットフォームの「GitHub」を活用しながらDXを推し進める狙いがあります。

また、AWSを提供するAmazonも2020年11月にNECとコーポレートレベルの戦略的協業を締結しました。
AWS認定資格保有者をNEC内で3000人体制にすることを発表し、DXに不可欠なクラウド技術に精通した技術者育成に本腰を入れて取り組んでいます。

デジタル化のフェーズではシステムは事業を下支えする役割でしたが、DXにおけるシステムは事業の中核であり、事業構造や各部門で働く従業員の行動や意識改革にも深く関わります。
非IT産業の企業においてもSIerなど外部のITベンダーのみに依存することなく、内製化を進めながら自走することを迫られる場面は今後増えていくでしょう。

真の解決策は主体性を取り戻すこと

---

IT業界の多重下請け構造は簡単に解消できる問題ではありません。
しかし、やみくもに内製化にシフトして単純にエンジニアを大量に採用しても、うまく機能するわけではありません。
また、「開発を内製化してDXを進めろ」ともっともらしく現場に丸投げをしても、なにひとつ合意形成されていないため理想と程遠い結果になります。多重下請け構造の最大の問題点は、発注側企業がシステム開発に対する主体性と意欲の低さにあります。意欲が低い状況を変えないまま、リソースを増やしたとしても付け焼き刃でしかありません。

まずは中長期的な視点からテクノロジーと事業の関係はどうあるべきか、どのような未来像を実現したかを経営層自ら考えることが内製化への第一歩です。そして、あるべきヴィジョンを実現する方法を社内で考えられる人材と組織に投資すべきでしょう。その上で、必要に応じて社内開発と外注を使い分け、社内・社外を問わず「指揮力」の高いエンジニアを育成することが、DXを遂行する強い原動力となります。

多重下請け構造の問題点をこれまで整理しましたが、開発を外注すること自体は「悪」ではありません。
現に欧米や中国においても、新興国の開発会社に外注するオフショア開発を採用するケースは珍しくありません。
日本の多重下請け構造の真の問題は、IT企業・非IT企業を問わずユーザー側企業がITに対する主体性を半ば放棄していることにあるのです。

DX時代において自分たちはどうあるべきかを考え、行動に移し、主体性を取り戻すことが日本企業には求められているのではないでしょうか。

IT業界の転職関連コンテンツ

---

IT業界の職務経歴書の書き方

---

• 外資IT営業職・セールス　職務経歴書の書き方【ダウンロードサンプル付き】
• 社内SE 職務経歴書の書き方【ダウンロードサンプル付き】
• ITコンサルタント　職務経歴書の書き方【ダウンロードサンプル付き】
• プロジェクトマネージャー（PM）職務経歴書の書き方【ダウンロードサンプル付き】
• データサイエンティスト 職務経歴書の書き方【ダウンロードサンプル付き】
• ネットワークエンジニア 職務経歴書の書き方【ダウンロードサンプル付き】
• インフラエンジニア 職務経職務経歴書の書き方【ダウンロードサンプル付き】
• IT業界　プリセールスエンジニア職務経歴書の書き方【ダウンロードサンプル付き】
• IT業界 営業職・セールス　職務経歴書の書き方【ダウンロードサンプル付き】
• IT業界 ITテクニカルサポート 職務経歴書の書き方【ダウンロードサンプル付き】
• システムエンジニア（SE）の職務経歴書の書き方｜具体的な記載事項から面接官が見ているポイントまで徹底解説

転職サポート　サービスの流れ

---

• Step 1ご登録

  

  まずはご登録ください。弊社コンサルタントから、ご連絡いたします。

• Step 2面談・求人紹介

  

  業界・職種に特化したコンサルタントが、複数人であなたをサポート。
  最適な求人・キャリアプランをご提案いたします。

• Step 3応募・面接

  

  ご提案求人の中から、ご興味いただいた企業へ、あなたをご推薦します。
  レジュメ添削、面接対策、スケジュール調整は、コンサルタントにお任せください。
  

• Step 4内定・入社

  

  条件交渉や入社日の調整などをお手伝いいたします。
  ご要望によって、円満退社に向けたアドバイス等も行っております。

• Step 5アフターフォロー

  

  ご入社後も、キャリアについてご相談がございましたら、お気軽にご連絡ください。
  人生を共に歩むパートナーとして、あなたのキャリアをサポートし続けます。