はてなブックマーク

ソフトウェアのカスタマーサポートという仕事をしていると、顧客から様々な問題が持ち込まれてくる。 先日取り組んでいたのは、カーネル内のある構造体のメンバ変数の不整合によりカーネルパニックが発生してしまうという問題だった。この手の障害解析には問題の再現環境を作ることが重要だが、顧客の開発部門での数カ月の努力にもかかわらず再現させることができず、製品のリリース時期が迫ってきたため私のところに持ち込まれてきたのだった。 私は3日ほどで再現プログラムを作ることができたが、このことに顧客の担当者は大変驚いたようだった。しかし、種明かしをすると、この問題はそれほど難しいものではなかった。この手のデータの不整合の原因としては、そのデータに関して何らかの競合状態が発生しているという場合が多い。そこでソースを見てみると、不整合の起きている構造体のメンバ変数は少し特殊な使われ方をされており、そのような競合状態の

エンジニアにとっての幸せとは何だろうか。一般的には、エンジニアとは何かを作る人だ。橋を作る人、ビルを作る人、電子機械を作る人、ソフトウェアを作る人、これらは皆エンジニアだ。よって、創造の喜びというのがひとつの答えとなるのではないだろうか。 一方で、世の中には、何も作りはしないけれども、エンジニアと同じように高度な専門技術を持っている人たちもいる。医者や弁護士やコンサルタントだ。このような人たちにとっての仕事をとおしての幸せは何だろうか。私は、技術の行使がその答えだと思う。 後者の人たちの仕事は、顧客あるいは患者から持ち込まれた問題を解決することだ。なぜ彼らのところに問題が持ち込まれるかというと、そのような問題の解決には高度な専門技術を要するからだ。問題解決者としての彼らの興味は、自らの専門技術を行使していかに困難な問題を解決するかという点に注がれるのではないかと思う。難しい問題ほど挑戦し甲

エンジニアなら誰でも突貫工事に喜びを見出した経験がある。深夜2時の夜食を共にした同僚のことは、その職業人生を通じて忘れることはない。しかし、そこにいかなるドラマがあろうとも、突貫工事は例外である。これを常態としてはならない。 メーカーの組込みプログラマとしてエンジニアのキャリアをスタートした私は、「よい製品はよいプロセスから生まれる」ことを頭に叩きこまれた。素晴らしい製品を生み出す工場は静かである。常に誰かが大声で叫んでいるような工場には明らかにプロセス上の問題が認められ、素晴らしい製品を生むことは決してない。 本物のエンジニアは突貫工事を好まない。突貫工事とはプロセス上の誤りであり、つまり誰かが大声で叫ばなければならないということだからである。エンジニアの仕事は計画され、コントロールされたものでなければならない。 長時間労働によって成果を生み出そうとすることも、やはり例外としなければなら

数年ぶりにポール・グレアムの『ハッカーと画家』を読みなおした。この本が出版されたのは2005年。当時大学院の修士1年生だった私は、就職活動のための新幹線での移動中にこの本を読んでいた。 あれから10年経った。紆余曲折あって、今は組込みOSのテクニカルサポートという仕事にありついた。10年前の私がそれを知ったらきっとこう思うだろう。テクニカルサポートなんて、全然ハッカーじゃないみたいじゃないか。 もしかすると、テクニカルサポートという仕事を聞き慣れない人もいるかも知れない。難しい仕事ではない。要はデバッグ屋である。障害解析というもっと格調高い言い方もあるが、私はデバッグ屋という方が気に入っている。障害解析なんて、全然ハッカーじゃないみたいじゃないか。 この仕事のコツは、遊び心と知的好奇心を持って事に当たることだ。組込み向けとはいえ数百万行（Linuxに比べれば楽勝だ）という規模のソフトウェア