サイボウズ・ラボの西尾 泰和さんが「エンジニアの学び方」について探求していく連載の第5回（毎週火曜日に掲載、これまでの連載一覧）。
富士通のエンジニアとしてLinuxカーネルの開発に参加されている小崎資広さんへの「インタビュー：その4」。Linuxカーネルという巨大なソースコードと日々戦っている小崎さんのお話は、きっと「エンジニアの学び方」の参考になるはずです。
本連載は、「WEB+DB PRESS Vol.80」（2014年4月24日発売）に執筆した「エンジニアの学び方──効率的に知識を得て，成果に結び付ける」の続編です。（編集部）
友達から借りたおもちゃを、中を見たい欲求を抑えきれず分解してしまい、親にとても怒られたことがあるという小崎さん。今回はそんな小崎さんに、どうしてコードを読もうと思ったのかを聞いてみました。
小崎資広さん
分からないものを分からないまま使うのが苦手
僕は凝り性なので、分からないものを分からないまま使うのが苦手で、つい中を覗いてしまう癖があるんです。それで、カーネルを読みぃの、libcを読みぃの、Xの中身を読みぃの（編集注：XとはX Window Systemのこと）。
どういうタイミングで「よし、中を読もう」って思うんですか？
それは一発目は、あれですよ、「このman、腐ってる」とかね（編集注：「man」はUNIXのオンラインマニュアルのこと）。
説明書の説明がよく分からないという状況ですか。
そうそう、ソースコード読んだほうが絶対早いっていう状況。
ソースコードを読むということに心の中でハードルを設けてしまっている人も多いと思うんですけども、そこのところは最初は抵抗はなかったんですか？ 一番最初に「このman、腐ってる、よし、ソースコード読もう」ってなったときはどうだったかな、と昔のことを思い出して頂けると……。
……あんまり苦労した記憶がないな、それは。
じゃあ、たまたま抵抗がなく「よしソースを見よう」となったと。そして「この説明じゃ分からないよ、よし中を見るか」→「中を読んだらなるほど分かった、説明が分からないときはソース読めばいいんだ」っていう成功体験を積んで、繰り返されてきたっていう感じですか。
そうですね、ちょっとネガティブな言い方をすると、組み込み開発だと関連するコンポーネントも自社開発だからドキュメントが非常にプアで、組織の壁があるとなかなかそう簡単に聞けなかったりするんですよ。でも、推測で「きっとこうだろう」とかやると、あとで火を噴いて自分がしんどくなるので、そこはきちんとやっておこうと思うと……。
ソースコードを読むしかないと……。
方法は2つある。「偉い人経由で問い合わせて何週間か待つ」というのと、「自分でその場で読む」っていうのと。どっちが自分にとってストレスが低いかって考えたときに「読んだほうが早いわ」ってなる。
なるほど。ソースコード以外のドキュメントがメンテされない状況だと、ソースコードが一番信用できるドキュメントで、だからそれを読むというわけですね。
集中してハードルを越える
そういう「よしソースコード読むか」っていうサイクルが回せていた当時、開発に使われてた言語は1種類だったんですか？
そうです、C言語だけです。
いろんな言語を使ってる会社だと「読もうと思ったら知らない言語だ」ということもあると思うのですけど、そんな状況だとハードルが高くなっちゃいそうですね。
そうですね。それは僕もちょうど悩んでるんですよ……。kvmのさ、libvirtの管理ツールとかさ、OCamlだったりするわけですよ。あとは最近はgolangとか流行ってたりとかするじゃないですか。（OCamlは言語の名前、golangはGo言語のこと）
流行ってますね。
僕のやってるサーバサイドでもDockerが大人気で、golangをできるようになってよとか、気軽に言われるんですけど、難易度が高くって。
そういう自分にとって難易度が高いものが現れたときって、どうやってそれに対して取り組んでいくんですか。
僕の場合は、祝日で何連休かできたときに、普段だったら勉強会に行ったりとか、会社の仕事とかこっそりやってるのをやめて、完全にそれの勉強しかしない。3日間連チャンでこれしかやってないっていう状況を作ると、1個ハードルを越えられる。
集中してそればっかりやる時間を設けるということですか。
そうですね。特に最初のとっかかりがないときって、ある程度連続した時間をとらないと無理じゃないかな。
ちょっとずつかじろうとすると、次の機会までにかじった内容を忘れてしまう。それを避けるためには、自分の中で結晶ができるくらいの分量を一度に入れないといけない、と。
そうですね。
チュートリアルを黙って写経
新しいプログラミング言語を学ぶときの具体的な方法論を教えて下さい。「時間を確保する」までは聞いたので、その次を教えて下さい。例えば、今日から3日間でgolangを覚えるとしましょう。
それは無理だけど。
じゃあ何か3日間でできそうなプログラミング言語を覚えるとしましょう。そういうとき、何から着手するんですか？
最近のプログラミング言語って、たいていチュートリアルがあるじゃないですか、まずそれを黙って写経じゃないんですか。
なるほど、黙って写経。まずはチュートリアルに書かれているコードを頭から順に入力していく、と。
黙って写経は意外とね、勉強の方法としてはかなり上位でいい感じ。
特に最初の一歩としてはすごくいいですね。
そう。やっぱり体を動かすことで、脳が活性化される。だから体を動かすのには非常に意味がある。
指先しか動いてないですけど。
でも意味あるんだよ、それでも。
確かに、ただ読んでると眠くなってしまったり、自分は読んでるつもりでページをめくっているけれども実は頭には入らずに全部素通りしていたりしますよね。指を動かして打っているとそういうことにならない。そういう意味では写経ってすごく意味があるんですね。
意味があるんです。
写経をやる際は、コードの粒度は細かいんですよね。一度に1000行写すとかではなく。
ないない、だって、1000行もあると考えながら書くことができないもの。
小さい単位で、考えながら書いて、実行して、結果がどうなったかを確認する、というサイクルを繰り返してくんですか？
そうですね。
ドキュメントがきちんと整備されて、違う部署への問い合わせもスムーズなのが理想です。しかし、現実にはそうではないことも多いでしょうね。そこでソースコードを読むんだ、というお話でした。おもちゃを分解して怒られたエピソードからは「中身を知りたい」という欲求を子供の頃から持っていたことがうかがえます。また「問い合わせるよりコードを読むほうが自分にとってストレスが低い」という発言も興味深い点です。
プロジェクトに使われるプログラミング言語が多様化すると、エンジニアがコードを読むコストは上がってしまいます。これは悩ましい問題ですね。解決方法は各エンジニアが各プログラミング言語を学ぶこと以外にあるのでしょうか。
プログラミング言語を学ぶには、まとまった時間を確保して、チュートリアルを写経するのがよいだろうとのこと。写経と言っても、何も考えずに漫然と書き写すのではなく、考えながら書き、実行して、結果がどうなったかを確認する、というサイクルが重要とのことでした。筆者もこの意見には賛成です。王道だと思います。ところが頭ではそう考えていながら、小崎さんの心は「3日間でgolangを修得することはできない」と信じ、その信念がgolangの学習を妨げているようです。なぜなのでしょうか。
インタビュー中、3日間連チャンで1つのことに没頭することが、日本にいたときはできていたが、今はできてない、というお話がありました。日本とアメリカでの環境の変化が原因なのかもしれません。これ以上の詳しいことは残念ながら今回のインタビューでは聞き出すことができませんでした。
次回は、小崎さんが初めてプログラミングを学んだときの話、そして「数の暴力に対する耐性」を身につけるに至った背景を深堀りしていきます。（了）
「これを知りたい！」や「これはどう思うか？」などのご質問、ご相談を受け付けています。筆者、または担当編集の風穴まで、お気軽にお寄せください。（編集部）
謝辞：
◎Web+DB Press編集部（技術評論社）のご厚意により、本連載のタイトルを「続・エンジニアの学び方」とさせていただきました。ありがとうございました。
◎インタビュー会場として、「イトーキ東京イノベーションセンターSYNQA（シンカ）」にご協力いただきました。ありがとうございました。