未経験エンジニアを採用して失敗した
採用が困難な時期に妥協して未経験エンジニアを採用したけど、それが失敗だった。なぜ失敗なのかを話していきたい。 ただし未経験エンジニアといってもいろいろあって、子どものころからずっと学習してきたような人はただ実務が未経験なだけというように考えている。こういう人はあまり未経験と考えない。 自分への戒めもこめて。 失敗点 リターンがほぼ回収できないエンジニアの生産性の違いが10倍、100倍になることは別におかしいことではない。 そのため、未経験エンジニアに費やした時間がリターンを産むまでにとてつもない時間がかかる。 たとえば、生産性100/営業日の人が10営業日かけて教えるのなら、教えられた人は、1000の生産をしなければ当然マイナスになる。これは泣こうが喚こうが世界の理なのでここは変えられない。 1000の生産は、生産性1/営業日であれば4年2ヶ月かかる。つまり生産性100倍の人を用いる場合は
ぶっちゃけITエンジニアで稼げるかどうかなんて運
バリバリの情報工学の大学出てすげえ技術持ってるのに、狂った炎上案件に突っ込まされて脳みそあうあうあーにされて廃人になったり、職場で基地外に絡まれて職歴あうあうあーにされて💩製造機と化して 末は電車に飛び込んで異世界転生キメるか、狂って女子高生や幼女に淫行しようとして警察に捕まり、懲役中で拘禁反応によりさらに狂って集団ストーカーガーとか煽り運転基地外に進化するという人間もたくさんいれば 狂った案件や職場の中を映画ミザリーやＳＡＷよろしく機転で乗り切って、ＩＴ業界の現実を知って慎重に立ち回りそれなりのポジションに入れたり、頑張っていっぱしのエンジニアになれるという人間もたくさんいるし 勢いだけで飛び込んだ結果、奇跡的なあたりを引きまくって一流どころしかいない職場ばっかりで働かせてもらって、気が付けば一流の仲間入りしててハッピーハッピーやんケっていうエンジニアだっている ただ、色んなエンジニア
「スキル不足で職場に居場所がないおじさん」の救済プロジェクトに関わった時の話
昔所属していたSI会社で、「職場に居場所がないおじさん」の救済プロジェクトに関わったことがあります。 いや、実際にそういうプロジェクト名だった訳ではなくて、確か 「キャリア再考プロジェクト」とか「スキルリデザインプロジェクト」とか、なんかそんなかっこいい名前だったような気がするんですが、 一緒に関わった先輩が言った「これ、やってることは職場で居場所がないおじさんのサルベージだよな…」という言葉が強く印象に残っていて、私の中でプロジェクト名が上書き保存されました。 まあその先輩、「リストラ前のアリバイ作りじゃねーの」とかひどいことも言ってたんですが。 どんなことをやったかというと、要するに人事部のサポートみたいな話でして、 ・所持スキルが案件に合わず、なかなかプロジェクトにアサイン出来ない人 ・プロジェクト内でスキル不足の為タスクが振れず、PMから扱いにくいとアラートが出ている人 ・要は社内
エンジニアはつらいよ。ミーム動画で遊ぶエンジニアたち - 中華IT最新事情
ネット上では、誰がオリジナルの作者なのかもはやわからなくなっているミーム画像、ミームGIFが出回っている。エンジニアたちは、このようなミームを拡散するのが大好きで、知乎などのQ&Aサイトに、そのようなミームを集めたまとめ記事が投稿されることがある。 誰の著作物かもはやわからなくなっているミーム ネット上にはミーム画像、ミーム動画が存在している。元々は誰かの著作物なのだろうが、改変されることを繰り返して、もはや原著作者が誰だかわからなくなっているような画像、動画だ。あるいは原著作者が、勝手に二次利用されることを容認、黙認しているものだ。 ミームとは遺伝子に対応するものとして、遺伝学者リチャード・ドーキンスが作った言葉。文化も遺伝子と同じように、模倣を繰り返しながら継承されていくというものだ。ミームは、ミミック（模倣）、メモリー（記憶）などの言葉から作った言葉だという。 エンジニアたちは自虐的
底辺IT企業は『書けない』プログラマとどう向き合ってきたか - megamouthの葬列
新年から夢のない話で申し訳ないのだが、表題のとおりのテーマである。 note.mu という記事があって、むやみに長いので飛ばし飛ばし読んだ。 大意としては、世の中には「書けない」プログラマというのがいて（元エントリでは学生さんのようである。さもありなん）そういう人はどうやったって書けるようにならないんだから、諦めろ、という話のようである。 で、じっと手を見て、下請け底辺のIT企業にいる私たちは、このような人々をどうしてきたろうか、と考えると、「放ったらかし」にしたなあ、と思うのである。 最初のほうは優しく教えていたと思う。話したりハンズオンしている時に、あっこの子、変数のことわかってないな、と感じたら、ホワイトボードを持ち出してきて、例の"x"と書いた箱の絵に矢印を引いて、値が入っている図を書いて、「わかった？」「あ、はい」みたいなやり取りをして終わり、という程度の「教育」である。 だが、
ITエンジニアの仕事環境ってどうするのがベスト？相談したら逆に混乱した｜TECH PLAY Magazine［テックプレイマガジン］
こんにちは。ヨッピーです。今めちゃくちゃ悩んでおります。 今日はITエンジニアのマネジメントをしているえらい人たちと一緒に「ITエンジニアの仕事環境はどう整えるのがベストか」みたいな話をしているのですが、 議論が多すぎて全然話がまとまりません。 おかしい……！ 「やっぱこういう環境がいいよね！」みたいにすんなり決まるかと思ったのに……！ とにかく、悩んでいてもしょうがないので、今日はこのド散らかった議論を包み隠さず出すことにしました。 ITエンジニア ITエンジニアをマネジメントしている人 ITエンジニアを採用したい人 なんかの人たちには有意義なものがたくさん含まれているので、ぜひ読んでいただきたいと思います。議論に参加してくれたのは、こちらの3名の方です！ ▲バリューコマース株式会社 執行役員 最高技術責任者 伊藤信敬さん 2002年4月エー・アンド・アイシステム株式会社（現株式会社ラッ
1行直すだけってそんなに大変なの？
どこの会社でも「1行直すだけでしょ？ そんなに大変なの？」ということを何度も聞かれる (もしくは言外にそのニュアンスを含められる) ので毎度説明するのだけれど、「いや、そう思うだろうけれど大変なんですよ」以外に答えられていなくて、自分でもあまりうまい答えではないなと感じるのでまじめに考えてみた。 まず大前提として1行を修正するのに本当に言われるがままにその1行を直すのであればそれは作業者で世の中にエンジニアなんて職業はいらないわけで、ぼくらの付加価値は1行を直すときに1行の外にあるものを想起できるから価値があるわけです。 じゃあ、どんなことを考えているかというと、まずたいていそんなすぐに安請け合いできないシステムというのは1行を直すときに影響を受ける行数というのは10行や20行ではないことが多い。そこで影響範囲を考えます。途端にこれが1万行になったりする。すると、1万行へ影響が出るのにこれ
エンジニアは業務時間外でも勉強するべきなのか | 株式会社アクシア
エンジニアがスキルアップするための勉強を業務時間外でもするべきかどうかについて、「教育してエンジニアを育てるのは企業側の責任だ」「エンジニアであればスキルアップのために当然自分で勉強すべきだ」といったような議論を度々見かけます。 この問題についてはどちらが正解というわけでもないかもしれませんし、企業やエンジニアのポリシーによるところも大きいかもしれません。 いずれにしても今後うちの会社の求人に応募してきてくれる方に向けて、企業として、または会社トップとしての私の考えを明確にしておくことはやっておいた方が良いなと思いましたので、この記事に私の考えをまとめてみたいと思います。 プライベートで勉強しなくても何とかなります 仕事をこなしていくという観点から言えばプライベートでの勉強を一切やらなくても何とかなります。たとえ未経験で入社してきた人であってもそれくらいの教育は行っています。 でも最初にこ
年収をあげるために自己主張してほしいWEBエンジニア | キャリハイ転職
日本には高い技術力を誇るメーカーがたくさん存在した。ソニー、パナソニック、富士通、日立、東芝、ダイキン、三菱重工、東レ..と数えきれないほどの優秀な技術力を誇る企業がある。 最近だとDeNA、サイバーエージェントといったWEB系の高い技術力をもつ優秀なエンジニアが所属する企業が増えた。しかし彼らの地位は高くない。今回はWEBエンジニアについて筆をとらせていただいた なぜ日本のWEBエンジニアは評価されないのか？日本のWEBエンジニアに限らず技術者は高い技術力を誇るにも関わらずなぜ評価されていないのか。評価されていないというのは、社内で、高い役職を得られず、調子にのった分からずやの営業部門が、指示する通りに動けよといったような半ば格下に見たような口調で指示を出されるなど相対的に待遇がよくないことを指す。加えて収入も高くないのが現状だろう。 高い技術力をもっていたとしても売上を作っている、お前
なぜ「システムが無事に動いている」ことの価値は理解されないのか
最近はあまり技術的な仕事をしていないんですが、実は私は元々DBエンジニアです。 OがつくDBとか、PがつくDBとか、mがつくDBとかをいじくって、クエリを書いたり、テーブルの設計をしたり、パフォーマンスのボトルネックをあれこれ調べて解消したり、INDEXヒントを総とっかえして頑迷なオプティマイザをぶん殴ったりすることが主なお仕事でした。今でもたまーにそういうことをします。 同業の方であればお分かりかと思うんですが、DBのパフォーマンスは凄く唐突に、かつ多くの場合極端に落ちます。そして、DBのパフォーマンスが落ちると物凄く広範囲に影響が及びます。 アプリケーションサーバ、重くなります。クライアント、ろくに動かなくなります。お客様、切れます。カスタマーサポートにはわんさか電話がかかってきます。 ただ「遅くなる」だけでも十分に影響は甚大なのですが、それ以上のトラブルが発生するとまあエラいこっちゃ
「エンジニアに資格はいらない」って本当？元資格屋の答え (1/2)
就職して3年が過ぎ、「そろそろ辞めどきかな」「この仕事をずっと続けられるのかな」と自分の仕事について不安を感じているエンジニアのために、転職と独立に役立つ「技術以外」の知識を紹介。派遣エンジニア、外資ITベンダーでトレーニングマネージャー、IT業界専門のベンチャーキャピタリストなど、ITを軸に多彩なキャリアを持つプロコーチの大滝由子さんが解説します。（編集部） Web業界の転職に資格はいりません！ Microsoft、Lotus（現IBM）、Oracle、Cisco などのベンダー資格を20代で取得し、のちに、シスコシステムズで認定資格試験のプロダクトマネジメントやマーケティングを担当した経験から、「どの資格を取ると転職に有利ですか？」との相談を受けることがよくあります。 アメリカでは、未経験者でも資格を持っていれば実務スキルがあるとみなし、ある程度の資格は採用される際に有利に働きます。資
社内にエンジニア的な視点を入れたくないというお話。
「なんで穴の空いたジーパン履いてるんですか？」 「汚いし、寒いし、動きづらいから、こっちのナイロンパンツ履きましょうよ！」 「このナイロンパンツ、ゴアテックスっていう高機能素材使っているから、雨にも強いし、風も通さないし、最高ですよ！」 「え、あっ…うん…」 さて、これは極端な話ですが、いま社内にエンジニア的な視点を入れたら、これと同じ現象が起きると思っています。 そして、こんな話を切り出されたら僕らは絶対に否定できない。どう考えても彼らの言っている事のほうが合理的だし、効率もよい。100％正しいことを言っていますからね。 でも間違いなく、この「穴の空いたジーパン」にも価値はある。その価値観を見出したくてやっているから、僕らは穴の空いたジーパンをこれからもしばらくは履き続けていきたいと思っているというのが今日の主題です。 一度失ってしまった価値観は、取り戻すことが不可能。 エンジニア的な視
週3日働いて月収36万円：フリーランスエンジニア向け求人サイトが地味に増えている : まだ仮想通貨持ってないの？
フリーランスエンジニアのマッチング市場って、かなり先進的で面白いんですよ。 週2日から働けるハイレベルエンジニア向け「PROsheet」 たとえば「PROsheet」。こちらは週2日から会社勤めができるという、未来的なマッチングサービスです。どちらかというとハイレベルなエンジニア向けで、たとえば「週3日で月収36万円」なんて仕事が掲載されています。 特徴は「人力」でマッチングしていくこと。専属のエージェントがクライアント企業、エンジニアの相性を見ながらマッチングしていきます。以前営業資料を見せていただいたんですが、すごい人たちがすごい企業で働いていてびっくりしました。 PROSheetの運営者・中川さんは鼻息荒く「新しい働き方を作るんです！」と語っています。平日9時5時で一つの会社に働く、という働き方は、30年後にはマジョリティではなくなっていくのかもしれませんね。 エンジニアナビ ギーク
エンジニアが地方に住むメリット/デメリット - kamiのサービス制作ログ
photo by Mark Pouley ぼくは熊本に22年間→東京に4年間→熊本復帰3ヶ月目です。 地方に住むメリットについてはイケダハヤトさんも言及していますが、実際どうよ、という内容をつらつらと書いてみます。 結論からいうと、成長×お金の2つが必要なエンジニアが地方で住むのは現状厳しいです。 以下、メリット/デメリットなど。 地方に住むメリット 1) 会議など、集中を妨害される機会が少ない ぼくが東京で働いていたときは、10分程度の小さな会議から1時間ほどの大きな会議まで、毎日当たり前のようにあった。 働いていると感覚がマヒしてくるけど、無駄な会議は徹底的に省くべきです。 地方で働いていると、必然的にオンラインでのやりとりのみになるので、必要最小限のコミュニケーションで済むようになります。 集中してコードを書く、集中してブレストする、その1回の時間が長くなりました。 2) お金がかか
地方の常駐・運用PGが、東京の開発エンジニアになるためにやった一つの事 - paiza times
Photo by Ryan Johnson 今回は、paiza開発担当の佐藤がお送りします。 paizaの開発エンジニアとして働き始めたのが今年2月から。日々Railsと格闘しつつpaizaのWebサービスの開発を行ってますが、それ以前は北陸のとある地方でC#メインの運用保守エンジニア（常駐型）をやってました。そんな自分が開発エンジニアになるためにやった事、また実際になってみて判った事について書いてみます。 ■何をやっていたか 地方の高専の情報工学科→同じ地方の大学に編入→大学院→同じ地方の常駐メインのIT企業→paiza(ギノ)というのがこれまでのキャリアです。その地方のIT企業では地方自治体のサーバの運用保守のエンジニアをやってました。 運用保守エンジニアの仕事は、他社が作ったシステムが納品されたところから引き継いで運用保守をしていたのですが、そのシステムは色々とバグが多かったので当初
なぜ開発で見積り失敗して忙しくなりがちなのか(アジャイルな見積りと計画づくり読んだ) - $shibayu36->blog;
最近タスクがどのくらいで終わるか見積もることが多いんだけど、そのたびにうまく見積もりができてなかったり、思ったより長引いてしまってすごく忙しくなってしまったり、といったことが何度かあった。このままじゃ良くないなーと思って、「アジャイルな見積りと計画づくり」を読んだ。 アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~ 作者:Mike Cohn,マイク コーン毎日コミュニケーションズAmazon 実際読んでみると今の状況に非常にぴったりで良い本だった。この本を読んでいくと、最初から正確な見積りをするのは不可能で、作業をしながら見積りの精度をあげるといったり、変更やリスクに強いスケジュールをうまく作るということをしていく必要があるということが分かる。なんとなく自分がタスク管理をしないといけなくなったけど、なんかうまくいかないと思っている人には非常に参考になると思う。あと
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
