Community Blog

書籍の評判と執筆の苦労

（名刺交換をするお二人…）

有賀： そうか、CTOですもんね。

本橋： CTOと言ってもエンジニアは僕入れて4人ですけどねｗ

有賀： よくあるスタートアップのCTOって最初のエンジニアで、みたいな感じで。だから4人いるんだったら、ハイアリングがもうできるようになったという。

本橋： でも、いまAndroidエンジニアがいないから僕Androidアプリ書いてますよｗ　もう少しすると入社する予定ですけれど。

有賀： スタートアップのCTOはできることは何でもやるということで。いやあ。ご活躍されていて。

本橋： いやいや。

有賀： （『前処理大全』の）翻訳権も売れたって話も、おめでとうございます。僕らもおかげさまで、韓国、中国、台湾へ翻訳権売れたんですけど、最初に韓国から話が来た時に「え、ところてんのKickstarterのやつ [1] どうやって訳すの？」って。

本橋： （笑）

有賀： そうしたら、オライリーの担当さんが「いや、僕らもね、アメリカのスタートレックなんかのギャグを一生懸命訳してますからね。彼らも頑張るんでしょう」って。オライリーでKubernetesとかSparkの本を翻訳している玉川さんにたまたまイベントで会う機会があって「どうですかね？機械学習の本とか出すんですけど、英訳とかどうすか？」って聞いたら「僕、機械学習についてはもう訳さないことにしてるんです」ってｗ　確かに専門知識、日本語と英語と機械学習と、3つの知識をすべて押さえるのが結構つらいんですよね。

本橋： そうですよね。本を書いているときに、正直pandasの中身なんかは調べながら書かないといけなくて、ミスするとパフォーマンスがひどくなるんですよ。

有賀： あー、はいはいはい。わかります、わかります。

本橋： 普通のサンプルコードでも無駄にDataFrameのマージをしまくっていて。あのマージ関数はとても効率が悪いのですが素直に考えるとマージを使うことになるので、いかに使わないかを考えてました。

有賀： 『前処理大全』を英語で出すとしたら、“High Performance pandas”って煽りのタイトルつけて、Comparing with SQL and Rってサブタイトルにして、構成は日本語のものと同じなんだけど、pandasとかRとかSQLでパフォーマンスや可読性を気にしながら処理を書くにはどうしたらいいだろうと。そういう書き方にするといまPythonとpandas方面が凄くホットだから。

本橋： そうですね。チューニングはやりすぎるとそれはもう趣味の世界になってしまうんですけど、pandasは罠が多いので、確かにその辺のニーズ高そうですね。Rよりも、pandasは結構怖い気がするんです。

有賀： そういう意味ではこの『前処理大全』を読んでいてpandasのつらさをすごい実感するというか。

本橋： 比較があるので。

有賀： そう、比較があるから、SQLは「こんなもん、そうだよね」と。Rは「似たようなもんだよね」ときて、で「pandas…」みたいなｗ

『前処理大全』

本橋： そうですね。何でしょうね。まあシステムができるという唯一無二のメリットがあるので、使ってる人は一番多いと思います。とはいえ、インデックスの仕様なんかがつらいですね。

有賀： インデックスってあのリセットインデックスのオンパレードですもんね。

本橋： サンプルを書いていて他の書き方が分からなかったんですが、上手い使い方があるんですかね。

有賀： 僕もpandasそこまで詳しいわけじゃないので。僕はどちらかというとPySparkで処理して toPandas で処理することが多いので。 [2]

本橋： ああｗ　僕も『前処理大全』のような書籍を書いていますけど、前処理はたいていSQLで書いて、機械学習コードはRとPythonでやっています。ただベンダー時代だと、環境が決まっていたりDBのリソースをそれほど好きには使えないということがありますね。Clouderaが入ってないところもたくさんありますよｗ

有賀： わかります、わかります。

機械学習のアルゴリズム以外の所について書きたかった

