スーパークリエイターがSI業界で即戦力になれない理由 - aikeの日記
少し前に若いエンジニア達と話す機会があった。この春SI企業に入社してプログラミングの研修を受けているという。みんなそれぞれ能力が高い上に、学習の高速道路を爆走中といった感じでネット上で話題になっているような技術情報には十分詳しい。SICPを全部解いたとも言っていたし本当はプログラミングの研修なんか必要ないのだろう。未踏に応募したり勉強会を開催したりするのはこういったタイプなんだろうかとか、いまどきのSI企業の人材獲得能力はすごいなとか思いつつ、でも彼らはこの業界に何を求めてどうなろうとしているのか少し気になったりもした。 これほど優秀で勉強もしてきた人達でも、SIerとしては即戦力にはならない。社会人マナーとか仕事の進め方の話ではなくて、単純に知識不足という意味で。そのため一緒に入社したプログラミング能力の低い社員と同じように扱われる可能性が高い。これはすごく不幸な状態だと思う。SI業界が
株式会社スターロジックの羽生章洋が書いてるブログ:元請けにこだわる理由 - livedoor Blog（ブログ）
私は文系の大学中退（まぁ高卒ですよね）です。最初に入ったのがソフト会社で、その次もソフト会社でした。最初の会社では未経験のど素人だったのでオペレータやパンチャー、運用と保守からやらせて頂きました。その後転職した2番目の会社で、絶対に忘れないと感じる出来事に出会いました。 ＃ とりあえず、以下のエピソードのあと、新婚早々に残業400時間/月とかやってて ＃ さすがに「これは死ねるかも」と思う程度に、月に200時間残業とかするのは ＃ 当然と思っていた、それでもそれが苦にならなかったほどに一体感を持つことが出来た ＃ 今思うに幸せな時代の話です。私は当時の会社を今でも誇りに思っています。 2番目の会社にはその年の1月に入社しましたので、その年の夏のボーナス（賞与というよりも私にはボーナスという言葉の方がゴージャスに聞こえるのでこれで押しますｗ）は当然出ません。というわけで、お金に困っていた私は
SIerの悲しい現実 - カレーなる辛口Javaな加齢日記
http://anond.hatelabo.jp/20080824080254 とりあえずメモ． SIerでお仕事してると、派遣とか常駐とか言う形で、色んな会社に行って、違う会社の人とお仕事するんだけど、「経験年数n年(n>3)です」っていう人達が、恐ろしく使えなくてびっくりすることがしばしば。 そんなもんらしい． そういう方たちは，こういう本の存在さえしらない．=>http://d.hatena.ne.jp/JavaBlack/20070522/p1 でもそういう人達の方が，SIerとしては安上がりで重宝するようだ．お客や上司が気にするのは品質や生産性ではなく価格だけだから．そしてこの主も，おそらく遠からずSIerの存在を疑問に感じ，他の道を模索するようになるんじゃないかな．よほどのコンピューター馬鹿か，或いは本当の馬鹿でなければ，SIerでプログラマを続けていくことなんて無理だろう．*
システムエンジニア不要説 - masayang's diary
JavaBlackさんからトラックバックいただいて、なんか面白い議論が進行中なのを知る。 フローチャートの呪い フローチャートがダメな3つの理由 ここではフローチャートの是非を論じるつもりはない。クソだから。もっと一般化してしまえば、○○設計書みたいに「設計書」と名のつくものは全部クソだ。だって動かないんだもん。 動かない以上、それら設計書が正しいのか、漏れがないのかは保証のしようがない。机上検証なんていう工程もあるらしいけど、君たちの脳味噌は何MIPSなんだと問い詰めたい。もちろん、机上検証で見つかる凡ミスもあるだろうけど、そんなのはズボンもパンツも履かずに会社に向かうのと同じくらいのレベルの間違いだろう。 結局はコードを仕上げてから動かして初めて「だめだこりゃ」ということになる。 そして、「だめだこりゃ」となった時に、内部設計書だか外部設計書だかなんだかしらないけど、そういう設計書関係
SI屋と顧客の未来 - masayang's diary
id:zakincoさんから、トラックバック「SIerにキンタマつかまれてるユーザー企業はSIerと心中するしかないね」をいただく。 どっちにしろモラルの無いSIerに未来は無い。だけど、会社としての未来は無いと分かっていても、社員を使い捨てにして自分達の退職金だけはせしめようってお偉方が居るSIerには気をつけましょう。 利益追求を求められる会社組織としてみれば、キンタマつかんだSI屋ってのは、実は「モラルのある」行動をとってきたわけですよ。 顧客からは「もっと安くしろ」といわれ 株主からは「もっと利益をあげよ」といわれ その妥協点として、「過去のソフトウェア資産を活用する」戦術が選ばれたわけ。 ところが、過去のソフトウェア資産なんていうのは実はCOBOL時代のデータ構造を引き継いだ時代遅れな代物。だんだん保守効率は低下し、ちょっとした修正でも偉く工数がかかるようになってしまう。かといっ
時代遅れの「基本」 - masayang's diary
フローチャート論争を見ていて思ったこと。 なにかにつけて「基本が大事」という人は、大概どこの現場にもいる 問題は...その人の言う「基本」ってのは「いつの時代の話なんだ」ということ その「基本」とやらが時代遅れであることを認識しつつ、敢えて旧式にこだわる人もいる。それはそれで一つの戦略・戦術としてはいいんじゃないかな。COBOL.co.jpみたいなやつね。新しい技術を覚えさせる必要がないということは、それだけ投資が少なくて済むということ。短期的には儲けやすい。市場がそういう開発体制を受け入れる間は商売としてはおいしいだろう。なんだかんだ言って、儲けた奴が勝ち、というのも事実。 ただし、受け入れる市場がなくなったら...そこで働く人達は、一から勉強しなおして新しい技術を習得する必要がある。旧式技術の「基本」に拘る人は、現場職員の将来を犠牲にしてお金を儲けているということを忘れてはならない。
COBOL屋の呪縛 - masayang's diary
今回の日本出張ではいくつかのプロジェクトの状況をみてきた。で、思ったこと。 「COBOL時代のデータ構造を引きずることで、生産性や保守性が落ちている」 フラグだらけのマスター 本物のコードをだすわけにはいかないので、すごく簡略化した例で説明したい。あるシステムを利用できるユーザのマスターテーブルがあるのだけど、そいつには「なんちゃらサービス利用可否フラグ」みたいなのがたくさんついているのね。 この方式の問題は以下の通り。 テスト負荷 フラグがあるということはそれをチェックするif文があるということ。 if文があればテスト件数は最低２件は増える。 入れ子になれば、４件、８件...と増えていく。andやorでも同じ。 コードの冗長性 「あるユーザがサービスAを使えるか」を調べる処理と「あるユーザがサービスBを使えるか」を調べる処理はほぼ同様になることは明らか。 「サービスAを使えるユーザ」を調
キンタマをつかむ - masayang's diary
どっこいSIerは簡単になくならないが面白い。著者id:mkusunokさんの意見に同意。 実のところ丸投げ自体が悪いとは思わない。経営にとって重要じゃない機能であれば、丸投げで型通りのものを使った方が安上がりだ。 もう一歩進んで、「経営にとって重要じゃない業務であれば、丸投げで型通りのものを使った方が安上がりだ。」とも言える。米国だとADPなんかが有名。ここは人事給与管理の業務を丸受けする会社。[*1] 開発だけを投げちゃうのは、「開発という業務は経営にとって重要じゃない」から。そして、そう判断できるのは「システムの企画から要件定義」と「設計開発」を分離できると経営陣が信じているから。[*2] これまで重要かどうか腑分けせず、さらに丸投げなのに手組みするものだから、おかしなことになっていた訳だが。 お客さんにとって重要な業務のシステムを丸受け（設計、開発から日々の運用まで）することを、自
雑種路線でいこう - どっこいSIerは簡単になくならない
SIerが変わらなきゃってことには同意。けど日本でSIerは当分なくならない。少なくとも解雇規制がなくならないとね。米国で何故ユーザー企業が専門家を雇えるかというと、要らなくなったらクビにできるからだ。例えば汎用機とCobolのシステムをLinuxとJavaに移行する場合は、汎用機オペレータとCobolプログラマを切って、LinuxオペレータｔJavaプログラマを雇い入れる。そういう世界だ。 日本じゃ簡単にクビを切れないから、潰しのきかない技術者はできるだけ雇いたくない。そこのところはSIerに押しつける訳だ。重層的な下請け構造が何故あるかというと、SIerも簡単にはクビを切れないんでバッファを必要とするからで、6次とか7次になれば会社そのものが吹けば飛ぶ世界で、労働基準法なんか形骸化しているしね。 今後はユーザー企業がどんどん内製で出来るようなシステム作りを支援する方向に向かわねばならな
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
