Best Reviewer Award のもらい方(?)

0. 私は誰?これは何?

この文章は「日本音響学会 学生・若手フォーラム Advent Calendar 2023」17日目 (12/17) の記事です。私は、東京の渋谷にある Google DeepMind の Senior Research Scientist です。詳細情報は以下にあります。 sites.google.com

光栄にも、今年は Interspeech 2023 から Outstanding Reviewer Award を、ASRU2023 Best Reviewer Award をいただくことができ、旧Twitter で自己顕示欲を満たしていたら

(元)日本音響学会の学生・若手フォーラムの方から、 とコメントをいただきました。

近年、音系国際会議の投稿数が爆増しており、査読者を集めること&すべての論文に規定数の査読者を割り当てることすら難しくなっています。そこで、皆さんが「国際会議の査読者になって賞をもらいたい!」と思っていただけるよう、僭越ながら記事を書かせていただこうと思った次第です。

1. はじめに

視聴数を稼ぐために、偉そうなタイトルをつけてみたのですが、正直、どうやったら Best Reviewer Award を受賞できるかは、正直、全くわかりません。がっかりされた方、早速タブを閉じてください :)

この理由は、Reviewer Award が、他の学会賞とはだいぶ毛色が違うのではないか?と感じるからです。 (これは自慢ですが)私は2012年に学部4年生で研究を始めてから、ほぼ毎年、なんらかの学会賞を頂いています。 音響学会の「独創研究奨励賞 板倉記念」や、公益財団法人 電気通信普及財団の「テレコムシステム技術賞」をはじめとする、大きな賞も複数頂くことができました。 これらの賞は歴史が長く、「良い研究&応募書類」の定義が固まってきていると思います。 ゆえに、沢山の方々に分かり易い論文や応募書類の書き方をご指導をいただいたおかげで、私はこの賞を頂くことができました(これは機会があれば、また別記事で書こうかな...と思います)。

一方で Reviewer Awards は、少なくとも音系の会議では、ここ数年で始まったものかと思います。 また(私は選考に関わったことがないので全くわかりませんが)各会議の Technical Program Chairs (TPCs) が、Area Chairs からの推薦に基づいて決めているのではないかと思います。ご存知の通り、ここ数年、音系国際会議の投稿数が爆増しています。したがって、上記の学会賞の選考過程のように、Area Chairs が全ての査読(=応募書類)に目を通しているとは考えにくいです。ゆえに、最も優れた査読を行なった査読者に賞を授与しているとは考えにくいです。

したがって、Reviewer Awards は、TPCs (学会運営者)が「あぁ、この人が査読者プールにいてくれて本当に助かった。今後も査読者プールに残ってほしい。」と思えるような人に授与しているのではないかと思います。 つまり、「選考基≠いい査読をした≠著者に貢献できた」だと思っています。 ゆえにこの記事では、私が 「査読者としてこうありたいと思っていること」(=学会に貢献するという観点) と 「査読コメントを書く際に意識していること」(=著者に貢献するという観点) の2つに分けて執筆します。

2. 査読者としてこうありたいと思っていること

私は可能な限り、親切な人であろうと心がけています。これは、2020年の DCASE Workshop で Technical Program Chair を務めた経験から来ています。当時 DCASE はそれほど大規模な Workshop ではなく、投稿数も150件程度であったと記憶しています。TPC members も3人いました。 しかし、この規模の Workshop でさえ、TPC の仕事は本当に大変でした。

最も大変だったことは、crash review への対応(=査読者が期日までに査読を行なってくれず、最終的にはブッチし、緊急で新しい査読者を探さなくてはならない)です。 TPC がそれらを査読できればいいのですが、自分の専門外の分野の論文には、いい査読を返すことはほぼ不可能です。 そうなると、査読者プールの中から、その分野の専門家に追加の査読をお願いすることになるのですが「ごめん、クラッシュしたから3日で査読して!」なんて言って「OKだよ!」なんて軽々しく返ってくるはずもありません。みんな忙しいのです。 そうなるとTPC としては、crash review をOKしてくれて、しかもその査読を期日までに返してくれて、さらには「まだ困っているなら、X本までなら協力するぜ!」とか言ってくれる人が救世主にしか見えなくなるのです。

