日本のITエンジニアの給与と評価が不当に低い要因はどこにあるのだろう - paiza times
こんにちは。谷口です。 先日、国税庁が2020年の民間給与実態統計調査の結果を発表して以来、日本における平均年収の低さが話題になっています。 特に会社員の平均年収は2年連続で下落、依然90年代よりも大幅に低い平均額で推移しています。 参考：令和２年分民間給与実態統計調査結果について ITエンジニアは国内では比較的平均給与が高い職業ではありますが、一方でpaizaを運営していると、「給与や評価に対する不満」を理由に転職活動をしている方も多く見受けられます。 そこで今回は、日本のエンジニアの給与や生産性の低さの要因について考えてみたいと思います。 エンジニアの生産性や評価が不当に低い企業で何が起きているか エンジニアのスキルレベルとマッチしない人月商売 システム開発において人月換算で費用を見積もる慣習はいまだに根強く残っています。 しかし、システムやサービスの提供価値ではなく、稼働そのものに対
人月商売のIT業界はブラックホール、落ちたら逃げられないのに説教して悪かった
今回は「人月商売のIT業界」をお題に、あまり出来のよくない謎掛けから始めることにしよう。人月商売のIT業界と掛けて、ブラックホールと解く。その心は、一度入り込むと二度と出てこられないでしょう。うーん、やはり下手くそだと苦笑するしかない。 ただ、下手くそであってもこの謎掛けは、人月商売の恐ろしさを物語っている。例えば新進気鋭のITベンチャーであっても、提供するクラウドサービスなどの売り上げが伸びず経営的に苦しい状況が続くと、人月商売のIT業界というブラックホールの強力な引力に捕まってしまう。というか、ITベンチャーの経営者が自らこのブラックホールに飛び込んでしまうといったほうがよい。 要するに、経営が苦しいので下請けのソフトウエア開発に手を出すわけだ。ソフトウエア開発と言えば聞こえは良いが、SIerが仕切るシステム開発の現場に手配師役のITベンダーを介して、SES（システム・エンジニアリング
公取委が目を付けた日本の恥部、人月商売のIT業界の悪行は元から絶つべし
今回は、2022年6月に公正取引委員会が公表した調査報告書を元ねたとして暴論しようと思う。その報告書とは「ソフトウェア業の下請取引等に関する実態調査報告書」。お察しの通りで、私が取り上げるのだから、当然ここでいう「ソフトウェア業」とは人月商売のIT業界のことだ。人月商売のIT業界をよく知らない人がこの報告書を読むと驚くだろうな。多重下請け構造を利用するITベンダーの悪行が余すところなく記されているぞ。 おっと、少し筆が滑ったな。「ITベンダーの悪行が余すところなく」は言い過ぎだ。公取委なのだから、多重下請けの形を取るITベンダーの取引に関わる悪行に限定して調べている。それにしても「中抜き事業者問題」や「一蓮托生（いちれんたくしょう）問題」など出るわ出るわである。もし、勘違いして人月商売のITベンダー、特に下請けITベンダーに就職してしまいそうな人が目の前にいて、思いとどまらせるにはこれを読
みずほとクラウドにみる「不都合な真実」、日本型SIに改めて問われる顧客重視
最近のITに関する話題の中から、日本型SI（システム構築）に「不都合な真実」を感じたエピソードを2つ紹介したい。 最初はクラウド活用の話。メガクラウドが企業のオンプレミス（自社所有）環境に向けたソリューションの拡充に本腰を入れてきた。米アマゾン・ウェブ・サービスの「Amazon Web Services（AWS）」や米マイクロソフトの「Microsoft Azure」に続いて米グーグルのGoogle Cloudが「Google Distributed Cloud」を発表し、3大クラウドの足並みがそろった。 Google Distributed Cloudは、Google CloudのソフトウエアなどをPCサーバーにあらかじめインストールし、それをユーザーのデータセンターなどに配置したうえで、運用や保守をマネージドサービスとして提供する。今や3大クラウドのクラウドソリューションまで詰め込んだ
プログラミングを外注したところ下請けの下請けの下請けの下請けくらいで自社に案件が戻ってきてしまった話
ありあ @aria_nico 「社内の人手が足りない、もうだめだ」ってプログラミングを外注したら、下請けの下請けの下請けの下請けくらいでプログラミングの案件話が自社に戻ってきた話する？ 2021-10-21 18:47:13
ユーザーはなぜ、自社のシステム開発に協力しないのか
ユーザーはなぜ、自社のシステム開発に協力しないのか：本業が忙しいから、お手伝いはできないよ（1/4 ページ） 複雑怪奇なIT“業界”を解説する本連載、第1弾はIT業界にまん延する多重下請け構造と偽装請負について、第2弾は多重下請け構造が起こる仕組みについて、第3弾はシステム開発プロジェクトには複数の契約形態が混在することを説明した。 今回は「ユーザー」の謎を解説する。彼らはなぜ、いつも当事者感覚がないのだろうか――。 お任せ体質ユーザーの末路 私はこれまで、システム開発のトラブルに関する連載や研修などを行うために、さまざまなIT訴訟について調べてきました。 悪い意味で印象的だったのは、ある清涼飲料水メーカーの在庫管理システム構築に関するトラブルです。ユーザー企業の担当者たちの知識不足、そしていわゆる「お任せ体質」がベンダーの作業を遅らせ、ついにはプロジェクトを破綻させてしまった事件でした。
ソースコード流出問題 「孫請け」文化、技術者管理の壁 - 日本経済新聞
三井住友銀行の業務システムのソースコードが、開発の委託先から流出したことが1月に明らかになった。発注者や1次請負の事業者の知らないところで、再委託先とみられるシステム開発の技術者がインターネット上のサイトに勝手に投稿。サイバー攻撃ではなく、漏洩させた技術者に罪の意識がなかったのが特徴で、委託先の管理が行き届かなかった。専門家は同様の事例が他にも埋もれている可能性があると指摘する。【関連記事】・・・プログラム共有サイト「ギットハブ」に技術者が投稿プログラムの処理内容を示した文書を指すソースコードは、三井住友銀行からNECが開発を請け負ったシステムのものとみられる。NECは「流出したソースコードの中に特定の顧客向けに開発したものが含まれていることを確認している」としている。情報を漏洩させた技術者は、NECから再委託などを受けていた企業や、さらにその先の委託先などに所属していたようだ。自分が記述
丸投げしたんだから、頑張ってくださいよ（作業量は増えたけどね）
丸投げしたんだから、頑張ってくださいよ（作業量は増えたけどね）：「訴えてやる！」の前に読む IT訴訟 徹底解説（67）（1/3 ページ） 下請けに丸投げした作業の工数が当初見積もりの6.4倍にまで増えてしまった。下請けの追加費用支払い要請に応じるか、契約を結び直すか――どうする、元請け！ 連載目次 IT訴訟事例を例にとり、トラブルの予防策と対処法を解説する本連載。今回取り上げるのは、「元請けベンダーと下請けベンダーの間に起きた機能追加費用を巡る争い」だ。 昨今、問題視されることの多いソフトウェア開発における多重請負構造。ユーザー企業から発注を受けた元請けベンダー（以降、本文中は「元請け」と表記）が作業の一部（あるいはほとんど！）を下請けベンダー（以降、本文中は「下請け」と表記）に再委託することは、むしろ一般的といってもいいほど数多く存在する。 両者の間で作業の分担や支払い、不具合の責任など
SIerってヤバいの？ ひろゆきがエンジニアに向けて語る、業界ごと沈まないためのキャリア戦略 - エンジニアtype | 転職type
2022.11.15 働き方 SIerプログラマーひろゆき駆け出し 日本のSI（システムインテグレーション）ビジネスの未来を危惧する声が聞かれるようになって久しい。にも関わらず、旧態依然としたビジネスモデルは回り続けており、そこでは多くのエンジニアが今も働いている。 日本最大の電子掲示板「２ちゃんねる（現５ちゃんねる）」の設立者であり、理路整然とした語り口と歯に衣着せぬ物言いで知られるひろゆき氏は、そうしたエンジニアに向けて「今すぐ逃げた方がいい」と呼びかける。 改めて、SIerはなぜ「ヤバい」のか。どうやって「それ以外の道」を模索すればいいのか。最新著『働き方完全無双』の売れ行きも好調なひろゆき氏に、今エンジニアが採るべきキャリア戦略を聞いた。 ※本記事は2018年8月7日に公開し、2022年11月15日に最新プロフィール情報に更新しています。 ひろゆき（@hirox246） 本名・西村
中堅中小SIerの逆襲が始まる
多重下請け構造が広がるIT業界で、ある異変が起きている。これまで下請けだった中堅中小のシステムインテグレーター（SIer）が、ユーザー企業と直接取引し始めているのだ。大手SIerとのコンペでも案件を勝ち取る例も珍しくない。理不尽な立場に追い込まれていた下請けSIerの“逆襲”と呼ベるが、ピンハネや丸投げを繰り返してきたような一部の元請けは窮地にさらされそうだ。 何もしないのに「4割」持っていく元請け 下請け時代に「死ぬまでやってくれる」と元請けから評され、約30年にわたって苦しみに耐えてきた中小SIerのシナプスイノベーション。同社は現在、下請けから元請けへと昇格し、ユーザー企業と直接取引できるようになった。同社の藤本繁夫社長はかつての元請けへの怒りをこうぶちまける。「（元請けが手掛ける）上流工程の遅れはすべて下請けがかぶらされる。料金をもらえない仕様変更も頻発。労働時間は全くコントロール
普通の受託開発会社をクラウドダイブさせる金春氏にとってのkintone (1/3)
kintoneとAWSのインテグレーションを積極的に手がける大阪のアールスリーインスティテュート。長らく普通の受託開発の会社だったにも関わらず、AWSとコミュニティ、そしてkintoneに出会ったことで突然変異を遂げている。アールスリーの金春利幸さんにkintoneにたどり着くまでの長い道のり、クラウドとコミュニティにかける想いを聞いた。（インタビュアーTECH.ASCII.jp 大谷イビサ） 大手SIerへの失念から受託開発会社の起業、そして淡々と12年 金春氏への対面でのインタビューは実は2回目で、初対面だった3年前にはJAWS-UGの人としてお話を聞いた。しかし、その後は金春氏も会社も大きく様変わりし、kintoneへの全力コミットを開始するようになるのだが、そこまでの経緯を再度おさらいしておこうと思う。3年の月日が経ち、金春氏ともユーザーコミュニティで親睦を深めてきたことで、より深
IT業界の「デスマーチ」がもたらすものは、長時間労働や人材の疲弊だけではない。もっと深刻だ。
IT業界が外部の人間から敬遠される理由の一つに「デスマーチ」がある。 ほとんど実現不可能に思える無理なスケジュールで、深夜におよぶ残業、休日出勤の連続、人海戦術でほとんど役に立たない新人までが駆り出され、終わりの見えないプロジェクトの完成にひた走る、これがデスマーチである。 そこではプログラマは一人また一人と過労に倒れ、うつろな目でキーボードを叩き続けるプログラマの連続勤務時間は20時間を優に超える、といった光景が見られる。 このようなデスマーチについて、人材の疲弊やそれに伴う退職など、ITベンダー側の不利益が語られることは多いが、クライアント側の不利益、もっといえばプロジェクトの成果物自体がデスマーチで台無しになってしまうことはあまり知られていない。 デスマーチのきっかけ 営業の無謀な受注、仕様の調整不足などで、システムの実装行程が確保できず、どうやっても通常の開発体制ではシステムの完成
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ITの多重下請け壊す？ 日本マイクロソフトが内製化促進 - 日本経済新聞
20代が激減、40代以上が増加傾向にあるSE業界 | スラド デベロッパー