本橋： 僕が前々職でベンダーの研究員兼コンサルタントの時に、よく分からないまま（案件に）突っこまれたことがあって。Hadoop基盤はわかるけれどデータ分析はやったことないという状態で。なぜかHadoopコンサルの時にお客さんに気に入られて、「お前次からは分析で来い」と言われて、大手のお客さんで断れなくて。それで、分析系がわからないのに入ったんです。僕はもともとデータ分析者を目指していなくて、DBとかKVSとかがすごい好きなんです。Qiitaでは全くアクセスが伸びていないんですけど、KVS、HBaseとCassandraの違い、設計思想の違いはどう違うのという記事を書いていて、これは数十くらいしかいいねが付かない。ところが、ある仕事のついでに「機械学習一覧法」 [3] という記事を書いたら1000いいねが集まるんです。

有賀： 機械学習についていうと、今回この対談を企画するにあたって、我々の間で共通点として感じているんですが、機械学習のアルゴリズムとかディープラーニングとか、華々しくフォーカスが当たるところはもういいかなと思っていて。『仕事ではじめる機械学習』は、その前後にフォーカスを当てたいなと思って書いていて、『前処理大全』にもまさにそういうモチベーションを感じて凄くいいなと思ったんです。

本橋： アルゴリズム以外のところはまだまだ手薄な気がしていて、そういう意味では後処理の部分は本を書けなかったんです。どちらかというと、前段のCSVを作る部分をひたすら書きたかった。実はデータのクレンジングの部分も書けていなくて、あの辺になると結構「文字コードが…」という話やシステム整備の話になってきて、そこまで行くと話題が広がり過ぎちゃうので。

有賀： わかります。よく言うデータマートじゃないけれど、データウェアハウスのようなものが存在していて、そこに綺麗にテーブルの状態でデータが入っているという形が想定して書かれているじゃないですか。その割り切りがいいなと思っていて。この前のところって幅が広過ぎて…

本橋： いや、そうなんですよ。全何冊になるんだろうって。

有賀： 『仕事ではじめる機械学習』の評判を見ていると「前処理とかもっとたくさんあると思ってたのに」と書かれてて、「そんなに一杯ありすぎて書けるわけないじゃん」って思ってたら『前処理大全』出てきたわ～とｗ

本橋： そこにフォーカスしていますからね。評価とか全部ぶった切っていますからね。

有賀： いや、そういう意味では「良かった。これからは『前処理大全』読んでください、ということでお薦めすればいいや」と。

本橋： ぜひぜひｗ　『仕事ではじめる機械学習』も僕は衝撃でしたけどね。いや、これ言い方悪いですけど「ずるい」って思いましたｗ　これみんな欲しいやつやって。

有賀： ありがとうございますｗ

本橋： これ想定読者、っていうか読んで欲しい読者が多いなって思いました。それこそベンダーで仕事してた時ならお客さんに読んでおいて欲しい。ベンダーの人はお客さんに「これあげるんでどうぞ」ってあげても元が取れると。

『仕事ではじめる機械学習』

有賀： この本、実は訳あってこれまで何度か転生しているんです。 [4] 元々本を出そうと思ったのは、自分がClouderaでお客さんに、その前にもCookpadで同僚から同じ話を何度も聞かれて。一番言われるのが「オンライン学習ってあるでしょ？あれってオンラインでモデルをトレーニングして、どんどんストリーミングでモデルを学習してストリーミングで予測するんでしょ？」って。「違います、違います」と。Cookpadでデータ基盤作っている青木峰郎さんに言われた時には、青木さんでさえそういうご理解なのかと。全く同じ話をClouderaのお客さんからも「ちょっと機械学習勉強したんですが…」と言われて、「いや、違うんです」って説明して。

本橋： Sparkの話を聞くと、そんなイメージを持ちやすいのかもしれないですね。

有賀： そうですね。デプロイパターンみたいなモノを書いたのはそれがきっかけで、オンライン学習って内部の最適化の方法なわけじゃないですか。パラメータをどうやってアップデートしていくのかってところで、「1レコードで入れるのか、バッチで入れるのか」そこだけなんですよ。というのでは伝わりきらないだろうと思って、こうしたい場合はこう、という感じで書いていって、システム的にはこうだよと。困るのは、機械学習の人と話していてバッチというと「オンライン学習とバッチ学習でしょ？」と言っていて、我々エンジニアにとってバッチと言えば「バッチ処理だよね」と。それで機械学習の人たちに「バッチ処理ってなんていうの？」って聞くと「それはオフライン処理だね」と答えが返ってくる。「え、オフライン？オフラインかー」と。用語がぐちゃぐちゃしてて伝わらないんですよ。それでエンジニア側に寄った話を書かなきゃという思いがあって。

