エンジニアの幸せ

エンジニアにとっての幸せとは何だろうか。一般的には、エンジニアとは何かを作る人だ。橋を作る人、ビルを作る人、電子機械を作る人、ソフトウェアを作る人、これらは皆エンジニアだ。よって、創造の喜びというのがひとつの答えとなるのではないだろうか。

一方で、世の中には、何も作りはしないけれども、エンジニアと同じように高度な専門技術を持っている人たちもいる。医者や弁護士やコンサルタントだ。このような人たちにとっての仕事をとおしての幸せは何だろうか。私は、技術の行使がその答えだと思う。

後者の人たちの仕事は、顧客あるいは患者から持ち込まれた問題を解決することだ。なぜ彼らのところに問題が持ち込まれるかというと、そのような問題の解決には高度な専門技術を要するからだ。問題解決者としての彼らの興味は、自らの専門技術を行使していかに困難な問題を解決するかという点に注がれるのではないかと思う。難しい問題ほど挑戦し甲斐があり、あるいは珍しい奇妙な問題には面白みがあることだろう。

私は、エンジニアにとっても技術の行使が幸せになりうると思う。土木技師にとって、溝を掘るのと橋を建設するのとでは、後者の仕事のほうがより幸せだろう。それは恐らく、何かを作るにしても後者のほうがより困難な問題であり、解決のためにより高度な技術を行使しなければならないからだ。

私はソフトウェアの世界で仕事をしているが、エンジニアの何かを作るという側面に執着しすぎている人、創造の喜びを追い求めすぎている人に出会うことがある。そのような人たちは、既存のシステムの拡張やレガシーなシステムのメンテナンスのような仕事を嫌う。そのような人たちは、常にゼロから自分の手で何かを作り上げたいと思っている。

そのような態度が悪いとか間違っているということはない。しかし、そのような人たちには、少し視点を変えて、技術の行使という側面に注目すると仕事の幅が広がるかも知れないよ、と教えてあげたい。一見創造的でない仕事でも、そこに何か技術的な困難さを見出すことができれば、それは技術の行使の機会であり、そこから幸せを得ることはできるのだ。

私は開発からサポートに移ってきた人間で、最近は仕事で何かを作るということはなくなってしまった。今、私が仕事で幸せを感じるのは障害対応だ。デバッグは本質的に難しい。カーニハンが言ったように、デバッグはコードを書くより3倍難しいのだ。デバッグからは創造の喜びを得ることは出来ないかも知れないが、高度な技術の行使という喜びを得ることはできる。困難なバグは私の技術への挑戦と心得ている。

結局、何かを作る人というのは、エンジニアの定義として狭すぎるのだろう。エンジニアとはエンジニアリングの専門家であり、医者や弁護士の仲間なのだ。技術の行使のひとつの形態として、たまたまエンジニアは何かを作る場合があるに過ぎないのである。

名探偵の秘密

ソフトウェアのカスタマーサポートという仕事をしていると、顧客から様々な問題が持ち込まれてくる。

先日取り組んでいたのは、カーネル内のある構造体のメンバ変数の不整合によりカーネルパニックが発生してしまうという問題だった。この手の障害解析には問題の再現環境を作ることが重要だが、顧客の開発部門での数カ月の努力にもかかわらず再現させることができず、製品のリリース時期が迫ってきたため私のところに持ち込まれてきたのだった。

私は3日ほどで再現プログラムを作ることができたが、このことに顧客の担当者は大変驚いたようだった。しかし、種明かしをすると、この問題はそれほど難しいものではなかった。この手のデータの不整合の原因としては、そのデータに関して何らかの競合状態が発生しているという場合が多い。そこでソースを見てみると、不整合の起きている構造体のメンバ変数は少し特殊な使われ方をされており、そのような競合状態の発生する可能性は1つしかないことがわかった。この時点で原因はわかったようなものなのだが、確認のためにアプリケーションからのAPI呼び出しでそのような状況を作ってみると見事に再現できた。

少し前のことだが、別の顧客で、アプリケーションを最適化オプションを有効にしてコンパイルするとある処理が遅くなってしまうという問題を扱ったことがある。原因は、最適化オプションの有無でその処理が読み書きするデータの配置されるアドレスが変化することにより、ページフォルトの発生状況が変化するというものだった。この問題には少し悩んだが、コードではなくデータが原因という視点が得られれば解決は容易かった。この問題も、種明かしをすると単純明快だ。

世界で最も有名な名探偵といえばシャーロック・ホームズである。物語の中で繰り返し出てくるエピソードとして、ホームズのもとを訪れた依頼人の職業を言い当ててしまうというものがある。最初、依頼人やワトソン博士は大層驚く。そこでホームズが種明かしをすると「何だ、そんなことですか」と言われてしまい、ホームズはがっかりしてしまう。ホームズは依頼人の服装や靴についた傷跡などから推理しているのだが、その推理の過程を説明されれば何も難しいことはない。

