「DXにはシステム内製化がいいの？」
「システム開発を内製化する方法を知りたい」
このように、DXのためのシステム内製化に対して多くの疑問や不安があるのではないでしょうか。

本記事では、DX推進にシステム内製化が注目されている理由に加え、内製化することによるメリットとデメリット、さらに日本国内おいてITエンジニア内製化の現状などを紹介しています。

この記事を読むことで、自社でシステム開発・運用を完結させる有用性やシステム内製化が生まれた背景を把握することができます。その知識をもとにシステム内製化を導入する判断がスムーズにできるようになるでしょう。

システム開発の自社運用を考えている方は、ぜひ、最後まで読んでみてください。

DXのためにシステムの内製化が注目されてきている理由

以前は、DX推進のシステム構築を外注する企業が多かったのですが、現在では自社で開発・運用する動きが目立っています。

その理由として、マーケットの変容やビジネス展開のスピードが上がってきたことがあるでしょう。外注の場合、システム障害のトラブルやシステムの再構成に迫られたときにどうしても対応が遅れてしまいます。

システム内製化を施すことで、これらの課題の解決に貢献する可能性が大きくなります。

内製化で考えられるメリット

従来、日本では社内システムをSlerやベンダーに任せていた企業が大半でした。

しかし先ほども触れたように、現代では目まぐるしく変わるビジネススピードに対応することが重要とされていることから、システムの内製化が推められています。自社の運用状況次第では、システム内製化によってメリットが大きくなることもあるでしょう。

ここでは、システム内製化によるメリットを紹介します。

開発や改善の速度を向上できる

システム内製化による大きなメリットは、開発や改善するスピードの向上でしょう。

例を挙げると、システム開発を外注する場合、社内会議を行いシステム案を形にした状態で発注をかけ、先方と調整した上で詳細を詰めていきます。また機能改善では、外注先と連絡を取り合うため、その都度手間と費用がかさんできます。

これらはシステムを内製化することで、自社で完結させることができ、スムーズな開発と運用が可能になります。

ノウハウやナレッジの蓄積ができる

システムを内製化すると自社で開発や運用を行うため、ノウハウやナレッジが蓄積されていきます。

緻密なデータや分析によるビジネスが主流となっている現代では、情報を活用できる人材は欠重宝されます。外注した場合だと業務フローこそ記録されますが、システム開発の肝となる部分は把握できません。

システム内製化で得たノウハウや知識は、資産としての価値も付随されるため長期的に見てもメリットとなるでしょう。

システムがブラックボックス化することを防げる

システムの内製化は、外注した場合に陥りやすいブラックボックス化を予防することにもつながります。

システム開発を外注すると業務の大半は自社で行いません。したがって、外注先との契約が終われば開発や運用がブラックボックス化してしまいます。それまでに人材が育っていなければ、育成に時間をとられビジネスに遅れをとるでしょう。

社内で蓄積されたノウハウがあれば情報の共有ができるため、トラブルにも対応できます。

内製化で考えられるデメリット

DXのためのシステム内製化はメリットだけではありません。

自社でシステム開発をするということは、それまで外部に任せていた業務を一手に担うようになり、開発のクオリティを維持することが困難になりがちです。また、内製化することによる課題も表面化してくる場合があるでしょう。

ここでは、システム内製化で考えられるデメリットを紹介します。

大規模な開発には見合った数の人員が必要になる

システムの内製化に移行することで小規模な開発には対応できますが、規模が大きくなると開発リソースが不足しがちになります。

たとえば、レガシーシステム関連は多くの技術者を必要としており、外部の力を借りることが一般的でしょう。

自社でDX推進を図る場合は、想定以上の人員を確保する必要があることを留意しておくといいでしょう。

人材不足のため採用に手間がかかる

現在、日本国内ではITエンジニアが不足しているため、人材確保が困難な状況にあります。

経済産業省が行った調査によると、2019年を境にITエンジニアの数は減少に向かい始めており、将来的には40～80万人の規模で不足するというデータが発表されています。

一定水準以上のキャリアとスキルを持つ人材は、給与が高く設定されている海外に流出していることもあるため、優秀なエンジニアが見つかりづらい状況にあります。

