昨年末あたりから、開発加速のためにエンジニアを募集しようと、 商用媒体にいくつか広告を出したりしてみたのだが、 なかなか良い人が見つからず、困っていたのである。 何か方法はないかと社内で立ち話をしているとき、 ふとこんな風に思ったのである。 「Twitterに書いてみたらどうなるかな？」 その発言から5分もしないうちに、私は急いで席に戻って、 Twitter に社員募集のメッセージを書き込んだ。 その後、4月7日現在までに、約３０人の人からリプライをもらったり、 DMをもらったり、会社見学に来てもらったりした。 結果的には現時点でもう出社している人が一人おり、 あと二人のエンジニアが近日中に開発チームに参加してくれることが決まっている。 今まさに面接の最中の人も何人かいる。 このエントリで書きたいことは、 Twitterで実際に採用活動ができた、 ということではない。 Twitterで採用

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

昨夜は2/14のバレンタインデーであるにも関わらず、男5人で飲んだ。 私もそこそこ飲む方ではあるのだが、店に向かう道中、 前回は日本酒を一人一升飲んだ等という大変恐ろしい会話が聞こえてきて、 そしてその時感じた不安は、 現実の問題としてその後すぐに私の前に突きつけられたのだった。 飲み会が始まるや否や、目の前で日本酒の升が次々と空になっていくではないか。 後半は何を話したのかほとんど覚えていない。 だから今日は平日であるにも関わらず、朝から酷い二日酔いだった。 二日酔いの治し方について書こうと思う。

* クリック単価は 2006/7/4 時点での AdWords 最低入札額。 * 支払額は AdSense 利用者にヒヤリングを実施した結果からクリック単価の 1/3 と推定。 上に挙げたのはこのブログでよくキーワードとして認識されていたものをピックアップして金額を推定したものだが、半年間ほど AdSense を利用してきた感覚としては、実際の支払額と上記の表は大きくは変わらないという印象である。(AdSense の契約で支払い実績の直接的な詳細は公開できない) 2. 広告主同士を戦わせるのがうまい 次に気になるのが、サイト運営者への支払いが大きいということは広告主の負担が大きいのではないかということである。私は自分の会社では AdWords 広告を出稿していて、ブログを書いているときにはサイト運営者として報酬を受けていたわけだが、同時に会社では広告主の立場でもあり、このテーマは私にとって

忙しい時にこそ考えなければならないのは、今まさに目の前にあるこの忙しさが本当に必要なものかどうかということで、普段は冷静に行動できる人であっても、忙しさで判断能力が低下した結果として、傍から見ればまったく意味がないことに忙しい忙しいと言って駆けずり回ってしまうことがある。 このような時にもっとも冷静さを保たなければならないのは組織を統括するマネージャーである訳だが、困ったことに忙しい時というのは、その忙しさを少しでも緩和するためにマネージャクラスの人間も現場の作業に駆り出されていることが多い。 だからそういう時には、マネージャーかどうかといった役職をこえて、一人一人のメンバーが次のような状況に陥っていないかどうか、こまめに自問自答しながらプロジェクトを進めて行きたいと思うのである。 目標拡散型 目標喪失型 猪突猛進型 概要

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

UIデザイン・プログラマーの話を書いたときに、何人かの方からそもそもUIデザイン・プログラマーはプログラマーではないのではないかという指摘をいただいた。 プログラムが書けるデザイナー 今となっては信じられないことだが、HTMLが普及し始めたばかりの頃にはHTMLを書くのはプログラマーの仕事で、その素案を作るところまでがデザイナーの仕事だった時代がほんの少しだけあった。すぐにデザイナーがツールの活用やスキルの習得によってHTMLを自分で書くようになって、動きのないWebページのデザインはデザイナーが、掲示板のようなCGIプログラミングが必要な箇所はプログラマーが担当するようになった。そしてさらにその後すぐに、JavaScriptやCGIを自分で書くことができるデザイナーが現れた。 ユーザビリティ・デザインの対象範囲 ソフトウェアの手触りをデザインする際には、静的な画面デザインだけでなく、ユー

小学校四年生の頃だったろうか。 毎週決まった曜日に、 10点満点の漢字テストがあった。 連休明けか何かでテストのことをすっかり忘れていた私は、 これまで9点か10点しかとったことのなかったテストで、 0点をとった。 親に言うことはできなかった。 答案用紙が返される日に 母親から結果を聞かれて、 漢字のテストはなくなったと答えた。 赤い文字で0点と書かれた答案用紙を 家に持って帰ることができず、 学校のごみ箱にも捨てることができず、 くしゃくしゃに丸めて教室の自分の机の奥にねじ込んだ。 答案用紙が返される日が来るたびに、 机の奥は、押し詰められた0点の答案用紙で一杯になっていった。 もうみんなに追いつけない。 踏み外してしまった。 自分だけ置いていかれてしまった。 道をはずれてしまった。 取り返しのつかないことになってしまった。 私は勉強をしない子供になった。 次第に他の教科でも手を抜くよう

