どうせ理系出身者なんていらねえんだよ。
いまさら言ってもしょうがないだろうが、SIerに就職を希望したり内定した人たちに一言いっておきたい。 http://blog.miraclelinux.com/yume/2007/11/post_1ab2.html http://d.hatena.ne.jp/itoyosuke/20071101/1193932945 http://www.atmarkit.co.jp/news/200710/31/ipa.html 元の報道や参加者のブログエントリ見たりすると、ありがち過ぎて泣けるのだ。はっきりいうと、SIerの人事は情報工学科出身者は求めていない。それどころか理系出身者すら求めていない。 口先では求めているというよ。また、現場で最後に「技術的になんとかする」のは理系に期待されることが多いし、実際に期待通りに解決するのは大抵理系だ。しかし評価はされないし感謝もされないよ。とくに給料に反映す
人月計算とExcelとスーツの世界より
俺の住む世界はアイティーとやらに支えられているらしい。 アイティーに関われば、俺の住む世界をさらに素敵なものにしていけるに違いない。していきたい。 そう願って、何も知らなかった文系新卒の俺が金融系のシステム会社に入って、もう一年以上が経つのだ。 昔、お遊びでゲームを作ったことはあった。RPGツクールなんかが好きだった。 だから自分はシステム会社に向いていると思った。 実際、資格取得を勧められて始めた勉強は楽しかった。 浮動小数点数、オートマトン、SQL、スタック、木、論理式。 パズルみたいで楽しかった。コンピュータの中身が理解できて、わくわくした。 楽々と基本情報技術者の資格を手にし、半年後にはほとんど勉強もせずにソフ開も取得した。 研修の課題では同期の誰よりも速く、短く効率のいいソースを仕上げた。 現場に出て、本番機に触った。 ３０年間親会社を支え続ける偉大なシステムの中身を、わくわくし
スーパークリエイターがSI業界で即戦力になれない理由 - aikeの日記
少し前に若いエンジニア達と話す機会があった。この春SI企業に入社してプログラミングの研修を受けているという。みんなそれぞれ能力が高い上に、学習の高速道路を爆走中といった感じでネット上で話題になっているような技術情報には十分詳しい。SICPを全部解いたとも言っていたし本当はプログラミングの研修なんか必要ないのだろう。未踏に応募したり勉強会を開催したりするのはこういったタイプなんだろうかとか、いまどきのSI企業の人材獲得能力はすごいなとか思いつつ、でも彼らはこの業界に何を求めてどうなろうとしているのか少し気になったりもした。 これほど優秀で勉強もしてきた人達でも、SIerとしては即戦力にはならない。社会人マナーとか仕事の進め方の話ではなくて、単純に知識不足という意味で。そのため一緒に入社したプログラミング能力の低い社員と同じように扱われる可能性が高い。これはすごく不幸な状態だと思う。SI業界が
SI業界を目指す君達へ贈る「何故システム開発はテンパるのか」 - novtan別館
先日学生に聞かれたんですよ。 「下流工程は大変って聞きますが、上流は楽なんですよね？」 よろしい、君はよく勉強している。でも根本的に間違っている。下流工程が辛いのは、上流工程でちゃんと仕事ができなかったからだ*1。 というわけで、主に学生向きに話を単純化して語ってみます。これが普通だとか、一般的だとか言うつもりはなく、違う視点もあるかと思いますが、一つの考え方として。 SIでのシステム開発は、建設業にたとえられます。が。 顧客の希望を聞き、設計し、施工し、引き渡す。こういった工程を踏む仕事ということで、システム開発はよく建設業にたとえられます。実際に工程管理の手法なども似通っています。ところが、大抵の場合、耐震偽造をした建築物よりもシステムのほうが脆弱に仕上がります。何故でしょうか。 一つには、建物の図面を引くには建築士の資格が必要ですが、システムの設計に資格は必要ありません。 もう一つ、
ミスとかトラブルとか - 最速配信研究会(@yamaz)
UIEUEIのid:shi3zさんがミスについての話を書いておられる(会社名間違えてました.大変失礼しました. > shi3zさん). 部下が致命的なミスをするのは全面的に上司の責任 1行でまとめると「ミスは必ずおきるので,ミスを事前に検知する仕組みが必要だよ」ということなんだけど,私も前職ではありとあらゆるミスやトラブルに遭い,それに対して思うところがあるので,どう対処してきたかを書いてみようと思う. このエントリは長くなりそうなので,先に「今来た3行」でまとめるとこんな感じになる. ミスやトラブルはありとあらゆる隙間を縫っておきるので,確率的なものととらえる方がいいよ. ミスやトラブルがおきた時の影響を最少にするためにはミスやトラブルを検知することの他に,「そもそもそんなミスが起きえないようにする」,「万一そのミスがおきても大丈夫なようにする」為の仕組み作りが重要だよ. 根性論に頼るの
SIerが必要としているのは業務知識だという都市伝説 - ひがやすを blog
SI業界が開発するシステムの目的は何か？ それがつまり「業務知識」というやつで、金融や保険だったり、証券取引、財務会計、生産管理、物流・在庫管理、販売管理だったりするのだ。それぞれ必要とされる知識は非常に多い。普通の新入社員がOJTで身につけようと思ったら数年かかってもおかしくないだろう。 金融(ディラーが使うようなポジション計算をするフロントシステム、リスク計算をするようなミドルオフィス、勘定系のバックオフィス)、流通、輸出入、製薬など、いろんな業務をやってきたおいらが通りますよ。 確かに金融は業務知識がないと歯が立たない。でも、自分の経験した限りでは、それ以外の業務は、案件が始まってから勉強しても十分間に合います。 一週間以内の勉強で、お客様のところにいってシステムの仕様を話し合うことはできるようになります。もちろん、この道何年って人にはかないませんよ。でも、仕様を決める分には困らない
プログラマが仕様を決めればいい - GoTheDistance
最近よく思います。 システム開発の上流工程においてはコードは出てこない。言葉や図解で埋めつくされて、最終的には日本語でしかない。設計書とか仕様書とか。で、この大抵上流工程ではこれらのドキュメントに対するレビューなるものがあるのですが、これが実に無益なものだと感じることが多い。こんな所でPDCAまわして何が面白いんだろうとよく思う。 ここでチェックする多くのことは、言葉の解釈に関することがほとんどです。 この言葉はプロジェクトで使われていない 書き方が統一されていない 誤字脱字が多いので直せ。 この文章ではこのように解釈される恐れがある ここではこのような話になっていたがどうなのか こんなんばっか。どこもそうだと思う。解釈の違いは、要件の違い。なんちゃって。 で、結局こういうことを繰り返していくうちに段々とドキュメントがグダグダになっていく。そして繰り返していっても前提が変わってしまえば全部
本当は楽しいIT業界――“重鎮”を超えて − ＠IT
2007/12/26 日本のIT業界は暗い話題に事欠かない。国内にはシステムエンジニアが31万人、プログラマが15万人いる。ユーザー企業のIT技術者やフリーのIT技術者を加えると50万人を超える人が関わっている。専門技術者では建築土木技術者に次いで多いといわれる。情報サービス業界全体の売り上げは16兆7000億円を超える（参考資料PDF）。IT業界が生まれて50年以上たち、それなりの規模に成長してきたわけだ。ただ、IT業界のイメージはここ数年で悪化してしまった。このままでいいと思っているIT業界内の人間は少ないだろう。＠ITが10月末に掲載した記事「IT業界不人気の理由は？現役学生が語るそのネガティブイメージ」が高い注目を集めたのは、IT業界の今後に対する不安が反映された結果だ。 IT業界。簡単に使ってしまっているがこの言葉が指す業界は幅広い。代表的なのはソフトウェア開発業だ。そのソフトウ
木走日記 - ＩＴ技術者派遣業〜現代日本の「奴隷商人」達
２月と言えば日本では試験の季節でありますね。 不肖・木走は、本業のＩＴ関連の零細企業経営の傍ら、工学系学校の講師をしていますので、この季節はゆううつなのでございます。 なんでゆううつなのかと言えば、担当科目の試験問題の作成とその採点があるからでございます。 私の現在の受け持ち科目はＷｅｂに関わるテクノロジー関連（科目名は内緒ネ（苦笑））なのですが、自分の得意である専門科目でありますから問題などすぐできるだろうと思われるのですが、それがそんな甘いもんじゃないのですよ、これが。 手を抜いて出題を「ＳＧＭＬ、ＸＭＬ、ＨＴＭＬ、ＸＨＴＭＬなどのマークアップ言語の詳細を述べよ」なんて記述問題にしちゃうと採点作業が地獄（苦笑）となっちゃうのでして、逆に採点を楽にしようとすれば問題を文章穴埋め問題とか手間暇掛けて作成しなければならないのであります。 先に苦労するか後で苦労するか、私のような本業掛け持ちの
知的労働者には「組織を移る力」がある
前回のエントリーに、Doraさんという方から「次回エントリー『こうすれば日本のSEは救われる！』を楽しみにしております！？」とのコメントをいただき、少し悩んでしまった。日本のSIer（少し前までは「SI屋」だと思っていた）の階層構造の問題を指摘しておきながら、何も提案しないのはあまりにも無責任かも知れない。 だからと言って、「日本のIT産業はこうあるべきだ」などと部外者である私が本当の意味で影響力のある発言をするのはあまりにも難しい。特に、IT業界に限らず、一旦こういった階層構造が出来てしまうと、業界で力を持つ上位レイヤーの会社や人たちにとって、改革は自己否定にもつながりかねないので良いと分かってはいても自分からわざわざ着手できない、というジレンマがあるのが一層解決を困難にしている。 では、現時点でIT業界で苦しむSEやプログラマーの人たちは何をしたら良いのだろうか。 とても難しい問題では
雑種路線でいこう - 自分が使い捨てられるのが怖くて会社を使い捨てる生き方
ぼくが大学に入って間もなくアキバの雑居ビルにあるジャンク屋で店番をしていた頃，DOS/Vの普及でパソコンの価格が暴落し，消費税が5%になって客足もパタリと止まり，メモリとかも潰れた問屋からのフロア買いが横行して香港のスポット価格よりアキバの店頭価格の方が低いという無茶苦茶な状況になってたんだけど「あのいい歳して量販店の店頭でハッピ着てパソコン売ってるおっちゃんたち，20年くらい前は系列SI業者でRPGとかJCL使ってホスト運用してたんだぜ」とか店長にいわれて，あーIT業界というのはこうやってヒトを使い捨てにしていくのか．グループでずっと面倒みてくれるのは親切という気もするけど，恐ろしい世界だな，と思った．自分はどう生きれば，20年後にハッピ着て量販店の店頭で接客しているのではなしに，自分の経験を糧に，周囲から尊敬され，やり甲斐のある仕事にありつけているんだろうか，と悩み始めた． 間もなくジ
使い回しの提案が目立つ「できます」と簡単に言うな
使い回しの提案が目立つ「できます」と簡単に言うな 石川 淳氏 プロントコーポレーション 経営企画室経営企画グループ担当マネージャー ITベンダーの営業担当者にはもっと、当社の業務を理解しようという姿勢を見せてもらいたい。提案書を見て、「使い回している」と感じることが多く、がっかりすることもある。 カフェチェーン「プロント」のPOS（販売時点情報管理）システムの再構築を検討していた4年前もそうだった。この案件では、8社のITベンダーから提案書をもらった。 既存のPOSシステムを構築したSIerや、飲食業向けPOSシステムの構築実績が多数あると聞いていた大手メーカーなどに声を掛けた。会社の規模も実績も申し分ないと思い、優れた提案書が出てくるはずだと考えていた。 ところが、この期待は裏切られた。いずれの提案書も、最新のPOS端末やソフトウエアの機能の説明に、大半のページが割かれていた。あとは開発
IT業界のネガティブイメージ - カレーなる辛口Javaな加齢日記
http://www.atmarkit.co.jp/news/200710/31/ipa.html 業界の重鎮もたじたじ 業界の重鎮＝老害？ 「トヨタ自動車やソニーのようなユーザー企業と違い、IT（の導入）しか行っていないNTTデータのような会社が一番謎」といった疑問が出た。イメージを聞かれても、そのイメージ自体が何もないという皮肉な答えだ。 必ずしも全員が3Kではない」と反論。岡本氏も「3Kの“帰れない”は、帰りたくない人が帰れないだけ。スケジュール管理の問題だ。 ふーん．帰りたくない人が９０％以上を占めるとは知らなかったな． できるヤツから潰される：http://www.mars.dti.ne.jp/~hirok/xp/col/031.html なぜ日本はこれほど残業が多いのだろう。理由は二つある。 もともと、年功序列・終身雇用というものは、ある程度の残業を前提にしたシステムだ。賃下げ
国産ベンダが目覚める前にエンジニアの空洞化が始まる ― ＠IT
2007/11/30 ガートナー ジャパンは11月30日、同社のイベント「Gartner SYMPOSIUM ITXPO 2007」でメディア向けのセッションを開催し、「日本の大手ベンダはオープン化で欧米のベンダに遅れて、また次の時代にも周回遅れになりそうになっている。20年は遅れる」（同社 ITインフラストラクチャ バイス プレジデント 亦賀忠明氏）と警告した。 ガートナーがこう警告する背景には、米国でグーグルが急成長し、IBMやオラクル、SAPなどの既存の大手ベンダに売り上げで迫りつつあることがある。グーグルは積極的な企業買収や、ユーザー指向のサービス開発、クラウド・コンピューティングの推進などで他社を圧倒。IBMなどもグーグルを最大のライバルと考え、クラウド・コンピューティングの戦略を練っている。そこにはNECや富士通、日立製作所などの国産ベンダが付け入る隙はなさそうだ。 象徴的なの
IT産業を呪縛する 「変われない日本」 - モジログ
ITproの高橋信頼記者より、先日の私のエントリ（「雇用規制撤廃と減税で日本経済は再生する」）を紹介したとの連絡をいただき、さっそく読んだ。 ITpro - 学生とIT業界トップの公開対談で胸を衝かれたこと---IT産業を呪縛する“変われない日本” http://itpro.nikkeibp.co.jp/article/COLUMN/20080530/305172/ ここしばらくIT系ブログやソーシャルブックマークなどで大きな話題になっていた、IPAX2008での対談イベント（関連記事は末尾を参照）をふりかえりつつ、そこにあらわれたIT業界の問題点が分析されている。 まず、IT業界のダメっぷりを示すこのエピソードが面白い。 ＜昔、「行き詰ったプロジェクトを立て直す」というテーマで取材したときに、ある大手システム・インテグレータで聞いた話だ。そのインテグレータで、火を噴いたあるプロジェクトを
情報サービス産業を救う銀の弾丸はない - 雑種路線でいこう
そうそう人月はなくならない。世界の何処だってヒトを売るときは人月だ。同じヒトを買うならユーザー企業が直接雇用した方が方が安いし組織の壁がなく合理的だ。米国で日本よりパッケージの活用が進むなど合理的な情報システムが構築されやすいのは、一時的なコンサルティングやプロフェッショナルサービスはともかく、システムの企画とか調整はユーザー企業の従業員が行っていることが大きい。きっちり業務プロセスから見直すことができるし、ちゃんとコストを下げるインセンティブが働いているのだ。 日本でそういった企業が少ないのは、ジョブローテーションの中で情シス部門のスペシャリストを育て、しかるべき処遇を用意することが難しく、減点法の人事評価ではリスクを取って新しい技術を導入するより、付き合いの長い業者に丸投げして失敗を避け、或いは失敗しても責任を押し付けた方が得だからだ。 つまりユーザー企業の発注能力が低いとか、重層的な
NTTデータと真昼の対決 - ひがやすを技術ブログ
昨日、NTTデータに「お前は最近、NTTデータに批判的でけしからん」ということで、呼び出されました。もちろん、「批判的でけしからん」というのは冗談ですが、私が、NTTデータを嫌っていると思っているデータ関係者は、実際多いようです。 データの偉い人の発言に対して、それはちょっとおかしいんじゃないのといったことはありますが、データを嫌いといったことはもちろんないはず。 データの社員の中に根強くある(と思う)「プログラミングがあまりできない人でも何とかなるように、ガチガチにルールやツールで縛る。できる人はスキルを発揮できなくなるかもしれないけど、それはしょうがない。」という考えは、個人的には好きじゃないけど。大規模なプロジェクトをまかされるSIerとして、そう思う気持ちは良くわかるんだけどね。 話し合いの中で、私が言ったのは、できる開発者が力を発揮できるように、体力勝負になってしまうような縛りは
人月を超えるということ
人月というのは文字通り働いた時間に応じて請求が行われるというもの。ブルーカラー的な労働をしている限りは人月で働くことは正当なわけです。 「作らない」という視点 人月を超えるためには時間に関係なく圧倒的な成果を挙げる方法を見つけなくてはいけません。でも、圧倒的に生産性をあげるという視点ではだめ。生産性を上げているというのは、あるプロセスの作業効率をあげて時間を短くしているに過ぎないので時間給の罠からは逃げられない。ありがちな話として3ヶ月かかるAさんよりも、2人月でできるBさんのほうが実入りが少ない。 では、どうするかというと「作らない」という視点になる必要性があります。作らないというのどういうことかというと「作ったものをいかに使いまわせすか」か「いかに他人に作ってもらうか」ということです。 作ったものをいかに使いまわせすか＝レバレッジを効かす 使いまわすというのはレバレッジ（てこ）を効
浜口さんに贈るSI業界を良くする方法 - ひがやすを技術ブログ
浜口さんの言葉には、ブクマや突っ込みを生み出す何かがありますね。 したがってシステムの大規模化は、必然的に想像以上のコストアップと信頼性リスクの増大を招くものであるとの認識が必要になる。 きました。想像以上のコストアップだそうです。 そんな浜口さんに贈ります。今よりコストダウンさせて、SI業界を良くする方法。 例えば、誰が書いても同じコードにするために、プログラム設計書(内部設計書)を今、書かせているとしたら、そんな無駄なものはやめたほうがいいと思う。 プログラム設計書は、自然言語で書きます。プログラムは、プログラミング言語で書きます。どっちの言語が、プログラムを書くのに適しているかといえば、誰が考えても、プログラミング言語ですよね。 いきなりプログラミングはできない人もいるから、プログラム設計書が必要だという人もいるかもしれませんが、それは、間違っていると断言しましょう。 いきなりプログ
受託からサービスへの移行に必要なこと。
よくwebの受託をメインにやっている会社さんが、儲からないという理由でサービスに行きたいとの話を聞く。 しかし結構、難しいですよね、と、ついつい言ってしまう。 理由のコアは、下記エントリーに書いてあった。 「中毒性」ある受託開発がソフトウェアベンチャーの躍進を阻む １．受託開発では「技術」が蓄積しない ２．受託開発では「人材」が蓄積しない ３．受託開発では「資金」が蓄積しない 技術が蓄積されないのは自社の役割や案件次第では？と思うこと以外は、結構同意だ。 （受託は、自社では実現できない案件に関われることなどが魅力で、そこに技術やノウハウ習得のチャンスは転がっていると思うし。） 一番重要なのは、キャッシュフローが安定しないところではないだろうか。 サービスと受託の大きな違いは、 「受託は技術を売る仕事」 「サービスは、文字通りサービスを売る仕事」 である。 サービスは、お客様がつくと継続的に
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
