エンジニアtype 技術者のキャリアを考えるWebマガジン - 転職＠typeエンジニアtypeは、各種エンジニアをはじめ「創る人たち」のキャリア形成に役立つ情報を発信する『＠type』のコンテンツです。
SIerからWebサービス事業会社の転職で気をつけるべき２つのこと - GoTheDistance
先日、知人のIT業界を主戦場にしておられるヘッドハンターの方とお会いしました。昨年度からソーシャルゲーム等を運営している会社様から引き合いが増えているようで、SIerやメーカーの研究職からWebサービス事業会社への転職の案件も増えているようです。 そのヘッドハンターの方が３つばかり、Webサービス事業会社への転職を考えているのなら気をつけるべきコトを教えてくれましたのでシェアしたいと思います。 1. 手を動かせる人であれ 端的に言っちゃうと、現場でコードを書いているエンジニアならまだしも、PMや管理業務が多くなってしまった方は正直不要なんじゃないですかってこと。欲しいのはサービスを拡大 or 安定運用しているエンジニアで、管理する人じゃないだろうから。でも、SIerで最も脂が乗り切っている世代ってPM/PLクラス。若けりゃ未経験でもいいだろうけど、SI業界10年選手とネット系企業とは相性が
人形つかい（1） 未知との遭遇：Press Enter■：エンジニアライフ
ふつーのプログラマです。主に企業内Webシステムの要件定義から保守まで何でもやってる、ふつーのプログラマです。 彼らには本当に知能があるのだろうか？ つまり、彼ら自身の知能が？ ぼくにはわからない。どうすればそれがわかるのかも、わからない。 ぼくの名前は細川マモル。横浜市内にオフィスを構える小さなシステム開発会社に勤務しているエンジニアだ。当年とって29歳、独身。付き合い始めて2年になる彼女がいるが、結婚を意識していいのかどうか決めかねている状態。 うちの会社は7年前に某大手SIerからスピンアウトした6人が立ち上げた、いわゆるベンチャー企業だ。最近の世界的な景気後退の大波を何とかしのいで、ここまで黒字を――かろうじて――維持してきている。もちろん危機的状況に陥ったことも少なくなく、役員の2人が給料なしでしのいだ月も何回かあったらしいが。 社員数は20名前後。開発要員は15名で、うち半数以
「ＤＢ構造を見直さない」というアンチパターン - 設計者の発言
システム開発プロジェクトの失敗原因のひとつに「システム刷新時に、ＤＢ構造を見直しせずにプログラムの言語だけを置き換える」というものがある。アンチパターンとまでは言えないとしても、クリティカルな問題をはらんでいる。にもかかわらず、いくつかの理由からこの方針は無批判に受け入れられるか、場合によっては歓迎さえされる。 なぜか。まず、システムの問題がＤＢ構造（帳簿組織）の悪さから来ているという認識を、ユーザーやシステム部門が持ちにくいため、その見直しが明示的に求められないからだ。また、必要なスキルを持った技術者が少ないため、開発側として（大手SIerでさえ）なるべく見直ししたくないのが本音だったりするからだ。いかにも問題がありそうに見えても「求められないから手をつけない」という理屈で通す。また、ＤＢ構造が多少おかしくてもエレガントなクラス構造でカバーできるから一刻も早くプログラミングさせてほしい―
プログラマーの成長を考えないSIerの仮説は間違っている - 達人プログラマーを目指して
Java EEや.NETはCOBOLやVB6よりも本当に生産性が高いか？ - 達人プログラマーを目指してのコメントで 熟練者も居ることは理解しているが、開発をする上で熟練者ばかりを集めることはできない。このため初心者側にレベルを合わせざるを得ない。 というコメントをいただきましたけれど、これは実に典型的なSIer（の上司）の考え方ですね。SIerの仮説と呼んでもよいくらいですね。とにかく、この仮説の前提となっているのは プログラマーのスキルレベルは一定で成長しない プログラマーは容易に交換可能なリソースである プログラマーは単純労働者である というモデルです。とにかく、この仮説がはびこっているから、いまだにSIerのフレームワークは「初心者側にレベルを合わせざるを得ない」という思い込みで作られていることが多いのでしょう。 COBOL（の初期の）時代ならまだしも、少なくとも現在の開発環境にお
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
