本稿では,なぜ論文は読みづらいのかについての私見を述べることから始める.簡潔にいうと,論文が読みづらいのは,あるいはもっと正確には論文を読んで研究を進めようとするのが難しいのは,論文というものは研究の進行と逆の順序で書かれていることが多いからである.
(浅野哲夫: 計算幾何学でいかに論文を書くか, 電子情報通信学会誌, Vol.93, No.2, p.162)
では,なぜ定義が問題なのか.論文が完成するまでの研究の経過を考えてみよう.論文の著者は最初から定義を思いついたわけではないだろう.よほどの天才でない限り,最初は成り立ってほしい定理を予想することから始め,小さな例題について定理の性質が成り立つかどうかを手で検証する.(略) このままの形で論文にまとめて国際会議やジャーナルに投稿しても,まずそのまま受理されることはないだろう.内容が洗練されていないからである.正しいということだけでは価値がないのである.
ここで定義が登場する.多くの場合分けをまとめて,簡潔に表現するために新たな概念の定義が必要である.どんな定義を思い付くかで論文の価値が決まるといっても過言ではない.良い定義を思い付けば頭の中が整理されて,更に別の問題にも同じ定義が応用できることが分かったりする.このように,定義は研究を進めていく上で遅い段階で生み出されることが多い.その定義が論文においては真っ先に登場するので,研究論文を書いたことがない学生が初めて読むと,研究では先に定義が必要なのかと思ってしまうことがある.(略)
(同,p.163)
この著者の名前は,記憶にあります.日記を見直してみると,Placeholder - わさっきで著書を取り上げていました.
定義・定理という言葉が出ているので,数学に近い分野での,研究の進め方のように見えます.開発したシステムが中心的な成果となる,自分の研究室では,「定義」は,システムの利用対象に相当しそうです.
上の引用から明確に伝わってくるメッセージは,「思索の順序」と「文章の組み立て」は違う,ということです.この観点で,最近読んだWebページと,自分の日記を,見直してみました.まずは,お外のを.
博士のときの研究で、@taku910さんからアイデアをもらった研究があるのだが、あるとき @taku910 さんがメールをくれて10行くらい箇条書きで「イントロはこう、関連研究はこう、アルゴリズムはこんな感じで、実験はこういう実験をすれば正しさを示せるはず。これで国際会議1本くらいは行けるでしょう。どうでしょうか」という内容を示してもらい、「え、こういうふうにやるんだ?!」と本当にびっくりした。ほとんど穴埋め問題になっていて、しかも穴も調べるだけで分かるという感じ。でも、実際そうやって論文(ストーリー)を書いてから実験をすると、びっくりするくらいスムーズに行くので、たぶん研究のお作法としては、こういう手順でやるべきなんだと思った(それ以降自分もそのスタイルを真似している)。どのように穴埋め問題を作るかが出題者の力量が問われるところなのだが、穴が埋まっていない状態の問題用紙を見ただけで、出題者の意図というか、いい問題 (=研究)かどうかが分かるのである。修士では問題解決能力が必要、博士では問題発見能力が必要、とよく言われるが、自分からすると、修士では穴埋め問題に答えられる能力が必要、博士では穴埋め問題を作る能力が必要、とそういうことだと思う。
博士で身につけるべき研究力とは穴埋め問題の作成能力 - 武蔵野日記
とはいえ、エンジニアとしては「まずコード書こう」「まずデモを作ろう」という姿勢は賞賛されるもの(実際ベストプラクティスでもある)なので、どちらがいいというものではなく、分野や職種によって違う、ということであり、自分がやりたいことと分野や職種がマッチするような選択をしましょう、という話。自然言語処理なんかだと、「まずデータ見よう」「まず人手で少しタグづけしてみよう」というのがあって、そこから「じゃあこういう研究になるか」というのが決まり、そこでようやくそれに必要なプログラムを書く、という展開になるのであり、実際プログラミングに費やす時間は全体からすると本当に少ないのではなかろうか。数字を挙げた方が実感湧くのであれば、自分の場合、論文を書くときプログラミングに費やす時間は多くて全体の1/3、少なければ1割かそれ以下くらい。分野や研究スタイルによっても違うかもしれないが、これは研究計画書を書いたりする時間や雑用の時間は含めていないので、職業としての研究者におけるコードを書く時間の占める割合は、仕事全体からすると本当に少なくなってしまうのではないかなーと思う(情報系ですらこれなので、それ以外だとどうなることやら)。
例えばこんな感じ、ある朝いつものようにラボにやってくると、Hey Kaz, I have an idea for a work, let's have a chat、みたいな感じでやってくる。行くと紙をペラッと持っていて、一番上にタイトル(メインメッセージ)、その下は左がサブメッセージが五つぐらい並び、その右に一つ一つデータ、実験結果のイメージ、見せ方が絵コンテのように入っている。要は紙芝居的なストーリーラインになっている。その一つ一つが大体非常に手堅い手法によって、どの程度のワークロードが発生するのか、誰にどう聞くとすぐに立ち上がるのか(註:同じラボの人とは限らない)が見えている。
圧倒的に生産性の高い人(サイエンティスト)の研究スタイル - ニューロサイエンスとマーケティングの間 - Between Neuroscience and Marketing
(略)
で、これに基づいてある種、その五つなら五つのパズルを埋めるように研究を進めていく。当然、この論理が崩れると、根底から見直しが必要という、issueの流れでいくと上流にある、かなり根源的な課題から取り組んでいく。
これは、こうやって聞くと当然のことのように思えるかもしれないが、殆どの問題解決者が出来ていない非常に重要なポイントだ。問題解決は常にここが崩れると話が崩壊するようなところから行わないといけない。例えば、恋人が出来ない人の問題解決であれば、会う人の数が足りていないのか、会ってからの成就の確率が低すぎるのか、がクリアにならなければ、問題解決は運頼みになってしまう。:)要は課題解決の論理のツリーがどこから始まると考えるべきか、ということでもある。
そして、アウトプットが出て論理に影響が出そうであれば、それに合わせて全体のストーリーライン、トップラインのメッセージを見直していく。したがって、当初の仮説の視点から見ると失敗しているのに、トップジャーナルに載ってしまうなんて言うことがいくらでもある。これはものすごいことだ。
文章のパワーがすごいです.多数のはてブにも,うなずけます.
パワーも説得力も,そもそも発信者のメディア力*1からして違うのは承知していますが,自分で過去に書いたものを並べておきます.
上述の本には,「証明」だけでなく,「証明するための考え方」が書かれています.すなわち,証明という名の道筋を構築することを目的として,スタートラインに何があって,どんな道具を使っていってゴールを目指せばいいかが,きちんと記されています.
証明とプログラムコード - わさっき
(略)私は,研究発表はコミュニケーションの場なのであり,したがって手法・手順だけでなく,その分野でよく知られた例題や,未解決あるいは解決された具体的な問題を提示することは,研究活動に説得力を持たせまた議論を活発化させる,極めて重要な行為だと,ここしばらくの発表と質疑を見聞きして,考えるようになりました.
例題から始めよう - わさっき
もちろんその例題にこだわるあまり,(例題にすぎないのに)例題こそ解くべき課題,ゴールだと誤解されてしまってはいけません.それは例えば,その例題の中にどんな構造が含まれているかを指摘することで,回避できるものです.
卒業研究と違うテーマで修士論文のための研究をすることになった人は,自分が理解でき,プレゼンを通じて親しみを持ってもらえそうな「例題」がないか,探してみてはいかがでしょうか.データベース関係であれば,実データを「揉んでみる」というのも,手です.
卒業研究を発展させるという人は,例題から始めるわけにはいかないでしょう.しかし,卒研活動で得た具体的な「成果」を示してから,それを踏まえて次にどんなことをしたいか,何を明らかにしたいかを提案すれば,これまた研究を周囲に理解してもらいやすくなるはずです.
就職活動の「エントリーシート」にヒントを得て,学会発表や修士論文・卒業論文を作る際に,研究報告シートをExcelでフォーマット化しました.
今年度の研究室独自の試みを振り返る(1) - わさっき
ここには,タイトル,著者,執筆完了日,発表方法,分野,研究対象・素材,使用する手法,何をするか,研究の動機・着想または仮説,この研究で関係・影響する人々,評価方法,評価結果,特長,先行研究,残された課題を記載してもらいます.
原稿を「書き始める」段階でまず作ります.途中で1〜2度,加筆訂正を促し,提出したら執筆完了日の「(執筆中)」を取り除いてもらいました.
*1:昨年度,比較的よくできる学生も勘違いしていたのですが,研究報告シートは「一度書けば終わり」というものではなく,まず書いてみて,教員の指示や,自分が研究を進めていく中で,その記述を変更し充実させ,研究終了時に完成版としてfixしてほしい,という意図で書かせています.fixしたExcelファイルは,しかるべきところに転送され,研究室の財産となり,あるいは,過去に誰が何をしたかを手早く見直すための資料となります.
今期の研究室独自活動 - わさっき
「書き順」といっても,漢字ではありません.プログラム一般です.とはいえC言語に限定しておきます.
書き順 - わさっき
関数を作るときは,(1)関数名,(2)戻り値の型,(3)引数の順に決めましょう.