トラックバック一覧 1. バグはいつか仕様に変わる？ [地方で活動するweb制作者の日々を綴るblog] 2007年07月18日 14:25 「バグは夜更け過ぎに仕様に変わるだろう」 というのは、IT屋さんの中では有名な格言らしいのですが（私は知りませんでしたが）、その全文版を公開したそうです。 業界の人なら受けること間違いなし。 そして、現実と照らし合わせてぞっとすることも間違いなし。 IT 業... 2. 2007年7月18日　1907年はこんな時代 [神戸の三代目] 2007年07月18日 20:04 またヤフー株が米国につられて下げてる・・。誰かアナリスト、ちゃんと指摘してよー。ネタ加藤一二三九段伝説　前も書いた気もするけど、加藤一二三が凄い（というか面白い）。　一芸に秀でている人はぶっ飛んでいる人が多 3. [研究室][雑記] [Gabari] 2007年07月18日 20:22

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

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

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

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

先日某所で講演をする機会があったのだが、 そこでお会いした大企業に所属されている方からの発言でいくつか印象的なものが あったので、ブログに書くことにした。 中にはぐったりしてしまうような内容のものもあるのだが、 会社が大きくなるとこういうことが起こりえるのだという自分への戒めも込めて。 とある大手 SI の方の話。 会社で 2ch へのアクセスを禁止したところ、開発の速度が目に見えて低下したので、 何が起こったのかと現場にヒヤリングしたところ、今までは困ったときに 2ch で聞いて問題を解決していたが、2ch にアクセスできなくなって、 はまってしまったときにどうにもならなくなってしまったとのこと。 これは Messenger / Skype を禁止している会社にも同様のことが言えるだろう。 プロが 2ch で聞くというのはどうなのかという意見もあるとは思うが、 会社の枠を超えた横のつなが

この半年ほど Ruby を使っていて思うのは、コーディング量が少なくてすむし、プログラム言語的な手触りが良いし、まず作ってみてどれくらい感動できるソフトなのかを確認しながらソフトウェアの仕様自体を見直してスパイラルでつくっていくという開発プロセスも取りやすいし、ライブラリも揃ってきているし、Ruby on Rails のバランス感覚はすばらしいし、といったことである。そういう意味では大絶賛なのである。 それでも、普段 Java をメインで使っていて、時々 Ruby にスイッチすると顔をしかめてしまうような猛烈なストレスに襲われるのは、標準的で、無料で、安定しており、好みに合わせてカスタマイズでき、リファクタリング機能 *1をサポートした IDE が存在しないからである。 もちろんこれは言語そのものの問題ではないが、結果的には、使用する言語を選択する際に、要求の変化などの外部的な変化には強く

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

大学の研究室の教官は昔NTT研究所の所長をされていた苗村先生という人で(と言いつつ私は大学の研究室にほとんど顔を出していなかったのだけれど)、彼の発言のうち印象に残っているものの一つとして、昔はソースコードのコメント率が50%を切るものはドキュメント不足で品質が低いものとされた、という内容のものがあった。 今、改めて考えて、どのような言語であってもどのようなコーディング規約であっても、私はソースコードのコメント率は原則20%を切ることが望ましいと思う。可読性の意味でもメンテナビリティの意味でも、開発生産性の意味でも。私が考えるに、本来コンピュータが読むためのものであるソースコードに人が読むためのコメントを付け加えなければならないのは、次の２通りの場合だけである。 1.公開されるAPI APIやソースコードそのものが公開される場合、利用者は不特定多数となり、利用者のスキルにもばらつきが出て、

分裂勘違い君劇場 - 優秀な人材に変身するキッカケに出会うか、未熟なまま老いていくかで述べられている内容について。 intelligent ではあるが wise ではないために今一アテにできない、という人にはいくつもの心当たりがあって、そういう人とうまく仕事をしていくことができなかった頃のもどかしさが蘇って来るようで、古傷に指を入れてこじ開けられるようで読み進めるのが辛かった。 一方で考えなければならないのは、物事を大きく変えるような提案というのは、実は往々にして、intelligent だけれども wise ではない人たちから出て来ている、ということである。 wise ではない人の意見は、第一印象として、マネージャや周囲の人たちから見てムッとする意見であることが多い。そのネガティブな反応の内訳は、ただでさえやることが山積みなのに新しい方法の導入を提案することに対する反発であったり、誰も問

私はその戦略をラストマン戦略と呼んでいる。 大学を卒業してサン･マイクロシステムズに入社してすぐにわかったことは、Java を生み出した会社でソフトウェア開発をやろうと思って入社したのに、日本サンはソフトはほとんどやっておらず、ほぼ100%ハードウェアを販売するための会社だったということだった。 野菜を売りたくて八百屋に入ったつもりなのに、間違えて肉屋に入ってしまった。このようなときにどのように行動すればよいか？ 1. 肉屋に入ったのだから、とりあえず肉屋を目指す 2. 八百屋への転職活動を開始する 3. 肉屋の中で野菜についての No.1 を目指す 一番多いのはパターン1の人で、入社の直前直後は熱くソフトウェア開発を語り合った同期の多くは、今ではハードウェアのスペシャリストへの道を目指している。 ラストマン戦略とは、ある所属組織内で自分が一番(最後に立っている人 = ラストマン)になれそ

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

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

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

AdSense や各種アフィリエイト、オークションサイトが登場したことで、 物を書く人や情報提供サイトを運営する人、個人で物を仕入れて販売する人たちは 今までにないまったく新しい仕事の仕方の選択肢を手に入れた。 会社に所属したり会社と契約したりしなくても、 コンテンツやサービスを提供したり、 個人で仕入れた物品をネットで販売したりすることによって、 それだけで十分に生活することができる収益を手にする人が出てきている。 会社に勤務しながらも、 個人でのネットでの収入が家計のポートフォリオの中で無視できない 位置を占めてきている人もすでに数多く存在する。 賃金水準が相対的に低い国では、 AdSense による収入が天から舞い降りた奇跡のように扱われているという。 日本でもネットでの収入で毎月数百万円を稼ぐ人があらわれてきている。 これらのネットで提供される仕組みは、 個人が企業で働く意味を改め

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

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

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

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

ひとことで言えば、「レビュー文化は良くない」ということになるだろうか。 Slack導入、そして同時期に開始した服装の自由化、バイモーダルという考え方の浸透、AIやブロックチェーンを活用したPOC等の取り組みによって、SIerとしてのセゾン情報システムズは、社内の雰囲気もずいぶんと変わってきた。 しかし、こうした取り組みだけではどうにもならないものも少なからずあった。 そのひとつは、「悪い報告がしづらい」ことだった。 これは他のSIerでも同様のことが多いのではないかと思うが、問題プロジェクトに認定されると、品質管理部のモニタリングが強化されたり、第三者によるプロジェクト監査が始まったり、経営会議での定期的な報告が求められたり、何をやっているのかとレビューでこっぴどく叩かれたり、、、。 そうした責任感から、遅れをキャッチアップできるよう少しでもがんばろう、と励まし合う中で、それなのに四方から