サイボウズ・ラボの西尾 泰和さんが「エンジニアの学び方」について探求していく連載の第21回（これまでの連載一覧）。サイボウズ・ラボの光成 滋生さんにお話を伺うシリーズ（4）です。

本連載は、「WEB+DB PRESS Vol.80」（2014年4月24日発売）に掲載された「エンジニアの学び方──効率的に知識を得て，成果に結び付ける」の続編です。（編集部）

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

たとえば最近だと機械学習が話題ですよね。機械学習に興味を持った人が、良い教科書だと評判の「パターン認識と機械学習」（通称「PRML」）を買ってきたとするじゃないですか。そうすると数式がいっぱい書かれていて「全然頭に入ってこない、どうしたらいんだろう」という悩みを抱えるというケースがあると思うんです。そんな人に何かアドバイスをするとしたら、どうします？

あれは単に計算するだけなんで、頭を使うとかじゃないよね。

……「単に計算するだけ」と言うけども、要は計算をしないといけないんですよね。

いや、それも認めりゃ別にしなくていいわけです。

givenなもの（与えられたもの）として認めるってことですか。

うん、コストをかけられないなら認めちゃえばいい。

なるほど、アドバイスとしては、時間をかけられないのなら「そういうもの」だと認めよう、時間かけられるんだったら納得いくまで緻密に計算して一歩ずつ進んでいこう、ということですか？

はい。立場にもよるでしょうが、私は大学生のような時間がいっぱいある人だったら、つまみ食いで先に進むよりは、確固としたものを手に入れるほうが応用範囲は広い気がします。

時間のたくさんある学生さんは基礎からがっちりと時間をかけるのが良いという話だと思うんですけど、社会人で「それほど時間かけられないよ」って方もいるかと思います。そういう人はどうしたらいいか？　どうするとたとえばPRMLを読んで理解できるようになるのか？

いや、目的があるはずなんですよ。何か具体的なライブラリが使えるようになりたいとか。じゃあ、それを使えるようになるためだけやりゃあいいんです。ベクトルや行列の計算できないときに、それに労力をかけたくない人がそこを読む必要はないんです、それよりはライブラリのマニュアルを読むとか、それを使ってる何か論文とかを見るほうがいい。

なるほど。

「PRMLを読むためにどうするか」っていうのはすでに目的がずれてる。

何かツールを使うのが目的なのか、PRMLを読むのが目的なのか？

そうそう、本を読むことが目的なんだったら読むしかないんです。

緻密に積み上げて数式を追っていくしかない？

さらっと読んだところで読んだことにはならない。

サイボウズ・ラボの機械学習勉強会でPRMLを読もうという話になったとき、どう読むかで議論になりましたね。

PRMLの読み方の議論になったとき、主催の中谷さんの目的は最先端の論文を自分で読んで解釈できるようになる力をつけることだった。私はその目的に賛成も反対もできる状態ではなかったし、PRMLを読んで何かやりたい目的があったわけでもない。なので、自分がやってた数学のやり方で読もうと考えた。

慣れた「積み上げていく読み方」で読もうとした、と。

そうするしかないよね。代替手段を思いつかなかったから。

なるほど。

ほぼスキップして終わったところで、そのあとどうするか具体的な目的がないんだったら、ゆっくり読むほうが有益だと考えた。

一方あのとき僕は「この分野どんな道具があるのかの大まかな地図を手に入れて、道具を使って実際に何かをやることができるようになることを目指してスピーディに進むべきだ」と考えたわけです。地図を手に入れなければどこに行こうという具体的な目的も生まれないし、試してみるための道具がなければ試行錯誤から学ぶこともできない、と。ある種、工学系と数学系の宗教戦争が起きたわけなんです。

そうですね。

結局数学系の主張が勝って、週2回、各1時間で8カ月、全部で100時間をかけて読んだわけです。その結果、僕は今は「ツールもどんどん陳腐化して新しいものが出てくるから、それを習得するコストはどうしても必要になる。ちゃんと数式を追っておくとそこのコストが下がる」と考えるようになって、結果としてすごく良かったと思っています。

PRMLを読みたいって学生で、ツールを使って論文を書いて卒業することだけが目的で、卒業後はやらないんだったら、さらっと読んだっていいと思います。卒業後も何かしていこうと思うんだったら、たとえば式変形が分からないんだったら、それに必要な教科書を見るしかない。

たとえば光成さんの出版したあの「パターン認識と機械学習の学習」を読むとか。

まぁあれで足りないんだったら、また別の読むとか、そういう手段を取るしかないんじゃないかな。

目的を明確にすることが大事で、それによって決まるんだってことですね。

あとですね、数学の話もPRMLの話も、両方教科書があるものを学ぶケースだったと思うんですけど、教科書がないものを学ぶときっていうのはどうしたらいんでしょうね？

何だろう、たとえばどんな？

たとえば、Linuxカーネルについて詳しくなりたい場合って、整備された教科書ってないですよね？

まあ、そうですね。

そういう場合「教科書を一歩ずつ読んでいく」という学び方がそもそも使えないわけですけど、そういうときはどうするんですか？　たとえばLinuxカーネルについて理解したい、理解することが仕事の上で実用上必要だという状況でです。

それは、問題ドリブンじゃないのかな。ネットワークの何かを解決したいんだったら、ネットワーク周りのところから見る。その場合はブートシーケンスとかはいらないし。

解決したい目的の明確化が必要で、それに必要なところからやる、と？

でもLinuxカーネルも全然知識がなく読み始めると大変じゃないですか。CはCですけど、いろいろ特有の関数とかマクロとかありますし。最初はやっぱり結構コストは高いと思うんですけど。

うーん、やっぱりそこもどこまで展開するかじゃないですかね。ざっくり見たいって言うんだったら、なんか知らない関数が出てきたとして、Linuxのカーネルだったら変な名前ってあんまりないから、関数名とか見て「とりあえずそういうもんなんだ」って、そのレイヤーで止めて読み進める。時間があればあとからもう一段階深く読む。

細かいものはgivenと認めて深追いしない、と？

幅優先でやったほうがいいと思いますけどね。