銀行系列の中規模SIerを退職し、 受託と自社サービスの開発を行っている小規模Web系に転職することになりました。 7/30が最終出社日でした。8/1からは新しい勤め先へ向かいます。 １．これまでやったこと ２．これからやりたいこと ３．なぜ転職しようと思ったのか なお、３はいわいる自分語りを含む上に長いのでご注意ください。 読ませる知り合いもいないのに何故書いた。 １．これまでにやってきたこと。 オープン系の基幹システムの保守開発に携わり4年ほど。 Java、COBOL、ExcelVBAをメインにやっていました。 もちろんSQLも普通に書いたりしつつ、触ったことのあるDBはOracle、PostgresSQL、SQLServer。 業務知識は主に流通系。Web開発とかもやりました。Javaでstruts1.Xとか、ASP.NETとC#とVBとか。 それと個人的欲求に基づき、Android

こんにちは、副社長のゴウです。 最近、転職系サイトをいくつか見ているんですが（求人を出す側としてです）、せっかくなので記事にまとめてみました。 転職を考えている人の参考になれば幸いです。 また、他にもこんなサイトあるよーというのがあれば、コメントなどいただけると嬉しいです。 では、いってみましょー！ ITに特化した転職サイト 数ある転職サイトの中でも、特にIT系に特化したサイトをまとめました。IT系に転職するならここから！ Findjob! LIGが大好きFind Job!。 昔からIT業界の求人を広く扱っている求人サイトですので、ご存知の方も多いかと思います。mixiが運営しているという事を意外と知らない人も多いかもしれませんね。 Find Job! キュリア YAHOO!が手がけるIT系転職サイト、キュリア。 人事担当者に「Q」という形で質問を送れるのが特徴です。 キュリア Green

エンジニアtypeは、各種エンジニアをはじめ「創る人たち」のキャリア形成に役立つ情報を発信する『＠type』のコンテンツです。

残念なソフトウェア開発の現場は、沈みかけの巨大な船に乗った航海に似ている。 船底の穴からの浸水を必死でかき出しながら、どうにか進んで行く。そういう航海だ。 船のどこにどれだけ浸水箇所があるのかは分からない。 ある穴を塞ごうと船底に板を打ち付けたら、 それによって別の場所に新しい穴を空けてしまったりする。 船の構造はあまりに複雑で、膨大な部品の間にどんな依存関係や相互作用があるのか、 誰も完全には把握していない。 それは、はるか昔に組み立てられた太古の船で、 構造把握の手掛かりは、代々伝わる不十分で不正確な古文書だけなのだ。 新任の船員は、出た水に対してとにかく手当たり次第に対処した。 どんな物でも使い、徹夜で穴を塞いで回った。 ひたすら大きな声で号令を出し、 いかに早く穴を塞ぐかが、船員の間で競われた。 何人もの船員が過労と心労で倒れ、 航跡には水葬者が点々と残された。 船員たちが経験を積

なんかソーシャルゲーム業界に転職したい増田がホッテントリしていた。 http://anond.hatelabo.jp/20130122131752 自己回顧録みたいなものをつけたいと思っていたところだったので、なんとなくこの2年間について書いてみようと思う。 もともと、2年前に当時SIerに勤めてて、そこでSEとかコンサルとかしてたんだけど、会社の経営が傾き始めたのがきっかけだった。 当時勢いのある（今もかな）ソーシャルゲーム業界にしたのは、単に元々Web系やってたし、勉強会だとかやってるっぽいし、花形っぽいし…みたいな。まぁこのへんの気持ちはIT系の人ならなんとなく分かってもらえると思う。 その頃は「今までやっていた官公庁や大企業向けのコンサル事案と比べたら格下だな」と思っていたところはある。正直、今も社会的地位みたいなものだと格下だと思ってる。 2年経過して、色々な人と交流して思うこと