私はエンジニアとしての教育を受けたが、私の今の仕事はむしろシャーロック・ホームズの範疇に属すると思っている。私の仕事は、証拠を集め、推理し、真実を明らかにする。そして顧客に報告すると(つまり種明かしをすると)、決まって「何だ、そんなことですか」と言われ、私はがっかりしてしまうのだ。

私の顧客の中には、カスタマーサポートとはなんと簡単な仕事なのだろうと思う者もいるかもしれない。しかし私は、自分の仕事は十分に困難で、高度な技術を要求され、チャレンジのある仕事だと思っている。ただし、私の仕事は、何かものを作っている普通のエンジニアとはその性質が少し異なるかもしれない。ホームズがタバコの灰からその銘柄を言い当てることができるように、私の仕事ではメモリのダンプからプログラムの状態を言い当てることができなければならない。

実は、私の子供の頃のヒーローはシャーロック・ホームズだった。小学校の図書館で子供向けのホームズ物語を借りて読んだものだった。私は本物の探偵にこそならなかったが、カスタマーサポートと呼ばれる「ソフトウェアの探偵」になることができた。私の仕事には殺人事件のようなドラマはないが、カーネルパニックという「ソフトウェアの死」は私の専門である。

ついに問題の尻尾をつかんだとき、私はいつも自分をホームズに重ね合わせる。さあワトソン、獲物が飛び出したぞ!

ダウニーカフェの思い出

藤沢に住んでいた頃、ダウニーというカフェがあった。アメリカンスタイルのハンバーガーがウリだったが、サンドイッチやパスタも素晴らしかった。ケーキも手作りで、種類も多く美味しかった。ケーキだけを買って帰るというお客さんも多かった。

私も週末のお昼にはよく通ったものだった。ランチタイムに行くと大変混雑しているので、あえて少し早めか少し遅目を狙って行ったものだった。

あるとき、ダウニーが閉店してしまった。マスターがしんどくなってしまったらしい。伝え聞いたところによると、「二度と飲食はやらない」と言い残して去って行ったということだった。

マスターは物静かなおじさんで、いつもは調理場にいた。接客はアルバイトの若者にまかせていたが、お店が暇なときは接客してくれることもあった。

仕入れから調理まで、すべてマスターひとりでやっていたということだった。ハンバーガーもケーキも全部ひとりで。すべてが卓越した仕事だった。すべてのメニューにおいて、街のカフェのレベルを超越していた。

素晴らしい仕事をすることはできる。しかし、それですべてがうまくいくという訳ではない。ダウニーの場合は、マスターを支えてあげられる誰かが必要だったのかも知れない。マスターはカフェ界のスーパーマンだったのかも知れないが、スーパーマンには相棒が必要だ。

その後、私は東京に引っ越してきた。オシャレなカフェをよく見かける。悪くはないが、ダウニーにはかなわない。マスターは今何をしているのか知らないが、私の思いとしては、どこかでまた素晴らしいカフェをやっていてほしいと思う。今度はしんどくならない方法で。

ハックは遍在する

数年ぶりにポール・グレアムの『ハッカーと画家』を読みなおした。この本が出版されたのは2005年。当時大学院の修士1年生だった私は、就職活動のための新幹線での移動中にこの本を読んでいた。

あれから10年経った。紆余曲折あって、今は組込みOSのテクニカルサポートという仕事にありついた。10年前の私がそれを知ったらきっとこう思うだろう。テクニカルサポートなんて、全然ハッカーじゃないみたいじゃないか。

もしかすると、テクニカルサポートという仕事を聞き慣れない人もいるかも知れない。難しい仕事ではない。要はデバッグ屋である。障害解析というもっと格調高い言い方もあるが、私はデバッグ屋という方が気に入っている。障害解析なんて、全然ハッカーじゃないみたいじゃないか。

この仕事のコツは、遊び心と知的好奇心を持って事に当たることだ。組込み向けとはいえ数百万行(Linuxに比べれば楽勝だ)という規模のソフトウェアの蓋を開けて中を覗かなければならない。Linuxの仕事が来ることもあるが、こちらは最後に数えた時は1700万行程度だった。いずれにせよ、普通の人なら圧倒されてしまうだろう。

ハッカーと画家』の中で、ポールは3つのことを強調している。プログラミングとベンチャーLispだ。言い換えると、ハッカーとは、ベンチャー企業で働いていてLispで何か新しいキラキラしたものを作るプログラマのことだ。

