エンジニアによる情報漏洩とSI多重請負の闇：日経ビジネスオンライン片山 良平 ギノ株式会社 代表取締役社長 2012年にギノを設立、ITエンジニアに実際にプログラムを書いてもらい技術を評価するサービス「paiza」（パイザ）を2013年10月に開始した。ニートや音楽活動をしていたという異色の経歴も。 この著者の記事を見る
銀行「技術者が足りなくて死にそうなの！助けて…」俺ら「単価上げろよ」 - novtan別館
なんかのギャグですかね？ IT技術者がいない みずほ不安の「2020年問題」 :日本経済新聞 みずほのシステム更改の予算感についてはもしかしたらアベノミクスによって大幅に増額を強いられるかもしれませな。その分本業で稼げる気がするけど。 まあそれ以前の問題で みずほ銀向けのシステム開発とは、基幹システムの統合作業のこと。みずほ銀は当初、2016年春の作業完了を目指していたが、作業に万全を期すため、２月になって計画を１年間ほど延期する方針を決めた。一見、開発スケジュールに余裕ができたようにみえるが、この幹部は心配している。 余裕ねーよｗｗｗｗ どうもここ数ヶ月で技術者の単価が急上昇している気配があります。リーマン・ショックからこのかた、銀行のシステム案件（銀行に限らずではあるけど特に）は「単価低減」要請との戦いと言っても過言ではない世界でした。現場では「単価下げたらクズしか残んないよ」という懸
プログラムの生産性をあげるためには - きしだのHatena
前回のエントリで、プログラマの業界が労働集約的なものと知識集約的なものにわかれてきているという話を書きました。 プログラマ業界の二分化 - きしだのはてな 前のエントリでは労働集約的なものと知識集約的なものに完全にわかれているように書きましたが、もちろん完全に労働集約的であったり完全に知識集約的であったりすることは少なく、どのような組織でもある程度は両方の性質をもっています。知識集約的な性質の強いSI会社というのもあります。 ただ、SIに労働集約的な、サービスに知識集約的な性質が強くなる傾向はあると思います。 また、知識集約的であればよくて労働集約的であればダメということもありません。労働集約的なSIでありながら良い会社というのもあります。 という断りをいれておかないと、SIで労働集約だからといって全部ひとからげにするなという、労働集約的なSIでありながら良い会社方面から鋭利なマサカリが飛
4年前、おれがSIerの片隅で、何者でもなかった頃 - たごもりすメモ
今からちょうど4年前の2010年2月、某巨大SIerの片隅でExcelやPowerPointばかりを眺めて過ごしていた頃、おれは仕事でも仕事以外でもコードなんかまったく書いていなかったし、GitHubのアカウントも持ってなかった。毎日見積書とWBSと納品書と請求書と、Excel方眼紙の詳細設計書と格闘してた。 当時おれは30歳だった。一度はプログラマとして生きるのは自分には無理だと思って入社したSIerで数年やってて、そこそこ成功した数年を送っているとは思っていたけど、でもやっぱり、そんな毎日に飽きていた。 技術力を重視とか言いながらプロパー社員にコードを書かせようとしない会社の方針にも、svnもgitも閉じられててガチガチに監視されたネットワークに繋がせておいてオープンソースがどうのと言う文化にも、手順や履歴を重視とか言いながらロクにバージョン管理システムを使おうとしない一部の同僚にも、
生産性が高いエンジニアを評価するための２つの仕組み - レベルエンター山本大のブログ
仕事ができるプログラマって、できないプログラマに比べて「１０倍」も生産性が高い。とか言う話がありますよね。 僕も体感的に、本当にできるエンジニアは本当に生産性が５倍とか１０倍とか変わることを見てきました。 でも開発の現場では「残業しまくってる」ほうが、なんだか仕事してるように見えてしまう。 そんな中で久々にこの記事を目にしました（漫画なので1分ぐらいで読めます）。 ■「残業しないで帰るSEってやるきないんじゃない？」 http://next.rikunabi.com/tech/docs/ct_s03600.jsp?p=000800 2006年の記事ではありますが、こういう話って普遍的なので古くもありませんね・ 残業しないで定時に帰れるって評価するべきだし、残業をせず家庭を大事にする社風にしたい。 すごく生産性が高いっていうエンジニアを評価したい。 でも残業してるのって分かりやすいから評価さ
コーディング技術にこだわり過ぎるとITエンジニアの地位は向上しない - プロマネブログ
日本のITエンジニアの地位はなぜ低いのか：日経ビジネスオンライン エンジニアの地位向上を図りたい、これは同意ですが、そのための解決策がコーディングスキルですか。。。 エンジニアの地位向上のためには、まず何が問題かをきちんと分析できなければ話になりません。ちょっと考えてみます。 追記) なぜかブコメ欄を見るといろいろコメントが発散してる。。。 下手な日本語で申し訳ないです。 本旨は「プラスアルファが必要って言ってるのに、paizaはコーディングの話だけなんだ～。プラスアルファどこいった」です。 ちなみにJavaの誤記は直しときました ブクマ炎上反省会はこちら 「コーディング技術にこだわり過ぎると～」の反省会 - プロマネブログ IT業界の価値提供の構造 いわゆるSIerをモデルに価値をどのように提供しているのか、考えてみます。 ※まあ、自分の仕事から考えるのが一番カンタンですし。 SIerを
2014年のSIビジネスとかそのあたり - 急がば回れ、選ぶなら近道
というわけで2014年に突入ですが・・・ 景気が回復しつつある現状で、SIの受注も好調なようです。ユーザー企業でも多少の予算の余裕も出てくるところもあり、システム投資には多少前向きになっているところも感じます。多少のでこぼこや、業界・業種によって色合いは異なるでしょうが、今後数年は景気の回復基調はコンセンサスになりつつあるようです。IT業界も例外ではないでしょう。もたもたしているビッグデータ案件を尻目に、システムリプレースや既存改修、新規でのシステム開発もスタートしつつあり、SI業界の件数ベースは今年は昨年を確実に上回るでしょう。 とはいえ一方で不採算案件も相当増えるように見えます。結果、SIビジネスはトレンド的には案件増・売上増ですが、利益減（または横ばい）というのが実態になるかと。要するに単金はそうそう簡単にはあがりませんが、案件は増えて、人繰りが追いつかず、結果限りなく失敗に近い「よ
「SIガラパゴス」を育んだIT部門の罪
日本のIT産業は、世界に類を見ないユニークなエコシステム（生態系）をつくり上げた。大手SIerを頂点とする多重下請け構造のピラミッドから成るITサービス業のことだ。日本だけで独自進化し一大産業として繁栄した。私はこれを「SIガラパゴス」と呼ぶ（関連記事：日本だけ！「SIガラパゴス」に明日はあるか）。 極めて便利な存在であるため、ユーザー企業はこの生態系を育んだ。その結果、日本企業のIT活用は今や欧米企業に比べ周回遅れで、新興国の企業にも追い抜かれようとしている。 米国のITベンダーの日本法人社長は、本社の幹部から「なぜ日本にはITサービス会社があんなにたくさんあるのか」とよく聞かれるそうだ。米国にもアクセンチュアやEDSのような企業は存在するが、数は限られているからだ。そして回答に苦慮する。 「日本のユーザー企業は独自仕様のシステムを作りたがるのに、その開発を外部委託することが多いから」。
顧客に価値を届ける、ってなんだっけ - (define -ayalog '())
2013-12-09 顧客に価値を届ける、ってなんだっけ 開発 日記 最近、@syobochimのブログを読んでいたら、こんな言葉が書いてあった。 顧客に価値を届けたい。 私はいま、価値届けられてるんだろうか。 アジャイルサムライを読んだら意識高まってつらい - そこに仁義はあるのか(仮) 僕はどうだろうか。今のプロジェクトはありていに言えば"炎上"している。 そんな中で「誰の考え方が一番正しい」のか分からなくなった。ので、今日はそんな話を書いてみようと思う。 この話の登場人物 あやぴー 僕です。 マツダさん 僕と同じ会社の先輩。エンジニア歴10年位。 モリさん 僕と同じ会社の上司にあたる人。エンジニア歴20年位の大ベテラン。 イノウエさん 元請けの会社に8月くらいに中途で入社したエンジニアさんで立場的にはプロジェクトリーダー(PL)的な感じ。転職するまでPL1とかVBとかのお仕事を
なぜ大手ICT企業で不採算案件が相次ぐのか、「対岸の火事」では済まされぬ根本的な原因
大手ICT企業の2013年度上期（2013年4～9月）の連結決算は、景気回復への追い風もあり、おおむね好調だったと思う。だが一方で、なぜか不採算案件の発表が相次いだのも特徴だった。
「SIをダメにする負のスパイラル」
きしだൠ(K1S) @kis SIの、元請はユーザー企業の業務をよりよくするために、プロダクトを作るんじゃなくて契約書をつくる。で、元請はそれを下請けにつくらせるんだけど、そのときはユーザー企業の業務をよりよくするためではなく契約を満たすためにプロダクトを作らせる。これが負のスパイラルの発端。 2013-11-15 08:17:14 きしだൠ(K1S) @kis 契約を満たすことが目的でプロダクトを作ってるから、実装段階で気づいたアイデアや欠陥は報告されない。納期や金額なんかの契約は満たさないといけないのに追加仕様や変更が発生してやぶへびだもん。品質は悪くなる。 2013-11-15 08:23:58 きしだൠ(K1S) @kis 品質が悪くなってとられる対策は、技術向上ではなく契約の厳密化。設計書を「きっちり」つくるとか、テストのエビデンス(画面キャプチャのかっこいい言い方)をとるとか、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IT技術者がいない みずほ不安の「2020年問題」 - 日本経済新聞