元ド底辺SIerの私が心機一転、スタートアップに参加して約1年半が立ちました。 今後の自分の仕事を占う意味でも、ここらで自分がこれまでに感じたこと、悩んだこと、考えたことを整理しておこうかと思います。 もしも現在、SIer系の仕事をされていて、いずれはベンチャーで働いてみたいという人の参考になればもちろん嬉しいのだけど、ベンチャーってのは本当に千差万別で、ここで書いたことがそのまま他のベンチャー企業に当てはまるとは限らない、ということだけはご了承を。 「仕様」って言うな！ 最初の問題はこれ。 SIerにとって「仕様」って言葉は絶対的な意味があるわけですよ。 お客様から要求を聞いて、要件を定義して、「はい、コレコレこういうもの作りますよ。この製品ではこういうことができます。逆にこういうことはできません。よろしいですか？」と約束した結果が仕様だから当然と言えば当然。だからこそ、仕様を定めること

近年「SIer」、そしてSIerの労働力の多くの割合を占める「SE」が「オワッテル」というような話を良く聞きます。 特に聞くのが「海外では」「欧米では」「アメリカでは」「USでは」といった枕詞を付けて構造・仕組みがおかしいという論調[*1]。 「日本では」、「海外と」「欧米と」「アメリカと」「USと」仕組みが違うので単純な比較は意味がありません。 "SIer"が生まれた背景としてはコンピュータシステムが複雑化しすぎて、開発・運用に多くの人的リソースが必要になったということがあります。 そしてユーザー企業の直接的な採算部門ではない技術部門に専門技能を持つ(恐らくそれなりに高給の)エンジニアを雇い入れ、開発・運用するのは難しいです。また特にコストのかかる開発が一段落して運用フェーズに入った段階で労働力が余ると非効率になります。 配置転換や経営の効率化など、解雇を回避する努力を最大限にしないと日

■勉強会で自社名を隠す人々 今年の2月に転職して以降、勉強会やカンファレンスでの発表資料に僕は会社名を書くようになった。 2010年9月にコミュニティで初めてのライトニングトークをして以降、今年の2月に転職するまで、僕は合計9回、ライトニングトークや、セッションで登壇している。そしてそのいずれも、会社名はあえて伏せていた。 そういった場面で名刺交換をする機会はあっても、僕は個人で作成した名刺を使い、会社の名刺を出すこともしていない。その当時、僕がなんという会社に勤務しているのか、おそらくほとんどの人は知らなかったはずだ。 転職以降も、こういった活動は続けているが、今は自己紹介で、どこの会社で、どういった仕事をしているか名乗るようになった。名刺交換でも、会社の名刺を出している。 勉強会やカンファレンスに行くと、様々な人と出会う。登壇者と仲良くなることもある。そういった人たちと話をしていると、

悩まないコーディングをしよう！ OOCSS,SMACSSを用いた、読みやすくてメンテナブルなCSS設計（Sass対応）Horiguchi Seito

ガンダムの名台詞をアレンジした、IT業界あるあるネタのツイートが意外なほどに熱い盛り上がりを見せました。 基本的にハッシュタグ#IT業界をガンダムで　がついたツイートを全て掲載しています。悲哀に満ちていながらも愛と誇りが感じられるツイートをお楽しみください。 【まとめ続編】IT戦士達の鳴り止まぬ鼓動 http://togetter.com/li/411948 続きを読む

デザイナーかるたに続いて、なんかできていたようなのでまとめてみました

