見出し画像

2020年現在の日本のIT業界とDXと

はじめに

2020年はコロナ渦で世の中は大きく変わりました。とくに働き方は変わり、リモートで働く人も増えました。業界によって業績も様々だと思いますが、幸いなことに私のいるIT業界の需要は比較的多いように感じます。IT業界の端っこにいる私ですが、このような情勢の中で、ある目標ができました。この記事の前半部分では日本のIT業界の問題点を振り返り、後半では2020年現在のDXへの追い風、そして私の目標について書きます。

受託企業と自社開発企業

御存知の通り、日本でIT企業というと受託でシステムを作る会社と、自社のサービスを作る会社にざっくり分けられます。有名どころであれば受託企業は株式会社エヌ・ティ・ティ・データ(NTTデータ)や株式会社野村総合研究所などです。これらの企業は受託企業の中でも「上流工程」を行っている企業と認識されています。以下、これらの企業のことをSIerと書きます。また、「下流工程」という部分を行っている企業もあります。その多くは中小企業や、大手でもそれを専門に行なっている会社です。

逆に自社開発を行っている企業は楽天株式会社やヤフー株式会社など、多くはベンチャーやメガベンチャーと言われる企業です。

私の観測範囲ではどちらかといえば受託開発が敬遠されています。「受託開発の上流では技術が身につかず、下流はブラックだ」という具合です。なぜそのように言われるのでしょうか。そこには日本独特のIT企業の問題があります。

日本とアメリカの違い

よく日本のSIerと比較されるのはアメリカの企業です。アメリカのITエンジニアの多くは、ユーザー企業(ITを本業としない製造業など)にいる割合が多いと聞きます。逆に日本のITエンジニアはSIerなど、ITを本業とする会社にいます。なぜなら、日本のユーザー企業はITエンジニアを抱えてしまうとアメリカと違って、ITへの投資を中止したくなったときに簡単に人を解雇できないからです。

そのため、日本のユーザー企業はシステム専門の子会社を作り、そこでITエンジニアを雇うという戦略をとります。しかし、常に親会社がITへの投資を行っているわけではないので、その子会社は外販(親会社以外のシステム開発)を始めます。それらの子会社はユーザー系SIerと呼ばれます。例えば以下のような企業がユーザー系SIerと呼ばれます。

  • 伊藤忠テクノソリューションズ株式会社(伊藤忠商事株式会社)

  • 日鉄ソリューションズ株式会社(日本製鉄株式会社)

  • SCSK株式会社(住友商事株式会社)

ユーザー系SIerを作る会社は大手が多いので、その子会社も比較的大きな企業が多いという印象です。そのため日本のITエンジニアが相対的にSIerに多く勤めているのではないでしょうか。

下請け構造

日本のSIerは下請け構造という特徴があります。なぜ下請けになるのかと言うと、一つの理由は大手のSIerは営業力が強く、社内のリソースに関わらず契約が取れます。社内のリソースが足りなければ下請け(パートナーと呼ばれる)に回すことでシステム開発が可能になります。

要件定義・設計・人員配置・マネジメントなどは大手のSIerが行うことになりますから、必然的に下請けに出されるのは実装やテストなど、いわゆる下流工程と呼ばれる部分になります。

下請けは中堅のSIerや中小の開発会社、SES(System Engineering Service)企業です。プログラミングスクールやプログラミング学習サービスがたくさんある今の時代、プログラマーになりたいという人材は多いのでその裾野は広く、元請け企業にリソースがなくても案件がこなせるというのが現状です。

また、この下請け構造では要件定義・基本設計・詳細設計・実装・単体テスト・結合テスト…と順番に行っていくウォーターフォール開発がマッチします。

下請け構造の問題点

1. 品質低下や納期の遅延を招く

※ この部分は私の想像がかなり含まれています。

下請け構造は当然問題が多く、それが一部のITエンジニアからSIerが嫌われているところでしょう。わかりやすいのは7payでしょうか。7payは株式会社セブン・フィナンシャルサービスが運営しようとしていた決済サービスですが、SNSなどでは数社のSIerが受注し、下請け企業が開発したのではないかと言われています。

開発自体は下請け企業のITエンジニアが多く関わっていると思われ、ユーザー企業としては末端のITエンジニアの技術力を把握するのが難しいです。ユーザー企業からすると窓口は取り仕切っている大手のSIerですので、スケジュールの遅延などがあればそこに文句を言います。そしてSIerは下請け企業に無理を言います。下請け企業は大量に採用した初心者を使っていることも多いですから、あまり質の高いコードを書けないこともあります。納期が短くなればなおさらです。

QRコード決算はPayPay株式会社や楽天株式会社など、自社にITエンジニアを抱える企業も開発をしているため競合が多いです。(7payはセブンイレブンでの決済を考えていたと思うので競合ではないかもしれませんが)

そのため、7payもスピードを重視していたのでしょう。要件定義を行って必要な人材を配置し、設計に数ヶ月かけて、実装、テストと順に行っていくウォーターフォールではスピードが出ず、下請け企業に無理なスケジュールを課していたのではないかと想像できます。その結果がサービス中止でしょう。

※ 繰り返しますが、7payが実際にそうだったかはわかりません。

2. 社内にノウハウがたまらない

自社開発と違って実際に開発を行ったのは自社の社員ではないので、社内にノウハウもたまりません。

3. 社内にシステムが分かる人がいないとぼったくられる

ユーザー企業がERPなど、企業の運営に関わるシステムを導入している場合、簡単にそのシステムを入れ替えることはできません。ですから、SIerに依頼するとボタン一つ変えるだけで数百万円〜数千万円という請求になる場合もあるそうです。