また、最近の音系の国際会議でも Rebuttal が付いてくるようになりました。 TPC も全ての分野に精通しているわけではないので、公平性のために、査読スコアで足切りするしかありません。 しかし、一発勝負の査読ではどうしても誤解があり、そのせいで良い論文がリジェクトされてしまうこともあります。 そこで、著者に反論の機会を持っていただき、複数の査読者で「あれ、キミの review なんかおかしくない?」みたいな議論をしてほしいはずです。 ただ、最近論文を投稿した多くの方は「Rebuttal って本当に読まれているのか...?」思っているでしょう。 査読者側から見ていると、残念ながら、全員が rebuttal discussion に参加しているとは思えません。みんな忙しいのです。 そんな中で、評価が真っ二つに割れた論文で、ポジティブ側とネガティブ側が、著者の意見を読んだ上で議論してくれると大変助かるわけです。 ゆえにrebuttal の議論に積極的に参加してくれる査読者もまた、救世主に見えるでしょう。

と、下心満載な感じで書きましたが、メッセージとしては、可能な限り学会運営の方々に協力しよう。そうすると賞がもらえるかもです。 私たちの音の分野は、AIの発展のおかげで技術進歩が凄まじく、人がどんどん増えています。 ゆえにこれまでの査読システムでは追いつかない面が多くあります。 みんな忙しいのはTPCもわかっています。私も全部の会議で親切な人であることは不可能です。 ただ皆さんに、ほんのちょっとだけ、査読プロセスに協力的になっていただければ、世界は平和になるかもしれないと思う次第です。

3. 査読コメントを書く際に意識していること

多くの査読者は、良いレビューを書きたい、と思っているはずです。

ですが、良いレビューの定義は、とても曖昧なのではないかと思います。 「strong accept をつけてくれる review が最高だ!」というのは著者としては当たり前ですが、 "Good paper, well done." とだけ返ってくる査読は「頑張って書いたのに...がっくし...」とも思います。 はっきり言って、フラフラになりながら頑張って書いた論文も、Attention Is All You Need のような本当に限られた論文を除き、 ちゃんと読んでくれるのはせいぜい100人くらいでしょう。 ですから3人の査読者くらいには、ちゃんと読んでいただき、率直なご意見をいただきたいものです。

しかし、みんな忙しいのです。 年に何回もある国際会議の査読イベントで、毎回10本近く回ってきたら、全部をちゃんと読んでる時間などありません。 ですので、これが正しいフォーマットなのかは全くわかりませんが、私は以下のフォーマットで査読を返すようにしています。 フォーマットが決まっていれば、読みながら査読コメントを書けるからです。 また、自分がクソ雑魚研究者で、著者がガチプロなんだ、と思うように心がけて査読します。そうしないと、「うっ、これはちょっと...」と思う論文をぶん投げて、crash review させてしまうかもしれないからです。

以下は私のフォーマットです。賛否両論あると思いますが、ご参考程度に。 (また、このフォーマットが書きやすいように論文を書いてもらえると、通りやすのかもしれません。)

  1. 論文の要約。何の問題を解こうとしていて、どこが従来と違って、何の観点で、どう良くなったのか、Abstract とは異なる言い回しで書こうとします。これが合ってれば、「ああこの査読者ちゃんと読んでくれたんだな」と思えますし、違うなら rebuttal で反論できます。
  2. 論文を褒める。「うっ、これはちょっと...」という論文でも、良い点はあるはずなのでめっちゃ探します。例えば、ただの technical report でも、実験設定が網羅的とか、よく練られている、とかこの観点は新しい、とかです。頑張ったことが同業者に認められれば、その次の批判も受け入れやすくなるかな、と思うからです。
  3. リジェクトを推奨するなら、一番「うっ、これはちょっと...」と思ったところを簡潔に述べる。
  4. 「うっ、これはちょっと...」と思ったところを改善案付きで指摘。どれだけ建設的にコメントしても、著者はリジェクト査読をもらって3日くらいは、画面を叩き割りたくなるくらい悲しい気持ちになるものです。私を含め、皆さん何度もこの気持ちになったはずです。でも悲しんでいても仕方ないので、数日後に再度、査読メールを読むわけですが、その時に、否定的なコメントに思考停止して「じゃあどうすりゃいいんだよ!」と突っぱねられてもお互いに悲しいだけです。その時に、こう解決すればいいよ、と書いてあるだけで(それもまた思考停止ですが)その通りに修正できたり、そこから思考を膨らませてより良い論文になるかもしれません。

アクセプトする論文のコメントを書くより、リジェクトする論文のコメントを書く方が労力を使います。 近年の査読では、3. のパートを書く量がどんどん増えている気がします。 しかしここを頑張って書くことで、今後の音分野の論文の質が上がり、査読者の労力が減り、結果的に crash review が減って学会運営が楽になり、みんながハッピーになれるアカデミアになればいいなと思っています。