物事に大きな影響を与える前提なのに案外知られていない。その一つがコンピュータソフトウエア投資とソフト開発技術者の所属先に関する日米の差である。 日本企業は自社で利用するソフトのほとんどをIT（情報技術）企業に開発させているのに対し、米国企業はソフトを内製する比率が高い。 日本のソフト開発技術者の大半はIT企業に所属するが、米国のソフト開発技術者の大半はIT企業ではなく一般企業に所属している。 上記二つの文は同じことを言っている。日本企業は社内にソフト開発技術者をあまり抱えていないためIT企業に外注するが、米国企業は社内にソフト開発技術者がおり内製できる。 「ほとんど」「高い」「大半」では曖昧なので数字を補足する。米国商務省経済分析局の数字によると、2010年の米国民間企業におけるソフトウエア投資の内訳は、内製（自社開発）が37.3％、外注（他社委託）が34.2％、パッケージソフト購入が28

国内でのアジャイル開発の普及と共に、アジャイルという言葉が指す内容にも広がりがでてきました。同じ「アジャイル」という言葉を用いたとしても、それが何を指すのかを注意深く理解する必要が出てきたといってもいいでしょう。 そんな現状を、アジャイル開発の第一人者である平鍋健児氏がブログ「An Agile Way」にポストしたエントリ「アジャイルの「ライトウィング」と「レフトウィング」」で、非常に分かりやすい図と共に整理しています。以下に許可を得てその主な部分を転載します。 アジャイルの「ライトウィング」と「レフトウィング」 アジャイルの認知が進むにつれて、アジャイルという言葉がどんどん広がっている。アジャイル、という言葉の中にはいろんな要素が入っていることが分かる。もっと大きなものは、CI（継続的インテグレーション）を中核とする技術的なプラクティス群と、スクラムプロセスフレームワークのような、人と人

VM持田 @mike_neck 100kbyte競争。100kbyteに圧縮されたjsの中からバグを一番早く探しだした人が優勝。ただし、ブラウザ、IDEなどのドーピング無し。秀丸のみとする。 #IT業界オリンピック 2012-08-06 22:28:04

会場は、さまざまな企画のブースが並ぶ一角。しかもすぐ隣の「超軽音部」のバンド演奏が流れてくるという、実に混沌とした空間だ。会場の壁にはニコニコ動画のような「字幕」が投影されている。すぐ隣ではバンド演奏があり、定時には「時報」のアナウンスが流れ講演をかき消すという、難条件のもとでの勉強会である。 しかし、四方から這い寄る混沌をものともせず、開発者コミュニティはそれぞれの精鋭を差し向けて、圧倒的な才能の無駄遣いぶりを披露。さながら“異種格闘技”のような世界と化していた。 五十嵐氏の基調講演「デザインのためのインタフェース」 基調講演は、 五十嵐健夫氏（東京大学大学院情報理工学系研究科コンピュータ科学専攻 教授／JST ERATO 五十嵐プロジェクト研究総括）による「デザインのためのインタフェース」。五十嵐氏は、研究成果を次々と鮮やかなデモンストレーションで見せていった。 五十嵐氏は、まず、普通

プロジェクト管理は決して精密な科学ではないが、これにソフトウェア開発が持つ予測が難しいという性質と組み合わせられると、大きな悲劇のレシピが生まれる。わたしは、ソフトウェア開発プロジェクトに取り組んでいるプロジェクトマネージャーがよく犯す過ちを数多く見てきた。それらの過ちの一部はソフトウェア開発に限ったことではないが、この文脈では特に頻繁に起こり、ダメージも大きい。 1．「人数を増やせばよい」という誤解 Fred Brooks氏は同氏の有名な言葉の中で、よくあるプロジェクト管理の間違いについて「ある女性が9カ月に1人子どもを産めるからといって、9人の女性がいれば1カ月に1人の子どもを産めるわけではない」と表現している。そして、この間違いは今でも頻繁に見られる。ある問題に多くの人間を割り当てれば、その問題は早く解決するという考え方だ。残念ながら、これは正しくない。 プロジェクトに人を1人投入す

サービス終了のお知らせ NAVERまとめは2020年9月30日をもちましてサービス終了いたしました。 約11年間、NAVERまとめをご利用・ご愛顧いただき誠にありがとうございました。