エンジニアtypeは、各種エンジニアをはじめ「創る人たち」のキャリア形成に役立つ情報を発信する『@type』のコンテンツです。
まず超個人的な見解です。あとWeb系の人は関係ないので、そういう人は読んでも無駄です。ここでいう業務系エンジニアというのは、主にSI屋で特定企業向けのシステムを構築しているエンジニアの人たちをさします。 まず、非常に難しい時代になったと思います。 端的に、ちゃんとしたSIをやることが難しくなりました。まず、技術的には面倒なことが増えた、というかできるオプションが制御できないくらいに増えているので、うまく制限をしないとコードや仕組みが劣化する一方になりました。エンジニアリングに自由を!というのは聞こえはいいのですが、チームプレーをするのに、いちいち約束事決めないと回らないようになっているような気がします。それも毎回。始めるたびに。 別段、いきなりチームメンバーの能力があがったり、さがったりするわけではないのですが、なぜか外すと酷いことになる振れ幅が増大したような気がします。ルール決めをいちい
今日はid:gothedistanceと飲んだ。1年ぐらい前から飲もう飲もうといっていてようやく実現。 さすがはござ先輩。いろいろと教えてもらった。 その中で、SIおよびSEのこれからに暗い影を落とす話をした。 これはウチの関西側の営業担当が聞いてきた、あるSE派遣の企業の話。(とはいえ関西企業に限った話ではない) 何十人もの新人さんを集めて、無料でいろんなプロジェクトに派遣するビジネスモデルが台頭してきているらしい。 何十人の内、数名でも生き残って、その後定期的な売り上げになれば良いという、携帯の新規契約無料みたいなモデルだ。 経験者も言い値で出すという。 新人さんに経験を付けてもらうためにお試しで出向することは百歩譲って良いとしよう。 いくらなんでも新人ばかりで上手くいくと思っているような 受け入れ側もプロジェクトもさすがにないから、 こういう新人さんを受け入れるのも1つのプロジェクト
さて、話は1996年のことだから、今からすでに12年近く前のことになる。 僕はある国立大学の工学系大学院修士課程を卒業したばかりで、生意気だった。当時、少林寺拳法三段をとったばかりだったし、体力的にも知力的にも僕が最も充実していた時期だ。 僕は通称「ミカカ」で知られる通信会社に採用され、フレームリレー交換機開発に回された。 正直に言って面白くなかった。1996年当時すでにフレームリレー交換機は時代遅れだったのだ。さらに面白くなかったのは、着任直後に少し禿げかかった風采の上がらないおじさんの下に付けられたことだ。その人の名は西嶋さんといった*1。 「よし、お前、来い」 西嶋さんは僕を呼んだ。僕を呼ぶ時には「お前」か「矢野」と呼び捨てだった。それも気に食わなかった。 「いいか、ここにある架は、大阪だ。そして、向こうにあるのが東京。そして、名古屋、福岡だ。いいか?」 職場にはフレームリレー交換機
デブサミが 10 周年でした。 残念ながらオファーなかったのですが、一昨日くらいに急に参加していいよって言われたので 「From Legacy to Agile 〜レガシー開発からアジャイル開発へ〜」に乱入してきました。 そこでチームビルディング的な話を話させてもらいました。 資料とか特に作っていなかったので僕がリーダーとしてチームメンバーにお願いしている決まり的なことを簡単にまとめておこうと思います。 テストを書け 問題を根性で解決するな 人を殺す以外なら何やってもいい 失敗を引きずるな 個別に補足書いて行きます。 一応状況の簡単な説明をしておくと、最初は 3 人しかいないチームに 「手伝ってくれないか?」と言われ合流しました。その後、僕がリーダーになり 今は 15 人前後のチームで動いています。 テストを書け これは僕がチームに入るときに最初に宣言しました。 「テストを書かないようなプ
ITエンジニアのための案件情報サイト。フリーで活躍するITエンジニアの方を中心に仕事情報を提供しています。自身に合った仕事を選び、ITの最前線「flontline」で活躍してください。条件交渉などは当社エージェントが代行し、貴方のキャリアアップをサポートします。ITエンジニア大募集!!最前線で大活躍!! 「フロントライン」は、フリーランスで働くあなたの為の、実績とスキルを活かせる案件情報が満載!! 1.豊富な案件情報 大手企業や、伸び盛りの新進企業からの新鮮な案件情報が豊富です。フリーエンジニア向けの有期期間の契約案件はもちろんのこと正社員募集といった案件も多数あります。またプロジェクトの内容上、一般には公開できない案件情報などもあります。 2.自分にあった仕事が見つかる 専任のキャリアアドバイザーが、1対1でじっくりとお話をお伺いし、将来のキャリアプランニング、業界動向や求人傾向など、多
開発手法とコミュ力は捨てろ――SIエンジニアに告げる、Web企業への転職戦略:きのこる先生のエンジニア転職指南(6)(1/2 ページ) 元プログラマ、現Web系企業の人事担当者による、エンジニア転職指南。「応募書類の書き方」や「自己PRの仕方」について、エンジニアの視点を持ちながらアドバイス。エンジニアの幸せな転職のために、菌類が奮闘する。 皆さん、こんにちは。2011年も残すところあとわずか。忙しい日々をお過ごしでしょうか。 師走ということで、師に負けず菌類も走り回っています。新卒採用のエントリが始まり、やるべきことは増えるばかり。冬眠したい気持ちをぐっとこらえてフル稼働中です。 繰り返す、ここはSIerではない さて今回は、かつて私が所属していた「システム・インテグレータ(SIer)」、そしていま所属している「Web系企業」についてお話します。 SIerは、長引く不況とIT業界の構造変
Joelの5つの世界というのをご存知だろうか。 (知らなければ是非、一読を→Joel on Software - 5つの世界) 5つの世界というのは −パッケージ −インターナル −組み込み −ゲーム −使い捨て の5つである。 このところは、スマートフォンアプリ開発という第6の世界が出現していると僕は考えている。 先日のエントリ「人月は悪どころか、ものすごい善かもしれない - 山本大の日記」のブコメで、上述の5つの世界を例にあげて、もっと考察が必要だと指摘してくれた人がいる。 僕はスマフォ関連の開発は5つの世界のどこにも当てはまり、どこにも当てはまらない世界だと思う。最近は、どういう切り口でIT業界を切ったとしてもどこにもホットトピックとしてスマフォが出てくる。パッケージだろうが、ゲームだろうが、SIだろうが、無差別であり、当然組み込みの世界にとても近い。どの世界の専属でもないが、Joe
人月計算は、悪だ。 という話はソフトウェア産業にいるエンジニアだったら、誰でも聞いたことがあるだろう。 よく言われる人月計算の悪とは、管理者の意識から個人個人の能力差などの情報が失われることが根本だと僕は考える。 悪影響の一例としてエンジニア単価に能力差が反映されないという点がある。 また別の例として「10人月の工数の作業も20人でやったら0.5ヶ月で終わるんじゃね?」 という単純計算による安易な管理が横行しデスマを生む原因となる。 「人月」の捉え方はともかくとして、すくなくとも良い評判を聞いたことがない。 しかし、僕は最近、人月計算とはとてつもない善ではないかという考え方になっている。 とくにエンジニアに対して「善」、というよりもエンジニアに対して優しさをもって考えられた仕組みだと感じて仕方ない。 人月の神話 作者: フレデリック・P・ブルックス Jr.,滝沢徹,牧野祐子,富澤昇出版社/
最近、こんなことを聞かれました。 「shiumachi 君、人生のロードマップとかそういうの持ってないの?」 「ありません」 と即答すると、「夢がないねぇ」と不思議そうな顔をされましたが、ないものはしょうがありません。 小学生だか中学生の頃に、「人生の計画を書いてみよう」という授業がありました。22才で就職して、27才で結婚して、……みたいなことを書いてみるという授業です。残念ながら、今の時代には全く役に立たないです。 ロードマップを書くような人生設計って自分の生活基盤が安定していることを大前提にしているのですが、残念ながら今の時代はそんなものは幻想なので、ロードマップを持つ意味は全くありませんし、それに依存するのは非常に高いリスクです。例えば、私は年金をもらえるなんて全く思ってないので、働けなくなってお金が尽きたら死ぬしかないわけです。会社どころか国だってこの先も存続するのかどうかわから
はじめに こんにちは、Python界の情弱です。ちょっと前にOCaml系のエントリを色々と眺めていたらYaron Minsky氏のエントリを見つけたので翻訳してみました。 OCaml for the Masses - ACM Queue Yaron Minsky氏はJane Streetで第一線で活躍されるエンジニアで、Jane Streetの技術ページをはじめ多くの場所でOCamlに関しての知見を語ってくださっています。 Jane Street Tech Blogs 本エントリはJohn Hughesの名エントリ「なぜ関数プログラミングは重要か」を受けてACM Queueに寄稿されたものの日本語訳です。 なぜ関数プログラミングは重要か Why the next language you learn should be functional YARON MINSKY, JANE STREE
この連載も早いものでもう23回です。そして最終回です。これまで2年近く、ありがとうございました。 これまでの総括というわけではありませんが、エンジニアとして成長していくために筆者が必要だと思うことについて、あらためてまとめてみます。 1.逃げない なんといっても一番成長するために必要なことは、逃げないことだと思います。たとえばトラブルはもっとも成長するチャンスですが、逃げていてはもちろんそのチャンスを活かすことはできません。またトラブルではなくても、とにかく逃げるということは、イコール経験値を貯めることを放棄することにほかなりません。 逃げなければ、経験値が貯まるだけではなく、周りからの信用も獲得し、より重要なタスクを任されるようになれ、さらに成長することができます。もちろん、逃げないだけではなく、逃げない上に結果を出すことが重要ですが、結果というのはそのとき自分が持っているスキルが足りて
一部の方には口頭ベースでお知らせしておりますが、2011年9月30日を持ちまして、株式会社リコーを退社することになりました。 プリンターメーカーの人間として紙の可能性をもっと自由闊達にいろんな組織・人間と議論できるような会社に変えていきたい メーカーという中でエンジニアが生きやすい風土作りはメーカーの中の人間しかできないから、それを達成するのが目標 優秀なエンジニアとサラリーマンエンジニアどっちにも価値があるのであって、対立関係ではなく相互に協力し合えるマインドセットを浸透させたい 技術的にはどこにも優れたところのない自分にとっては、大企業にいるということだけが強みなんだから、ソフトをハックできない代わりに会社をハックしたい とかえらそうなことを抜かしておきながら逃げ出してんじゃねーよ、と思う皆さんも多いでしょうが、そのとおりです。嗤ってやってください。 Why? 弊社*1 が早期退職者優
定期的にSI業界が終わったという話が出ますが、本当にそうでしょうか。終わるべきは一括発注・請負のディフェンシブなビジネスモデルです。受託はなくなることはありません。ソフトウェアの開発を、他の業界のアナロジーで考えるのではなく、正面から取り組んだビジネスモデルについて語っています。 ディフェンシブな開発 今から5年前に、SI業界における多くの問題の原因がそのビジネスモデルにあるという「ディフェンシブな開発〜SIビジネスの致命的欠陥」という記事を書きました。SIにおけるビジネスモデルは、発注者とベンダーはあらかじめ決めた金額と要件の中で納品と検収を目指すため、利益を出すためには双方がリスクを取らずに「守り」に入る必要があります。その結果、顧客にとって価値を産むかどうかよりも決められた要件通りに作られることを重視することになってしまいます。人月という単位であらかじめ決めるとなれば、単価の安い下請
ソースコードのレビューはシステムの品質を高めるのに大切な作業だ。GoogleやVMWareでも使われており、ブラウザを使って差分を確認してコメントができるようになっている。社内向けには拙作のSubversionソースコードレビューシステムの宍道湖がある(Rails製)。 Git向けソースコードレビューシステム この手のツールはSubversion向けのものが多かったが、Gitでも使いたいならGerritに挑戦してみよう。 今回紹介するオープンソース・ソフトウェアはGerrit、Git向けソースコードレビューシステムだ。 GerritはGoogleが大々的に発表している訳ではないが、Google社員が開発しておりAndroidのオープンソースプロジェクトにおけるソースコードレビューにも利用されている。他のシステム同様に差分を見て、そこにコメントすることが可能だ。 差分を見てコメントする 差分
こんにちはアメーバ事業本部のブログDivでエンジニアをしているgenkiと申します。 今回は、今月開催されたピクシブ株式会社様との合同勉強会を初めて開催しまし たので、ご報告したいと思います。 ■勉強会の様子 ピクシブ株式会社様の受付には、数多くのイラストが展示されておりました。 当日は両社合わせて50名程度の参加者が集まりました。 プログラムは、セッション20分×4→LT×4→懇親会という流れでした。 以下では、セッションの発表内容をご紹介したいと思います。 ■ピクシブセッション1:「memcachedからKyotoTcoonへ」 久保達彦さん(twitter: @cubicdaiya)の発表になります。 memcachedからKyoto Tycoonへの移行までについてお話をしていただきました。 memcachedの運用では、UNIX Domain Socketでアクセスを行う事につい
1. Copyright(C) Software Research Associates, Inc. All Rights Reserved. エンジニアなら知っておきたい 「仮想マシン」のしくみ v1.1a hbstudy #17 (2010/11/26 ハロー会議室@新宿) ネットワークシステムサービス本部 ネットワーク運用・構築部 長谷川 猛 (hasegaw at sra.co.jp) Twitter : @hasegaw ※本資料中の解説内容は、弊社としての 統一的な見解を示すものではありません。 2. 2 自己紹介 所属所属 興味分野興味分野 株式会社SRA ネットワークシステムサービス本部 ネットワーク運用・構築部 現在は提案支援業務に携わる 特にLinux や仮想化技術を得意とする、 雑食系システムエンジニア 主な著書主な著書 『Xen 徹底入門』 初版、第二版(2007、
先日、知人のIT業界を主戦場にしておられるヘッドハンターの方とお会いしました。昨年度からソーシャルゲーム等を運営している会社様から引き合いが増えているようで、SIerやメーカーの研究職からWebサービス事業会社への転職の案件も増えているようです。 そのヘッドハンターの方が3つばかり、Webサービス事業会社への転職を考えているのなら気をつけるべきコトを教えてくれましたのでシェアしたいと思います。 1. 手を動かせる人であれ 端的に言っちゃうと、現場でコードを書いているエンジニアならまだしも、PMや管理業務が多くなってしまった方は正直不要なんじゃないですかってこと。欲しいのはサービスを拡大 or 安定運用しているエンジニアで、管理する人じゃないだろうから。でも、SIerで最も脂が乗り切っている世代ってPM/PLクラス。若けりゃ未経験でもいいだろうけど、SI業界10年選手とネット系企業とは相性が
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く