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

8/5から三日間、昨年に引き続き、九州大学非常勤講師として高度ICTリーダー特論という大学院の授業で福岡に来ている。この授業では、日本の大企業からはNECのシステム開発本部長の池上さん、国際的なリーダーシップということで東京海上で世界中を飛び回っている牧野さん、外資系企業のマイクロソフト楠さん、ベンチャー企業のUEI shi3zさんと私、経産省の境さんと、様々な立場の講師がプレゼン、パネルディスカッション、グループワークなどに参加しながら授業を進めるというなかなか面白いタイプの授業である。 こうした諍いのことをネットに書くのもどうかとも思ったのだが、リーダーシップを論じるために呼ばれた講師同士が飲み会で喧嘩、ということになると、授業そのものが駄目なリーダーの見本市のような様相を呈してしまうため、私たちが何を議論していたのかについて、shi3zさんにならって私の視点からもブログに書いてみよう

プログラミングを始めてから今日に至るまで、 様々なタイプのプログラマーと開発を共にしてきたが、 驚くべき速度で高い品質のソフトウェアを作り上げるプログラマーには、 一つ共通の特徴があるように思える。 それは、「はまる」時間が極端に短い、ということである。 風のプログラマー」を指向しており、開発速度を重要視している。 例えば平成14年未踏ソフトウェア創造事業「PICSY」では、 発表直前に知人でプロジェクトリーダーの鈴木健にレスキュー隊として呼ばれて 2,3日でGUI全般と、クライアント/サーバー通信部分の設計と実装を終わらせたのだが、 このときなどは、大体の要件を口頭で聞いた後は、 ほぼまったく手が止まらずコードを書き続ける感じで開発をしていた。 「はまる」時間の長さは開発速度に直結するわけだが、 プログラマーが「はまる」場合にはある程度の傾向があると思うので、 今日は「はまる」プログラマ

技術者・SE・プログラマ面接時の技術的な質問事項というエントリをはてブで見かけたのだが、私もjavaプログラマーの面接を割とよくやっているので、よく質問する内容をまとめてみた。 (ちなみに、基本的にコーディング面接の形態を取っている) プロジェクトの性質にもよると思うが、私の場合には、情報処理技術者試験的に基礎が満遍なく抑えられているかどうかよりも、 すぐ答えが見つからないような課題に対して、きちんと自分でやり方を考え、対応することができるか 「変な」コードをコミットしたりしないか(見つけにくいバグを混入させるとか、汚いとか、遅いとか)といった点を重視している。 まず、何を知っているかよりも、どんなものを作れるか、どんなことができるか、という質問。 ここで強烈な回答が来る人は、たいていここより下の質問は「あー、はいはい」という感じでサラッと答えてくることが多い。 これまでに携わってきた開発

基礎的な学力を表す言葉として読み書きそろばんという言葉があるが、 私はプログラミングについても読み書きそろばんに当たるものがあると思っている。 まず読みというのは、プログラムを読む能力である。 たまに、人の書いたソースを見て、すぐに 「全面的に書き直さないと使い物にならない」とか、 「グチャグチャですよ」とか、 「気持ち悪い」といったことを口にする人がいるのだが、 多くの場合、なぜそのように感じるのかを聞いてみると、 単に自分が今まで書いてきたコードと違ったスタイルで書かれている、 ということだったり、ごく一般的なデザインパターンが使われているのに、 そのデザインパターンを自分が知らないだけで 「わかりにくくて読めない」などと言っていたり、 人のコードを使い物にならないと簡単に口にする人であればあるほど、 その人自身が使い物にならない、という傾向がある。 もちろん、全体の整合性を取るために

ブログを始めた当初、私にとってのブログは何を書いてもいい場所だった。 もちろん、今でも何を書いてもいい場所ではある - ブログというものの定義の上では。 これは多くのブロガーが感じていることだと思うが、 ブログを始めたばかりで何人かの知人だけが見ていたころは 今日感じたこと、個人的に少し考えたことなど、気軽にどんなことでも書けたのが、 不特定多数の人が見てくれる状況になってくるにつれ、 この内容はわざわざブログに書くようなことではないな、という風に、 思ったことをそのままブログには書けなくなってくる*1。 はてなダイアリーを始めて、そこにWoWで遊んでいて楽しかったことなどを 気軽に書いていこうと考えた。そして最初の頃、それはうまく機能していた。 ある時、WoWは英語版しかなくてとっつきにくいという声をよく耳にするので、 クエスト情報を日本語に翻訳するQuestJapanizerというAd

