エンジニアtype 技術者のキャリアを考えるWebマガジン - 転職＠typeエンジニアtypeは、各種エンジニアをはじめ「創る人たち」のキャリア形成に役立つ情報を発信する『＠type』のコンテンツです。
ホウレンソウに頼らないマネジメント - もぎゃろぐ
Twitterのつぶやきを見ていたら、わりと常識に縛られないタイプの方なのに、「新人研修で覚えてもらうのはホウレンソウとプログラミングくらいかなぁ」的なことを言われていて。そういえばホウレンソウって必須でもなんでもないことは意外と知られていないなぁ、と思ったので書いてみる。 ホウレンソウに頼ったAくんの仕事の進め方 9:00 業務開始。朝Mtgで、その日やることをみんなの前で発表。ぼく早くプログラム書き始めたいんだけどな... 9:30頃 昨日の進捗報告に上司からツッコミが。詳細な説明を書いて返信する。 10:00頃 ようやくプログラムを書き始める。 12:00 お昼休み。 13:00 再びプログラムを書き始める。 14:00 今朝のメールに上司は納得しなかったらしく、呼び出された。状況を説明してようやく納得してもらう 15:00 えーと。何してたんだっけ。あれ。このあと進捗会議か。 1
日本人プログラマーについての記事が Hacker News で話題になった
東京住まいの外国人プログラマーが日本人のプログラミング世界について記事を書いて (Jawaad Mahmood 氏のブログ記事)、その記事が Hacker News で取り上げられて、話題になった。 "My hypothesis is that a lot of Japanese companies produce little new because they have people solving solved problems over and over again." 以下、拙訳。(*) がついているところは訳していて意味がくみ取れなかった部分なのでコメント頂ければ幸い。誰か Hacker News へのコメントも要約してくれると助かる。 昨日、コーヒーを飲みながらアール氏とアキバに関する話題やらボードゲームやビジネスについて話していた。まじめな話題としてはプログラミングについて、
優秀な社員が、無能な管理職になる瞬間 - 知っておきたい「ピーターの法則」 - Feel Like A Fallinstar
最近、すっかり組織をどう作るかとか5年後どんな仕組みにするかとか、そんなことを考えていたりいなかったりします。 その中で、1つ常に意識しているものに「ピーターの法則」なんてものがあるので、せっかくなので紹介がてらにブログで書いてみようかな、と。 優秀なプレイヤーと、優秀な上司はまったくの別物 どの組織でもそうなのかは分かりませんが、出世したり責任を任されたりする人というのは大体何かしら「過去の貢献・成果」を評価されています。 たとえば、 いいプログラムを書いた人が開発の責任者になったり 成績抜群の営業マンが、営業部門の新規開拓の主任になったり 実績を出したコンサルタントが、マネージャーになったり そんな感じではないかなと。 でも、そうやった起用（抜擢）が自動的にうまく行くほど甘くは無いのが組織のうっとうしいところ。 なぜなら、（たとえば3つ目の例で言うと）「優秀なコンサルタント（プレイヤー
エンジニアの役割
技術評論社の WEB+DB PRESS に連載中のコラムが新しくウェブで公開されたので、ぜひとも読んでいただきたい。 エンジニアの魔法の手〜面白いプロジェクトの関るには このコラムで一番注目していただきたい部分は、以下の一節。 自分が関わっているプロジェクトの方向性がおかしいと思ったら，自分がどんな立場にいようと強く主張すべきだ。会社はそんなエンジニアを必要としているし，本当に会社のためになるのであれば必ず耳を傾けてもらえるはずだ。「そうは言っても，難しいんだよ」などと逃げを決める上司は怒鳴りつけてやればよい。 会社にとって最悪なのは，「こんなものを作っても誰も使わないんじゃないか，会社の価値を上げることにつながらないんじゃないか」と思いながらも黙々と仕事をするエンジニアだ。そんなエンジニアばかり集まっている会社は絶対に市場で成功しない。プロジェクトに関わるエンジニア全員が，「自分たちがど
なぜ糞システムができあがるか
納期が、予算が、バグフィックスが、性能、デザイン、インタフェース、使い勝手、保守が、可用性が、移行にマイグレーション、稼働率が、糞だ。そもそも要求を満たしとらんまともに動かない糞システムが、なぜ莫大な銭金かけてできあがってしまうのは、なぜか? アナリスト、コンサル、PM、SE、プログラマ、テスタ、ヘルプデスク、メンテ、ユーザー、そして経営者と、それぞれの立場から言いたいことは山ほどある。それぞれの立場から「これぞ真の原因!」と叫びたいのも分かる。経営者を除き、全てのキャリアをやってきたから。だから、自信をもって断言する。糞システムができあがる、最も根っこの原因はこれだ。 一つ前の仕事をしている それぞれの立場で「やるべきこと」は分かっている。だからこそ、そのインプットが体を成していないことが明白なのだ。仕方がないので、自分で「インプット」相当を作るハメになる。 例えばプログラマ、プログラミ
蒼と碧の幻想 プロジェクトマネジメントのノウハウ（2011/4）
受託系ソフトウェア開発チームのリーダーをやり続け、現在までにおおよそ２０プロジェクト全勝・・は言い過ぎだけど、とりあえず無敗とは言えそう♪ 最初の会社では「なんでそんなにうまくいくのかさっぱりわからない」と言われ続け、今の会社ではチームと個人の賞を独占したノウハウをタダで公開♪ -- ●リード １）プロジェクトの成功には、短期的な成功と中長期的な成功をがある。両方を意識すること。 ２）プロジェクトの短期的な成功は、お客さんを満足させて利益をあげること。 ３）プロジェクトの中長期的な成功は、メンバーが成長することとメンバー同士がまた一緒に仕事したいなと思い合うこと。 ４）リーダーとメンバーがフラットでオープンな関係を築けなかったプロジェクトは、中長期的には失敗する。 ５）ほとんどの人にとって仕事はあくまで生活の手段。生活のイベントより大切な仕事のタスクなんてない。 ●フラット １）リーダー、
オペレーションエンジニアとは何かを理解するために「ウェブオペレーション」を読んで欲しい
最近は、@kazeburo さんの真似をして自分も「オペレーションエンジニア」と名乗ろうかと思ってます。正直最初にオペレーションエンジニアって聞いた時、なんのことだかよくわからなかったんですよね。ちょうどこの言葉を最初に見たのは 1 年前くらいで、その時僕は 2 年目に入ったところで MySQL Conference から帰ったばかりで「おらは DataBase Administrator(DBA)なんだ！」と思ってた頃でした。 それからちょうど 1 年。1 年目の時も DB だけをやってたわけではないですが、この 1 年はより広くより深くいろんなモノを見てきた関係で、自分の仕事は「DBA」だけだとちょっと説明に足りないなぁと思ってたところで、「オペレーションエンジニア」という言葉を思い出しました。そう、僕の仕事は「オペレーションエンジニア」なんです。ひよっこだけど ん、ちょっと待てって？
35歳を超えたエンジニアの5つの働き方
おおいしつかさ 旅行とバイクとドライブと料理と宇宙が好き。 Ubie Discoveryのプログラマ。 ぼくは36歳です。けっこう大きなサイトで、RailsやJavascriptを書いたり、パフォーマンス改善したり、iPhoneアプリの開発でObjective-Cを書いたりしています。マネージメントはしていなくて、今でも普通にエンジニアとして働いています。 35歳定年説の35歳を超えてから1年以上が過ぎたところですが、昔のようにはいかなくなってきたところ、昔と変わらないところ、昔よりよくなってきたところなどがいろいろあります。年を取ってもエンジニアを続けたい人の参考になるかどうかわかりませんが、そういう人たちのためにぼく個人の体験をここに書いておこうと思います。 1.理解できるまで聞き返す 特に若い人たちとの会話で痛感するのですが、相手の言いたいことを一度で理解することが難しくなってきまし
組み込み系と業務系のイメージのギャップ
日々雑記新人を見ていてふと思った。実際に彼・彼女らがどう思っているかは聞いていないけど、よくいうところの「SEの仕事」をイメージして組み込みの世界に来ると、そのギャップに戸惑ったりはしないのだろうか。 「SEの仕事」のパターン、お客さんのところで要件定義、概要設計、機能設計、という上流の工程なんかが、組み込み、例えば携帯電話なんかだと 要件定義...キャリアが決めた仕様があるのですでに要件はある。やっても... 新人を見ていてふと思った。実際に彼・彼女らがどう思っているかは聞いていないけど、よくいうところの「SEの仕事」をイメージして組み込みの世界に来ると、そのギャップに戸惑ったりはしないのだろうか。 「SEの仕事」のパターン、お客さんのところで要件定義、概要設計、機能設計、という上流の工程なんかが、組み込み、例えば携帯電話なんかだと 要件定義...キャリアが決めた仕様があるのですでに要件
Webエンジニアスキルの勘所
Webのエンジニアにはどういうスキルが一番必要か？という話を考えてみた。 例えば、C言語やUnixの経験が長く、オブジェクト指向も理解していたとしたら、PHPから始まり、Rubyなどの理解は決して難しくないだろう。 では、それだけの経験で一線級のWebエンジニアとしての信頼が置けるかというと、ちょっと違うような気がする。 考え方のベースは、 「Webは、要するにテキスト処理であることが多い。だから難しい」 ほとんどの事がHTTPプロトコルを通じてテキストデータとして情報が、なんのネットワークの制約もなく流通する。つまり、HTTPヘッダを含むテキストの操作でセキュリティホールを作り、それが世界のどこから攻撃されるかわからない。 また、 同様に世界中からアクセスが集まることがありうるので、回りくどいテーブル設計をしてしまうと、あっというまに破綻してしまうこともある。 そして、 基本的にマルチア
綺麗なブラック（注:そんなものはありません） - みねこあ
昨日は久々に 一番最初の会社の同僚達と飲んできました。超ブラックだったこの会社は日々驚愕のエピソードを体験させてくれたので何年経っても記憶が薄れることがありません。 給料日は同期みんなでマクドナルドにいって会社の愚痴をいいながらお昼を食べるのが習わしでした。昼を食べ終わり会社に変える際に「あぁ、この角曲がったら社屋に鉄球が叩き込まれていて崩壊していないかな」とか語り合ったのは、今となっては良い思い出です。 ──そう、思えば本当に酷い会社でした。 * * * 絶対に守れるはずの無いスケジュールが引かれ、その上常に案件は3件同時進行（定時分・残業分・休日分 と揶揄してました）、誰も手が開いていない状態でも平気で新しい仕事が放り込まれ、真実の鐘は22時、プライベートは掛け値なしにゼロであり、徹夜明けの朝、やってきた新人に仕事の指示をするようになったら一人前みたいな酷い生活。 そこで「人間追い込ま
ルーチンワークじゃあるまいし、効率や生産性を上げたからって残業はなくせんよ。 - レベルエンター山本大のブログ
今の勤務先では毎週水曜日、定時退社日となっていて ドアの前に張り紙が貼られる 「今日は定時退社日です。仕事の効率を上げて定時で退社しましょう」 と いやいや。効率上げても残業はなくせないよ。 ルーチンワークなら、効率を上げたから早く帰れるだろうけど、 エンジニアの仕事は、結局はモノづくり。 時間があれば、より時間をかけて良いものに仕上げるべきだ 時間があれば、より素早く先のリスクを摘んでおくべきだ という考え方になる。 定時退社したいなら、やるべきことは4つだけ 見切りを付ける やらないでいいことはやらない 時間泥棒にかかわらない 時計を中心に置く 見切りを付ける 約束や締切りが迫っている仕事以外は、見切りをつけてOKだ。 緊急だと思ってる仕事は、焦ってやっても上手くいかない。 長時間かかる仕事は、あと２時間や３時間やっても、大差ない。 やらないでいいことはやらない 効率を上げてゴミを掃除
私がソフトウェア技術者をやめた理由 - Rails で行こう！
昨日、 人生の転機 - Rails で行こう！ の中で「ソフトウェア作りが嫌いだ」と言い切ってしまったことが引っかかっている。 私の職業生活でもっとも多くの時間を注いだのがソフトウェア作りだ。その作業に対して、実際のところ、好きとか嫌いとか一言で割り切れるはずがない。複雑な感情を持っているというのが正直なところだ。 私の職業プログラマのとしての最大の欠点は、ソースコードに対して強い美意識を持たずにいられなかったところだろう。生来の生真面目な性格が災いし、私の基準で美しいとはいえないソースコードを敵視しすぎた。 簡単な例を挙げよう。 うるう年を計算するアルゴリズムを考えてみる。うるう年とは、「4で割り切れて、かつ100で割り切れない年。ただし、400で割り切れたら、やはりうるう年」である。 def leap_year?(y) (y % 4 == 0) && ((y % 100 != 0) |
ある程度の年齢を迎えたプログラマが抱える悩み - bkブログ
ある程度の年齢を迎えたプログラマが抱える悩み ある程度の年齢を迎えたプログラマが抱える悩みに、「若手のプログラマと比べて、どうやって価値を出していくか」という問題があります。これは言い換えれば「同じような生産性であれば、相対的に給料の低い若手のプログラマに置き換えられてしまうのではないか」という悩みです。 この問題のひとつの解決策は、プログラマ以外の仕事のポジション（たとえば管理職など）に移ることですが、他のポジションには向いていない、まだまだ現役でプログラマをやりたいという場合にどんな戦略があるか考えてみました。なお、後述するように、以下に挙げた戦略は相反するものではなく、組み合わせが可能です。 エキスパート戦略 この分野ではトップクラス、というレベルの専門性を身につけ、その分野に特化してキャリアを築くという戦略です。たとえば、ネットワークやセキュリティといった分野で一流と認められる専門
「Linuxの開発に加わるにはどうすればいい？」Linusは言った、「もうそんな質問はするな」 - 科学と非科学の迷宮
2年半以上も前にほぼ同様の記事を書いたのですが、以下の2つの記事を読んだら再度掲載したくなりました。 http://blog.livedoor.jp/insidears/archives/52373634.html http://anond.hatelabo.jp/20100917191635 2008年の初め、The Linux Foundation はオープンソース界の著名人へのインタビューを収録したポッドキャストを配信する企画を始めました。 企画自体は半年ほどで打ち切りになったようですが、その第一回を飾るのが Linux 作者 Linus Torvalds でした。前後編合わせて1時間半にも及ぶロングインタビューです。 かつて私はこの内容に感動し、1年かけて翻訳を行いました。その訳文は JF Project の一部として収録されています。これがオープンソースコミュニティにおける、私の
派遣PG時代の思い出
@vjroba 某N社で「メソッドを作ると処理が上下に飛んで可読性が落ちるので、出来る限り一つにまとめてください」と言われたことがある。僕は300行で挫折したが、1万行メソッドを書ききった強者がいた。クラスを作るには申請書が必要だった。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
@tarosite
Togetter - 国内最大級のTwitterまとめメディア
はてなブログ | 無料ブログを作成しよう
