そして、新規にメールを作成しようと、メールのメールの宛先に sato@some... と入力していくと、アドレスが自動補完されて「株式会社△△佐藤 <sato@somecompany.com>」となってしまい、tanaka@somecompany.com に至っては「弊社田中 <tanaka@somecompany.com>」になってしまう。 英語圏ではファーストネーム + ラストネームが一般的なのでこれでも問題ないが、日本語圏では「様」とか「弊社」といった文字が使われていることが多いので、このままでは次のような失礼なメールになってしまう。 しかも、名前の部分を削除してメールアドレスだけにしようとしても再度補完されてしまうため、この問題を解決するには、アドオン無しのデフォルトの状態では、アドレス帳を失礼のないように手作業で変更するか、自動補完機能をオフにするかしかない。手作業で一つ一つのア

諸君 私はプログラミングが好きだ 諸君 私はプログラミングが好きだ 諸君 私はプログラミングが大好きだ 設計が好きだ 実装が好きだ デバッグが好きだ コンパイルが好きだ リファクタリングが好きだ パフォーマンスチューニングが好きだ ペアプログラミングが好きだ クラスの名前を考えるのが好きだ 自分が書いたソースを眺めるのが好きだ Java で C で C++ で C# で Perl で Ruby で PHP で Python で Lisp で VB で この地上で行われる ありとあらゆるプログラミング行為が大好きだ 轟音と共にバグを吹き飛ばしていくのが好きだ 空中高く放り上げられたバグが 効力射でばらばらになった時など心がおどる プログラマーの操る キーボードが コンパイルエラーを撃破するのが好きだ 悲鳴を上げて 燃えさかるソースコードから飛び出してきたエラーを テキストエディタで薙ぎ倒した

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

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

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