4.おわりに

Reviewer Award は、学会運営者が、将来の査読者を育てたり、この賞のために査読プロセスに協力的になってもらうために作ったものなのだろうと、個人的に理解しています。 これにただ乗っかるのは、斜に構えた私たちには癪に障るかもしれませんが、結果的には私たちのいる世界が幸せになるいい仕組みだと思います。 皆さん、世界平和のために、ほんのちょっとだけ、学会運営に協力的になってみませんか?

私はこうやってGoogleに入った (Research Scientist編)

1. はじめに

私は、東京の渋谷オフィスにある、Google Research の音声チームの Research Scientist です。以前は、NTTの音声音響の研究所で、研究員をしていました。詳細情報は以下にあります。

sites.google.com

 

私が入社面接を受ける際、「私はこうやってGoogleに入った」blog群が非常に参考になった一方で、研究系のポジションの情報は、全さんのtweet:

くらいしか情報がなく、とても不安になったことを覚えています。執筆日現在(2022年4月10日)、私の所属するチームが Research Software Engineer を募集していることもあり、研究者の皆さんの心理的ハードルを下げるために、過去の記事を参考に、私がどう準備をしていたかの情報を記そうと思います。(なお、面接を受けていた時期は2020年夏のコロナ禍真っ最中でした。)

 

 

2. 面接までのプログラミングと英語の経験

おそらく、Googleのエンジニアリング関連の従業員の中で、最もプログラミングと英語ができない部類に入ります。

 

まず、プログラミングについて。おそらく多くの研究職の方がそうなのではないか?と思うのですが、このblog

hoge.blog

やこのblog

ctrl-x-s.blog

で触れられているほどのコーディング経験はないのではないでしょうか?「C++?触ったことない...」「データ構造?ハッシュ?なんか大学時代て聞いたことあるような...」「Git?著者実装コードが落ちてるところ?」という認識の方も多いはずです。私もそうでした。いま思うと赤面モノの自己流スパゲッティコードを書き散らし、ドキュメントなんて書いたこともなく、コードレビューなんてものの存在も知りませんでした。逆に言えば、現在では沢山の先人の知恵が遺されているおかげで、準備を怠らなければGoogleに入れるということかもしれません。

 

次に、英語について。Googleに入る直前に受けたTOEICが680点でした。kumagiさんのblogにある情報とほぼ同じです。私は、論文の読み書きはしましたが、精度の高い翻訳サービスを使い倒しており、国際会議では石のように突っ立っているか、日本人の聴衆を捕まえて翻訳してもらっていました。

 

 

3. 応募まで(学生時代と前職)

音響学会誌の以下の文献に、転職までのキャリアを簡単にまとめてあります。J-STAGE から無料で閲覧できますので、ご興味のある方はご覧ください。

[1] 小泉 悠馬 "とある学生・若手フォーラム代表のキャリア", 日本音響学会誌, 77-1, p. 40-41, 2020.

www.jstage.jst.go.jp

 

前職には、挙げきれないほど沢山の退職ブログやヘイトtweetがあります。しかし、上記の文献でも書いた通り、私の前職での経験は、非常にポジティブなものでした。ただ、いつかはメジャーリーグに挑戦してみたかったのと、いくつかのタイミングが重なり、転職することにしました。

 

研究職での転職先を探しているときに、LinkedInで今のポジションの募集を見つけました。そのチームには知り合いの研究者の方がいましたので、メッセージを送ってみると「マネージャーと話をしてみる?」とお声がけをいただきました。ただ、後述しますが、巷で話題の"Googleコーディングインタビュー"

kumagi.hatenablog.com

を通過できる自信が全くなかったので、その時は遠慮しました。ただ、お察しの通り、音声音響の研究職で、前職以上に学会で活躍できるところ、となるとほぼ候補がなく、腹を括ってGoogleを受けることにしました。そして、レジュメ(履歴書)を作り、現在のマネージャーと1時間ほどビデオ会議をし、知り合いの研究者の方からリファラルを頂いて応募しました。

 

 

4. 電話インタビュー

応募から1週間ほどでリクルーターの方からご連絡をいただきました。「ビデオ会議で、2回の面接をします。それぞれ、機械学習関連のコーディングと、研究内容を問うものです。」と言われ、いくつかの参考資料をいただきました。上述の通り、コーディングに全く自信がなかったので、面接日はその日から約1ヶ月半後にしてもらいました。

 

