エンジニアにとって生産性の高い環境を追い求めているだけでは事業は成長しない - jkondoの日記
最近ちょっと会社の中の歯車がかみ合い始めて、ごろごろごろと大きな回転が始まった感覚があります。 会社をやり始めて10年目。ようやくかよ、という突っ込みは真摯に受け入れるとして、何を変えたのが大きかったかというと社内のコミュニケーションのやり方です。特に、組織の中で直接つながりのある人どうし＝上司と部下の間のコミュニケーション。なんか書いていると馬鹿らしくなってくるくらい基本的な事で恥ずかしいですが、直接の部下に対してやるべきことをちゃんと伝えたり、部下から上司に対して行う、いわゆる「ほうれんそう」などです。 思えば、はてなの仕事の進め方というのは、エンジニアにとって最も生産性が高い環境を追求する、ということに最適化してきたように思います。会議はなるべく減らして、必要な事ははてなグループかIRCに書いて伝える。プログラムを書いていると2時間くらい集中して作業をしたくなるので、その間なるべく作
エンジニアが人月商売の会社で働くのってどうよ？ - GoTheDistance
タケルンバ卿より下記内容についてリクエストをもらったので回答してみる。 ポイントをまとめると、こんな感じです。 人月商売をやっている会社は、単価によって大凡のサービス価格が決まる。よって下請けに安い単価で出してマージン抜くと利益率向上に直結する。 が、下げられる単価にも国内では限界がある。人工商売なら海外に安い労働力を求めるのが合理的なので、海外へ委託するしか無いのではないか？ 翻ってこういう会社で生き残るには、マネージャ職につくしかないのではないか？ITの場合、プログラマでいたいなら一人親方にならざるをえないのではないか？ 人月は流れて西へ - (旧姓)タケルンバ卿日記 結論から言うと、全部同感。ITでも人材派遣(警備業界とか)でも、根っこは一緒。 人月商売は「単価」×「人数」×「期間」のかけ算が基本的な考え方。このモデルで利益率を増やす為には「単価を上げる」か「安い単価の人間を使うか」
プロとしての行為 Act as Proffesional
スーパーエンジニア達の習慣が大人気だったので、自戒の意も込めて、反面教師として成長しないエンジニアの悪習慣について僕の経験と視点からまとめてみる。 業務時間外での学びがない プロ野球選手は日々練習をして、試合という本番で勝敗の結果を出して評価されるこれをエンジニアに置き換えると、どこかで練習をして、仕事という試合をして、ソフトウェアという勝敗の結果をつくりだす。プロ野球選手が試合を練習だと思って取り組んでいたら、結果を出せるのだろうか？ 業務外で練習をして、本番で良い結果を出せるように努力しよう。練習大事!! 時間をかければよいものができると信じているいくら時間をかけたって、バグのないエレガントなコードのソフトウェアはできない。効率的に仕様を満たしていくことが求められている。むしろ、時間をかけるべき所は上記で指している練習!! 参考：集中力を発揮して、生産性を高めるために知っておくべきこと
これはマネしたい！スーパーエンジニア達の習慣 | Act as Professional
いままで勉強会に顔を出し、すばらしいエンジニアと数多く会うことができた。そして、スーパーエンジニアと共に仕事をすることもできたし、できている。そんなスーパーエンジニア達が持っていた習慣を僕の経験と視点からまとめてみる。 自分が使う道具を厳選して選んで手入れをしているエンジニアでいえばエディタやツールなど。皆が使っているIDEやエディタを何も考えずに使い始めたりしない。 厳選したエディタやツールを使って、手になじませるのである。手になじませるというのは、2つの意味がある。 1つは操作性に慣れること。呼吸をするように自然に、キーボードの上を駆け回る心地よいリズムを奏でるエディタを選ぶ。 2つめは、自分に合わせて拡張しているということ。プラグインのON/OFFだけではなく、オリジナルのショートカットを設定し、適切なハイライト、シンタックスのチェック、コーディングルールのチェック、様々な言語への対
Leaving Yahoo! Japan « The Jon
After a little more than 4 years, I haves decided to leave Yahoo! Japan for greener pastures. When I first joined Yahoo, my very first project was to improve the backend system for the video news portion of Yahoo. Before entering the company, I had actually used curl to download the ASX file to watch these videos in Linux. So it was something that I was familiar with, but from a users perspective.
ソフトウェアエンジニアが自分の成果を表現する必要性について
2008年も終わりに近づいている。2008年の年初にこのような金融危機からくる景気の急速な減速が起こるとは予想もしていなかった。 この事態に一時的に職を失った人もいると思うので軽々なことは言えないが、毎日流れる不況のニュースを聞いていて技術者にとって仕事とはなんだろうかといろいろ考えを巡らせたのでその内容を書きたいと思う。 ソフトウェア技術者として仕事をしているのであれば、個人の価値と組織の価値をできるだけオーバーラップさせ、かつ、大変だけれども楽しいと思える仕事をしたいと思っているし、このブログでそう書いてきたつもりだ。実際にエンジニアとして仕事をしてきた自分自身の22年間を振り返ると多くの時間がそうであったと思うし、それなりの満足感もある。 過去を振り返ったときに満足感を得るためには、その時その時に流されてしまってはいけない。ここぞというときにはこだわりを持って踏ん張らなければならない
ソフトウェアエンジニアは、クールでセクシーな仕事 － ＠IT自分戦略研究所
エンジニアにとって、シリコンバレーで働くとはどういうことなのだろうか。日本との違いや、シリコンバレー特有の文化、キャリア形成などを、実際の企業や、現地で働いているエンジニアたちの言葉から考える。 前編｜1 2｜次のページ 前編ではVMwareとヒューレット・パッカード（HP）の「内側」を紹介した、パソナテック主催のシリコンバレーツアーレポート。後編の今回は、シリコンバレーで働く邦人エンジニアのセッションから見た「エンジニア事情の日米比較」と、それを受けてツアーに参加したエンジニアたちがどう感じたかをレポートする。 ■グーグル、アドビ、元アップル シリコンバレーで活躍する、4人の日本人。グーグルのソフトウェアエンジニアの廣島直己氏、アドビ システムズのソフトウェアエンジニアの松原晶子氏、元アップルのソフトウェアエンジニアで、現在はフリーコンサルタントの佐藤真治氏。モデレータを務めたBlues
梅田望夫氏が提案“2007年ＩＴエンジニア進化論”／Ｔｅｃｈ総研
コンピュータの歴史は約50年、インターネットが登場して約10年。だが、今ほどこの歴史が大きく変化する時代はないだろうと語る梅田望夫氏。この2007年にはどのような変化が訪れるのか。そして次の10年、15年先のITビジネスやネット社会はどう進化していくのだろう。 梅田望夫氏（うめだ・もちお） 1960年生まれ。慶應義塾大学工学部卒業。東京大学大学院情報科学科修士課程修了。1994年よりシリコンバレー在住。1997年にコンサルティング会社、ミューズ・アソシエイツをシリコンバレーで創業。2000年には岡本行夫氏らとベンチャーキャピタル、パシフィカファンド設立。2005年3月より(株)はてな取締役。著書に『ウェブ進化論』（ちくま新書）、『シリコンバレー精神』(ちくま文庫)、『ウェブ人間論』（新潮新書）。 2006年は、日本ではSNSのミクシィの株式公開、アメリカでは動画のYouTube（ユーチュー
ITmedia News：「ネットは遊び場」――「字幕.in」を1人で作る25歳・無職 (1/3)
YouTubeの動画に字幕を付けられる「字幕.in」、mixiやGREEなど人気SNSの会員数をリアルタイムで算出する「SNS統計ページ」、2ちゃんねる風掲示板サービス「2ちゃんねる2」――リリースのたびにネットを騒がせたこれらのサービスは、矢野さとるさん（25）が、個人で作ったものだ。 矢野さんは、サービスポータル「satoru.net」の管理人で、個人で運営するサービスは50以上。合計ページビューは1日500万にも上る。 これだけのサービスを運営している矢野さんは、会社員でもなく、個人事業主でもない。「職業欄に『無職』と堂々と書いています」。一部サービスに広告をはっており、そこから上がる広告収益だけで何とか食べていっている。 19歳で地元・福岡に就職し、21歳で上京。ヤフー、ライブドアなどネット企業を渡り歩いた後、昨年末、無職になった。組織に縛られず、好きなサービスだけを作っていける今
未来の転職が、過去にさかのぼって現在の自分を有能にする - 分裂勘違い君劇場
転職、すなわち中途採用の面接では、自分が過去に取り組んだ仕事について質問されます。 しかも、ごまかしがきかないよう、具体的な行動内容を、細かく聞かれます。 広く浅く訊くのではなく、何カ所か適当に選んで、狭く深く訊いていきます。 たとえば、エンジニアなら、過去に自分が開発したシステムにおいて、 なぜ、そのフレームワーク、ツール、ライブラリ、DBを使ったのか？ 他に、どのようなフレームワーク、ツール、ライブラリ、DBが候補として 上げられたのか？ 他の選択肢と比べて、どの様な短所と長所があるのか？ なぜ、他の選択肢ではなく、それを選んだのか？ 使う前に、どのように性能評価・検証したのか？ なぜ、ある部分を汎用的に作り、別の部分をハードコーディングしたのか？ なぜ、その設計だと、生産性が高く、トラブルのリスクやメンテナンスコストが低くなるのか？ もっと低くできる余地として、どのようなものが考えら
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
