以前、みずほ銀行、駿河銀行、7payのサービス停止が話題になりましたが、これに限らずIT系の炎上プロジェクトの話題は常に絶えませんね。私も炎上プロジェクトの助っ人に行きまくっていました。
誰だって炎上プロジェクトにはかかわりたくないとは思いますが、いかんせんSIer的な業界構造やビジネススタイルには、個人の努力だけでは解決しきれない問題を抱えています。
というわけで今回は、IT業界の構造がどうなれば問題解決につながるのだろう…という話を、エンジニア目線で考えてみました。
現実的にはなかなか難しいこともあるかと思いますが、元SIerのエンジニアの個人的な考えと思って読んでいただければと思います。
日本のIT業界（特にSIer）における問題
専門知識のない人が雇用される
ほかの分野の仕事、たとえば食品化学系や医療系などでは、大学などで専門的な勉強をしてきた人でなければ就職できないでしょう。
私は情報系の専攻でしたが、近いところでは電気系や機械系の仕事でも、それらの専攻や研究をしてきた人がつくケースがほとんどです。あとは研究職や、士業などの資格が必要な仕事などは言うまでもありません。
しかし、なぜかSIerは違います。ITのIの字も知らないような人も雇用して、最低限の研修だけで開発現場に送り込んでしまう。
システム開発を仕事にするというのは、そんなに簡単なものではありません。
そもそもできる人とできない人では、生産性がまったく違います。
ソフトウェア開発プロジェクトについて書かれた書籍『ピープルウェア』では、優秀なプログラマと成績の悪いプログラマの生産性には約10倍の差があるという記述があります。『ソフトウエア開発 55の真実と10のウソ』でも、エンジニア個人においては、5から28倍のスキルの差があるとまとめられています。
- 作者: トム・デマルコ,ティモシー・リスター,松原友夫,山浦恒央
- 出版社/メーカー: 日経BP
- 発売日: 2013/12/18
- メディア: 単行本（ソフトカバー）
- 作者: ロバート・L・グラス,山浦恒央
- 出版社/メーカー: 日経BP出版センター
- 発売日: 2004/04/08
- メディア: 単行本
「何倍になる」の数値に関しては諸説あるので置いときますけど、要は昔からいろいろな研究者や技術者が「システム開発って、人によって生産性にすごく差が出るよね」と言いまくっているということです。
向いていなくて知識も足りていない人たちが10人集まって一週間かかっても作れないシステムでも、一人の優秀なエンジニアがいれば3時間で完成させられちゃう…みたいな事例がしょっちゅう起きています。
これは、向いているから優れている、向いていないから劣っているという話ではありません。前提知識のレベル感も適性もまったく無視された雇用が横行しているのが問題だととらえています。
ウォーターフォールの多重下請け構造
雇用だけでなく、ビジネス的な構造にも問題があります。
（この手の考えを記事にするとSIer叩きと言われたりするわけですが、私自身SIer出身で、SIerにいたことで成長できた自覚と恩がありますし、大規模な開発にはSIerが必要であると思っています。私が問題視しているのは、あくまで多重下請けの構造です）
多重下請け構造とは、受託システム開発において、発注元企業から直接仕事を請け負った元請企業が、その仕事を分割して下請け企業に下ろし、一次請け、二次請け、三次請け、四次請け……と下請け企業がさらにその下請けに仕事を分割して下ろしていくピラミッド型の構造です。
このピラミッドが大きくなればなるほど、正しく要件定義をして正しく必要なものをつくる、PMやPLが正しくチームをまとめあげる…といった当たり前の仕事が難しくなってしまいます。
加えて、中間の企業はマージンを抜いてから下層のn次請け企業に業務を委託していくため、下層になればなるほど下りてくる金額は安くなっていきます。
これが横行すると、末端で開発をする技術者にもしわ寄せが来ます。たとえ同じレベルの成果物を作れても、中間にどれぐらい上位請け企業が入っているかで受けとる金額は変わります。それどころか、現実には下請け同士の価格競争まで発生しています。
そのせいで下に行くほど、現場の技術者が受け取る賃金は減少し、「技術に対して正当な対価」が支払われない状況を招いてしまいます。
その上、n次請が増えると責任問題が曖昧になったり、常駐によるトラブルも起こりがちです。
何より、技術的にも「みんなが使えて、過去に実績がある技術」「客先に指定された技術」しか使えず、開発スキルが高い人がいても、それを生かした生産性が発揮しづらく、エンジニアとして核であるはずの技術を磨くことが難しくなってしまうわけです。
業界がどうなったら上記の問題を解決できるのか
多重下請けをなくす、せめて減らす
基本的には、システムやサービスを作りたい会社が開発部門を抱え込んで内製できればよいのですが、大きいシステムなどを作る場合などは現実的には難しいでしょう。
ただ、前述のとおり下請けが増えれば増えるほど問題が発生しやすくなりますから、ピラミッドの階層が浅くなり、具体的には発注元が請け負ってくれるエンジニアに直接発注する、ぐらいの構造になったほうが健全だと思います。
「作ってもらいたい人」と「作る人」が近ければその中間にあたる人たちは不要になります。金銭的にも、いわゆる中抜きされるお金が減って、技術者に入るお金が増えれば、「作ってもらいたい人」「作る人」両者にとって得なはずです。
また、そうなればプライム側におけるマネジメント業務の難易度や、エンジニアの技量を見抜く能力も高まっていくでしょう（少なくとも今よりは…）。そして、エンジニア側にも高いスキルが求められるようになりますから、高額な金額を支払うのにも納得感が出るはずです。
もちろん、そのような構造になったら、エンジニアは自分で仕事がとれるレベルのスキルがある人しか生き残れない、仕事にありつけない状態になってしまいます。
しかし、そもそもエンジニアというのは技術職なのですから、技術がない人は淘汰されてやっていけない、技術がある人は評価されて対価も上がっていく…というのがあるべき状態ではないでしょうか。
もっと言うと、工数換算ではなく、より少ない工数でよい成果をあげられる人が評価されるべきですよね。
IT業界の門戸を狭くする
そのような状態がなぜ横行しているかというと、そもそもは技術者を頭数と工数だけで換算しているからでしょう。
同じお金を出すなら、きちんとした技術がある人に依頼をして、かかった工数ではなくできあがった成果物で評価したほうがよほど健全です。
この業界的な体質が改善されないと、いつまでたっても日本のIT業界の未来は暗いと思います。
まとめ
というわけで、日本の構造や問題を解決させるにはどうしたらいいんだろう、業界がどうなっていくとよいか考えてみたお話でした。
SIer的な多重下請け構造の中では、技術者やマネージャーの人たちをろくに育成もせずに使い潰しているような状態が続いているので、本当に技術のある人がそれを発揮できてきちんと評価される業界になっていけばいいなと思います。
IT業界の現場の真実 