出典：参考資料（ＩＴ人材育成の状況等について）　IT人材需要の変化①｜経済産業省
参照：https://www.meti.go.jp/shingikai/economy/daiyoji_sangyo_skill/pdf/001_s03_00.pdf

人材を育成しようとすると時間を要する

システム開発に携わる人材育成は容易ではなく、数ヵ月あるいは数年間もの時間を必要とします。

採用した人材のスキルや経験によって育成スピードは変わりますが、長期的な取り組みが欠かせないため、どうしても時間がかかるでしょう。

企業の経営状況によって外部に発注するのか、または時間をかけて育成するのかという点を見定めることが肝要です。

極端に低い日本のITエンジニア内製化率

あまり知られていないことですが、日本のITエンジニアはほとんどがシステム開発企業に所属しています。驚異的なことにこの比率はアメリカに比べるとマイノリティーが逆転していますので、大きく違うことが伺えます。

アメリカは開発スピードや品質を重視し、当たり前のように自部門でエンジニアを抱えるのに対し、日本は開発会社に全てお任せ、これが日本流の開発スタイルと言えます。釈迦に説法かと思いますが、内製開発と外部請負開発での差はかなり大きく存在します。

開発スピードは内製化がはるかに上回り、スケジュール内の開発であればコストもおよそ3~4割ほど変化すると言われています。一方でスケジュールをオーバーした場合、内製開発の方がコストが高くなるというのはリスクとして存在しています。

なぜ開発会社へのお任せスタイルが生まれたか

この理由についてとてもわかりやすく越えられる壁と越えられない壁の２点が存在すると考えます。

・開発マネジメントをする能力を企業が有していないためスケジュールオーバーリスクを踏めない（越えられる壁）
・社内の開発プロジェクトは日々変化することに対して「雇用」は流動性が低く、中長期を見据えて自社で雇えない（越えられない壁）

上記のうち後者については、特にアメリカにおいては真逆の状況です。

そもそもアメリカは日本と比較すると、雇用というスタイル自体が流動的です。開発プロジェクトが変化し続けるということに対して流動性の高い雇用スタイルというのはとても相性が良く、企業が雇用を推進する後押しになっていると考えます。

それでは日本はもうこのままいくしかないのか？について我々は解を持っています。

日本型雇用の仕組みを変えずとも実現できるハイブリッドチーム構想

僕は日本雇用の仕組みを変えてくれと国に働きかけますということはするつもりはありません。

なぜならこれを解決するためには、特に需給バランスにおいて、業種ギャップや年齢別ギャップがあまりに激しい中、雇用のマクロ理論に触れていかなければならないからあり、他方、時間が解決するからと思っているからです。

ただし、この時間経過を待っているわけにはいかないため、既存のシステムに触れず、常識の変革を行いたいと思っています。

それが前回説明をした業務委託や派遣、週2~3、技術顧問などが混在するハイブリッドチームです。これはチーム流動性がとても高く、この流動レベルはアメリカの雇用状況と非常に近しいものを実現できると思っています。

これにより企業がリスクを恐れずに内製化を実現できる常識をつくりたいと考えています。

日本のDXスケジュールは想像を超えてなだらかである

この内製化構想は我々が実現するに10年かかるものと思っています。どのような時間軸で内製化に関わるDXが動いているか、我々はこのように考えています。

市場段階1　ツールを導入し業務DXを実現する
＝SaaSプロダクトの急伸
市場段階2　ツールの共存や、業務レベルアップに向けて開発需要が出る
＝システム開発会社の急伸
市場段階3　事業拡張を目的としたシステム化や複雑なシステムニーズ
＝内製化関連サービスの急伸

現状のボリュームゾーンは段階1~2であり、我々のサービスを利用していただいている企業様は早期にDXを実現できている企業様であると考えています。

我々は段階3へ移行を推進するとともに、あるべき段階3をつくることで日本のITレベルは急速に発展できると確信しています。

BEのエンジニアリング事業は、本質的内製化によってIT革新を起こす

Branding Engineerは外から見ると「日本の内製化率を下げに行っているのではないか」と思われると思いますが、真逆です。日本のIT革新には内製化は必須であり、その本質を我らはつくりたいと考えています。

ITエンジニア内製化に取り組みたい企業様はぜひお力にならせてください。コンタクトフォームは以下です。