4. エンドユーザーにとって不便なものが出来上がる

下請け構造では自分のいる会社の上流がお客さんですから、ビジネスのことだけを考えるとエンドユーザーにとっての便利さよりも直接のお客さんにとって正しいものを提供する意識になるでしょう。未だにネットバンキングシステムなどで「エラーコード:001」のような表示を見かけます。これはエンドユーザーにとってはどうでもいい情報ですが、設計をする際に会社間での齟齬が少なくなるようにそういう仕様になっているのではないかと想像できます。

AIなど特定領域では当てはまらないことも

2020年12月現在、私の所属している会社はAIの開発を行うベンチャー企業で、BtoBのAIも開発しています。この分野ではその企業独自のノウハウもあるため、我々のような小規模のベンチャー企業と大手の企業が直接契約を結ぶことも多いです。単純なシステム開発ではなく、特定の技術ではこの下請けの構造に当てはまらないでしょう。

AI分野にも問題点がある

数年前から一般企業でもAIへの注目が高まり、自社のサービスに取り入れたいと考える企業が増えました。ただ問題なのは、その企業の問題解決にAIが最適ではないことも多々あるということです。たとえば、現在エクセルで行っている作業をAIを使って効率化できないかという相談があった場合に、それはAIではなく単純にパッケージソフトを導入したりBIツールを導入すればすむ問題である可能性もあります。

しかし、ユーザー企業の上層部がAI投資に前向きだったり「AIを使って○○しました」というプレスを打ちたいような場合は、それでもAIが売れてしまいます。また、AIを売りたい企業も自社のサービスを売りたいので、最適解ではなかったとしても売ってしまいます。一見両者にとって有益のようですが、実際には現場の役に立っていないという状況があるかもしれません。現時点でユーザー企業がAIを効果的に使うのは難しいですし、それをコンサルティングできる人材も多くないでしょう。

IT業界は変わらなければならない

ここまではSIerの構造の問題を見てきました。このような問題があるため、日本のITが遅れていると言われたり、一部のITエンジニアからSIerが嫌われたりという状態になっています。

製造業をはじめとして日本の企業のポテンシャルはまだまだ世界に負けていないと思っています。ただ、今の時代ITが遅れたままでは人材や市場規模も大きい中国やインドに負けてしまうでしょう。日本の企業も単なる業務効率化だけではなく、経営戦略としてITを活用することが重要だと考えます。

普通に考えて、IT業界は変わらなければならない状況です。単純な業務効率化に関してはシステムを作らずともすでにあるものを使うことが多くなっていくでしょうから、その辺りはITコンサルティングファームの分野になります。経営戦略としてのITはいわゆるDX(Digital transformation)と呼ばれるものになっていくでしょう。

では製造業なども社内SEを増やして自社開発をやっていくのが良いのでしょうか。もちろんそれが1番だと思います。しかしそれだと最初に書いたように新たなユーザー系SIerが生まれるだけです。日本においてはこれからもしばらくはSIerと一緒に仕事をするというのが主流だと思います。それでも下請け構造を抜け出す必要はあるでしょう。

AI企業の例もありますから、小さな会社が一社で大手企業のシステムを作り上げることは、可能か不可能かで言えば可能だと思います。AI企業などでそれができているのはアジャイル(スクラム)での開発を行っていると言うのが一つの理由だと思います。アジャイル開発は、リリースできる状態のシステムを少しずつ大きくして行くという開発方法で、ウォーターフォールとは比較されます。

社会的なDXへの流れ

大手SIerもユーザー企業も変わらなければいけないでしょうが、今は時代的に追い風ではないかと思います。そう思うのは次のような時代の流れがあるからです。

  • 下請け構造は業界の中でも問題視されている

  • コロナウィルスによって保守的な企業もDXに向かい始めた

  • 経済産業省が中心となってDXを推進している

  • デジタル庁設置の流れ

変化を妨害するもの

SIerが変わるためにはアジャイル開発で行うのが一つの解決策だというのが個人的な考えです。しかしそのためにはいくつかの問題があります。

1つ目はユーザー企業が開発についてある程度理解しなければいけないことです。アジャイル開発は短い期間で開発・確認を繰り返しますから、ユーザー企業も丸投げというわけには行きません。また、そのシステム開発が終わったあとには自社で運営するためのノウハウも社内に蓄積する必要があります。そうでなければこれまでの開発と変わりません。そのため、少なからず負担はかかります。

2つ目はITエンジニアの人材不足です。アジャイル開発は少人数のチームで、それぞれのメンバーがある程度複数の領域の開発を行わないといけませんから、一人ひとりの求められるレベルが上がります。プログラミングスクールで数ヶ月勉強しただけというITエンジニアでは難しい仕事になっていくかもしれません。そのため人材は不足しそうです。逆に、相対的にITエンジニアの地位は上がるとも考えられます。

一番問題なのは、これまでの慣習があるので変化はかなり遅いだろうということです。

最後に個人的なこと

私はBtoC・BtoB・スタートアップ・一部上場企業など、IT業界の中でいくつか経験しました。その中で必ずしも皆が望んでいる働き方やビジネスにはなっていないということを知っています。だから日本のITを変えたい思いました。そしてそれが私の2021年からの目標です。IT業界の端っこで、できることは小さいですが、ほんの少しでも貢献できればと思っています。

具体的には、これから私が関わる開発では本格的なアジャイルで行う予定です。他の会社にも誇れるような成功事例を作るのが直近の目標の一つです。それらを発信し、真似されるようになって、業界のスタンダードが少しずつ変わり、下請け構造がなくなっていくような文化づくりに貢献できれば、これ以上のことはありません。

この記事が気に入ったらサポートをしてみませんか?