ニッポンIT業界絶望論:江島健太郎 / Kenn's Clairvoyance - CNET Japan
日本のIT業界は救いようがない。絶望的としか言いようがない。 IT業界不人気なんて、この業界に重くのしかかる決して晴れることのない暗雲の氷山の一角に過ぎない。はてなの匿名ダイアリーにもどうせ理系出身者なんていらねえんだよ。なんて書かれていたけど、これが現実なのだよ、学生諸君。 ちょっと補足しておくけど、ここでIT業界っていうのは、SIerのことだ。お客さんの要件をヒアリングして、その要求に沿ったシステムを受託開発するっていうビジネスのことを指している。 ぼくもその昔、その世界のループに組み込まれていた。そして華麗なるコミュニケーション能力とやらをいかんなく発揮し、場の空気を読み、生意気なぐらいのチャレンジ精神で、それなりに仕事のできるよい子だったようだ。 いや、正直に言うよ。正直に言うとだね、結構楽しかった。 だって、考えてみてごらん。お客さんのところに出向いて行って、その業界のことをじっ
外国人のホンネ「ソコがヘンだよ！日本人エンジニア」／Ｔｅｃｈ総研
職場に外国人エンジニアが徐々に増えはじめ、いよいよグローバリゼーションが実感をともなってきた。しかし、異国の目から見たニッポンの仕事・職場はまだまだ“ヘン”がいっぱいの様子。外国人エンジニアの本音をズバリ直撃してみた！ 少子化による理工系学生減少のため、IT業界の人材が不足し、大手メーカーも今後の巨大マーケットを見越して中国をはじめとするアジア諸国に海外事業所を設置するなど、優秀な外国人エンジニアの獲得に積極的だ。今回の調査でも「外国人と仕事の接点がある」と答えた人が50％と半数を占め、57％が外国人と仕事をする機会の増加を認めている。外国人エンジニアの技術力へのハングリー精神や高い語学力に「刺激を受けた」という回答も多く、外国人エンジニアの存在は「よき競争相手」「よき仕事仲間」として認識されはじめている。 技術力は国境を越えても、なかなか越えられないのが言葉の壁とワークカルチャーの違い。
強制労働の文化
JavaBlackさんのところの産科医が年間300件の分娩するまで問題はないという記事を読んだ。 なんだか某業界を見るようだ． 1. 営業が赤字案件を取ってきた． 2. 開発が月１００時間残業でなんとか間に合わせる 3. 営業は次からは残業１００時間込みで見積もりするようになる． 4. 残業時間が２００時間，３００時間と増えていく． 5. 開発メンバーが辞めはじめる．（今の産科医療はここ．） 6. 会社が潰れる． ふーむ。そういうスパイラルだなあ、確かに、と妙に納得。 そこで紹介されていた、masayangさんのエントリー。 「生産性を向上させても、その分仕事を追加されるのがオチ」と考えている人が少なからずいる あとJavaBlackさん経由で、城繁幸さんの、休まない国、日本というエントリー。 更に雑感@取材のここ。 「勝ち組という幻想にこだわるよりも、既に既存の価値観が破綻していることを
ユメのチカラ: 開発工程を別々に担当してはいけない
古典的なウォータフォールモデルでは、ソフトウェア開発を要求仕様分析、概要設計、詳細設計、実装(コーディング)、内部テスト、統合テスト、運用、保守みたいな工程にわけ、通常は各工程を別々の人が担当するというような方法がよくおこなわれている。 特に、要求仕様の分析、概要設計などは上流工程などとよばれていて、詳細設計、実装とは別の人ないしは組織が担当する。実装とかテストは下流工程などとよばれている。 よくあるパターンとしては元請けが上流工程を、下請け、孫請けが実装やテストなどを担当し、人月単価も下流の方が安い。 ウォーターフォールモデルでは各工程毎に成果物(仕様書や各種ドキュメント、プログラム)が大量に生産される。各フェーズ毎に定義された成果物がそろってから次のフェーズに移行するというのが建前なので、各フェーズでのドキュメントはどうしても冗長になりがちである。 一度固定した文書は次のフェーズで変更
「渡された仕様書を実装するサラリーマンプログラマ」の悲哀
@ITの「業務用途でRubyを使う上での課題 」を読んでなんだか悲しくなった。 チーム開発でRubyを使ったときに今後起こりえる問題として、サン・マイクロシステムズ システム技術統括本部 チーフテクノロジストの下道高志氏は、こう指摘する。「他人の書いたPHPコードのメンテナンスはできない。Rubyはどうかといえば、現状はいい。しかし今後“職業プログラマ”ではなく、渡された仕様書を実装する“サラリーマンプログラマ”が増えてくると、コードのスパゲッティ化は避けられないだろう」。 【業務用途でRubyを使う上での課題 − ＠ITより引用】 これは言語の問題ではなく、日本のソフトウェア産業全体が抱える問題。以前にも「ソフトウェアの仕様書は料理のレシピに似ている」というエントリーで書いたが、本来のソフトウェア作りとは、絵を描いたり、音楽を作ったり、建物をデザインするのと同じ「創作活動」である。ドラッ
アメリカにはSIerなんて存在しない - GoTheDistance
知人のmark-wadaさんのBlogからTB。 親子丼的ビジネス奮闘記(4) IT業界構造 SIerなんてものは無い 米国と日本との大きな違いは、米国の企業は基本的に内製なのだ。すなわち、社内のＩＴ部門に開発エンジニアを抱え、そこでシステムの開発から運用を行なう。 ですから、米国のベンダーはそこに製品を供給する役割であり、日本でいうSIerというのはほとんどなく、あっても企業でリソースが不足したらそれを補う役割でしかない。契約にしてもはっきりしますよね。提供されるプロダクトやサービスに対する対価を払えばよいわけで、かかった人月で支払ういう出来高払いのような形態は少ない。日本のようにベンダーやSIerに丸投げして、できてからこんなはずではなかったなんて事態にははじめからならない構造なのだ。 親子丼的ビジネス奮闘記(4) IT業界構造 言われてみれば・・・、っていう感じですが改めて目が鱗です
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
