日本でオフショア開発が普及するとプログラマの給料が上がる仮説

ここ数日「アメリカのプログラマの給料が高い！」という話題が飛び交ってますね。

まあ、給与の話はだれでも気になりますよね。私も気になります。

日本でオフショア開発が普及するとプログラマの給料が上がる仮説

もしかしたら、アメリカのプログラマの給料が高い理由って以前書いた記事に大きく関係するんじゃないかなと思ったので、ちょいとイメージを整理してみようかと。

アメリカの20年前に起きたオフショア活用の拡大と同様の事態が、日本人プログラマ*1の人とお金の動きに与える影響イメージを図示してみます。

かなり適当な絵ですけど。。。

ざっくりと説明すると

1. 国内のプログラマの仕事のうち、日本人プログラマでは採算の合わない仕事がオフショアへ移管。逆に、日本人が必要となる高スキルな仕事でのプログラマが残る。
2. 一部の高収入なプログラマを除き、多数のプログラマは仕事を失う。一部の資金はオフショアの外注費となるが、オフショアは人件費が安いため、結果として余剰資金が発生。
3. （IT投資意欲が減少しない限り）余剰資金を国内プログラマの雇用に再投資。平均給与が既に上昇している状態なので、上昇後の給与をベースに再雇用。仕事を失ったプログラマの一部が新たな仕事に。

といったイメージとなります。まあ、まんまアメリカの昔話を日本に当てはめただけです。

つまり、日本のプログラマの仕事がオフショアに移った場合、失職するプログラマが多数発生しますが、それでも残ったプログラマの平均年収は今よりも上がる形になるわけですね。

上記図の最初で、プログラマの人数と年収を企業規模ごとに変えた形で図示してます。これは、政府統計から、プログラマ給与の基礎データを抽出したデータを参考にしたためです。*2

企業規模	平均年齢	人数	平均月収	賞与	年収
1000人以上	35.7	15890	¥376,000	¥1,371,100	¥5,883,100
100～999人	31.3	27250	¥313,400	¥615,800	¥4,376,600
10~99人	31.7	38970	¥275,200	¥426,600	¥3,729,000
平均	32.3	合計　82100	¥307,400	¥672,100	¥4,360,900

上記の表からの推測ですが、もし、今現在の状態で日本人プログラマがアメリカのプログラマと同程度の待遇(物価や社会保障の差異を考えると平均年収が600～800万円ぐらい)を得ると想定した場合、日本人プログラマは現在の2～3割ぐらいしか残らないんじゃないかなって気がします。

※要は、上記の大企業で年収600万円相当をもらっているプログラマが、スキルの高い国内残存プログラマにそっくり入れ替わるイメージ。

ちなみに、アメリカではIT投資意欲が高く、追加予算がどんどん振り分けられた形となります。当然、プログラマ需要が高まったわけですけど、上記の失職したプログラマではなく、H1‐Bビザを活用してオフショアや国外の優秀なプログラマを呼び寄せる形になったとのこと。

結果、現在のシリコンバレーの移民および移民一世に比率は「64％」になったとのことです。*3

まとめ

まあ、色々書いてみたわけですが、アメリカのITエンジニア事情にあこがれて日本も同じようにしようとした場合、しわ寄せがどこかによっちゃうんだろうなと推測できるんですよね。

なんで、「アメリカのエンジニア事情は素晴らしい。日本もマネすべき」ってのを聞くと、どうしても身構えて慎重に考えてしまいます。

こういうときに、誰もが幸せになれるような画期的なアイデアが浮かべば一商売できそうな気がするんだけどなあ。なかなか難しい。

以上

*1:厳密にはソフトウェアデベロップメントのスキルを持ったソフトウェア開発者なんですけど、便宜上

*2:統計表一覧 政府統計の総合窓口 GL08020103

*3:シリコンバレー発 ビジネス最前線

銀行決済24時間化が2018年となる理由をちょっとだけ推測

銀行振り込み｢1時間だけ｣延長…ご冗談を！ | 夏野剛のググっても絶対出ないハナシ | 東洋経済オンライン | 新世代リーダーのためのビジネスサイト

 銀行は専門じゃあないので、内容は不確かなところもありますがご了承を。