本橋： そういう点は一緒ですね。結局、僕もエンジニアとしてスタートしているので。

有賀： そうなんですね。

本橋： 元々DBとか触ったり、スマホの開発もやらされてたので。だから逆にエンジニア側の気持ちは結構わかると。こんなRで解いたコード渡されても困るよ、みたいな。まあそうだよねと。だから『前処理大全』では、「データ分析者がなぜこんな処理してるの？」とか、「これ別によくないですか？」みたいなことに対して、「実はこういう背景でやってるんだよ」って伝えたいって思いもあります。

有賀： いいですね。

本橋： 組織によっては、エンジニアとデータサイエンティストが対立構造になるじゃないですか。下手をすると。実は一緒になるとより力を発揮できるのに。それこそ、いまデータエンジニアって言葉が海外でも出てきていますから、今後はそういうポジションが増えていくのかと思って。

有賀： そうですね。その歩み寄りみたいなところは大事ですし、理解するって事ができるといいですね。

書籍の裏に秘められた過去の経験

本橋： 『前処理大全』でRとSQLとPythonと、3つのコードを書いた理由はいくつかあるんですが、まずはあの本書いたきっかけがおかしくて。これはあとがきにも書いているんですけど、とあるホクソエムという会社がありまして、よく分からないんですが、なぜかそこに入ることになり、ある日「ちょっと編集者と飯に行くから来い」と言われていったら、「いやキミが本を書くんだけど」と言われてｗ　勝手に企画書ができていて、編集者と話が進んでるんですよ。で、既に話は詰んでいて「じゃあ、企画は通っているからキミ、サンプル書いてみて」と。

有賀： （笑）

本橋： 頭おかしいですよ。だって僕、転職して数週間ですよ。出会って数週間の人にそんな。

有賀： （爆笑）

本橋： それでその時に話したのは、ベンダーにいると入った環境でどの技術を使いたいって選べないこともあるので――それは僕が実際に経験していたので――僕と同じ苦しみを味わっている、しかもデータ分析わからないけどやれと言われているエンジニアを助けたい。あの時の僕に贈りたい本というテーマがひとつ。もうひとつは、プログラミング言語に愛があるのはいいと思うんですけれど、Rを知っている、SQLやPythonを知っているから、そこから脱せない人に、こっちの方が書きやすいよとか、こっちの方がパフォーマンス出るよという世界を見せて、そこを行き来してほしいなと思っていて。多分、どれかひとつでもできる人って他の言語もできるんですよ。そういう意味ではマルチ言語で書くようなデータ分析とかデータエンジニアが増えた方が幸せかなと思って。

有賀： わかります。クロスジョインのコードを見たときに、SQLだと「ふーん、そうだよね」と、Rだと「はー」。Pythonだと「うおー、頭おかしい」って。

本橋： そもそもジョインの条件指定が本当につらいんですよね。。結合条件に不等号が使えない。いったん全部ジョインした後にフィルタするので、明らかに計算パフォーマンスが悪い。似たような話に昔HadoopでHiveの検証をしていたことがあって、出たての頃にMapReduceとHiveでどうやってパフォーマンス変わるのかと言って、Hadoopで適当にMapReduce書いたんですよね。（すると）結構普通にHiveに負けるんですよね。あれ結構すごくて、Hive結構きちんとやっていて、例えば全キャストするように、要はバイナリでデータがあるとするじゃないですか。カンマで区切られているので、最初バイナリで読んでキャストして、それで必要なフィルタリングの処理をするような、要はキャストする部分を共通の処理として書いてたんですよね。そうしたら、Hiveって必要な部分しかキャストしないんで負けるんですよ。それでちゃんとやろうって。当時、HiveにMapReduceが勝てるのはどこかと言えば、 inner join しかなかった。自己結合で、あれHiveで同じテーブルで結合しようとしても2回読むはずなんですよ。