年が明けて成人の日が近づくに連れて思い出すのは大学入試のセンター試験のことで、大学受験から十数年経った今になって思うのは、あの試験をつくる側の人は意外とネタっぽく、ププッと吹き出したりしながら試験問題を作ったりしているのではないかということである。 文章中に下線を引いて、そこに対する正しい記述と正しくない記述とを織り交ぜて問題をつくっていくわけだから、特に正しくない記述の選択肢を考えるのはかなりネタっぽい作業なわけである。 それが具体的にどのような作業であるのかを体験するには、身近なテーマについて、センター試験の形式で問題をつくってみるのが最良なのではないかと考えた。 以上の経緯で、平成19年の現代社会のセンター試験を参考にしながら、現代ウェブ社会と題して以下のように試験問題をつくってみた。 現代ウェブ社会 第1問 次の文章を読み、下の問い(問1 〜 問12)に答えよ。(配点 36) はて

半年ほど前に♪ バグは夜更け過ぎに仕様に変わるだろうというエントリを書いたのだが、時期的にクリスマスでなかったのが何となく心残りだったのと、サビの部分はやはり繰り返しにすべきだろうなどといくつか思うところがあったので、もうすぐクリスマスの今日という日に、Alternative Version をお届けします。 ♪ バグは夜更け過ぎに ♪ 仕様に変わるだろう ♪ サーバー・ダウン　ケータイ・コール ♪ きっと君はこない ♪ ひとりきりのサーバールーム ♪ サーバー・ダウン　ケータイ・コール ♪ 帰れそうもない ♪ 必ず今夜こそ ♪ 寝られそうな気がした ♪ サーバー・ダウン　ケータイ・コール ♪ まだ消え残る 君への想い ♪ 夜へと降り続く ♪ 卓上にはスタミナドリンク ♪ ディスクからは不吉なサウンド ♪ サーバー・ダウン　ケータイ・コール 繰り返しになりますが、関係者の皆様 ネタですので

ドラクエIIIでは遊び人はレベル20になると無条件に賢者になれる。 現代において、リアルの世界で、これはある意味真実味を帯びていると私は思っている。 それは例えば「King Of Doomからの手紙 ゲーム大会優勝で社長になった男」にあるような話だ。 何年か前までCNET Japanの社長を勤めていた御手洗氏は、 秋葉原のバイト店員時代にDoomというネトゲを極めたことがきっかけで 伊藤穣一氏と出会い、賢者への道を歩んでいった。 しかし梅田氏が「徹底的に勤勉であること」という表現を使っているのを見て、 私の考えている「好きなことを貫く」ことと梅田氏の考えている「好きなことを貫く」こととは 異なるものなのかもしれないと感じている*1。 私が考える「好きなことを貫く」こととは、「勤勉さ」という表現が絶対に適用できないものだ。 例えば私はここ数ヶ月、毎日ネトゲのWoWばかりやっている。勢いでギル

404 Blog Not Foundの注目エントリを見てて思ったんだけど、 やっぱりdankogaiはすごい。エントリ数もブクマ数もすごい。 ということで、イチロー伝説にちなんでdankogai伝説をお送りします。 ・トラックバックしただけで相手ブロガーが泣いて謝った、心臓発作を起こすブロガーも ・一文字もない空エントリでもホッテントリ入り ・寝ている間にも3エントリをポスト ・パソコンを起動せずにトラックバックしたことも ・ホッテントリ1位でも納得できなければエントリ削除 ・ディスプレイを一睨みしただけで10万アクセス ・初めて書評を書いたときにamazonがダウンしたことは有名 ・グッとガッツポーズしただけで5エントリポストされた ・リンクされるとYahoo!でも臨時でサーバー増設 ・言葉を覚える前からブログを書いていたという噂も ・あまりにもブクマされるのではてなユーザーが利用規約違

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

「直感を信じろ、自分を信じろ、好きを貫け、人を褒めろ、人の粗探ししてる暇があったら自分で何かやれ」という梅田望夫氏のエントリは、読み物系のエントリとしてははてなブックマークで過去最高クラスの、1100件を超えるブックマークを記録しました。 梅田望夫氏がこれまでの書籍やブログのエントリで繰り返し発信しているように、好きなことを貫き、好きであるが故に人生のどれだけ多くの時間を使っても苦にならないような分野に身を置いて仕事をしている人というのは、本当に輝いて見えます。 しかし一方で、ひとたび社会に出れば「俺が今感じてる閉塞感をリアルな言葉にしてやるよ」に見られるような閉塞感を感じ、日本という社会においては好きなことを仕事にしていくことができるのはごく一部の環境や能力に恵まれた人だけなのではないかと感じている人も少なくないのが実際のところなのではないかと思います。 では、好きなことを貫いていくには

