paiza開発日誌

IT/Webエンジニア向け総合求人・学習サービス「paiza」(https://paiza.jp ギノ株式会社)の開発者が開発の事、プログラミングネタ、ITエンジニアの転職などについて書いています。

「日本も米国もSIerは同じ」は本当か?日米SIerの構造的な差とは

f:id:paiza:20130918201254g:plain今回のpaiza開発日誌は片山がお送りします。

これまでブログ等でシリコンバレー周辺のエンジニア事情と日本のエンジニアについて比較する記事等を書いてきましたが、SI事業で見れば日本も米国もたいして変わらないのでは?という事が気になったので米国のSIer事情について少し調べてみました。

そもそもアメリカにはSIerなんてないのでないか説

いきなり今回のブログのタイトルを覆すようですが、米国のSIer事情について調べていくと様々な場所で「日本のSIerのような企業はあまり多くない」という記述を見かけます。

アメリカの企業はシステムの開発/導入/運用を基本的に自社内のエンジニアが行う。日本のようにSIerにアウトソースして、一切を任せるということはない。
(中略)
もちろんSIerが全くない訳ではなく、展示会などに行くと、システム構築をお手伝いする企業だとか、運用を請け負う企業だとかは見かけるのですが、彼らは、リソースが足りなく、スケジュールが厳しく、かつコスト対効果が見合うときにのみ声がかかるいわばピンチヒッター的な役割が多い様子。

余道を愉しむ:日本とアメリカのITに関連する違い

米国のITベンダーの日本法人社長は、本社の幹部から「なぜ日本にはITサービス会社があんなにたくさんあるのか」とよく聞かれるそうだ。米国にもアクセンチュアやEDSのような企業は存在するが、数は限られているからだ。そして回答に苦慮する。

IT Pro:「SIガラパゴス」を育んだIT部門の罪

米国と日本との大きな違いは、米国の企業は基本的に内製なのだ。すなわち、社内のIT部門に開発エンジニアを抱え、そこでシステムの開発から運用を行なう。ですから、米国のベンダーはそこに製品を供給する役割であり、日本でいうSIerというのはほとんどなく、あっても企業でリソースが不足したらそれを補う役割でしかない。
mark-wada blog:IT業界構造 - 親子丼的ビジネス奮闘記(4)


これらを見ると、さすがに「アメリカにはSIerが無い」というのは言い過ぎのようです。

ただ端的に言うと、システムを発注する側のユーザー企業にはエンジニアが多数おり、企画、設計、開発もしくはパッケージ導入をして、手が足らないところを一部外注するのがアメリカ流。

ユーザー企業(発注側)は基本的にレビューするだけで、一切合切すべて丸投げしてしまうのが日本流、という事のようです。たしかに自分自身が以前関わった案件を思い返してみても、社内のエンジニアに聞いても、設計をユーザー企業側でやっていたという話はほぼ皆無でした。

「日米のエンジニアの置かれている環境の違いを知る」という意味では、そもそも米国ではSIerが少ないので日米でSIer比較する事自体があまり意味が無いかも知れません。

アメリカはユーザー企業の技術者が圧倒的に多い

これを裏付けるように、日本とアメリカのITサービス企業(SIerなどITのサービス提供者)技術者数とユーザー企業技術者数みてみると、アメリカではユーザー企業の技術者数がITサービス企業技術者数の2倍以上居ます。(米国のITサービス企業技術者数94.1万人、ユーザー企業技術者数236.2万人)日本のユーザー企業技術者数はITサービス企業技術者数の約1/3しかいません。(日本のITサービス企業技術者数77.1万人、ユーザー企業技術者数25.5万人)

f:id:paiza:20140327141051g:plain
IPA「グローバル化を支えるIT人材確保・育成施策に関する調査」概要報告書より

何故こういった違いが起きるのか日米の産業構造を紐解くと、雇用の流動性が高いか低いかという事に行き着きます。アメリカでは雇用の流動性が高く、社内のシステム開発部隊を必要に応じて調整が可能なので内部に抱える事ができるが、日本は雇用流動性が低いため、SIerが人材サービス的な役割として多く求められるようになるという事です。(GoogleFacebookTwitterなどのWebサービスがユーザー企業側でカウントされている事も米国でユーザー企業が多くなっている要因の一つだとは思いますが。)

内部で開発の出来るエンジニアを抱えられず、保守・運用業務に必要最低限の技術者しか居ない体制だと、設計から丸投げとなり、利用部門の社内調整もままならず、様々な関係者から出る意見をどんどん取り入れ、カスタマイズが横行し、結果として使いづらいシステムが出来上がる。そしてそういうカスタマイズが慣例化するため、より個別開発に向くSIer需要も高まるという循環に成っていったと推測できます。

パッケージを上手く使うには業務を標準化する必要が有り、システムを深く理解したエンジニア(IT部門)が経営レイヤーから関わっていけなければ業務プロセスを変える事は難しいでしょう。米国でパッケージ、SaaSを上手く活用できる(それらの市場が伸びている)背景には、ユーザー企業側に優秀なエンジニアが居る事が大きな要因と考えられます。

内部で関係部門と調整しつつ開発・実装を進められる米国的ポジションと、外部から情報システム部をはさみ関係部門の調整もままならないまま設計を行ない、実装はオフショアするという日本的ポジションでは、構造的に生み出す事の出来る付加価値も、生産性も圧倒的に違うと考えられます。

※米国でSIerが少ないもう一つの要因としては、米国の地理的要因として国土が広いので、一部の大手アウトソーサーか地場Sierしか存在しないという事も有ると思われます。この辺りについてはまた次回にでも。

日本でエンジニアの価値を高めるには何が必要か?

ビジネスシーンに置いてエンジニアの価値を高めるには、高い技術を持った上で、技術とビジネスを結びつけられる、という事に尽きる、と思います。文章にすると当たり前過ぎますが。。

現在のビジネスシーンに置いて、システムはウォーターフォール的に一度作ったらほぼ完成という事は無くなってきており、運用での開発スピードをいかにあげるかが非常に重要になってきています。サービスの改善スピード自体が競争優位性になります。下記のクラウドワークスCTO大場氏のインタビュー記事でもその辺りのギャップについて書かれています。

開発が完了したら、チームは解散。これは完全にSIerの感覚です。システムが完成した後は、開発チームはなくなり、運用チームに引き渡すというものです。


私は「サービスは本来、そういうものではない」と主張しました。「ユーザーの要求に対して、絶えずサービスを改善し続けないと、競合他社のサービスには勝てない」と上司に訴えたのです。その結果、返ってきたのが「分かった。その改善にあと何人月必要なんだ」でした。


それを聞いて、痛感しました。SIerには、サービスを継続的に作り続けるという考え方はあまりなじまないんです。企業文化の違いでしょうかね。


IT Pro:「技術が古いとエンジニアがやる気をなくす」、クラウドワークスCTOの大場氏

ビジネスに近い位置で(プロフィットセンターの中で)、いかに早い改善スピードでサービス運用を行なっていくかを考えると、技術力は必須になります。

一度作っておしまいであれば、コードの保守性、拡張性を気にする必要もないし、適当なものを組み合わせて作るだけでも十分です。しかしローンチ後からが本番のサービスサイドにおいては、保守性、拡張性の低さ、開発スピードの遅さは命取りに成ります。 これらを実現するためには「遠い昔にCを書いてました」、というレベルの技術力では不十分です。

現在の日本SIerの構造だと、外部というポジションでユーザー企業の社内調整もまま成らず、また分業化が進みすぎて技術の解らないPMが設計をおこない、ローンチしたらチーム解散という状態が多いので、ビジネスとして成功するためのサービス運用改善に耐えるシステムはなかなか出来ないでしょう。(近年では”納品の無い受託開発”を掲げるソニックガーデンさんなど、こういった範疇には入らない新しい形態のSIerも登場しております)

雇用流動性の問題はありますが時代の流れとともに、カスタマイズ文化は減り、クラウドが主流になる。そして競争力の源泉と成る部分は内製化していく。内部で足りない部分はオフショア化していく。

そのような事を考えていくと、コードが書ける、技術を深く理解している、という事は必須で、その上でさらにDevOps、ビジネスの理解、周辺領域(フロントエンド、インフラ)といった複数領域に精通しているエンジニアが価値の高いエンジニアという事に成ってくると思います。つまりキャリアパスとしては、従来のコードを書かない仕様まとめのマネージャーというキャリアパスだけでなく、スペシャリストとして技術をきわめて行く事も十分に可能な環境に成ってきたと言えるでしょう。またもう一つの道としては、技術が解っている上でビジネスサイドに寄ったポジションというのも非常に価値の高いエンジニアと考えられます。従来のようなウォーターフォールの中でPG(プログラマー)、SE(システムエンジニア)、PL(プロジェクトリーダー)、PM(プロジェクトマネージャー)と分業化で考えていると価値の低いエンジニアと成ってしまう可能性が高いように思います。

最後に一つ、最近タイムラインに流れてきた笑えない話を紹介して終わりたいと思います。

設計書にSQLを日本語で書くことを指示される -> 机上ではよくわからないから実際のSQL書く -> それを元に設計書を書く -> PGと呼ばれる人たちがそれを見ながらコード上にSQL書く ということをやってた現場知ってる。

https://twitter.com/daiksy/statuses/443215842566627330

 

エンジニアのスキルの可視化

今後のエンジニアにおいて技術力は必須、と考えて立ち上げたサービスがpaizaです(宣伝)

学歴や職歴、また面接でのしゃべりでの評価ではなく、コードで評価する事により、実力のあるエンジニアが評価され、口下手でも技術でアピールでき、活躍できるような環境を作ることで、エンジニアの技術力の底上げをし、技術力のあるエンジニアの待遇や社会的地位を改善し、ひいては日本のソフトウェア産業全体の国際競争力を高める事につなげられればという思いでサービスを運営しています。

現在は転職という一領域だけではありますが、僕たちのミッションである「日本のIT/Webエンジニアを世界レベルに引き上げる」事を目指して、今後様々なサービスを展開していければと考えています。


プログラミング入門講座|paizaラーニング

PHP入門編Ruby入門編Python入門編Java入門編JavaScript入門編C言語入門編C#入門編アルゴリズム入門編