サイボウズ・ラボの西尾 泰和さんが「エンジニアの学び方」について探求していく連載の第2回（毎週火曜日に掲載、これまでの連載一覧）。「WEB+DB PRESS Vol.80」（2014年4月24日発売）に執筆した「エンジニアの学び方──効率的に知識を得て，成果に結び付ける」の続編です。（編集部）

文：西尾 泰和
イラスト：歌工房

小崎資広さん（左）

まず、読者の方に、小崎さんが普段どれくらい大変なことをしているかを伝える必要があると思います。どれくらいの分量の情報に日々接していているのですか？

現在は専業カーネルハッカーをしていて、メールの分量が日々1000通くらいあります。そういうのを見ながらバグを直したり、機能を開発したりしています。

1000通もあると大変ですよね、読むだけでも。

そうですね。何割かはタイトルだけ見てスキップしています。

メールは毎日コンスタントに読むのだと思いますが、ソースコードはどうですか？　やっぱり毎日コンスタントに読むのですか？

いや、ソースコードは違います。僕はバグが火を噴いてないときに自分が興味があるところを読み進めておいて、実際にバグを直したり機能を作ったりしているときにはあまり読まない、と波があります。例えば、誰かがブログやツイッターでLinuxの話をしているのを読んで知らない単語が出てくると「何だっけ」とか言いながらEmacsを開いて、周辺のコード読んで「ふーん」とかよくやります。

なるほど、自分が知らない単語が話題に出たときに、それを詳しく調べるわけですか？

完全に知らないと「うん？」とも思わないんで、「自分の知っていることに関連が強いはずだけど、知らないぞ」というものですね。

自分の知ってる範囲と知らない範囲の境目にある「知っていることに近いけど知らないこと」を見つけて、それを学ぶことで境界を広げていくということですか。

まさにそんな感じ。

なるほど。そのコードリーディングは気が向いたときにやるわけですか？

そうですね。コードを読むのはストレス発散に良いと思うんですよ。僕の中では写経と同じで、コードを一心に書くのと、ただひたすら読むのはストレス発散の手法なんです。

読んでる間って心が静かで落ち着いた、座禅みたいな状態になってるんですか？

そうそう。

じゃあ、何も考ずにただ読むんですか？　それとも、このコードどうなってるんだろうとかいろいろ考えながら読む？

単に気になって読んだときは、あまり考えてないし、仕事的にやっているときは当然考えながら読まないと、見落としてハマるので、モードはやっぱり違うんですよ。

コードを読むときの心の状態には、仕事上の問題解決のために「まじめに読む」とは別に、「何も考えずに読む」という状態があるんですね。

そうですね。

ソースコードやメーリングリストなど、膨大な情報をこなしていくための方法論について教えてください。

やっぱり「毎日やる」「飽きないでやる」が一番重要です。毎日やるのは難しいのですが、それでも毎日ちょっとでもやることは重要です。日が空けば空くほど、スタートするときのスイッチを入れるのが大変になるんですよ。僕はスタート時の心のスイッチのコストを下げることに気を遣っています。

なるほど、具体的には？

例えばこのPC、会社のシステム上の制限でWindowsしか使えないんですけども、常に仮想マシンでLinuxが立ち上がっていて、そこでタグが打ってあるLinuxのソースファイルが全部展開されています。何か気になるところができたら、すぐその場でタグジャンプして、ソースコードが読めるようになっています。自分が「あれっ？」と思ったときにGoogle検索と同じ速度でソースコードが見られるような状況を作っておかないと、そもそも面倒くさくて調べなくなっちゃう。

なるほど、Google検索と同じくらい低いコストで調べられる仕組みをあらかじめ作っておくということですか。

確かに「久しぶりに読んでみようかな」だと、腰が重くなってしまいますね。でも「毎日やる」って目標は理想論で、現実的には「できない日」もありますよね。そういうのは特に気にせず、「あ、今日はできなかったな」的な感じなんですか？

うん、気にしない。つまり挽回しようとすると、余計腰が重くなるので、過去は振り返らないほうがいい。

挽回しようと思って腰が重くなるくらいだったら、過去のことは過去でスパっと忘れて「明日からガンバロウ」みたいな感じなんですね。