私も10年前にはそう思っていた。だが、私もエンジニアとしての経験を積み、その考えも変わってきた。ベンチャー企業で働いていなくても、Lispでプログラミングをしていなくても、そしてプログラマでさえなくても、ハッカーとそのセントラルドグマであるハッカー精神は存在しうるのではないか。

ハッカーとは単なるプログラマではない。ハッカーとは、情熱と創意工夫とによって知的に高度な難問に取り組むことに喜びを感じる人のことである。難問への回答が計算機プログラムという形式を取るとき、ハッカープログラマである。

この1週間ほど、特定のCPUアーキテクチャに依存するメモリバリアに関するちょっと面白い問題を追っている。この手の問題は、ソースコードだけを見ていてもわからない。CPUの気持ちになって考えることが肝要だ。これぞハックだと思った。

日本におけるOS研究のパイオニア、高橋延匡先生は、OSの設計者はオーケストラの指揮者であると仰った。デバッグ屋としての私の仕事は、不協和音を奏でるようになったオーケストラに、再び美しいシンフォニーを演奏させることである。これは大変な難問である。

最近の私は、プログラミングをする機会はめっきり減ってしまった。最近書いたプログラムはEmacsのちょっとしたカスタマイズコードである(私はちゃんとLispを使っている)。それでも、私の日々の仕事は知的に高度な難問でいっぱいだ。そういう仕事に取り組むとき、私はハッカーになるのである。

ハックは遍在する。あらゆるところに。

明日のための仕事

本日をもってミラクル・リナックスを退職する。2年半という短い間だったが、たくさんの方々にお世話になった。お礼を申し上げる。

私のミラクルでの仕事を振り返ってみると、最大の貢献と言えるものはLinuxに関連することではなかった。エンジニアリングですらなかった。それは人に関連することだった。すなわち、若者の育成であった。

仕事を行う者にとって、学校を卒業して最初に入る会社は重要である。最初に入った会社で、仕事を行う者としての価値観を築く。仕事のやり方を覚える。それはその人の職業人生をとおして大きな影響を与える。

私は、三菱電機でエンジニアとしてのキャリアをスタートさせた。私の配属された鎌倉の古い工場は私の原点である。私はいつでもそこへ戻ることが出来る。私のエンジニアとしての精神的バックボーンは今も鎌倉の工場にある。

私がミラクルへ入社した年は、ミラクルが本格的に新卒採用を始めた年でもあった。ミラクルでは、驚くほど新卒を受け入れる体制ができていなかった。学校を卒業して最初に会社に入る者への責任を果たしていなかった。

その年入社した女性には、最初の1年は非常につらい思いをさせてしまった。先輩たちはただ見守ることすらできなかった。見守るということを知らなかった。彼女は今では立派なエンジニアに成長したが、これは100%彼女自身の努力によるものと言ってよい。

明らかに改善の余地があった。そこで私は、人事部門と協力して若者のメンター制度を構築することにした。これは、三菱電機で私を教育してくれた人たちへの恩返しのつもりでもあった。

この制度の特徴は、若者の後見人としてのメンターと、OJTで実務を教えるプロフェッショナルとしてのトレーナーを明確に区別することにあった。若者は様々な仕事を行わなければならない。それぞれの仕事にトレーナーが存在する。しかし、仕事を行う者としての若者の成長には一貫してひとりのメンターが責任を持つ。

この制度のモチベーションとしては、日々の多様な業務に流されて、ただ慌ただしく時間が過ぎ去らないようにとの配慮がある。様々な業務を行う中で、自分を見失うことなく着実に成長し、価値観を築き、精神的バックボーンを築いて欲しいとの意図である。

もちろん、この制度がベストだとは思っていない。この制度はまだ時の試練を受けていない。これから何年も運用して改善していかなければならない。

今日の仕事を行うのは我々の責任である。しかし、明日の価値を作り、明日の仕事を行うのは若い人たちである。したがって、人材の育成はそれ自体が価値をもつ成果であると言ってよい。今日の仕事として、明日を担う若者を育成しなければならない。

社会人として

ここ数年、私が使うのを避けている言葉がある。「社会人」がそれである。この言葉は、「社会人として〜」という使われ方をする。人が(私も人である)「社会人として〜」と言っているとき、この「社会人」とはいったい何を意味するのだろうか?

「社会人」こそ無意味な思考停止キーワードである。それは、「サラリーマン」と言っているのと同じ程度の意味しか持たない。試しに、「社会人として〜」を「サラリーマンとして〜」に置換してみるがよい。その言葉があまりにも何も定義しないことに驚くだろう。

