論文投稿視点でのSteam審査レビューの通し方
『真ッ赤の太陽』、Steam版が発売されました。
作中でも石餅が言っていますが、研究者は論文を書くのが仕事です。「論文を書く」というのがどういうものかはあまり知られていないと思いますが、
- 書く
- 雑誌に投稿してレビューを受ける
- 結果を受け取り修正する
- 受理されて掲載される
というのが（望ましい）ルートです。
これはSteamなどでゲームを売る場合でも同じで、
- 作る
- Steamなどにストアを作ってレビューを受ける
- 結果を受け取り修正する
- 販売開始する
というのが（望ましい）ルートで、つまりゲーム製作って研究と同じなんだ！ とんかつDJアゲ太郎。
そういった視点から、両方を経験している筆者が「論文を採択されるためにどうレビューに回答するのか」をざっくり「Steam審査プロセスを潜り抜けるにはどうすれば良いか」に変換したのが本記事です。
なお、筆者はべつだんSteamのレビュープロセスにはまったく詳しくありませんが、論文投稿でも言うほど卓越した業績を挙げているわけではないので、テクニカルな話ではなく心構えというか、礼儀作法のような話になります。
- 目次
- R2Rを書こう
- できれば修正をしよう
- 全部応えよう
- 感謝をしよう
- ヘタクソな英語を使おう
R2Rを書こう
まず、もっとも大事なのはResponse to reviewers（研究分野ではあまりこういう略し方はしないだろうけど、以下R2Rと略す）を作ることです。
一般に論文レビューには複数のレビュワーによる査読を受けます。そのため「reviewers」という複数形になるわけですが（さっそくSteamと論文で違うところが出てきたな）、レビュワーが複数いることは重要ではありません。
大事なのは「レスポンス」の部分、すなわちレビュワー（たち）が論文の疑問点や問題点を指摘してきたことに逐次回答することです。
例を挙げると、実際の論文レビューはざっくり以下のようなかんじで来ます。
推奨：メジャーリビジョン（大幅な修正が必要）
ジェネラルコメント（全体的なコメント）
例）この論文で香川で蛇口から出る麺ツユの濃度と徳島からの距離の関係を解析したのは面白い。一方でうどんのコシについての評価がまったくされていないのがいまいちなので、ツユだけではなく麺にも気を配っていく必要がある。
メジャーコメント（重要なコメント）
例）X行目で「ごはんはおかず」と書かれているが、根拠が示されていない。また、「ごはんはおかずやぁ↓」は「ごはんはおかずやぁ↑」の間違いではないか？
マイナーコメント（誤字脱字の指摘や、あまり重要ではないコメント）
例）Y行目の「完壁」は「完璧」の間違いではないか？
これらに対し、「コメントひとつに対してひとつずつ回答したリスト」を製作します。
つまり、以下のようになります。
ジェネラルコメント（全体的なコメント）
Q. この論文で香川で蛇口から出る麺ツユの濃度と徳島からの距離の関係を解析したのは面白い。一方でうどんのコシについての評価がまったくされていないのがいまいちなので、ツユだけではなく麺にも気を配っていただきたいと思っている。
A. コメントありがとう。うどんのコシ関する評価も重要な課題だと感じている。メジャーコメントでも回答しているが、コシに関する評価関数を導入した。
メジャーコメント（重要なコメント）
Q. X行目で「ごはんはおかず」と書かれているが、根拠が示されていない。また、「ごはんはおかずやぁ↓」は「ごはんはおかずやぁ↑」の間違いではないか？
A. ご指摘ありがとう。X行目に「ごはんはおかず」の根拠となる先行研究を引用し、記述も修正した。
マイナーコメント（誤字脱字の指摘や、あまり重要ではないコメント）
Q. Y行目の「完壁」は「完璧」の間違いではないか？
A. 修正した。
このように、「どういうコメントがあって、それに対してどう対処したか」をわかりやすく書くのがR2Rです。
Steamレビュー時にも、返ってきたコメントに対してR2Rを作ることで、修正箇所がレビュワーにわかりやすくなるのはもちろんですが、修正時に「何をすればいいのか」も明確になります。
なのでコメントが返ってきた段階で、まずはR2Rを作るために内容をリストアップしましょう。
できれば修正しよう
当たり前のことですが、コメントをついたところにはできる限り修正を入れることが必要です。
これは当たり前、つまり大前提です。
ただし、すべてを言われた通りに修正すれば良いのか、というとそういうわけではありません。
なぜなら、「実質的に不可能な指摘」というものがあるからです。
『真ッ赤の太陽』作中でも以下のようなやり取りがあります。
石餅「……まぁ、多少間違えても修正すればいい、というのは論文のディフェンスになると話が別だけどな」
高橋「ディフェンス……ってなんですか？」
石餅「論文投稿したら査読が入るだろ。レビューへの対応だよ。レビュワーが、あれはおかしい、これがおかしいだのと難癖つけてくる。これをどうにか掻い潜ってアクセプトまで持っていかなきゃいけないのだが、そうなると認めるライン、認めないラインの内訳が必要になってくる。
たとえばこのやり方は良くないのではないか、みたいな指摘をされたときに、計算方法をちょっと変えてやり直せるのか。現実的な話として計算資源の問題があるだろう？
特にグローバルモデルを使って高解像度で計算する、とか、長期間の複数パターンでモデル計算する、みたいなことをやっていたとすると、そんな簡単に修正はできない。いや、修正はできるけれど、計算は終わらない。
だからそういうパターンは、これでいいのだということを説明するか、でなければ、今回のやり方は完璧ではないけれどこういった考え方に沿ってやっているから大丈夫なんだ、みたいな主張が必要なわけだ。」
元研究者の石餅（赤字）は修士課程の高橋（青字）に対し、レビューへの回答が必ずしも「言われた通りにするわけではない」ことをディフェンスという形で示します。
計算資源的にできない計算、あまりにも膨大すぎる課題、本研究の意図からは外れる内容。そういったものには対処できません。
ゲーム製作でもそうですが、「相手の指摘を受け入れられるライン」「受け入れられないライン」というのがあります。
では「受け入れられないライン」を超えてきたレビューがあったときにどうするか？
それでも対応する必要はあります。
すべてに対応しよう
某T大（『真ッ赤の太陽』の東北のT大とは別のT大です）の某研究科の某研究室には「どんなに出来の良い学生でもストレート（3年）では博士号を取らせないようになっている」という噂があります。
これが成立するのは「完成品にはいくらでも難癖はつけられ、それがあまり大筋には影響しない」からです。
たとえば以下のような文章があったとします。
香川県ではあらゆる運河にはうどんが流れているが、その長さや太さは河川流量とダムからの距離と相関があることが知られている。
（うどん大魔神, 4545）
しかしこの文章に対して、
- 「香川県ではあらゆる運河にうどんが流れている」というのは常識的な事実だが、その引用は必要ではないのか？
- 長さや太さ以外にも評価要素があるのではないのか？
- 一級河川と二級河川での違いについては書く必要はないのか？
というような指摘を入れることができます。
これらの指摘に対して、それぞれの修正を行うことは難しくはありません。しかし、指摘があったとしても、それが最適かどうか・妥当かどうかは別問題です。
というのも、仮に上の指摘内容を最初から盛り込んでいたとししても、
- 「香川県であらゆる運河にうどんが流れている」というのは常識なのでわざわざ書く必要はない
- 野生のうどんで重要なのは長さや太さだけに言及すれば十分である
- 本研究でターゲットにしているのは一級河川なので、二級河川について書くことは論文のテーマがブレる
というような逆の指摘ができてしまうのです。
なので、指摘された＝間違い、というわけではありません。「指摘が起きることが最上ではない証拠」というわけではないのですから。
であれば「すべてのコメントに対し、必ずしも指摘されたとおりの対応をする必要はない」……といっても、それはあくまで「相手の指摘が最上とは限らない」というだけで、何もしなくてもいい、というわけではありません。
なぜならレビュワーが引っかかった（問題に感じた）ということは、読者／プレイヤーも問題に感じる可能性がある、ということだからです。
論文レビューでもSteam審査でもそうですが、最終的に肝要なのは「良いものを世に出すこと」です。
レビュワーはそのために必要な指摘をしてきます。それは受け入れ難い指摘だったり、自分では必要のないように感じる指摘かもしれませんが、あなたは読者／プレイヤーではありません。一方でレビュワーは（少なくとも著者／製作者であるあなたよりは）読者／プレイヤーに近い立場です。
もし受け入れられないラインの指摘だった場合、重要なのは「受け入れられない指摘だからそれは無視する、あるいはこれで問題はないと一方的に告げる」ことではなく、相手の意図を理解したうえで、「こういう指摘があったうえで、こういう修正をしてみた」「こういう対処ではどうか？」というアプローチを行うことが必要です。これは論文でもゲームでも同じです。
修正するかどうかは別として、R2Rはすべてのコメントに対して行わなければなりません。上で「マイナーコメント」は「あまり重要ではない」と書きました。べつにこれは「対応しなくて良い」という意味ではありません。例外はありません。すべてに「対応」そのものは必要です。
感謝をしよう
レビュワーは人間です。
研究論文だとわかりやすいですが、研究者は投稿者＝レビューを受ける側であると同時に査読者＝レビューをする側にもなりえます（ちなみに無給です）。
Steamの場合は製作者がレビューする側になることは基本的にないとは思いますが、それでも相手は人間です。
そして人間を相手にする場合、重要な武器になるのが「感謝」です。
「R2Rを書こう」の章の返答例で書いているように、感謝を伝えるのは非常に重要です。
なぜなら感謝という技はとりあえず置いておけば一定の効果があるうえに効果が高く、文字数稼ぎになるという「とりあえず出しておける」技だからです。
「まずは感謝ぶっぱしておけばいい」くらいの安定感があります。
応用もしやすく、
- （ジェネラルコメントに対し)「レビューありがとう」
- （とりあえず）「コメントありがとう」
- （具体的な指摘があったら）「指摘ありがとう」
- （こうしたらどうか？ という提案があったら）「提案ありがとう」
のように分岐も多数あります。
とはいってもあんまり感謝しすぎるのも胡散臭いわけで、「ここは置き感謝するにはちょっとスペースが怪しいな」という部分があったら、そこは多少感謝を抑えるのも技です。
ヘタクソな英語を使おう
現代では簡単に自然な英語翻訳ができるようになりました。
とはいえわれわれは本質的には英語はヘタクソなわけで、だったら少なくともレビュワーへのレスポンスに対してはヘタクソな英語を使っておきたい、という認識はないでもないです。
ここでいう「ヘタクソな英語」というのは「支離滅裂な英語」という意味ではもちろんありません。
難しい言い回しをしない、正しい文法で教科書的なわかりやすさを持つ英語、という意味です。
自分の理解や対処、修正が非常に洗練されたものであるならば、それに応じて英語も洗練されたものであることはふさわしいでしょう。
しかし実際は英語もなんとか理解しようと努める程度であり、言われた問題点を完全に読み解けるとは限らず、その場限りの対処でどうにか上手い具合に着地しようとしている、ということのほうが多いはずです。そうした中でただ文章だけ美辞麗句を並べ立てるのは、むしろ波風を立てる要素になりかねません。
変にこなれた英語表現を使うと「こいつそれっぽい英語はあるが、それにしては本質的にお粗末だな」と思われることは、むしろデメリットになりかねないのです。
とはいっても、めちゃくちゃな英語で回答したらそれはそれで問題があります。言語というのは伝わってこそ意味があるのです。
無駄な言い回しを除外したうえで、きちんと内容が伝わるような、そんな表現を心がけましょう。
以上が個人的にレビューを通すうえで気をつけていることです。
「感謝をしよう」のセクションでも触れましたが、投稿論文においては投稿者は査読を受ける側ですが、時に査読をする側にもなります。
「接客業を経験したことがあれば、店員を無下に扱わない」という話もありますが、レビューをする側に回ればレビュワーの苦労もわかるものです。
もちろん必要以上にへりくだっても逆効果なのですが、レビューをしているのは人間であり、到達地点は「良いものを出すこと」なのですから。
0 件のコメント:
コメントを投稿