ITエンジニアのキャリアに本気で向き合うメディア
ITエンジニアのキャリアに本気で向き合うメディア
目次
■エンジニアの軌跡
2018.08.07 2024.03.28 約4分
さまざまな企業で働くエンジニアとリレー形式で対談を行うDevRelay。今回はクックパッドの菊田遥平 (@yohei_kikuta) 氏です。「結果を改善する取り組みがないと、データ分析は意味がない」と語る菊田氏。あまりエンジニアに馴染みのない「研究開発」を仕事とする菊田氏にインタビュー前半はクックパッドに参加した経緯や機械学習についてお話しを伺いました。この対談は、2部構成（vol.23・vol.24）でお届けします。
idesaku：前回の丸山さんからご紹介をいただきまして、今回はクックパッドの同僚でいらっしゃる菊田遥平さんにお話しを伺います。
丸山さんと菊田さんは、年齢的に、ほぼ同世代ですよね。
yohei_kikuta：そうですね。個人的にも仲は良いですよ。
私が所属する研究開発部は2年くらい前にできた部です。現在は機械学習やスマートキッチンなどを中心の研究テーマとしているのですが、社内では比較的、独立性が高い部門ということもあり、ほかの部門とどのように連携していくかも重要になっています。
丸山さんには、個人的に仲良くしてもらっているのはもちろん、社内の他部門と研究開発部との架け橋的な役割も担ってもらっていて、とてもお世話になっています。
idesaku：そうなのですね。前回、お話しを伺った際には、丸山さんは自分に対して「シャイ」という評価をされていたのですが…。
yohei_kikuta：ご自分では、なぜかそうおっしゃるんですよね（笑）。でも、私から言わせるとあれだけ高いレベルのコミュニケーション力とエンジニアリング力を兼ね備えた人は、そういませんよ。私が尊敬している社内エンジニアの1人です。
idesaku：丸山さんがプロダクトマネージャーを務めたクックパッドアプリで「料理きろく」の開発を一緒にやられたとか。
yohei_kikuta：はい。彼はサービス開発側の立場で指揮をとっていて、私を含めた機械学習チームは、ユーザーの端末内にある画像が「料理」か「それ以外」かを判別するモデルの開発と提供を行いました。社内での検証や、機械学習のモデルとサービスとをどう連携させていくかといったあたりについて、協力しながらやっていった感じです。
idesaku：リリースは2016年の12月でしたが、ユーザーもかなり増えたのではないですか。
yohei_kikuta：料理と判定された画像数でいえば、すでに3,000万枚を超える投稿をいただいています。
idesaku：それはスゴイ数ですね。
idesaku：ここから、少し昔のことをお伺いしたいと思います。大学で博士課程修了後は、一般企業に進まれたのですね。
yohei_kikuta：ええ。就職先を考えていたころ、ちょうど世の中では「ビッグデータ」のブームが起こっていました。自分がやっていた研究では、この世界で起こる素粒子の現象を測定、すなわちデータとして取得してそれを理論で説明するということをやっていました。
そのため、ビッグデータのムーブメントも、世の中の動きをデータ分析で理論的に説明し、ビジネスに生かすという点で共通するものがあったんです。
idesaku：世の中で「ビックデータ」がもてはやされる以前から、研究の世界では膨大な量のデータをスパコンでぶん回すようなことは行われていたと思うのですが、研究者時代には、そうしたこともやっておられたのですか。
yohei_kikuta：いいえ、私自身はあまりやっていなかったですね。簡単なプログラミングや科学技術計算用のソフトを使った計算などはしていましたが。
idesaku：本格的に、コンピューター上で大規模な分析をやるようになったのは、就職されてからなのですね。
yohei_kikuta：そうですね。研究では FORTRAN くらいしか使っていませんでしたし、最初の会社に就職した当時は Git も Python も知りませんでした。
idesaku：そんな菊田さんが、今ではクックパッドの機械学習チームで辣腕を振るっていらっしゃるのは意外に感じるのですが、その間に何があったんでしょう。
yohei_kikuta：いやー、ぶっちゃけると、クックパッドを最初に受けていたら、100％落ちていたと思うんですよね。GitHub にリポジトリとかなかったし（笑）。新卒で就職したのは大手の会計系コンサルティングファームだったのですが、同社の新卒を一括採用して社内で育てるという、いわば「古くからの日本式採用スキーム」に助けられた部分はあったと思います。その意味では今でも感謝しています。
idesaku：その会社で仕事としての統計分析や、コンピューターを使ったデータ処理について実績を積まれたのですね。
yohei_kikuta：特に統計解析の基本、それこそ検定がどうだとか、重回帰分析がどうだとか、実際にデータに適用したらどうだとかいったようなことは、その時に初めてきちんと勉強しましたね。
機械学習について、本格的に学び始めたのもその頃です。当時は、ディープラーニングが流行り始めていたのですが、職場の先輩に勧められて、人工知能学会の学会誌に掲載されていたディープラーニングに関する連載を読んでみたんですよ。そこで、「ボルツマンマシン」など、物理学にかなり影響を受けている分野だということを知ったんです。そちらは、私の得意分野でもあったので、それほど違和感なく入っていくことができました。
idesaku：ディープラーニングで機械学習の世界が、自分が得意としていた物理の世界に近づいてきているというイメージで勉強できたということでしょうか。
yohei_kikuta：たしかにそういう要素もあったと思うんですが、私にとっては数式を読むことが全然苦ではなかったというのが一番大きいのではないですかね。多少難しい論文に突き当たっても、読んで勉強さえすれば大丈夫だろうと楽天的になれたというのがよかったのだろうと思います。学生時代の研究や勉強で苦労したことを思えば、まぁ、どこで何をやることになったとしても、自分ががんばりさえすれば何とかなると思えたんですね（笑）。
idesaku：ある意味で、学生時代の苦労で身についた経験が、会社に勤めはじめてからも役に立っているのかもしれませんね。
idesaku：そこから、転職されてクックパッドに移られたわけですが、どんなきっかけがあったのですか。
yohei_kikuta：前の会社はコンサルティングファームということもあって、人月ベースでどれだけ利益を上げられるかというコスト感覚が非常に重視されていました。私は研究開発チームにいたのですが、そうした企業風土だと、どうしても目に見える数字を作りづらい研究開発は立場が弱くなりがちで、やりたいこととやるべきことをうまく合致させるのが難しかったというのがひとつ。
もうひとつは、実際に仕事としてデータ分析をやる中で「結果をもとに、継続して改善していく取り組みがないと、データ分析は成果につながらない」と感じたというのがあります。事業としてコンサルティングをやっていると、1社のお客さんとのプロジェクトは数ヶ月程度の短いものになりがちです。
その期間の中で何らかの成果を出そうと思っても、そもそも分析の時間自体が十分には取れませんし、結果を元に継続的な改善をしていくことも難しい。そのあたりにジレンマを感じるようになっていました。
であれば、Web系のように自社でデータを持っていて、それをもとにした分析から自社サービスを継続的に改善していけるようなところで仕事をしたいと考えるようになったんです。
idesaku：Web系企業ということであれば、データサイエンスに詳しいエンジニアは引く手あまただったと思うのですが、その中からクックパッドを選ばれたのには、何か理由はあったのでしょうか。
yohei_kikuta：うーん、将来的なキャリアパスを考えた結果でしょうか。具体的に転職を考えながらいくつもの企業をあたってみたのですが、やはり企業によっては、内部のエンジニアがやっていることを社外にアウトプットすることにあまり積極的でなかったり、認めていなかったりというところもあるんですね。
私自身が、そういうことをするのが好きだということもあって、その点ではクックパッドが一番私の指向に合う会社だったんです。
idesaku：たしかに、菊田さんは論文の読書会を企画したり、開発者イベントで発表したりすることなどに積極的な印象があります。そうした活動へのモチベーションも、やはり将来に向けたキャリア形成にあるのですか。
yohei_kikuta：もちろん、個人として業界の中で生きていけるような存在感を身につけたいというのはひとつの動機ですね。もうひとつは、例えばイベントで発表すると「発表駆動で勉強する」ようになるんです。
idesaku：なるほど。「締切駆動で仕事がはかどる」のと一緒ですね（笑）。
yohei_kikuta：イベントで、それぞれに知識量や共通認識の異なる人たちに伝わるように技術を説明するというのは、この上ない勉強の駆動力になります。また、自分で本などを読んで「理解した」と思えるレベルと、人に教えられるレベルで理解するというのは、深さがまったく違うんですよ。そのギャップを埋めるためにも、人前での発表は積極的にやったほうがいいと思っています。
idesaku：ここからは、クックパッドでのお仕事について聞かせて下さい。
研究開発部門では、具体的に日々どのような形で仕事をしておられるのですか。というのも、私のように、会社に行って、ちょっと打ち合わせをして、後はひたすらコードを書いて、終わったら帰るといった形で働いているエンジニアからすると、いわゆる「研究開発」の仕事というのがどういうものなのかイメージしにくいのですが。
yohei_kikuta：なるほど。そういう意味での基本的な時間の使い方は、あまり変わらないと思いますよ。エンジニアがコードを読んだり書いたりする時間の一部が、論文を読んだり書いたり、データをいじってアイデアを出したりするための時間に変わる感じです。
idesaku：菊田さんの場合、論文の読み書きなどは結構、夜中にやっておられませんか。
yohei_kikuta：あぁ、たしかに。私の場合は、論文を読み込むのは会社ではないかもしれません。会社でも新しいアイデア、使えそうなアイデアを探すために目を通す程度のことはしますが、じっくりと式展開を追うような読み込みはプライベートでやることが多いですね。
idesaku：「目を通す」というのは、イントロと結果をざっと見るといった感じですかね。
yohei_kikuta：そうですね。あと「GitHub にコード上がってないかな」と探したりもします。たまに、arXiv（研究者による論文の公開サイト）にある論文からリンクされているコードを見つけてダウンロードするのですが、まぁ、動かないものが少なくありません。
idesaku：動きませんか（笑）。
yohei_kikuta：動きませんねー。ほとんどは Python のコードなんですけれど、まず当たり前のように動作環境が書かれていない。requirements などに簡単に書かれていることもありますが、そこ以外の環境依存性のせいで動かない。
個人的には、研究者も Dockerfile をコードと一緒に提供すればいいと思っているんですよ。Linux などにそれほど詳しくなくても、コンテナイメージを1つビルドするくらいだったら、そう苦労しないはずで、それでアイデアが評価される場も広がるわけですから。ただ、現状、そのようなケースは少ないですね。
たぶん、機械学習界隈の盛り上がりが急すぎて、研究畑にいる人のエンジニアリングに対する理解が追いついていないのが原因だろうと思うのですが。
idesaku：査読付きの論文でも、コードを合わせて公開するようなことは一般的になってきているのですか。
yohei_kikuta：学会のタイプにもよりますね。純粋な理論についての学会だと、そもそもソースコードなんか公開の必要はないというスタンスですし、それはそれでいいのだろうと思います。逆に、少しでも応用を考えているようなものであれば、コードを公開するのは重要になってきています。
ただ、査読は、読む側は誰が書いた論文かを知らず、書く側も誰が読むか分からない状況での「ブラインドレビュー」が原則ですので、ソースコードを公開しているとしても、論文中に URL は入れられないんですよ。
idesaku：なるほど、言われてみればそのとおりです。
yohei_kikuta：ええ。ですのでコードがある場合、論文には「source code will be available」とだけ書いてあるようなケースもあります。
ただ、このあたりの慣例は変わってきている印象もあります。論文の査読では先ほど述べた「ブラインドレビュー」に、今でも非常に重きが置かれているのですが、arXiv に実名で論文を公開したり、GitHub にコードを公開したりといったことについては二重投稿にならないという明言する分野もあり変化が生まれています。
査読は一般的に時間がかかるので、最初にこの研究を行ったのは自分だという証跡を残すという意味と、アイデアをコミュニティで共有することには有益であるという意味から、そのような流れになったのだろうと思うのですが、実際、事前に arXiv に投稿された論文のほうが、そうでない論文に比べて採択率が倍近く高いといった状況もあり、そういう動きは加速していますね。
idesaku：オープンソース界隈の文化が、研究者の世界にも少しずつ浸透してきているという感じなのでしょうか。
yohei_kikuta：恐らくそうで、その傾向はもっと進んでいってほしいと思っています。ちなみに物理や数学の分野では、論文を書いたらまず arXiv に投稿して、それから学会誌に投稿という流れが普通になっています。
機械学習の分野は変化のサイクルが早くなっていて、1年もあれば状況がまったく変わってしまうこともあります。そういう状況だからこそ、新しいアイデアはスピード感を持って公開して、それを読んだ人たちが、査読の結果を待たずに、自分たちでその価値を判断できるような状況になっていくべきだと思います。
idesaku：菊田さんは、論文を読まれるだけでなく、ご自身でも意欲的に論文を書いておられますよね。論文執筆は片手間ではできないでしょうし、会社員であればなおさら大変だろうと想像するのですが、会社員として論文を出すことの意味というのは何なのですか。
yohei_kikuta：エンジニアにとって GitHub に上がっているコードがスキルとキャリアを示す材料になるように、研究者の場合は、良い研究をして論文を出し、それが多く参照されることがそのままキャリアになります。特に任期付きのポスドクなどだと、今の場所でのキャリアが証明できなければ、次の仕事につながらないわけです。
会社員の場合だと、企業から大学に戻るようなことを考えている場合に論文を書くケースもありますが、私の場合は組織としてこんなことをやっているというのを研究者コミュニティにアピールして関心を持ってほしいというのと、世の中に出していく価値があると思うものをもっと広めていきたいという個人的な動機の両方ですね。ただし、業務でサービスの研究開発をしてそれをそのまま学術論文としてトップカンファレンスに通すというのは難しくて自分も出来ていません。今後の目標の一つです。
※本記事の内容は掲載当時の情報であり、現在の情報とは異なる可能性がございます。
本サイト掲載の全て記事は、フォークウェル編集部が監修しています。編集部では、企画・執筆・編集・入稿の全工程をチェックしています。