2018年まで改修が必要となる理由は政治じゃないかな

 この夏野氏。2018年まで銀行24時間決済が実現しないのを憤っているご様子ですが、正直銀行のせいじゃあないと思うんだけどなあ。

今、銀行系のシステムでは「金融一体課税(2016年1月完了)」「みずほ銀行のシステム更改(2016年後半頃完了)」「マイナンバー制度(2016年～2017年順次完了)」って形で、かなりの規模のシステム改修が動いている形となります。

上記を見ての通り、既に2017年までシステム改修スケジュールが埋まっている状態なんですよね。

しかも、政府主導の制度案件がかなり多く占めてます。

このような状況で、例えば「マイナンバー制度」のリリースが破綻してしまい、そもそも制度がスタートできなくなってしまうなんて自体は政治的にも避けたいところ。

そういった形から、制度案件だけでなく、平行して稼働している中～大型案件については、かなり厳しいチェックを受けている状況じゃないかなと思われます。

※金融系のシステム開発ではよくある話。

このような条件下で「決済24時間化」を2017年までに銀行協会が推し進めようとしても、政治の面からストップがかかるんじゃないかなって思います。どんなにユーザ視点を強調しても。

ただ、これは政治の都合としては仕方ないんじゃないかなって思うんですよね。

金融一体課税にせよ、マイナンバー制度にせよ、銀行以外にも多数の業界でシステム改修対応を行っている案件ですし、その影響の大きさから、制度破綻を招くようなシステム開発の失敗は許されないでしょう。

最悪の最悪の事態として、ミッションクリティカルの取引網の中心に存在する銀行系システムが、制度対応できなければ政治的な超法規的判断で制度開始延期にならざるを得ないなんて状況も考えられます。

安全第一にならざるを得ない状況ってのもまあわかります。

※これも、現在のミッションクリティカル系システムが高度化しすぎて、業界横断で結合しすぎだったりするせいもあるんですけど。

まとめ

夏野氏は、2018年まで変更が遅れることについて、「銀行業界がユーザ目線がないせいだ」と憤っておりますけど、そんなことは無いんじゃないかな。

制度改正といった政治の都合に翻弄されながらも、精一杯ユーザの要望に答えようとした結果、2018年というスケジュールが出てきたんじゃないのという気がしますよ。

以上

2015年の決済サービス―決済の脱「ガラパゴス化」

paizaには認識されてないSIerで身につけられる技術

SI⇒Web転向に失敗するエンジニアに共通した【たった１つの特徴】 - paiza開発日誌

SIerがぬるま湯なのか。。。SIerって平均的にはわりかし給料が高いけど、高給ぬるま湯ならホワイト企業ってことで、SIerへ転向進めたほうがいいんじゃないのかな。

2014/11/12 00:41

個別の転職話は正直興味ない話なのでここではおいておくとして。。。

毎度のごとく、SIer disへの誤りを指摘しておきますか。

転向者の割合を求められる水準の高さと勘違いしてはダメでしょ

しかしWeb系企業の中途採用におけるSIerから転向者は22.8%であり、決して広き門とは言えない状況です。

ふむふむ。主張としては、WEB業界へ転向する人のうち、22.8％しかいないため、WEB系企業で求められる人材の水準が高い、と言いたいようですが。。。

でも、その直前にはこんなこと記載しているんですよね。。。

逆のSIerの中途採用の7.3%がユーザ企業から、2.2%がWeb企業からとなっており、SIerからユーザー企業、Web企業への流出は増加しています。

・・・これ、数字だけ見れば、WEB系からSIerへの転向者の割合は、SIerからWEB系企業への転向に比べて著しく少なく、更に高い技術水準を求められているってことになるんじゃないのかな。。。

WEB系企業からわずか2.2％しか転向しないIT企業は、さらなる狭き門である！と。

まあ、自分で書いていて何書いてんだろうという気分になるわけですが。。。

お分かりの通り転向者のパーセンテージを見て、広き門だ、狭き門だ、なんて主張すること自体があまり意味が無いわけですよね。

