エンジニアtypeは、各種エンジニアをはじめ「創る人たち」のキャリア形成に役立つ情報を発信する『@type』のコンテンツです。
それとも、”私はデザイナーなので、そんなことを知る必要はありません”と言い張るのか 私の職業はデザイナーです。私はエンジニアが好きです。ちょっと度が過ぎるくらい好きかもしれません。以前、Facebookの グループ に参加した時、かなり前からチームのメンバであるiOSのエンジニアと初めて話して、口から泡を吹いたことを思い出します。私はその時、これまでに自分がObjective-Cでコーディングしたものについて、勢い込んで話し始めました。まるで、高校の新入生が、上流階級の生徒に対して、自分が付き合う価値のあるカッコいい人間だと証明しようとしているみたいだと感じました。 デザイナーの多くが、エンジニアとの話し合い方を実はよく分かっていないと思います。もちろん、デザイナーはエンジニアと話しますが、本当の意味で関わろうとしていません。この記事を書いた理由はそこにあります。ソフトウェアエンジニアの懸
僕は本来、人前に出て積極的に話そうとは思わないし、目立たずにおとなしく引きこもっていたいみたいな気持ちがある。潔癖な部分もあるので、プレゼンスばかり高くて技術力がないような中身が無い人間になりたくないし、そうなったら死ぬしか無い、みたいな気持ちもある。それなのに何故、ものすごく技術力があるわけではない自分が対外発表をするのか。 それは元はと言えば対外発表をするような側に行かないとエンジニアとして生き残れないのではないかという危機感があったからです。 Shibuya.pmの衝撃 初めて参加したShibuya.pmは#10だった。その頃の僕は一企業のよくある何でも屋の1人システム担当であり、開発のメインは前担当者から引き継いだレガシーASPだった。そしてつぶしの効く技術を習得したいと思いPerlを学び始めた頃だった。そしてPerlがそこそこ書けると手応えを感じ始めているところだった。 ところが
仕事ができるプログラマって、できないプログラマに比べて「10倍」も生産性が高い。とか言う話がありますよね。 僕も体感的に、本当にできるエンジニアは本当に生産性が5倍とか10倍とか変わることを見てきました。 でも開発の現場では「残業しまくってる」ほうが、なんだか仕事してるように見えてしまう。 そんな中で久々にこの記事を目にしました(漫画なので1分ぐらいで読めます)。 ■「残業しないで帰るSEってやるきないんじゃない?」 http://next.rikunabi.com/tech/docs/ct_s03600.jsp?p=000800 2006年の記事ではありますが、こういう話って普遍的なので古くもありませんね・ 残業しないで定時に帰れるって評価するべきだし、残業をせず家庭を大事にする社風にしたい。 すごく生産性が高いっていうエンジニアを評価したい。 でも残業してるのって分かりやすいから評価さ
サイボウズ・ラボの西尾 泰和さんが「エンジニアの学び方」について探求していく連載の第2回(毎週火曜日に掲載、これまでの連載一覧)。「WEB+DB PRESS Vol.80」(2014年4月24日発売)に執筆した「エンジニアの学び方──効率的に知識を得て,成果に結び付ける」の続編です。(編集部) 文:西尾 泰和 イラスト:歌工房 この連載では「エンジニアの学び方」をテーマにインタビューを行い、どういう「学び方」をしているのか探求していきたいと思っています。第1弾は、富士通のエンジニアとしてLinuxカーネルの開発に参加されている小崎資広さんです。 Linuxカーネルは、ソースファイルだけで3万5000個以上、行数にして1500万行を超える、巨大ソフトウェアです。小崎さんが、どうやってこの巨大なソースコードと戦っているかは、きっと「エンジニアの学び方」の参考になるはずです。
「バブル期の日本」と「シリコンバレーなう」の共通点:プログラマ社長のコラム「エンジニア、起業のススメ」(10)(1/2 ページ) シリコンバレーでは今、二流エンジニアたちがオフィスの卓球台の周りで多忙ぶりを嘆き合っている。その姿はまるで、バブル時代のニッポンのサラリーマンのようだ。 連載目次 私が初めて日本に来たのは、1980年台後半のバブル全盛期だった。 誰も彼もがジュリアナで踊り、「『NO』と言える日本人」が話題だった。日本車や日本製の電化製品が世界市場を席巻し、西側諸国は日本の労働市場に羨望(せんぼう)のまなざしを向けていた。日本人従業員は教育レベルが高く、規律正しく、信じられないほどの働き者として有名だった。 労働現場の実態 その勤勉な国で働くことになり、私がどんなに困惑したか、あなたに想像できるだろうか? 私が働いていたのは、日本の大手IT企業だった。同僚たちは9時の定時前に全員
というような大きく構えたタイトルにしてみたが、デジタルな結論を持った記事ではない。 教育制度として文系とか理系とか分ける意味あんのか、というような議論はさておき、現行でそういう制度が存在している以上は僕の身の周りにも文系学部からプログラマーになった人、理系学部からプログラマーになった人がいて、僕の知る限りでは両者にプログラマーとしての能力の差は見受けられない。 世間では、どうやらプログラムを書くのには数学的な能力が必要だと思われているせいか、あるいはいわゆる情報システム系の学部が理系学部に分類されているせいか、理由は全員に聞いてみたことがあるわけじゃないのでよく分からないが、どうやらプログラマーといえば理系だと思っている人が多いようだ。 僕個人で言うと、大学・大学院と数学の点数の低さを英語の点数でカバーしてきた(これは実際には点数の照会なんてしてないので実際には不明なのだが、明らかに手応え
今までパッケージソフトとかWebサービスの開発をしてきた中で、ビジネス上の納期や要求を満たすためにひどいコードを書くっていうのは自分の経験ではあまりなかった気がします。なにかひどいバグがあって、とりあえずのパッチを当てて間に合わす、ということはたまにあるけれど。SIの世界は知りませんよ。 そもそもコードを汚くかけば納期に間に合うということもないし、ビジネス上の近道になるということもない。コードをきれいに書こうが汚く書こうが無理なものは無理。第一汚いコードを意図的に書くというのも意外に難しいということは、普段まあまあきれいなコードを書いている人ならわかってくれるんじゃないかと思います。 仕様変更に設計がついていけてなくておかしいとかならともかく、関数が1000行あるとか、newした瞬間全てが終わるとか、変数のスコープがびっくりするくらい広い、みたいなコードについてははビジネス上の要求ではなく
「恐怖」を知ること 35歳が目前に迫りつつある中、ぼちぼちスピリチュアルなことも書いていこうかと思う今日この頃です。 これまで十数年、小さな会社やフリーランス、大企業(はすぐ辞めたけど)を渡り歩いてきて改めてベンチャーの面白さを実感しています。 様々な要素がありますが、その最たる物は「エンジニアが会社の命運を握っている」という紛れもない事実です。自社でプロダクトを開発しているベンチャーにおいて、どんなに立派な経営理念やビジネスモデルも動かないシステムの前ではクソの役にも立ちません。 そして、それはそのままエンジニアの過ちが会社を危機に陥れるリスクを意味します。言ってしまえば「ワンクリックデプロイ」が「ワンクリック倒産」へと直結するかもしれないのです。省力化そのものは目指すべきですが、自分の行為が内包するリスクは忘れてはならないのです。 「何か」が起きてしまった時に上長の責任だ、確認ミスだと
2013.01.31 ITニュース いまやプログラマーの「必須プラットフォーム」となりつつあるGitHub。サービス開始からわずか5年で全世界にユーザーを獲得してきた同社は、独自の経営理念によって「プログラマー天国」を築き上げていると評判だ。その根底にある考え方や、組織運営のこだわりとは何なのか? 来日中のGitHub経営陣に、編集長の伊藤健吾が話を聞いた。 GitHub COOのPJ Hyett氏(左)と、CIOのScott Chacon氏(右)。多忙なスケジュールの中で取材に応じてくれた 「これからの時代、プログラマーをやりたい人にとって、GitHubアカウントを持たなくて済むのは小学生までとなるでしょう」 弊誌対談「小飼弾×増井雄一郎が大激論! 開発者「大増殖時代」の到来で、プログラマーの存在意義はどう変わる?」で小飼氏がこう述べるほど、世界中のプログラマーに利用されるようになった開
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く