小飼弾さんのブログで、やっちゃうとバカにみえちゃう英文法の間違いという記事があったのだが、読んでいて、こういう間違えやすい英語というのはプログラミングの世界でもあるなと思ったので、私が実際見たことある事例に絞って、プログラマー版を何点か。 * 小飼弾さんと秋元さんからいただいたトラックバックの内容に基づいて、一部追記しました。 たまに、フィールドやメソッドの名前で、「メモリにキャッシュする」というようなケースで使われる「キャッシュ」が cash になっていることを見かけるのだが、cash は現金という意味のキャッシュで、正確には cache。そんな間違いする人いないのでは、と言う人もいるかもしれないが、この間違いは実際に何度か見たことがある。 2. Programming - Programing 辞書的には programming (mが2つ) が正しい表記。ただ、Google などで検

1. 割り箸を職場に常備する 草野球をやっていた人は子供の頃、怒られたことがあると思う。 打った後にバットを投げ出して走り始めてはいけないと。 いつも使うものは丁寧に扱いなさいと。 プログラマーがキーボードやマウスを油で汚すなんてことは言語道断である。 ポテトチップスや唐揚げ、スナック菓子などを直接手で食べてはいけない。 かならず割り箸を使って手を汚さずに食べる。 それがプログラマーとして最低限の作法。 XP な職場であればあるほどお菓子が用意されていたりするから、 なお要注意である。 文章を書く場合でも、ソフトウェアを開発する場合でも、 プレゼン資料を作る場合でも、 成果物のイメージが明確になっている場合には キーボード＆マウスは極めて有効なデバイスだ。 だが、構想を練っている段階やアイデアを膨らませている段階では、 紙とエンピツでアナログなやり方をする方が圧倒的に仕事が進む。 これは誰

私はもともとはプレゼンは完全にアドリブ派で、大まかな流れだけサッと考えて直前に資料をつくって、後はぶっつけ本番で、残り時間を見ながら話す内容をその場で考えてプレゼンする、というのがお決まりのスタイルだったのだが、昨年末あたりから、このやり方だと、内容はそれなりに伝えられても、発言に冗長なところがあったり、表現が洗練されていなかったり、そして何よりも、プレゼンの中にドラマがないというか、良いプレゼンを見ていると、どれも周到に準備されていて、話の展開はもちろんのこと、沈黙のタイミングや長さ、声の調子に至るまで微にいり細にいり実によく考えられており、アドリブのプレゼンだと、このようによく準備されたプレゼンと比較すると、演出の面において決定的に劣ってしまうのではないかと考えるようになった。

仕事が思うように進まないということは誰にでもあることで、時としてはそれは集中力の問題やモチベーションの問題といった比較的深刻な問題が原因となっていることもあるわけだが、ちょっとした工夫で状況が一変してしまうこともかなり多い。私がこれまで人から聞いたり、自分で見つけたりしたものの中で、今でも結構役立っているのは次の4つの対策である。どれも当たり前と言えば当たり前だが、意識してやってみると結果がかなり変わってくる。

担当者に代わって機能追加を行うのが本来の目的だったはずなのに、 該当箇所の周辺の実装をフムフムなるほどと確認しているうちに 自分だったらこう書くな、と思う箇所があると、 直接関係ない箇所まで自分色に染め始めてしまうのが プログラマーとしての私の性質の一つである。

高校の陸上部に入って最初に教えられたことは、400m 走は最後まで全力で走り抜けることはできないから、ペース配分が大切だということだった。 先輩曰く、 1. 最初の 100m スタートダッシュ 2. 次の 100m 全力疾走 3. 次の 100m ペース維持 4. 最後の 100m ラストスパート これは一見、言葉を変えただけで全部全力疾走じゃないかという風にも見えるのだが、実は3番目の 100m で少し力を抜くというのがポイントで、実際、どこかでうまく力を抜かないと良い結果が出ない。 この力の抜き方には人それぞれに得意不得意があって、前半力を出し切ってトップを取る方が精神的に楽だと感じる人、最後まで力を溜めておいて一気に抜き去る方が楽だと感じる人、さらには満遍なく一定のペースを維持するのがやりやすいと感じる人と、人それぞれによって実力を出しやすいペース配分というものがある。 興味深いのは

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