ぶっちゃけていってしまえば、他業種、他業界からの転向者の多寡なんてのは、その業界に対する求人需要の差異の現れなだけで、それをもって「SIer⇒自社Webサービスは非常にハードルが高いのです。」ってのは些か話が飛び過ぎってもんでしょう。

paizaには認識されてないSIerで身につけられる技術

paiza社の記事で一貫しているのは、「働く個人としては低スキルでも働けるようになっており、スキル向上の場がない」、つまり、SEはスキルが低いという主張しているわけですね。

いや、もしくはプロジェクトマネジメントぐらいしか身につけられるスキルが無いと。。。ホントかい。

SIerは個人個人のスキルが無くても、プロジェクトを細かくタスク分解し、誰にでもできる作業に落とし込んでいく事で、属人性を排し、多重下請け構造で巨大なシステムを作れるように仕組化されています。

それができるなら、ウチのチームのメンバーはとっくの昔に全員オフショアにしているっての。

タスクを分解することは、「誰にでもできる作業に落としこむ」のではなく「求められるスキルセットに合わせた仕事に分解する」ってのが正解です。

例えば、ヨーロッパなどではSEの仕事として

• システムアーキテクト
• エンタープライズアーキテクト
• システムアナリスト
• ビジネスアナリスト
• アナリストデペロッパ
• ソフトウェアデベロップメント　(Java/C#/.Netなど言語ごと)

に分けられたりします。

あっちではジョブ型雇用が中心なので、実際に行うスキルセットに応じた雇用が存在するのでわかりやすいのですが、日本はどちらかと言うとメンバーシップ型雇用なので、上記のような欧州では複数のスキルセットとして見られる仕事を横断的に実施することが多い。

上記を見てもわかるように、SEに求められるスキルはかなり多岐にわたっているんですよね。

オッサンみたいなプロマネは、WBSで作業をメンバーのスキルセットに合わせた作業単位に分解することで、各人の得意とするスキルに合わせた円滑な仕事をできるようにするというわけですよ。

属人性を無くすとかってのは、どちらかと言うとサービスを維持するための話。「誰でも出来る」の冠詞には「必要なスキルが有る人なら」が隠れているわけ。

エンジニアとしてのスキルがいらない、って話とは違います。当たり前なんだけど。

で、上記の様にWBSごとに作業を分けたとして、アサインする仕事を変えたり、そもそもタイプの違う仕事をスキルの身につき方は変わってくるわけで、成長しないなんてことはないわけで。

そもそも業界理解が甘い

 ここまでがメインなのであとは細かい指摘を。。。

 そのためSIerは官公庁や銀行保険などの一部の巨大なシステム以外ではシュリンクしていかざるを得ないのです。

銀行なら「 地銀共同センター」や「NEXTBASE」、保険なら「e-JIBAI」とか知らないのかな？

金融系って昔からASP(要はSaaS)の利用が活発だったりするのですけど。。。

ここで銀行保険を例示するのは適切じゃあないですね。

ビジネスシフトが進むと、事業のコアとなるシステムは、コアコンピタンスが流出しないように内製化が中心となり

システム内製化でSIerへのシステム外注より競争力を高められるのか - プロマネブログでも記載したんですけど、オントレ証券なんかではITが事業のコアとなっているわけですが、外注率が高い。

「人材教育・評価体制の構築」「外注価格と外注先のスキル」「事業の撤退可能性と容易性の確保(逃げ道戦略)」「IT以外の営業戦略の存在と比重」「予算の固定化/流動化」「法・政治リスク」「セキュリティ」などのファクトが存在し、内製化が良いのか、外注が良いのか判断したりするわけで、単純にコアコンピタンスだから内製化する、ってほど簡単な問題じゃあないです。

他にもありますが、このぐらいで。

まとめ

paiza社の記事見ると、ソフトウェアデベロップメント以外のスキルは存在しないと主張しているように見えますが。。。

まあ、ソフトウェアデベロップメントのスキルを商売にしている会社だし、「我々の認定しているスキル以外は存在しないので、paizaのサービス利用してね」ってポジショントークとしては仕方が無いのでしょう。

ただ、他の業界をdisるのは感心できる行為ではないです。しかも、企業広報ブログで。

企業広報が自社のCSRやコーポレート・ガバナンスをあまり考えてないのか。。。

自社の価値を高めるどころか、ヘタしたら自社の価値を下げる可能性は意識してないのかなあ。

繰り返しとなりますが、WEB系で求められるスキルが有るようにSIerで求められるスキルも存在します。

自分の業界ではそのスキルが必要ないって話と、スキルを成長できないって話はまた別物。

それを、「SIerではスキルを成長できない」なんてとらえるのは、ちょっと視野が狭いんじゃあないかなあ。

以上

プロジェクトマネジメントで大切な一つのこと

ほうほうと思って内容見ていたのですが。。。ちょっとだけ。

プロジェクトマネジメントで大切な一つのこと

まあ、プロジェクトマネジメント語る上で、スケジュール管理や課題管理など、色々管理しなければならないことがあります。

PMBOKでは、以下の様なことを管理しろとあります。

• 総合管理
• スコープ管理
• タイム管理
• コスト管理
• 品質管理
• 人的資源管理
• コミュニケーション管理
• リスク管理
• 調達管理
• ステークホルダ管理

教科書的には上記のような管理が大切なのできちんと行いましょう、というのが答えになるんでしょうけど、それだけだとつまらないので。。。

オッサンが考える、プロジェクトマネジメントで一番大切なことは何か、と聞かれればぶっちゃけ「計画」かな、と答えます。

要は、不確定要素がなくやるべきこと明確で、ステークホルダーの誰もが文句を言わないような状態に持ってきて。で、スケジュールも余裕。予算もきちんと抑えた状態。こんなだれでも勝てるプロジェクト計画立てられるようにすることが重要と。

・・・まあ、プロジェクトの進め方の答えが事前にわかってれば、淡々と仕事進められるわけで当然なんですけど。。。

実は、PMBOKなんかでも「計画」を重点的に記載してたりしてるんですよ。

プロジェクトは変化していくもの。なので、この前提に立って変化に耐えられるような実行→監視→再計画のフィードバック管理も重要なのですけど、それらの変化すらも予想できるような計画立てられれば更にスムーズなプロジェクト運営ができるだろうと思います。

計画段階で落としこみができていれば楽

プロジェクト計画ってわりかしおろそかにされたり、場合によっては読めないからとりあえず開発しようなんて進められたりもします。これもまあ一つの答えであるわけですが。。。

※この場合は、リスクが積み上がった状態でプロジェクトが進められていることとなりますね。

ただ、気をつけなければならないのは、「スケジュール管理」や「課題管理」として実行の場に出てきた問題ってのは、事前の計画段階で潰しこみができていれば半分以下、場合によっては1/10よりも小さな労力で対応できることもしばしばです。

後手後手の対応では、どんどんコスト・労力が積み重なってきてしまい、対応にかけるリソースが不足してきます。エスカレートしていけば、ついにはデスマーチに突入となってしまいます。

コスト管理やリソース管理は重要です。それが成立してなければ、スケジュール管理や情報共有の仕組みも機能しません。

デスマーチ状態に陥った場合、ちょっとやそっとのスケジュール管理や課題管理では焼け石に水状態だったり。デスマーチ状態での課題・問題分析は精度が下がったりすることもあり、更に傷口を広げることもあります。

なので、デスマーチに陥らないよう事前にどうすれば最小の労力、最小のリスクでプロジェクトを達成できるか、計画をたてることが重要ってわけですね。

てなわけで、早め早めに対応するよう、実行段階の管理も重要なのですが、それ以上に計画をマネジメントすることが重要だと思うわけですよ。ついでに言うと、実行段階で出てきた課題や問題の振り返りをきちんと行い、次回のプロジェクトの計画の精度を高めるようにすることが大切だったりも。

まとめ

実は、オッサンも昔は「スケジュール管理」や「課題管理」などの実行プロセスを血眼になって追っかけていたのですが、それでは見えないコストばかり積み重なってきてしまい、残業だなんだと疲労の毎日になってしまったのですね。

それからというもの、計画段階で如何に楽で勝てる計画をたてるか、ということに注力するようにしました。

慣れてくれば、中小規模の案件なら、前述した理想状態のプロジェクト計画を立てられるもので、スケジュール管理や課題管理などであまり苦労することなくプロジェクト進められますよ。

大規模案件ではなおさら。計画段階できちんと先読みができるかどうかで、その後の労力は段違いです。

なので、元増田氏の語るように実行段階のマネジメントも重要なのですけど、もう一步進んで計画をマネジメントすることも気をつけたほうがいいんじゃないかなと。

プロマネに求められる重要な素養として、幅広い情報収集能力と、現状分析や経験から、未来を予測し、早期に問題発見できる能力になるんじゃないのかな、なんて思うわけです。

※情報共有についてなど他にも語りたいことがあったのですが、だるくなったのでこのぐらいで。。。

以上

プロジェクトマネジメント知識体系ガイド（PMBOKガイド）第５版 (A Guide to the Project Management Body of Knowledge)

指摘密度だけでレビュー品質をチェックするPMOは仕事をサボっているも同然

ひと通り笑ったので。。。

用語統一厨は結構重要な指摘

用語統一厨 「"お問い合わせ"は"お問合せ"と表記することに決まってるので」

元増田ではクソレビューアに「用語統一厨 」が挙げられているわけですが、結構この指摘って重要なんですよね。

というのも、オフショアとの開発やっていると、用語一つ一つが認識相違の致命傷となることがよくあるから。

オフショア側の人間ってやっぱり日本語に慣れてないこともあるので、用語がバラバラの設計書を渡したりすると、日本人からすれば同じ意味と把握できるような単語でも、別の読みや言葉として認識したりする場合もあったり。

オフショア開発で痛い目にあった、という人の話を聞くと、用語の統一や表記の統一みたいな、日本人からすると些細な部分できちんとコミュニケーションをとれてない場合があります。

でも、これってドキュメントを上手く解釈してくれるよう読み手に甘えている部分でもあるので、書き手の責任としては、きちんと用語を統一するように書くのが正解じゃないかな、と思います。

指摘密度と品質の関係

PMO 「指摘密度が基準値に満たないので、その他なんでもいいので指摘ありませんか?」

合同プロジェクトなどにチームで支援にいったりすると、PMO部隊が支援チームのPMの活動を分析したりすることがあります。

なので、オッサンがレビューした結果に対して合同プロジェクトのPMO部隊から「レビュー指摘が足りてないんじゃないですか？」なんて言われることまれにあります。

現場見てないので、数値で判断するわけですね。

その度に「いや、ウチのチームとしては十分レビューできているって」なんてバトルになったりすることもしばしば。

そもそも指摘密度って何か。

指摘密度自体位は、過去の類似プロジェクトにおけるレビューの実施状況から、「おおよそ１Pあたり○○件～XX件の指摘が発生する傾向がある」という結果より、レビューが適切に行われたかどうかを判断する指標となります。

上記の下限値より指摘密度が小さい場合、レビューできちんと問題点を指摘できてないんじゃないだろうか、上限値より指摘密度が大きい場合、そもそも成果物品質が悪いんじゃないだろうか、みたいな感じで使うわけです。

さて。上記の評価ですが何が問題か。

決定的な問題としては「質的な面で品質評価してない」ってことです。

例えば、レビューイが前回初めてドキュメントを作成した人で、今回修正内容について設計内容を熟知している場合、当然2回めの修正は慣れがありますので、指摘件数が少なくなる傾向があります。指摘は少なく、品質は向上するってパターンです。

逆に、レビューアが前回とは異なる人物で、体裁や表記があまり理解できない場合、自分の理解しやすいドキュメントでないと成果物とならないなんて考えた結果、表記や体裁等の指摘が増える傾向があります。この場合は、指摘は多いものの、あまり品質に変化なしってパターンです。

又、そもそも前述したPMO部隊がチェック基準としている指摘密度が、過去品質の悪いプロジェクトのものを採用していたりもして、ノウハウやドキュメントをきちんと整備したオッサンのチームのレビューで使うには、あまりにも状況が乖離していたりも。

とまあ、色々なパターンが考えられるわけですが。。。

要は指摘密度から外れても品質面は変わらない、あるいは向上しているパターンがあるってことをきちんと把握しなければならないわけですね。

まとめ

結局のところ、指摘密度は「品質を保証するための指標」ではなく、「レビューの場面で前回と異なる何かが起きたアラート」だと思うのが適切だと思うのですよ。

PMOはレビューの品質を指摘密度といった数字で判断するのではなく、指摘密度でチェックに引っかかったレビューの定性評価をきちんと行うことで判断しなければ、きPMOとしての品質評価にならんと思うわけです。

言い換えれば、指摘密度だけでしか品質を判断しないPMOは仕事サボっているのと同然になってしまう、と思うわけです。

以上

なぜ重大な問題を見逃すのか? 間違いだらけの設計レビュー

WEBサービス会社のはてながSIerからシステムを買ったこと

getlife - 『ミロク情報サービス×はてな、CFO対談　「上場の意義」…』 へのコメント
2014/10/22 08:59 にブックマーク

 へー、はてなってミロクさんの会計パッケージ使ってたんだ。

知らなかった。

「WEBサービス会社」のはてながSIerからサービスを買った理由

SIerで働いている人ならあまり違和感ないんですけど、業務システムに詳しくない人だと「はてなって内製でサービス作っているのに、なぜSIerからサービス買うの？」と思った人もいるんじゃないかと思ったので、ちょっとだけ。

企業の業務システムは、色々な分析方法がありますが、一般的なのは顧客との距離ごとに「フロントオフィス」「ミドルオフィス」「バックオフィス」に分けて機能分析を行うことが多いです。

フロントオフィス

顧客との直接的な営業活動を行う機能に対して働きかけるシステム。CRMやコールセンタシステム等。WEBサービスもここに含まれる

ミドルオフィス

企業収益活動の中心となり、営業の実行と企業戦略を統括するシステム。ミドルオフィスと合わせてバックオフィスと呼ばれることも。

バックオフィス

円滑な企業活動を支援するための間接機能を管理するシステム

イメージ的には以下の図のような形となります。

さて。

はてながミロク情報サービスから購入したのは、「MJSLINK NX-I」。財務会計を中心とした業務システムで、バックオフィスからミドルオフィスの入り口までの機能を管理するシステムとなります。

一般にバックオフィス機能のシステムですが、

• 仕様変更が少ない
• 変更時のスコープ管理がしづらい(制度変更など、お上の都合で仕様変更が要求される)
• システムリリース期限の自由が持ちづらい(お上の都合で決まることがある)
• コストセンターである

と言った特徴をもつシステムと言われてます。

上記の特徴は、アジャイル開発等のWEBサービスでよく使われる開発スタイルと相性が非常に悪く、内製化だとどうしても高コスト化しやすい部分であり、維持するモチベーションを持ちづらい。

なので、ERP導入したりパッケージ構築、SaaSやASPなどSIerのサービス買うのが合理的と考えてます。

※そういえば、以前はスクラッチで作ってる事例もありましたけど、最近はトンと聞かないですね。。。観測領域だけなのかな。

なので、今回のはてなの判断は、IT投資管理上合理的な判断だと思います。

エンプラシステムとして見た場合のはてなのシステム構成

比較的モダンなエンプラシステムでは、フロントもミドルもバックも全て共通のEBSに載せたSOA形式でアーキテクチャ組むこともありますが、記事を見ただけでははてなの事例ではそこまで全体最適化されたエンプラアーキテクチャになってなさそう。

上場ぐらいまでなら現状でも大丈夫かな、と思いますが、さらなる事業拡大を考えた場合、いずれかのタイミングでアーキテクチャの改善が必要となる場面があるんじゃないかな、なんて思います。

まとめ

そういや以前、

相互の能力需給関係のマッチングがあるからこそ、ユーザは高いカネを支払ってでもSIerに仕事を依頼したい。

別に、ユーザはシステムの規模が大規模だからSIerへ仕事を依頼するわけではありません。規模はただの一要因。大小関わらず、比較優位の原則に従いSIerに仕事を依頼することが合理的であれば、ユーザ企業は仕事を依頼するだけです。

ビジネスモデルの違いはエンジニアの価値を毀損しない - プロマネブログ

と書いてpaiza社のSIerへのDisに文句たれてたわけですが、まさにその反証を同WEBサービス企業であるはてなが実施しているかたちになったことにちょっとオドロキ。

はてなは、きちんとIT投資管理を理解しているんだなあ。

まあ、WEBサービス業も企業である以上は収益性等の考慮が必要なわけで。。。

はてな含むWEBサービス業では、収益を最大化するためには、どこまで内製化するのか、どこまで外注するのか、と言った見極めが必要な分、CIO等経営層に求められるIT投資管理は重要性を増すのじゃあないだろうかなんて思うわけです。

 以上

ValIT入門―IT投資管理フレームワーク

40歳年収が高い会社ランキング（IT関連業界抽出版）

最新版！「40歳年収が高い会社｣トップ300 | ランキング | 東洋経済オンライン | 新世代リーダーのためのビジネスサイト

持株会社が含まれてたり、従業員数が入ってなかったりするのでイマイチぴんとこなかったので、IT業界を中心に抽出してみました。

分析に入る前に 

抽出条件としては以下のとおりです。

• 東洋経済オンラインに掲載された1～300位の企業
• 情報通信業、及びサービス業でWEBサービスを中心に行っている企業
• 持株会社は除く(やっぱり知りたいのは一般従業員の給与ですし)
• 情報通信業でも、メディア、広告代理店は除く(非IT業界)
• 個人的な趣味でキャリアは除く
• 非情報通信業でのシステムインテグレータやっている会社で知っている会社は入れておく

とまあ、個人の趣味バリバリのランキングですね。

40歳年収を中心にしたランキングということで、平均年齢が著しく乖離している平均年齢の若い企業は、平均年齢を赤字にしてます。

IT業界だけだと味気ないので、ざっくりとですが分類分けしてます。

分類は、ソリューション提供していたらシステムインテグレータ、パッケージ売やソフトウェアハウス的な開発中心ならソフトウェア開発、WEBサービスからの収益がメインそうならWEBサービスとしてます。

システムインテグレータ以外は結構適当。

40歳年収が高い会社（IT業界抽出版） 

順位	元順位	社名	40歳推定年収	平均年収	平均年齢	社員数（単独）	分類
1	20	野村総合研究所	1134	1091	38.7	5938	システムインテグレータ
2	36	グリー	1030	744	31.2	1200	WEBサービス
3	40	日本オラクル	1007	1010	40.1	2468	ソフトウェア開発
4	74	オービック	907	773	35.3	1510	システムインテグレータ
5	84	エックスネット	892	769	35.6	150	システムインテグレータ
6	89	コロプラ	887	617	30.2	403	ソフトウェア開発
6	89	NTTデータ	887	798	36.7	11000	システムインテグレータ
8	94	フューチャーアーキテクト	882	739	34.9	769	システムインテグレータ
9	103	ISID	870	857	39.5	1313	システムインテグレータ
10	107	ディー・エヌ・エー	868	719	32.1	936	WEBサービス
11	112	ジャストシステム	863	828	38.6	388 （連）	ソフトウェア開発
12	120	クックパッド	852	688	31.2	181	WEBサービス
13	128	アバント	846	789	33.9	227	ソフトウェア開発*1
14	135	サイバーエージェント	844	666	30.3	3165 （連）	WEBサービス
15	139	新日鉄住金ソリューションズ	841	802	38.4	2383	システムインテグレータ
16	141	テクマトリックス	840	739	36.1	392	ネットワークインテグレータ
17	145	トレンドマイクロ	836	761	37.0	5217	ソフトウェア開発
18	148	ACCESS	831	751	36.8	229	ソフトウェア開発
19	153	ヤフー	824	768	34.4	4860	WEBサービス
20	157	大塚商会	820	806	39.4	6634	システムインテグレータ
21	169	日立製作所	810	828	40.7	33500	メーカ
22	170	東洋ビジネスエンジニアリング	809	790	39.2	413	システムインテグレータ
22	170	オービックビジネスコンサルタント	809	606	32.2	641	ソフトウェア開発
23	173	プラネット*2	805	823	41.1	158	システムインテグレータ
24	177	enish	803	597	32.0	187	ソフトウェア開発
25	179	アイ・ピー・エス	801	575	31.0	70	システムインテグレータ
25	179	都築電気	801	847	42.6	1367	システムインテグレータ
27	182	伊藤忠テクノソリューションズ	799	778	39.1	3919	システムインテグレータ
28	194	システムインテグレータ	791	666	35.0	148	システムインテグレータ
29	196	サイボウズ	789	616	33.2	295	ソフトウェア開発
30	210	ボルテージ	782	484	27.4	300	ソフトウェア開発
31	214	ドリコム	781	575	31.7	227	ソフトウェア開発
32	218	楽天	780	652	32.5	3762	WEBサービス
33	229	インターネットイニシアティブ	775	664	35.4	1671	システムインテグレータ
34	235	カカクコム	773	664	33.5	491	WEBサービス
34	235	ネットワンシステムズ	773	703	37.0	2163	ネットワークインテグレータ
36	250	ビットアイル	768	676	36.1	140	データセンター
37	258	インフォコム	766	779	40.6	1188	システムインテグレータ
38	263	アイスタイル	764	511	29.2	388	WEBサービス
39	270	セック	761	651	35.4	267	システムインテグレータ
40	270	ブレインパッド	761	589	33.0	143 （連）	ソフトウェア開発
41	281	ユビキタス	756	731	41.2	54	ソフトウェア開発
42	286	ガイアックス	755	556	31.7	196	ITアウトソーシング
42	286	イマジニア	755	679	36.7	77 （連）	ソフトウェア開発
44	300	東芝	751	812	42.7	35942	メーカ

感想

中の企業知ってますけど、平均年齢が40未満の会社で、実際には40歳になる前に「40歳推定年収」に到達している事例を見かけますので、給与テーブルのシミュレーションはちょっと甘いんじゃないかな、という気がします。

アプリ開発を中心とした企業や、WEBサービスを中心とした企業の多くは、平均年齢が40歳よりもかなり低いです。

人員流動の激しい会社もありそうですし、実際に40歳まで到達している人数も少ないことから、40歳推定年収を本当にもらえるかはちょっとわからないかと思います。 

言い方を変えると、今後順調に企業成長すれば、現在の推定年収以上の年収となる可能性があるため、あくまで参考値として見るのが良いかと思います。

本来であれば、日本IBMやアクセンチュア等外資系も欲しいところですけど、データがないので仕方ないですね。。。気になるところです。

メーカは日立と東芝だけですか。。。見落としたかと思って3回ほど見返しましたが、NECと富士通の気配が消えてしまった模様。昔は年収上位に上がっていた気がしたんだけどなあ。

システムインテグレータは元請け会社が多そうですけど、元請け、再委託の両方を請け負っている1.5次請け企業も結構ランクインしていたりもします。

元請けやっている企業の中には「ユーザ子会社」も多く、非上場企業が多かったりするんですよね。

意外とランキングに出てこない企業があるので、そういった企業も含めたランキングを一度作ってみたいものです。

まとめ

まあ、こういった年収は所詮今現在の年収ですし、将来どうなっているかなんてわかりません。

なので、年収ランキングの順位がどのように変動したのか、という視点の分析はより面白いんじゃないかな、なんて思います。

例えば、昔は上位にいたはずのNECや富士通といったメーカが今回のランキングにはない。ITビジネスの中心がハードウェアから、ソリューションビジネス、ソフトウェア開発にシフトしたことが原因かもしれない、とか。

そういう観点から業界動向を占ってみるのも面白いと思いますよ。

以上

職業別・会社別・業界別 ダイヤモンド給料データブック (週刊ダイヤモンドBOOKS)

*1:実質的には持株会社

*2:同名企業が多いけど、上場しているのはここ　株式会社プラネット