サイボウズ・ラボの西尾 泰和さんが「エンジニアの学び方」について探求していく連載の第3回（毎週火曜日に掲載、これまでの連載一覧）。
富士通のエンジニアとしてLinuxカーネルの開発に参加されている小崎資広さんへの「インタビュー：その2」。小崎さんが、Linuxカーネルという巨大なソースコードとどうやって戦っているかは、きっと「エンジニアの学び方」の参考になるはずです。
本連載は、「WEB+DB PRESS Vol.80」（2014年4月24日発売）に執筆した「エンジニアの学び方──効率的に知識を得て，成果に結び付ける」の続編です。（編集部）
前回、コードリーディングの手法としてタグジャンプ、デバッガ、更新差分の3つがあることが分かりました。今回は、小崎さんがどうやってこのスキルを習得したのかについて掘り下げていきます。
小崎資広さん（左）
組み込み系の事情
ソースコードを読むうえでは、タグジャンプ、デバッガ、更新差分、の3つの扱いに習熟することがすごく重要なんですよね。
超重要ですね。
どうやって習熟したんですか？
そうですね。僕はキャリアの一番最初が組み込み系だったんです。組み込み系って、機器ごとにだいぶ違うんです。デスクトップのLinuxだと例えば普通GNOMEがあって普通Emacsが入っていて、とコンテクストの共有があるわけです。しかし組み込み系は、同じような機能を持ってても機器Aと機器Bではソフトウェアスタックが全然違ったりするんですよ。なので「この機能があるからにはこういう名前の関数で、このライブラリをきっと使ってるはずだ」っていう推測が成り立たない。そうするといっぱい読んで把握するしかないんですよ。
なるほど。
そうすると一から読んでられないわけです。「最初はmainの冒頭にブレークポイントをはって、ステップ実行でとりあえず一番奥までいってみよう」とか「それから逆にタグジャンプで戻りながらボトムアップでフローを理解しよう」とか「その過程でライブラリ間がどう繋がるのか理解しよう」とか、そういう方法論を自分で作らないと納期までに間に合わないような状況なんです。
効率よくソースコードを理解する方法論を、作りながら読んでいく、と。
そうそう。
ものによって「このソースコードにはこの方法論がいい」とか「こっちには違う」とかいう状況があるんですか？
それは、ある。例えばデバッガで追っていく方法は、途中にメッセージキュー的なものがあるとできなくなるんですよ。
ああ、なるほど。そこで途切れちゃうから順番に読むわけにいかなくなっちゃう（筆者注：メッセージキューは人間に例えると、今いない人に書き置きを残して帰るようなもの。処理の流れがそこで途切れてしまうので、デバッガで処理を追う方法では繋がりが分からなくなってしまう）。
メッセージキューがある場合は、メッセージキューを起点にして、そこでデバッグプリントして、ログを出しまくる。そして「こういう順番でメッセージが来るんだ」っていうのを把握してから「このタイプのメッセージを投げるのは誰なんだ」をgrepして見つけたりする。
なるほど、なるほど。ソースコードによって、戦い方、取り組み方が違うわけですね。「このソースコードを読むうえではどうすれば効率が良いか」を常日頃考えていて、コードリーディングの技法はその過程で身に付いたものだということですか？
そうですね。特にやっぱり仕事で締め切りがあると、デバッガのマクロっぽいのって全部、だんだん暗記するというか、そうしないと時間がいくらあっても足りないですよね。
納期のプレッシャーがあると効率化するモチベーションになるわけですね。
納期は超重要キーワードです
そう、納期は超重要キーワードです。自分のやりたい趣味のやつでも、自分納期は作らないといけない。締め切りがないと、到達しないすごく遠いゴールに向かって走ってしまって、完成する前にどっか霧散しちゃうので。
耳が痛い……。
特に僕ら仕事に山、谷があるので、次の山が来る前に趣味プロジェクトに一段落つけとかないと、一切趣味ができない期間がしばらく続いて、何やってたかを完全に忘れてしまう。僕よく失敗した。
なるほど。よく勉強会の発表を先に申し込んでしまって、そこから考えるメソッドとかありますよね。あれも、自分納期を決める方法と言えるわけですね。
そうなんです。社内勉強会とか外の勉強会とかに申し込んじゃうのは、超いいライフハックです。そうするとおしりが決まるので「できる範囲でやる」というのが自然とできる。
しかもやったものを他人に対して話さないといけないので、学んだことの言語化が促されるわけですね。
そう。しかもフィードバッグがその場でもらえて超いい。
なるほど。
たまに失敗してね、勉強会のプレゼンの動画が、何年も残ったりとかして、黒歴史になる。
自分があとから見直して「ああ、間違ったことを言ってる」という気持ちになるんですか。
うん、それもある。それもあるし、間違ってなくても恥ずかしいよね。
どういうところが恥ずかしいですか？ 人の前で話すのってだいぶ慣れてらっしゃるように見えるんですけれども。録画されてるのが恥ずかしい？
いや、そんなでもないけど、話すときは逆に緊張で一周してるから話せるわけですよ。
緊張が限界を超えて振り切ってしまっているからこそ、逆にテンション高くワーッと喋れるということですか、なるほど。
社会人の学び方の特徴がよく現れています。学生時代には、学ぶ期間とテストの期間が分かれていました。だからテスト前に勉強をすればよかったのです。しかし、社会人は毎日がテスト期間です。その状況で学んでいくためには「日々のテストは、未来のテストのための勉強でもある」と意識し、「どうすれば未来のテストの成績が向上するか」を考えながら日々のテストをこなしていくことが求められるわけです（※1）。小崎さんがコードを読む力を鍛えてきた過程はまさに日々の仕事の中でのテスト勉強だったわけです。
「納期重要」はいいキャッチフレーズですね。小崎さんの例では納期のプレッシャーが、コードリーディングの効率を向上することのモチベーションになっていたわけです。学習にはゴールがないので、納期を決めなければいつまでたっても「ゴールした達成感」を得られません。納期を作ることで充実感を持って学ぶことができるわけですね。
また「勉強会での発表を申し込んでから話す内容を作る」というテクニックには3つのメリットがあることが明らかになりました。納期が決まること、学んだことを言語化すること、フィードバックがもらえること、の3つです。自分が学んだことを他人に伝えるために言語化することは学びの効率を高めるという研究（※2）がありますが、それだけではなく納期が決まることも良い効果をもたらすわけですね。昔からよく使われているテクニックですが、改めて考えてみるとかなり有用な学び方です。
ちなみに、小崎さんが黒歴史として言及している動画は、
「glibc mallocについて」（第67回カーネル読書会）
です。発表資料は
mallocの旅（glibc編）
で見ることができます。筆者はお笑いには詳しくないんですが「押すなよ！ 押すなよ！」と言われたときには全力で押せばいいんですよね？
次回は「そもそもどうしてLinuxカーネルをやろうと思ったのか」というところを深堀りしていきたいと思います。（了）
※1：Ericsson, K. A., Krampe, R. Th., & Tesch-Römer, C. (1993). The role of deliberate practice in the acquisition of expert performance. Psychological Review, 100(3), 363-406.
※2：Di Stefano, G., Gino, F., Pisano, G., Staats, B., & Di-Stefano, G. (2014). Learning by Thinking: How Reflection Aids Performance. Harvard Business School NOM Unit Working Paper, (14-093), 14-093.
「これを知りたい！」や「これはどう思うか？」などのご質問、ご相談を受け付けますので、筆者、または担当編集の風穴まで、お気軽にお寄せください。（編集部）
謝辞：
Web+DB Press編集部（技術評論社）のご厚意により、本連載のタイトルを「続・エンジニアの学び方」とさせていただきました。ありがとうございました。
インタビュー会場として、「イトーキ東京イノベーションセンターSYNQA（シンカ）」にご協力いただきました。ありがとうございました。