Twitter を始めてから半年が過ぎようとしている。 使い始めて3ヶ月位して思ったのは、Twitter には3つの段階があるということ。 3段階目の「What are you thinking of?」が楽しくて仕方なかったので、 家でも会社でもブラウザのトップページを Netvibes から Twitter に変更した。 しかし、その頃私が見ていた世界は Twitter の二つの世界のうち 実は一方の世界だけだったということに気付かされたのは、9月21日のことだった。 「@lalha は32人しか follow してないのに twitter の何を語ってんだ。」 最初私が感じたのは、「それは違うだろう」という抵抗感だった。 というのも、以前から RSS や Twitter について、フィード登録数や Follow 数が少ない人間は語る資格がないという趣旨の発言を見るたびに、どちらもこん

昨日MIJSのコンソーシアム内での技術発表会があり、理事会の方から「参加ベンダーの技術者が集まるイベントなので、技術者に元気を与えられるような人に講演をお願いしたい」という話があったので、はてな伊藤さんに講演をお願いした。 伊藤さんにお願いしようと思ったのは、伊藤さんなら、エンタープライズの世界にウェブの世界の元気な風を吹き込んでくれるのではないかと思ったからだ。 以下、私なりに講演の内容をまとめてみた。 ■「建物の建て方」 つくる対象がどのようなものかで、作り方は当然変わってくる。これは建物もソフトウェアも同じ。1階建ての格好良い小さなロッジを建てるのと、60階建ての安全で高品質な巨大ビルを建てるのとは方法も道具も異なる。ロッジを建てる時にはノコギリを使うが、巨大ビルを建てるにはクレーンを使う。 よくブログの世界でソフトウェアの開発について、ぜんぜん違うことをやっている人が同じ土俵で議論

ここ数日、私はずっとペアプログラミングをしている。 ペアプログラミング自体は、これまでに何度も経験したことがある。 しかし今回の試みが今までと違うのは、 一日中、ペアプログラミングしかしないという点である。 １セット1時間半、15分の休憩を入れて、 ドライバーとナビゲーターを交互に入れ替えて毎日4セットやる。 このところ、これを何日も続けている。 こうやって、ある程度ストイックに続けてみることで、 わかってきたことがある。 それは、ペアプログラミングにはメガトン級の破壊力があるということだ。 プログラマーは絶えず誘惑にさらされている。 調べ物でウェブを見たついでに何時間もネットサーフィンしてしまったり、 考えたことをメモするついでに2時間かけてブログを書いてしまったり、 仕事の用事で知人に IM したついでにしばらくだべってしまったり、 Twitter に書き込んだついでに Friends

はじめに断っておくと私はかなりポジティブシンキングな方である。問題が見つかったときにも「調査が進み問題が発見された」などと、つい前向きに発言してしまうところがある。 ポジティブシンキングの功と罪のうち、功については言わずもがな、文句ばかり言っているよりも物事に前向きに取り組んだ方が気持ちが良いし、前向きな姿勢でいるからこそ見えてくる可能性というものもある。 しかしこのエントリで取り扱いたいのは主にポジティブシンキングの罪の部分である。 往々にして最も大切なことは最も言いにくいことの中に隠されており、ポジティブシンキングであるが故に負の部分が見えなくなって本質を見誤ってしまうといった危険性は、私たちの生活の様々な場面において存在する。 自分たちが提供しているソフトウェアやサービスで、最も嫌いな機能、最も使いにくい箇所等をユーザーや社内の関連部署の人に投票してもらってランキングを競う。ここで見

会社で問題が起きたとき、なぜそんな問題が起こったのかと詳しく話を聞いていくと、 問題を構成するほとんどすべての項目について、ミスコミュニケーションがその根本の原因となっていることがある。 誰かが手を抜いているわけではない。誰もが前向きに一生懸命やっていこうとしている。 それでも、ミスコミュニケーションが重なると、問題が次第に大きくなり、修復することが難しくなっていく。 場合によってはその積み重ねが相手に対する不信感を生み、人間関係に悪影響を及ぼすこともある。 ミスコミュニケーションは人の問題であり、簡単には解決できないようにも思える。 しかし、対策の打ちようはある。 【ミスコミュニケーションの分類】

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

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

(プログラム・デザイナーと職人プログラマーの続き) かつて、 「すごいプログラマー」は みんな職人プログラマーだった。 今は、 「すごいプログラマー」の 多くはプログラム・デザイナーだ。 拡張の快適さ といったものだから、 主観的にしか評価することはできない。 プログラム・デザイナーの 仕事の本質は、 つくること以上に デザインすることだから、 今のソフト業界がファッション業界に似ている というのは当然のことなのかも知れない。 Binary 2.0 という考え方が出てくるのも、 こうしたことが背景にあるのだろう。 プログラム・デザイナーと 職人プログラマーとは、 いがみ合いやすい。 あいつは機械のことがわかっていない。 あいつは動けばいいと思っている。 あいつの書いたコードは誰もメンテナンスできない。 あいつはあんなことも知らない。 この種の対立は不毛である。 プログラム・デザイナーよりさ

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