条件分岐で書く論文執筆

はじめに

企業の研究開発職に勤めています。業務と並行して論文投稿を目指そうと思うと、当然ですが学生の時より圧倒的に時間が取れません。そこで、論文執筆を支援するフローチャートを作成しました。
これまでに以下の状況に陥った時の自分なりの解決方法ですので、同じ境遇の方がいらしたら参考になれると幸いです。

• これまでやってきた研究開発業務から論文を作成したい
• 手元の業務成果がそもそも論文になるのかを判断したい
• 業務での研究開発の成果を効率的に論文にまとめたい

論文の骨子を作る

タイトルのフローチャートはこちらです。大きな図なので順を追って説明します。

#1 研究成果を論文にしたいか

自分はそう思っていても、チームメンバーは成果の論文執筆に関心を持っていないことも多いです。まずは研究成果を論文にしたいかをチームメンバーに確認して、協力してくれる人を探しましょう。今は論文を書く段階ではない、と判断した場合は、デモ機の作成やプロトタイプの実装等、他の業務があるでしょうから、技術開発に集中しましょう。

#2 やりたいことは明らかか

研究はしたいけど何を研究したいかが決まっていない人は意外といます。マルチモーダルAIを使ってよい感じの研究がやりたい、という人もいればchatGPTを使ってチャットボットを作りたい、小型のロボットを作りたいという人もいます。自分もそう思う経験もありましたが、そんな時は、やりたいことを「〇〇を××したい」の形に明確化することを意識しました。

とはいえ「チャットボットを作成したい」だと、手段が目的になってしまっているので、〇〇には問題を、××には解決方法を入れるとやりたいことが具体化できると思います。例えば、「書き言葉を話し言葉に変換したい」「生成型言語モデルの出力中の不適切なフレーズを検出したい」「入力画像から前景の物体のみを抽出したい」「マイク入力から環境音だけ取り除きたい」などです。

#3 〇〇と××の定義は明らかか

〇〇と××の言葉の中に、社内でしか通じない言葉や、受け手の数だけ解釈が存在する言葉が使われる場合があります。受け手の数だけ解釈が存在する言葉というのは、例えば「高品質」「優れた」「リアルな」「気づき」「適切」「印象」などの抽象度の高い単語です。使いやすいのは確かですが、抽象度の高いまま研究を進めてしまうと、例えば評価の際に何を測定すればよいか分からなくなる場合があります。良い論文ほど、この定義がよく明らかにされていて読みやすい印象があります。

受け手の数だけ解釈が存在する言葉を使わないためには、〇〇と××を初めて聞いた人でも確実に伝わる表現に置き換えることを意識するのが重要だと考えています。論文でよく見かける例としては、「以下の条件を満たすものを本研究では〇〇と呼ぶ。条件1:---, 条件2:---」という流れです。

#4 すでに(部分的にでも)実装されている技術はあるか

公開されている技術を組み合わせるだけでやりたいことが成し遂げられるのであれば、おそらくそこに研究テーマは無いです。単なる組み合わせだけではやりたいことが達成できない場合は、先行技術を調べましょう。多くの場合はやりたいことに近いgithubのリポジトリが見つかって、それをローカル環境で動作確認するところから始まるように思います。運が良いと社内ですでに実装されていることもあります。ここで重要なのは、すでに実装されている技術がどんな仕組みで動いているか理解することです。動いていればフローチャートが書けるはずですから(稀に動いているのにフローチャートが書けないものもあります、筆者は手作りブラックボックスと呼んでいます)、入力がどんな情報に加工されて出力されるのかを理解しましょう。

#5 現在の実装だけではできない点・足りない点は明らかか

仕組みが分かれば、できることとできないことが予想できます。いくつか入力を試してみて、今の実装で対応できている点と、今の実装では足りていない点を言語化しましょう。ここは色んな粒度のできない点・足りない点が出てきますから、大きすぎず小さすぎずの粒度でできない点・足りない点を挙げるのが重要です。(例えば画像認識の論文に対して、動画入力に対応していない、というできない点は粒度が大きいと筆者は思います。画像認識ならクラス数が少ない、低頻度クラスが多い、高解像度画像を大量に処理するときに推論速度が遅くなる、などが挙げられると思います。)

#6 できない点・足りない点を解決するための案と仮説は明らかか

上で挙げたできない点・足りない点はなぜできない・なぜ足りないのか考えましょう。その時考えた「なぜ」の理由が仮説の卵になります。これらの仮説を踏まえて、仮説で挙げた原因を解決する解決案を考えましょう。これが提案手法になります。この仮説が正しいと、提案手法が有効であることになり、提案手法はできない点・足りない点を解決するための解の一つになります。ここで重要なのは、解決案だけを考えるのではなく、仮説と解決案をセットで考える点です。解決策だけ考えてうまくいった後になぜうまくいったかを考えるやり方もよく見られますが、このやり方だとうまくいくまで終わりが見えず時間を大量に消費し疲弊してしまいます。

なぜうまくいかないのかを自分なりに解釈して仮説を作り、それを解決するための案を作ります。この時点で評価指標が明らか、もしくは検討が付いていれば、従来法と比較して、提案手法はどんなグラフを描けるのかまで作れると考察がしやすくなります。実装する前に予想結果のグラフまで作ってしまうのは気が引けるかもしれませんが、締め切り直前で考察をひねり出す苦しさよりも余裕のある段階で考察の種を作っておく、と考えると気が楽になります。

#7 現在の環境で容易に実行可能か

実装は一度動いてからが始まりです。機械学習系のタスクであれば学習に十分なデータセットがあるのか、AWSなどのクラウドの計算資源を使うなら何回学習する予定か等をざっくりでよいので把握しておかないと、終盤になって成果に必要なデータや計算資源が足りなくなることがあります。実験参加者さんによる実験をする必要があるのなら、謝礼や実験委託費も踏まえて、実行可能か検討する必要があります。

おわりに

論文執筆を支援するフローチャートを作りました。初めて論文を書く方や、企業で研究開発職について時間がないながらも論文執筆を行っている方等、様々な方の助けになれれば幸いです。

このやり方が一番だと主張するものではありません。こんなやり方もあるよという方法を紹介してもよいという方がいらっしゃいましたら、教えていただけますと幸いです。