「会社に遅刻をしてはいけないよ」と、私はよく上司に言われたものだ。まだ若く世間知らずだった私は、当然の疑問として「なぜ遅刻をしてはいけないか?」と問うた。上司の答えは「社会人として」だった。若者は(私も若者だった)これでは納得しない。

この上司は、「遅刻をすると約束の相手の時間を無駄にすることになる。誰もが他人の時間を無駄にし始めたら、誰も仕事を行うことはできない。現に今、あなたはこうして私の時間を無駄にしている」とは言わなかった。

もし、この上司がこう答えていたならば、私は追求の第二弾に出ただろう。「では、誰の時間も無駄にしないのであれば遅刻をしてもよいのか?」と。

私はまだこのときの上司の年齢には及ばないが、それでも後輩を指導しなければならない立場にはなった。私も後輩から追求の第二弾を受けるかもしれない。「社会人」などという無意味な思考停止キーワードを使わないように準備しておかなければならない。

こう答えよう。「そのとおりである。本当に誰の邪魔もせず、かつ仕事ができるのであれば、会社に来る必要もなく、したがって朝起きる必要も、布団から出る必要さえない」と。ただし、「あなたにはそれが出来るのか?」と付け加えることを忘れない。

遅刻をした若者に注意を与えるとき、大抵の人はここまで考えてはいない。なんとなく、皆が同じ時間に会社に来ているからあなたも(そして私も)そうしなければならないという程度にしか考えていない。そういうとき、つい「社会人」という言葉を使ってしまう。

他にも「社会人」という言葉が出てくる場面はたくさんある。忘れ物をするな、小奇麗にしろ、飲み会で上司にお酌をしろ云々。要注意である。これらは実に些細なことであるが、しかし人が思考停止に陥る典型的パターンである。

我々は仕事を行う人間として働いている。仕事を行うことこそ使命である。我々は単なる「サラリーマン」でないのと同様に「社会人」でない。

私は、まったく会社に出社せず、メールだけで仕事をしている人物を知っている。しかし、誰かが、この人物を「社会人」でないと批判しているのを聞いたことはない。その人物は確かに仕事を行うことができ、それで十分である。

あと1ヶ月ほどで「新社会人」が我々の仲間に加わることとになる。企業とは、学校とはまったく違う性質を持つ組織である。彼らは、かつての私がそうだったように、最初は大いに戸惑うことだろう。その時、私は「社会人」などといういい加減なものではなく、本当に仕事を行う人間としてよき手本となりたい。

若いエンジニアへ

エンジニアなら誰でも突貫工事に喜びを見出した経験がある。深夜2時の夜食を共にした同僚のことは、その職業人生を通じて忘れることはない。しかし、そこにいかなるドラマがあろうとも、突貫工事は例外である。これを常態としてはならない。

メーカーの組込みプログラマとしてエンジニアのキャリアをスタートした私は、「よい製品はよいプロセスから生まれる」ことを頭に叩きこまれた。素晴らしい製品を生み出す工場は静かである。常に誰かが大声で叫んでいるような工場には明らかにプロセス上の問題が認められ、素晴らしい製品を生むことは決してない。

本物のエンジニアは突貫工事を好まない。突貫工事とはプロセス上の誤りであり、つまり誰かが大声で叫ばなければならないということだからである。エンジニアの仕事は計画され、コントロールされたものでなければならない。

長時間労働によって成果を生み出そうとすることも、やはり例外としなければならない。長時間労働もプロセス上の誤りである。長時間労働とは「体力勝負」の世界であり、技術の専門家たるエンジニアの地位を貶めるものである。

エンジニアの創造性を引き出すものは、長時間労働ではなく集中である。誰もが知っているように、集中とは1日18時間持続するものではない。普通の人は2, 3時間がせいぜいである。

どうすればこのわずか2, 3時間の集中に入れるのかを知る者こそ本物のエンジニアである。ある人にとっては深夜や早朝かもしれない。朝メールをチェックして、お気に入りのWebサイトを見て回ったあとでないと集中できないという人もいる。

かつて、NHKで「プロジェクトX」という人気番組があった。そこで紹介されるプロジェクトは、ほとんどすべてが突貫工事と長時間労働のドラマだった。視聴者に、あたかも、突貫工事と長時間労働こそが素晴らしい製品を生み出すかの誤解を与えるものであった。

あの番組を見て違和感を覚えたエンジニアは多いはずだ。私が駆け出しのエンジニアの頃上司から受けたアドバイスは、あのような番組を真に受けるなということだった。メーカーを退職した今でも、私は「よい製品はよいプロセスから生まれる」というこのコンセプトが正しいと思っている。

若いエンジニアには、よいプロセスは退屈に見えるかもしれない。しかし、本物のエンジニアにとっては、日々の秩序の中にこそ素晴らしいドラマがあるのである。