サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
いまさら言ってもしょうがないだろうが、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の人事は情報工学科出身者は求めていない。それどころか理系出身者すら求めていない。 口先では求めているというよ。また、現場で最後に「技術的になんとかする」のは理系に期待されることが多いし、実際に期待通りに解決するのは大抵理系だ。しかし評価はされないし感謝もされないよ。とくに給料に反映す
先日学生に聞かれたんですよ。 「下流工程は大変って聞きますが、上流は楽なんですよね？」 よろしい、君はよく勉強している。でも根本的に間違っている。下流工程が辛いのは、上流工程でちゃんと仕事ができなかったからだ*1。 というわけで、主に学生向きに話を単純化して語ってみます。これが普通だとか、一般的だとか言うつもりはなく、違う視点もあるかと思いますが、一つの考え方として。 SIでのシステム開発は、建設業にたとえられます。が。 顧客の希望を聞き、設計し、施工し、引き渡す。こういった工程を踏む仕事ということで、システム開発はよく建設業にたとえられます。実際に工程管理の手法なども似通っています。ところが、大抵の場合、耐震偽造をした建築物よりもシステムのほうが脆弱に仕上がります。何故でしょうか。 一つには、建物の図面を引くには建築士の資格が必要ですが、システムの設計に資格は必要ありません。 もう一つ、
SI業界が開発するシステムの目的は何か？ それがつまり「業務知識」というやつで、金融や保険だったり、証券取引、財務会計、生産管理、物流・在庫管理、販売管理だったりするのだ。それぞれ必要とされる知識は非常に多い。普通の新入社員がOJTで身につけようと思ったら数年かかってもおかしくないだろう。 金融(ディラーが使うようなポジション計算をするフロントシステム、リスク計算をするようなミドルオフィス、勘定系のバックオフィス)、流通、輸出入、製薬など、いろんな業務をやってきたおいらが通りますよ。 確かに金融は業務知識がないと歯が立たない。でも、自分の経験した限りでは、それ以外の業務は、案件が始まってから勉強しても十分間に合います。 一週間以内の勉強で、お客様のところにいってシステムの仕様を話し合うことはできるようになります。もちろん、この道何年って人にはかないませんよ。でも、仕様を決める分には困らない
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 なぜ日本はこれほど残業が多いのだろう。理由は二つある。 もともと、年功序列・終身雇用というものは、ある程度の残業を前提にしたシステムだ。賃下げ
ITproの高橋信頼記者より、先日の私のエントリ（「雇用規制撤廃と減税で日本経済は再生する」）を紹介したとの連絡をいただき、さっそく読んだ。ITpro - 学生とIT業界トップの公開対談で胸を衝かれたこと---IT産業を呪縛する“変われない日本” http://itpro.nikkeibp.co.jp/article/COLUMN/20080530/305172/ ここしばらくIT系ブログやソーシャルブックマークなどで大きな話題になっていた、IPAX2008での対談イベント（関連記事は末尾を参照）をふりかえりつつ、そこにあらわれたIT業界の問題点が分析されている。 まず、IT業界のダメっぷりを示すこのエピソードが面白い。 ＜昔、「行き詰ったプロジェクトを立て直す」というテーマで取材したときに、ある大手システム・インテグレータで聞いた話だ。そのインテグレータで、火を噴いたあるプロジェクトを
そうそう人月はなくならない。世界の何処だってヒトを売るときは人月だ。同じヒトを買うならユーザー企業が直接雇用した方が方が安いし組織の壁がなく合理的だ。米国で日本よりパッケージの活用が進むなど合理的な情報システムが構築されやすいのは、一時的なコンサルティングやプロフェッショナルサービスはともかく、システムの企画とか調整はユーザー企業の従業員が行っていることが大きい。きっちり業務プロセスから見直すことができるし、ちゃんとコストを下げるインセンティブが働いているのだ。 日本でそういった企業が少ないのは、ジョブローテーションの中で情シス部門のスペシャリストを育て、しかるべき処遇を用意することが難しく、減点法の人事評価ではリスクを取って新しい技術を導入するより、付き合いの長い業者に丸投げして失敗を避け、或いは失敗しても責任を押し付けた方が得だからだ。 つまりユーザー企業の発注能力が低いとか、重層的な
人月というのは文字通り働いた時間に応じて請求が行われるというもの。ブルーカラー的な労働をしている限りは人月で働くことは正当なわけです。 「作らない」という視点 人月を超えるためには時間に関係なく圧倒的な成果を挙げる方法を見つけなくてはいけません。でも、圧倒的に生産性をあげるという視点ではだめ。生産性を上げているというのは、あるプロセスの作業効率をあげて時間を短くしているに過ぎないので時間給の罠からは逃げられない。ありがちな話として3ヶ月かかるAさんよりも、2人月でできるBさんのほうが実入りが少ない。 では、どうするかというと「作らない」という視点になる必要性があります。作らないというのどういうことかというと「作ったものをいかに使いまわせすか」か「いかに他人に作ってもらうか」ということです。 作ったものをいかに使いまわせすか＝レバレッジを効かす 使いまわすというのはレバレッジ（てこ）を効
よくwebの受託をメインにやっている会社さんが、儲からないという理由でサービスに行きたいとの話を聞く。 しかし結構、難しいですよね、と、ついつい言ってしまう。 理由のコアは、下記エントリーに書いてあった。 「中毒性」ある受託開発がソフトウェアベンチャーの躍進を阻む １．受託開発では「技術」が蓄積しない ２．受託開発では「人材」が蓄積しない ３．受託開発では「資金」が蓄積しない技術が蓄積されないのは自社の役割や案件次第では？と思うこと以外は、結構同意だ。 （受託は、自社では実現できない案件に関われることなどが魅力で、そこに技術やノウハウ習得のチャンスは転がっていると思うし。） 一番重要なのは、キャッシュフローが安定しないところではないだろうか。 サービスと受託の大きな違いは、 「受託は技術を売る仕事」 「サービスは、文字通りサービスを売る仕事」 である。 サービスは、お客様がつくと継続的に
なんかはてブってば情報サービス産業の悲惨さを訴えると急速にブクマが伸びるものらしく、お前らダラダラ職場からブクマチェックしないで、とっとと帰れよと思うこともあるが、きっと帰れない深い事情もあるのだろう。 しかし分かってないなあ。10兆円台に乗せた情報サービス産業にあって、経済産業省のIT関連予算ってイマドキ400億円もなくて、これって腐りきった社保庁システムの年間保守費用より小さいんだぜ。それが日本のIT業界発展を阻害しているなんて過大評価じゃね。 日本のSI業界の過酷な労働条件を改善したければ、やるべきことは労基法の改正とかじゃなくて、市場メカニズムを正しく機能させることだ。日本のIT業界を発展させたければ、援助交際をやめて何もしないことだ。 最近こそ郵政4分割とか、自民党の参院選対策で大見栄を切った年金の名寄せとか、政治に皺寄せされた不条理なデスマ案件が散見されるけれども、官公需って昔
Business Value ofIT, Future of business/companies/workers, Ability to innovate. 業界内では半ば常識かもしれないが、自分の頭の整理のために書いておきます。 日本のIT業界のマクロな構図として、大手のプレイヤーはみんなコンピューターメーカー系列だという点が特徴として挙げられると思う（IBM、富士通、NEC、日立）。私の理解している範囲で、これまでの経緯をザックリとまとめると、 ハードウェアに関しては、国策としてコンピューターメーカーの育成をしてきた。（そのため、元々産業規模の割にメーカー数が多かった） ソフトウェアに関しては、元々は、コンピューターメーカーが高価なハードウェアを買ってもらうために「オマケ」として提供するところから始まった。しかし、メーカーごとに独自のアーキテクチャーが存在したため、いったんユーザー
皆さん，2008年の目標は何ですか？ 私の目標は「健康的に太る」。そう思って食生活を変えようと牛タンを食べましたが，すぐにギブアップ。うーん，パスタなどの穀物で太るか。エビちゃんのように筋肉もつけたいんだけどなぁ。 最近，業態としてのSI（System Integration）は不人気だ。3Kと言われたり，クリエイティブじゃないと言われたり。確かに，SIer様と働くことが多い私としては，正直この業界で魅力的な人と会うことは少ないとは思う。 ただ，これだけは言える。プラクティカルという意味で，SIerの方々は非常に優秀だ。なぜなら，物事を構造化してまとめる能力と，決まったゴールを目指して何かを作るという点では，他の業界の人に比べて抜きん出た力を持つから。 しかし，それでも一緒に働いていると「オヤ？」と思うことは多い。今回は「SIerのジレンマ」と題してSIの実態を紹介したいと思う。 地獄の社
Twitter Friendsが新卒でSIerに入られるそうなので、これはSIerの中の暮らしを可能な限り語るしかないと思いついカッとなって書いた。今はネタ切れに困ってる。相当長いので、つまみ食いしてください。 2003年当時の状況を振り返る 私は2003年に今の会社(SIer)に新卒で入ったのですが、新卒入社の方々の中には「HTMLって何？」という方が結構いらっしゃいました。ハイテンションマンザイランゲージですってボケてみればよかった。ほんとなんだって。全部で90名ぐらいいたけど。エンジニアとして採用されて入社してるのに、それはないだろと思われるでしょうが、「俺は名を上げるぜ」的なモチベーションで4月から会社はいるヤツなんてマイノリティ。Googleを知っている人も少なかった。Twitterに戯れある程度Webサービスというものが語れてコードもかけてBlog等の何かしらのWebサイトを
アウトソーシングが当たり前のはずの米国には、有能なCIOの下に膨大な技術者を抱える強力なIT部門を抱える企業が結構ある。付加価値の低い単純な業務システムはパッケージ導入で済ませるが、戦略的なシステムは自前で作っている。だから、欧米ではシステム・インテグレーションというビジネスは大きく育たなかった。一見当たり前のことのようだが、これって不思議だったんだよね・・・。 何年かに一度の基幹系システムの再構築プロジェクトが終わったとしよう。戦略的に重要なシステムの開発プロジェクトはそうそうあるものではないから、彼らの仕事もなくなってしまう。では、どうして強力なIT部門が維持できるのか。大規模なシステム開発が終了して、IT部門の仕事の中心が運用ベースになれば、開発主体のIT部門は一気に弱体化してしまう。 日本のユーザー企業の場合、これでIT部門が衰退した。以前書いたことだが、15年、20年前なら日本企
1リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
