サイボウズ・ラボの西尾 泰和さんが「エンジニアの学び方」について探求していく連載の第4回（毎週火曜日に掲載、これまでの連載一覧）。
富士通のエンジニアとしてLinuxカーネルの開発に参加されている小崎資広さんへの「インタビュー：その3」。Linuxカーネルという巨大なソースコードと日々戦っている小崎さんのお話は、きっと「エンジニアの学び方」の参考になるはずです。
本連載は、「WEB+DB PRESS Vol.80」（2014年4月24日発売）に執筆した「エンジニアの学び方──効率的に知識を得て，成果に結び付ける」の続編です。（編集部）
前回はコードリーディングの手法をどうやって習得したのかについて伺いました。今回は「どうしてLinuxカーネルを学んでいこうと思ったのか」というところを深堀りしていきたいと思います。
Linuxを選んだのは前向きな理由じゃないんですよ
小崎さんがどうしてLinuxを学んでいこうと思ったのかを聞きたいと思います。なぜかというと「何を学んだらいいのかが分からない。決められない」という人が多いからなんです。小崎さんはどこかの時点で「自分はLinuxが得意」と認識され「だからLinuxをもっと学んでいこう」と思ったのだと……（小崎さんの表情を見て）……あれ？ 違う？
違う。たまたま仕事でLinuxをやっていて、OSの専門家がいなかったから、自分で解決しないといけなかったんですよ。きっかけになったエピソードを話しましょう。製品開発で組み込みのブラウザを開発していて、めっちゃ遅いんだけど何が原因か分からないってことがあったんです。で、全員が呼び出されて「自分の担当範囲をレビューし直して間違いを見つけろ」と指示されたんです。僕はそのときにすごく納得いかなかった。「間違えたやつが自分で見直して分かるわけないじゃん」って思ったわけです。そこで自分の与えられた仕事を完全ブッチして、Linuxカーネルのプロファイラを作り始めたんです。
遅い原因を特定するためのツール（プロファイラ）を作り始めた、と。
当時はx86だとoprofileっていう良いプロファイラがあったんですけれども、組み込み専用CPUだとそういうのが一切なかった。ないからしょうがないからソースコードを見直してねって話だったんだけど「いや、ツールぐらい作りゃあいいじゃん」と思って、1日サボってツールを作った。
勝手に作った、と。
作った結果、実はブラウザの中にボトルネックは一切なくて、Xサーバに問題があるっていうことが分かった。これはカーネルにプロファイラを仕込まないと分からないことだった。
そういう成功体験があって「カーネルに手を入れないと解決できない問題があるんだな」という気づきがあったと。
そうそう、一度成功体験があると、チームの中で「こいつ分かってるから、難しいこと押し付けよう」となる。そこで僕の持ちネタに「カーネル」っていうのが加わって、ブラウザも分かるよ、Xサーバも分かるよ、カーネルも分かるよ、というレパートリーになったわけです。その後全然違うことをやろうとしたときに「ブラウザの中身知ってるよ」というスキルセットは使いにくいんですよ。Linuxのカーネルは持ってるスキルセットの中で一番幅があった。Linuxを選んだのは前向きな理由じゃないんですよ。
お仕事としては組み込みのブラウザを作っていて、カーネルに手を入れることで問題が解決されるという成功体験があったと。それで「この方針はいけるぞ」と続けているうちに、こっちのほうが評価されることが多いと気づいた。「ブラウザの中身知っています」より「カーネルの中身知ってます」のほうが、世の中的には注目されると……（表情を見て）……注目ではない？
注目ではない。
市場価値？
そんな感じですよね。転職したときにブラウザのスキルセットは捨てて、カーネル屋さんとして転職。
転職のキーワードとしては、カーネルが有効だったと。ブラウザは有効ではなかったということなんですか。
そうですね。だって、ブラウザを自社で作る会社は少ないでしょう。
俺プロジェクトは「ひとつでは多すぎる」
Linuxカーネルを詳しくなっていく過程って結構しんどいとこも多かったと思うんですけれども、投げ出さないで続けられた理由はなんでしょう？
後ろ向きな理由ですけど、仕事が楽しくなかったからじゃないですかね。
後ろ向きな理由ですけど、よく聞く話ですね。
（笑）
仕事が楽しくないからオープンソース活動にすごく注力している人とかよく聞く話ですよね。おっと、あまりぶっちゃけすぎるとカットされるかもしれないのでもう少し前向きな表現にすると……カーネルをハックしているときのほうがエンジニアとして楽しく、やりがいがあったからですか？
そうね。あと、僕は人生の中で2つ「俺プロジェクト」がないと駄目だと思っている。つまり製品開発をやっていて1年間のプロジェクトをやるとするじゃないですか、後半の2カ月、3カ月は絶対巻きのフェーズだから、デバッグしかしないわけで、どう考えても楽しくなりようがない。そこで、1つのプロジェクトしかしてないと、気分がどんどん落ち込んでいく。心に澱が貯まっていって「もうやってられるか！ 転職するぞ！」って流れにしかならない。
そこで心をきれいにするための俺プロジェクトがもう1つ必要という感じ？ 仕事と別に？
完全に趣味でもいいし、会社の中でやってる別のチームに参加してもいいし、方法論はその場その場でいろいろとあると思う。ただ、1つのプロジェクトだけで開発をエンジョイし続けるのは難しいと思う。
確かに「ひとつでは多すぎる」などと言われることがありますよね。複数あったほうが心の負担は軽くなる、と［1］。
ほう。
「しんどいのに投げ出さずに頑張ってきた」というよりは、むしろ「しんどいものがあったときに、息抜きとしてやってきた」ということですか。
そうですね。そんな感じ。
そのうちに自分の中に徐々に知識が蓄積され、頼られることが多くなったり転職に有利になったりしたと。
そうです、そんな感じです。
「仕事をサボって勝手にやってみたらうまくいった」「息抜きでやってるうちに詳しくなった」という逸話で、世の中の真面目すぎる人たちは少し気が楽になるのではないでしょうか。これを「倫理的によくないことだ」と考える方もいるでしょう。しかし「勝手にやる」の反対は「言われたことしかしない」です。こちらのほうが良いのでしょうか？
勝手に自分プロジェクトをやるなどの「明文化された正規の仕事以外を業務時間にやる行為」は「アンダー・ザ・テーブル」、「ブートレッギング」（密造酒作り）、「アングラ研究」、「シャドーワーク」などと呼ばれていて、いろいろな企業で行われています。この種のキーワードで検索してみれば、多くの事例が見つかるかと思います。
また、競争力の強い企業ではシャドーワークをやる社員が多く、その社員は年収が高い傾向がある、という研究結果もあります［2］。
小崎さんの場合は、シャドーワークに挑戦し、成功したことで「カーネルに詳しい人」という社内の評判を得ることができました。その結果、カーネルに関係しそうな課題が集まってくるようになり、堂々と業務時間を使ってカーネルハックを行えるようになりました。そして、この仕事を通して小崎さんの中にカーネルの知識が蓄積され、それによって小崎さんの転職市場での価値が上がったわけです。いわば給与とは別に「スキルを磨く時間」というボーナスをもらったようなものです。シャドーワーク成功の報酬として妥当なものだと思います。
次回は「どうしてコードを読もうと思ったのか」と「どうやって新しい言語を学ぶのか」について聞いてみたいと思います。（了）
［1］「人生複線の思想──ひとつでは多すぎる」（外山 滋比古／みすず書房／2014年）
［2］「シャドーワーク──知識創造を促す組織戦略」（一條 和生、徳岡 晃一郎／東洋経済新報社／2007年）
「これを知りたい！」や「これはどう思うか？」などのご質問、ご相談を受け付けますので、筆者、または担当編集の風穴まで、お気軽にお寄せください。（編集部）
謝辞：
Web+DB Press編集部（技術評論社）のご厚意により、本連載のタイトルを「続・エンジニアの学び方」とさせていただきました。ありがとうございました。
インタビュー会場として、「イトーキ東京イノベーションセンターSYNQA（シンカ）」にご協力いただきました。ありがとうございました。