そうそう。世の中のライフハックとかって「効率を上げよう」とするんだけれども、僕の中で一番重要なのは「何にもしない時間を削ること」なんです。何もしない時間は生まれる原因には、腰が重いとか、別のところでストレスを受けてしまって心の治療に時間を使っているとかがあるわけです。そういう何もしない原因を解決して、何にもやってない時間を削ると、ライフハックなどで効率を1割2割改善しようと頑張らなくても結構なパフォーマンスが出る。

なるほど。「効率を上げよう」と思うのではなくて、心が傷つかないようにするとか、最初の一歩が踏み出しやすいように下地を作っておくとかのほうが重要だということですか。

そうですね。

コードリーディングの具体的な方法論について伺えますか？

僕の場合、特にカーネルだから、特にたくさん読まないといけないわけですよ。で、僕の方法論は「Gitの履歴を追いかけまくる」です。つまりパッチで読むんですよ。

バージョン管理システムに記録された変更の差分を読むというイメージ？

そう。ソースコードは頭から読むようにできていないんです。頭から読むのは、学生の頃にやって失敗しまくった。要するに心が乱れるんですよ。本は前から読むように最適化されるんだけど、それは著者がそうなるように頑張ってるからなんです。生の情報は最適化されていないんです。だから、ソースコードを本のように読むのは、かなり非効率な読み方なんです。

なるほど、本と違って前から読むように整理されてないから、違う読み方が必要だ、と。

なので、タグジャンプを使ってトップダウンやボトムアップで読むか、デバッガーで実行順序で読むか、Gitとかを使って時系列で見るか、が三大流派です。

なるほど。

Gitで時系列で見るのは何がいいか。人間のやることですから、ソースコードには絶対間違いがあるんですよ。だから、深い理由があるコードと、単に間違っているコードとを見分けないといけないんです。履歴を見ると、深い理由があるコードは、入った瞬間に絶対何か痕跡があるんです。パッチディスクリプションが書いてあるとか、コメントを頑張って入れようとしてあるとか…。

深い理由があるコードと間違っているコードの違いを具体的に教えてもらえますか？

例えば、関数Aと関数Bがあって、同じような仕様をしてるんだけども、if文の条件が微妙に違うとしましょう。これが深い意味があってわざわざ関数を分けてif文の条件を変えたのか、それともたまたま違う人がそれぞれの関数を書いていて、うっかりで2つできてしまったのか、どっちなんだろうというのを見分けないといけない。特にバグフィックする際にどう直していいのか判断がつかない。

意味があって分けてるんだったら、なぜ分けたかについてのコミットログが付いているはずだということ？

そうそう

それはみんながコミットログを適切な粒度で付ける文化が前提のように思います。

それはあるね。カーネルはかなりコミット粒度を頑張っている。それは僕みたいにパッチ単位で見る人がすごく多いから。パッチ単位で見たときに読みにくいと「読みにくいから却下」となる。

「あとでパッチを読む人のことを考えて読みやすいパッチを作れ」という方針があるということですか。

読みにくいと「読みにくいから放置」となるので、そのパッチを入れたい人が困る。なので「あとの人」のためというよりは、パッチを入れたい人がその人自身のために、読みやすいパッチを作るようになっていく。

パッチだけ見て分かるようにしようという淘汰圧がかかるわけですね。

そうですね、Rubyとの一番の違いはそれ。Rubyはコミッタ制なんですよ。だから、入れたい人が入れたいときに入れれるから、クリーンナップより新機能のほうに時間を使われがち。

読みやすいパッチを作ろうというモチベーションが沸きにくい構造になっちゃってるということ？

最終的なコードはきれいなんだよ。ただ「パッチのディスクリプションとコードがマッチしてる」というのは最終的なコードの美しさとは違う。普通に書くとパッチが10個くらいできて、後半5個くらい全部バグフィックスだったりするわけですよ。それをマージする前に全部もう一遍仕切り直してきれいなパッチにし直さないといけない。そうしないと、1個目のパッチを読んだときに、バグが5個も6個も入っていて心が乱されることになる。

なるほど。バグを入れてしまったという過去を消すことで、他の人がすんなり読めるパッチにすることができるわけですね。

そうですね。

両方のコミッタだからこそわかる興味深いお話だったと思います。