今週は外出が多く、社内にいる時間がほとんどない。 普段とペースが違うためか、ここ数日、生活の基本的なレベルでの調子が狂い気味である。 一昨日は都庁から都庁前駅にたどり着くまで20分もかかったし、 今朝は気づいたらシャンプーで顔を洗っていた。 一つのものしか知らないと、 それ以外のものを目の当たりにしたときに、 こんなことも知らないのかと相手を馬鹿にしたり、 目くじらを立てて怒ったり、 そういう風に行動してしまいやすい。 自分が許せないと思うことは他の人も許せないと思ってくれる。 集まりの中で常識とすべきこととそうでないこととが峻別されていくにつれ、 それらを共有できる人たちにとっての心地よさはさらに高まり、 時として最後まで残ったものがビジョンや哲学となる。 これは自然なことだ。 しかしこのような心地よさが、 常識を共有できない相手に対する排他的な態度につながってしまうこともある。 そして

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

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

1976年生まれ。1999年慶應義塾大学環境情報学部卒業後、同年サン・マイクロシステムズ株式会社に入社。入社後まもなく米国 Sun Microsystems, Inc での開発を経験し、2000年より株式会社アプレッソ代表取締役に就任、データ連携ミドルウェア DataSpider を開発する。2002年には DataSpider が SOFTIC ソフトウェア・プロダクト・オブ・ザ・イヤーを受賞。2004年度未踏ソフトウェア創造事業 Galapagos プロジェクト共同開発者。2007年〜2010年日経ソフトウェア巻頭連載「小野和俊のプログラマ独立独歩」執筆。2008年〜2011年九州大学大学院「高度ICTリーダーシップ特論」非常勤講師。2013年よりセゾン情報システムズ HULFT事業CTO、2014年 CTO、2015年 取締役 CTO、2016年 常務取締役 CTOを務め、2019年

昨夜はシリコンバレーで会社を営みながらいくつもの会社の顧問や社外取締役をつとめているスーパーマリオ似のNさんと飲んだ。50半ばにして10代の若者のようなバイタリティー。経験豊富なだけあって実に話がおもしろい。 曰く、 アメリカ人はすぐミス・ユニバースなどと言う。 日本人は謙虚だから No.1 を宣言するとしてもせいぜいミス・ジャパンである。 ユニバースという言葉は国や地球や銀河系を超えて全宇宙を含むので、 せめてミス・ギャラクシーくらいにしないと他の星雲の人たちが怒ってしまうのではないか。 そんな冗談のような話を真顔でしながら、 彼はこうも言った。 すぐにミス・ユニバースを目指すアメリカ人の気質があってこそである。 狭い範囲で No.1 を目指すことと、 はじめからユニバースの中での No.1 を目指すこととは根本的に違う。 人も組織もやり方も給与体系も短期計画も中長期計画も、何もかも違う

昨日から関西に出張で、 朝の新幹線に遅刻しそうだったのでタクシーに乗った。 「東京駅まで、9時20分の新幹線に乗りたいので急ぎ目でお願いします。」 50歳近くの運転手は最近運転手になったばかりなのだろうか、 この近辺の地理に詳しくないらしく、 前に進むべきところを突然Uターンしたので どのような行き方をするつもりなのだろうかと思っていたら、 歩いて5分でたどり着くはずの飯田橋までぐるぐる回って7,8分かけてたどり着き、 そこから東京駅に向かった。 乗客が急いでいるのに道がわからず焦っているのが後ろから見ていてもわかる。 いつもそうすることにしているのだろう。 運転手はガムをどうぞ、4種類ありますがどれがお好きですかと聞いてくる。 ではこれをと答えると、 ペンギンのマークがついてますね、ペンギンのマークがついている場合には飴もと言って、 わからない道を右手一本でハンドルを切りながら、 前を見

1. 勝てないと感じている相手に鋭い指摘をされたとき プライドが高い人に起きやすい。 この手のケースでは論理的にカッとなるから手に負えない。 実はお互いに勝てないと感じていたりするともうゴジラ対キングギドラである。 口から絶え間なく吐き続けられる燃えさかる言葉の炎。 2. 対応能力のキャパシティを超えた事態が発生したとき パニックになって周囲に当たり散らす。 逆に卑屈になって極端に低い姿勢で謝り続けることも。 周囲から見ていると別に大したことじゃないのにと思えてしまうことが多い。 怒りの炎は引火する。 昨日あいつがあんなに怒っていたじゃないか。 だから今の俺の怒りだって抑えずに爆発させてしまっていいのだ ムカーッ！ 連鎖する怒りの垂れ流し。 4. 極度に忙しくてカリカリしているとき 自分の作業が遅れているだけなのに他の人も道連れにしようとしたりする。 暗黙に自分の仕事が終わるまでみんなを帰

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

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

今週末は熱海の温泉に行ってきた。 行き帰りの新幹線で読んだJoel on Softwareは衝撃的に良かった。 この本はソフトウェア開発に携わるすべての人が読むべき本だと真剣に思う。 中でも第三章に書かれているジョエルテストが面白かったので、 これをアプレッソに当てはめて判定してみることにした。 現在のアプレッソでは、12のテストのうち、10項目が当てはまっている。 該当する項目が2から3の会社が圧倒的に多いということなので、 判定結果としてはかなり良い方だと思う。 しかし、今は導入した後でその効果を知っているから全面的に賛成できるのだが、導入する前は、 「今のままで特に大きな問題があるわけでもないし、 新しい方法を導入することにはリスクも伴う。 このままでも良いのではないか。」 という理由で導入を躊躇したものも多かった。 これらはどの項目についても、マネージャーがどんなに反対したとしても

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