正直、ここが一番困りました。

 

ネットには、一般のプログラミングスキルを問う面接問題は山のように落ちています。例えば

1kohei1.com

とか

qiita.com

です。でも、どこを探しても、英語で探しても、「機械学習関連のコーディング」なんて情報はありません。しょうがないので、AtCoder と LeetCode を沢山解きました。まず方針を英語で説明して、説明しながらコード書いて、計算量の面でどこが改善できそうか、を説明する脳内シミュレーションも沢山しました。毎晩1時間以上、やっていました。1ヶ月半後には、それまでとは見違えるくらいコーディング関連の知識がつき「落ちたとしても非常に実りのある準備期間だった!」と開き直れるくらいにはなりました。

なお、研究ディスカッションは、まあポスターセッションみたいなものだろ、と腹を括り、苦手なコーディングに焦点を絞って準備をしました。英語は1ヶ月半でなんとかなるなら、こんな苦労してない!と開き直って何もやりませんでした。

 

で、蓋を開けてみると、普段から研究をするのに自分の手を動かしていれば答えられる質問でした。ただ、面接の脳内シミュレーションをしすぎて、それと少しズレた内容になったためパニックになり、受け答えは支離滅裂だったと思います。落ちたと思っていましたが、1週間ほどで「本面接に進みます」とご連絡をいただきました。

ですので、以降、受ける方には、「自分の想定と違う面接内容になっても落ち着いてください」と応援したいと思います。

 

 

5. 本インタビュー

上述の通り、コロナ禍であるため、本インタビューもビデオ会議で行われました。本来であれば、マウンテンビューで面接だったらしいので、正直ホッとしました。リクルーターの方から頂いた内容は、全さんの時と同じく、

という感じだ、と情報をもらいました。電話インタビューからの間は1ヶ月くらい空いていたと思います。研究トークのスライドを作ったり、上述のコーディング練習をその間も続けていました。Maeharaさんのblogも大変参考になりました。

www.notion.so

特に、"Behavioral Interview"は英会話が絶対まずいと思っていたので、想定質問を100個ほど作って、脳内シミュレーションしました。

 

コーディングインタビューはやっぱり爆死しましたが、面接中にディスカッションしながらヒントを沢山もらって、なんとかなりました。研究面接は、他の人もよく言うのですが、その道のスペシャリスト(だいたい学会で見たことある人)と1時間、和気藹々と研究ディスカッションできる凄い機会なので、楽しかった、という記憶しかありません。

 

 

6. 追加インタビュー

面接後からは、精神面が少し問題でした。1ヶ月ほど面接の結果が来ず、毎日ソワソワした日々を過ごしていました。Quoraで毎日、"Google Hiring Committee" と検索していたのを覚えています。これ

www.quora.com

とかこれ

www.quora.com

を見ながら、毎日過ごしていました。

 

そして決定は、「研究内容に関する追加インタビュー」でした。こういう質問を見つけては、自己肯定感を高めるように努めました。

www.quora.com

面接官は知り合いだったので、最近のその人の論文をいくつか読んで、あとは特に準備をしませんでした。

 

面接は変わらず研究ディスカッションだったので、最近の時間領域音声強調について、あーだこーだ言いながら終わりました。その後2週間ほどで採用通知を受けました。

 

 

7. 面接後から現在まで

採用通知をもらった時は、飛び上がるほど嬉しかったです。給料は Open Salary にある情報で概ね間違ってないと思いますが、入社年は、ボーナスとかの関係で、もうちょい低かったです。それでも前職の2.5倍くらいになりました。

opensalary.jp

 

上述の通り、今でもコーディングはダメダメなのですが、同僚のコードレビューのおかげで、社内で公開しても恥ずかしくないくらいにはコードが書けるようになりました。Pythonに関しては、Googlw SWE本の76ページにある「リーダリティ認定」(その言語に関しては、コーディング規則を守って書けますよ、と言う社内免許)を受けることができました。

研究に関しては、超大規模な計算リソースを使い、自由に研究できています。幸いにも、国際会議で賞をいただくことができたり、音声強調音声認識音声合成と幅広い範囲の研究に関わることができています。

 

Google Research Tokyo では、ポジションは少ないですが、たまに人員を募集しています。私の経験が、今後応募してくださる方の心理的ハードルを下げることに少しでも貢献できれば幸いです。

research.google

careers.google.com