有賀： なるほど。

本橋： そこをちゃんとReduceで読み込まれる順番を決めて、メモリに乗り切るサイズで自己結合するような処理を書くと、テーブルを1回読み込むだけで処理を実現できるので、圧倒的に早くなる。ああいうのを、こうなんか基盤屋とかエンジニアならわかるんだけど、データサイエンティストって結構気にせずに書いちゃう。全結合してフィルタリングでいいじゃんって。サンプルではうまく動いてるよ、とかメモリに乗り切るよって。

有賀： ある、ある、ある。「スモールデータでは動くけど、それデータが増えたときにNの2乗で増えてくけど大丈夫？」って。

本橋： そうそうそう。それはよくあるんですけれど、データサイエンティストにそれを全部求めるのは酷だし、かといって受け渡された方は「これやって意味あるのかな？」って思いながら、簡単に処理を変えることはできない。その翻訳は必要だなって。そのジョインのところはすごい魂込めてますね。今回の本で書きたかったのは、あそこと「 order by random の後の limit N 」かな、この2点が伝われば、正直この本を書いた意味はあるなと思っています。あとは、まあ読まなくてもいいんじゃないかとさえｗ

有賀： 僕が読んでて感じたのは本橋さんご自身の、過去のつらい経験が漏れ出てきていて、「これは同じ匂いを感じる」というところがｗ

本橋： それ嬉しいですねｗ

有賀： 僕はなんかね、なんて言ったらいいですかね。綺麗に教科書的な感じで書いている本は「いろいろ調べてやったんだろうな」ってみたいな感じがするんですが、この本の問題設定で、このホテルの大きい地域と小さい地域でjoinするとか、これ完全に業務でやってたやつだろうなとかｗ [5]

本橋： バレてますねｗ

有賀： じゃないとこの問題設定でこういう処理を思いつかないし、「Rだとこのライブラリで一発ですが」と書いてあると「この時はRで一発で完結できて万々歳だったんだろうな」って、そういういろいろなところでご自身のつらい背景みたいなものが、血を吐いて経験された事の脳内がダンプされてるのが伝わってきて、これはいい本だなってｗ

本橋： そうですね、魂は乗ってますね。裏のストーリー、全部ポエム書けますねｗ　実際は守秘義務があるので書けないですけれどｗ

有賀： 僕らもそういえば、そういう裏のストーリーをしれっと入れてあったりするんですけれど。僕よりも共著のところてんが、公式に「このレビューはここまでね」という締切が過ぎた後くらいのギリギリのタイミングで自分の担当分を終わらせて、「はー、やっとこれで落ち着いて人の原稿読めるわ」って、そこからグワーッてissueを送ってきて、「マジ勘弁してくれよ、なんだよこれ。学会の締切伸びたからって全力だす助手みたいなのやめてくれよ」って。それでヒイヒイ泣きながら対応している横で「ねえねえ、ちょっとさ、過去の経験に基づくつらい話入れてもいいかな？」って言い出して、「いいんじゃない？」って答えたら、僕の担当する章の中にしれっと闇の深い話がどーんと入ってます。この本のメインの想定読者は「ふーん」と思うくらいだと思うんですけど、第3の想定読者――同僚に「この本読んどけ」って言って机の上に置きたい人――がいるんですけど、そういう分かる人が「あるある～」って思うような。

本橋： 「仲間がいる」っていうメッセージを伝えたくなりますよね。

有賀康顕（ありがみちあき）

電機メーカーの研究所、レシピサービスの会社を経て現在はCloudera所属。フィールドデータサイエンティストとして、データ活用や機械学習の支援を行う。

• https://twitter.com/chezou
• https://www.slideshare.net/chezou
• https://chezo.uno/

本橋智光（もとはしともみつ）

SIerの研究員、Web系企業のデータサイエンティストを経て、現在はデジタル医療スタートアップのサスメド株式会社のCTO。ホクソエム株式会社にも所属。量子アニーリングコンピュータの検証に個人事業主として従事。製造業、小売業、金融業、運輸業、レジャー業、Webなど多様な業種なデータ分析を経験。

• https://twitter.com/tomomoto_LV3

※このプロフィールは対談時のものです。