タグ

ブックマーク / blog.livedoor.jp/lalha (6)

  • 小野和俊のブログ:アンチ・プログラマー35歳定年説

    プログラマー35歳定年説の論拠は一般的に次の2点だと思う。 1. 若いプログラマーでないと徹夜で仕事することができない 言語道断。徹夜が当たり前になっている業界の体質自体がそもそもおかしい。 スケジュールを守らなければいけないという真面目さは良い。 予測できない突発的な問題が発生する。 バッファを取っていても解決の目処が立たない問題が発生したらどうにもならない。 人員補充をしようとしても良い人が見つからなければ少人数で取り組んだ方が解決が早い。 良い人を探そうとしても見つからない。または他のプロジェクトで手一杯になっている。 そういう難しさは、刃物で身が切られるように、痛いほどわかる。 しかし、 そうならないようにするのがマネージャの仕事であり、 問題が起こってしまった時にスケジュールを調整したり機能が削れないか交渉したり、 何とか良い人を探してきたりするのもマネージャの仕事である。 それ

    小野和俊のブログ:アンチ・プログラマー35歳定年説
  • 小野和俊のブログ:プログラマー風林火山

    アプレッソというベンチャー企業の CTO を務めて6年と2ヶ月になる。変化の激しいベンチャーに比較的長い期間身をおいていたので、社内外のいろいろなタイプのエンジニア仕事をしてきた。 あるエンジニアが参加することで開発チームが短い期間で大きく変わったこともあったし、開発チームのメンバーが15人いた頃よりも、お互い補い合えるエンジニアが5人くらいの頃の方が成果が出たりすることもあった。 そういう経験を重ねていくにつれ、私の中では、スターエンジニアと呼べる人たちの持っているものについての、いくつかの類型ができてきている。今まで一緒に仕事をしていく中で当に心強かったのは、最近エンジニアのキャリアパスの議論でよく言われるような財務のわかるエンジニアとか営業もできるエンジニアではなく、あるいは人と異なるユニークな能力を身に付けようとしているエンジニアでもなかった。ではどういうエンジニアが、というこ

    小野和俊のブログ:プログラマー風林火山
  • 小野和俊のブログ:徹夜をしてはいけない理由

    どうしても昨日までに仕上げなければならない仕事があったので、一昨日は徹夜で開発をした。一人で飲んだり、人と飲んだり、布団の中で考え事をしたり、徹夜をすること自体は悪いことではない。しかし、徹夜で仕事をするのは可能な限り避けた方が良い。 ベンチャーを始めてからの最初の2年は、年末年始を含めて365日1日も休まず仕事をした。徹夜なんて当たり前である。そんな私だったが、会社が3年目に入る頃に休息の重要性を痛感し、以来、できるだけ徹夜はしないようにしている。それは、徹夜がもたらす作業時間よりも、悪影響の方がずっと大きいということに気づいたからだ。 私の経験では、徹夜が常習化するにつれ、個人/組織には次のような症状が出てくることがある。特に、影響力のある人がこのような状態になると、組織全体が影響されて深刻な症状にかかりやすい。

    小野和俊のブログ:徹夜をしてはいけない理由
    at9100
    at9100 2005/12/20
    あるあるw
  • 知識が摘み取る創造力の芽 : 小野和俊のブログ

    こういうものをつくりたいと思います。 それはすでに世の中にある別のものでも十分なのだ。 他の会社は先駆けてその分野に着手している。 差別化ポイントは? 調べに調べつくして、 他の人がもうやっていることだったのかと落胆して 何も始めずに終わる人もいる。 何も知らずにトップに躍り出る人もいる。 誰よりも遠くまで飛べた人。 彼らは、躍動する筋肉を楽しんでいた。 風を切って風景がみるみる変わっていくことに興奮していた。 明日もこのことについてずっと考えていたい。 そう思えるものがある人には、知識なんて不要なのだ。 それをやっている人はもういますよ。 それは今からやったって難しい。 最先端の研究ではこうなっている。 速く走ろうとしている者の前に、 そんな指摘がどれほどの意味を持つのか。 彼らが無邪気でいられなくなったときには、 過去に同じ境遇にあった人の話を、しみじみと眉をひそめて聞くだろう。 壁を

    知識が摘み取る創造力の芽 : 小野和俊のブログ
  • 小野和俊のブログ:私がシリコンバレーで学んだ5つの教訓

    1. 会議を最適化する ミーティングのゴールを明確に設定する。 ミーティングの最後に必ず結論と ToDo を確認する。 ミーティングの回数をできるだけ少なくして時間もできるだけ短くする。 ミーティングのトピックごとに関係する人だけ集めて最少人数で議論を行う。 (途中であなたはこのトピックに関係ないから退席して良いです、と指示がでる) 会議を最適化することで労働時間中の実作業時間を最大化させ、労働時間全体を圧縮する。そして、早く帰る。 この体験は、その後自分が会社で会議をしていく上で大きく役立った。 XM(eXtreme Meeting)にも、この時の体験が直接的にも間接的にも影響を与えたと思う。 アドバイザーとしてプロジェクトに参加していたテクニカル・コンサルタントが、技術的に明らかに間違った発言をしたことがあった。 私を含む日から来ていた何人かのメンバーは、あんな基的なこともわかって

    小野和俊のブログ:私がシリコンバレーで学んだ5つの教訓
  • 小野和俊のブログ:続・プログラム・デザイナー宣言

    前回書いたプログラム・デザイナーと職人プログラマーとプログラム・デザイナー宣言と同じような感覚を持っている人は意外と多いのではないかと思って探してみたところ、はてなの伊藤さんのエントリ(こちらも)が見つかった。伊藤さんとは何度か話をする機会があったが、ウルティマ・オンラインの話で盛り上がってしまって、今までIT関連の話はしたことがなかった。ブログを読んでいて、伊藤さんもきっとプログラム・デザイナーなのだろうな、と思った。 UNIXにみる世代間の断絶にならって職人プログラマー/プログラム・デザイナー/UIデザイン・プログラマーを表にすると次のようになる。 比較項目 職人プログラマー プログラム・デザイナー UIデザイン・プログラマー 譲れない点

    小野和俊のブログ:続・プログラム・デザイナー宣言
  • 1