統計ソフト選び：RでOK!

統計ソフト選びは好き嫌い、個人の慣れや需要に左右されることが多いと思うで参考になるか分からないが一応記事にしておく。 妻はRでパッケージを作っている側の人間なのでまたそっちの話を書いてもらおうとも思う。 「ペーパー書きたいんだけど、どれ勉強したらいいですか？」 という人に僕は恐る恐るRを勧めている。 僕が使ったことのあるソフトは SAS R Python (Python は言語だろ的なツッコミは無しで…) Stata 習熟度はまばらで用途も違うのだが、1番長く使っているのはSAS。Python は機械学習のプラットフォームを作るのに勉強して今はデータハンドリングに使っている。Rはほとんど data viz  (data visualization) のみ。Stata は授業で嫌々1年間使わされたがあまり身に入っていない。 全てのプラットフォームを使い尽くしたわけでは全然ないしもちろん見落としている長所短所があると思うので、こんな特徴もあるよというお声があればシェアしていただけたらとてもありがたい。 以下は僕の私見。 SAS vs. R ベーシックな臨床・アウトカムリサーチをするのに必要な解析手法はSAS 内で完結していると思う。Rはそれに加えて、プラットフォームが柔軟でdata vizが他と比べて格段に優れているので更に上を行く印象。Pythonはおそらく機械学習やディープラーニングの方に行く時に有効だと思うのだが、普通の生物統計系の解析やdata vizに弱い感じがする。 なので、例えば共同研究者がSASのスーパーユーザーでSASを使った方がコミュニケーションとりやすい、とかSASを手取り足取り教えてくれる、等の外的要因がない限りはRスタートが良いと思う。 基本的に、SASにできてRにできないことは無いと思う。また、SASのヘルプページは象形文字レベルの不可解さでRのサポートコミュニティーや掲示板の比にならない。 そして重要なのが、SASは有料でライセンスを個人で買う場合１００万円とかする。Rは無料なのでそこでも大差がつく。そしてWindows版のみ。 その上で僕が経験したSASが必要だと感じたかなり特殊なケースは： Centers for Medicare and Medicaid (CMS) などの政府機関は認定された開発者が書いたパケージ/ソフトではないとダメなのでSAS推奨。 ニッチなパッケージが何故かSAS専用にデベロップされていてR版が存在しない、もしくはベータ版オンリーで弱い。 に限られるので基本Rで良いと思う。 ただ、SASの方が最初の立ち上げ手順が簡単なことやデータシートが直感的だったりコードが書きやすかったりでラーニングカーブはRと比べて低めな気はする。 下はお蔵入りしたが気に入っていたggplotを使ってRで作った図。あとTable 1 作成を効率化できるtableoneとか気に入っている。後は、図を手書きっぽい仕様にしてくれるggroughでできた図をいつか論文に通したいと思っている。その程度でR語ってんじゃねぇという方、ごもっともです！ Stata vs. R or SAS Stataはスーパーユーザーの生物統計系の人に聞いたところSASと同等レベルのことができるので他に手を出す必要は感じない、という意見を得た。 僕はSAS, R, Python 後の強制Stataだったのであまり良い印象はない。

Reviewer response letter の書き方 Part2：理不尽コメント編

前回のPart 1 に数点捕捉したい。 Part 1 ではうわべのテクニックで査読をしのげる、という語弊があったかもしれないが、基本的にコメントを取り入れることで論文は向上すると思う。 ただ理不尽なコメントや的外れなコメントが付いて返答に困ることもある。 僕の経験から理不尽なコメントをタイプ分けしてみた。ちょっと査読者の悪口みたいになってしまうのはご了承いただきたい。 1. 大した理由もなく他の結果をみたがる 論文に建設的な興味を持ってくれて、この関連性もみたらおもしろいよね！という様なコメントをつけてくれる人は、度合いや言い方は違えども結構多いと思う。 本当に論文の主旨に沿っていて論文を深めることを見据えての追加解析なのか、ただ単に興味本位で言ってみただけのものなのかを区別することは重要ではないだろうか。 コメントが論文の主旨に沿っていたらもちろん追加解析したら良い。 しかし、おもしろそうだが主旨から外れていたり、特におもしろくなかったり、追加解析・データ集めに理不尽に手間がかかりすぎる場合は： “We thank you for the reviewer’s interesting and constructive comment. While this is a very interesting suggestion, it may be best pursued in a separate manuscript to address the importance of the problem in full extent.” という感じで、興味深くて掘り下げた方が良さそうなので他のペーパーでやります！という旨のレスポンスが使えたりする。ただ次のラウンドでも追求された場合は腹を括ってちゃんと対処しなければいけないかもしれない。 エディターが吟味した後に残ったコメントである可能性は常にあるので、そのジャーナルやエディターの慣習が分からない場合は躱すかどうかのさじ加減が難しい。 例えば以前、査読者とのやり取りの際に、対処した方が良いか判らない査読コメントがあったので「エディターの指示を仰ぎます」という返答をしたらエディターから「対処するべきだと思ったのでわざわざ残したコメントなので一回でちゃんと対処してください」というお叱りを受けたことがあった。 また、サブグループ解析メインの論文で、査読者２人＋エディター全員からの「全体コホートの解析もやってくれ」というコメントから何を思ったのか逃げ切ろうとした結果、かなりランクの下がる姉妹紙に飛ばされてしまった経験がある。 更に辛いのが、結局次のラウンドで全体コホートの解析をやらざるを得なくなったにもかかわらず姉妹誌から親元のジャーナルには戻してもらえなかった。これはかなり悪手。

Reviewer response letter の書き方: Part 1

サブミットした論文の Decision が忘れた頃に届く。 ドキドキしながら1パラグラフ目を流し読みしてまずrejectではないことを確認。 あぁよかった。 Major revision らしいがこれはいけるかも。 レビュアーのコメントを見ながらメールをスクロールしていくが 読んでも 読んでも 読んでも 終わらない。 Associate editor、安定の適当さ。 Reviewer 1、２、３、４…は、４？？ Statistical reviewer, うーんキビしいご指摘… Associate statistical reviewer, 統計レビュアー二人もいる？？ レビュアーをつけまくることで有名な胸部心臓外科のジャーナルがあるのだが、こんな感じが多い。もちろんリジェクトされることも結構ある。 査読者の数に関わらず、どのジャーナルでもReviewer response letter を書くのは辛い。 僕にとっては論文掲載までのプロセスの中で１番辛いステップだと思う。 Response letter を書くときの僕なりの心得は： もちろん個人のスタイルがあると思うのだが、これは僕なりに試行錯誤しながら上の人に言われたことを取り入れて行っていること。 続きはNoteで。

論文１本書くのに何時間かかる？

論文を書きまくるには効率化を図らなければいけないが、一定の時間がかかる。 では論文を１本仕上げるのにどれくらい時間がかかるのだろうか。 かなり色々な要素によるのだが、原著論文一本仕上げるのには 大体40-150時間くらい かかるのではないだろうか。 3000語程度の書き物に100時間以上かけて、お金がいっぱいもらえるとか何かいいことがあるに違いないと思うかもしれないが 特にいいことはない。 それでも論文書く人たちへ… 時間のかかり具合の要素としては データが既に存在するか 仮説とデザインの煮詰まり具合 解析のスピード 論文英語のレベル   といったところだと思う。 そして時間をかけた論文が必ずしも高インパクトに仕上がるとは限らない。 むしろ勢いのある爆進していったプロジェクトの方が、ゆっくり煮詰めていったものより出来が良かったりする。 僕の最短は30時間強の原著論文で、他のプロジェクトから派生したものだったのでアイデアも固まっていたしデータもあったので勢い良く進んで出来も僕の書いたものの中では良い方だった。 学生の頃に手掛けた長い、泥沼にはまったもので大体200時間くらい。これはたくさんのジャーナルから蹴られまくった挙句インパクトファクター１ちょっとの底辺ジャーナルに落ち着いた。 上記の4つによって変化する時間を抑えていけば効率化につながると思う。 1. データが既に存在するか これはスタディーデザインと親密に関わっているのだが、もちろんデータが既に存在する場合とデータ集めから始めなければいけない場合なら前者の方が絶対にいい。 結局のところ、論文は検証可能な事象（データが採れる・存在する）の枠に収まらなければいけないので、超重要なリサーチクエスチョンがあったとしてもデータが採れるデザインに落とし込まなければいけない。そしてその過程で元々検証したかったリサーチクエスチョンからどんどん離れていってしまうことも少なくない。 なので、ある程度リサーチクエスチョンが固まっているものを既存のデータに当てはめて妥協しながらリーズナブルな労力で検証可能なものにすることは自然なプロセスだと思う。 変数がしっかり定義されている既存のデータベースの例えはこちら。 無料で公開されているデータも上手く使えばかなり良い論文が書けると思うので（実際かなりの数の高インパクト論文が一般公開されているデータから書かれている）、初期投資として、どういったデータベースが存在するのかを勉強するのはオススメ。 2. 仮説とデザインの煮詰まり具合 これは本来なら大前提であるべきステップだが、ある程度データベースの型とサンプル数がわかっている状態にならないと、どういった仮説が検証可能で統計的に有力な解析ができるかどうかが分からないことは多いと思う。 なのでサンプル数の見当が全くつかずにデータベースを構築しなければいけない場合、泥沼にハマるリスクは覚悟しなければいけないし、サンプル数が少なすぎるとわかった時点でプロジェクトを中止して損切りする決断のは大事だと思う。サンプル数についてはまた書きたいが、スタディーが上手くいくかどうかの最重要ファクターだと思う。 そういった理由で僕は最近は既存データベースを使うようにしている。 3. 解析のスピード ほとんどの後ろ向きの効果比較研究は、かなりファンシーな統計手法に手を出さない限りは一つのテンプレートで解析ができると思う。 なのでそのテンプレートが出来上がっているかどうか、またそのデータベースの変数用のコードが存在しているかどうかで結構時間が変わってくる。 なのでコードのテンプレートを作りにくい解析ソフトはあまりオススメしない。JMPなどがこれにあたるのではないだろうか。 僕はSAS, R Studio, Jupyter のPython を必要に応じて使い分けている。 また、データベースを変える度に新しいデータベースの性質を勉強してクリーニングのコード、新しい変数の名前に合わせたコードを書かなければいけないので僕は一つのデータベースに慣れたら３−４本くらいは書こうとする。せっかく時間をかけてデータベースの詳細を学んでコードも書いたのだから、その知識が活きて比較的簡単になる２本目３本目へといきたくなってしまう。 もっと言えば、最低数本は書ける目処の立つデータベースじゃないと手を出さない。   4. 論文英語のレベル これは慣れるしかないと思う。ネイティブでも論文を書いたことのない学生に書かせると全部書き直しになることは多いので、筆記英語力云々の問題だけではないと思う。もちろんリライトサービスやかなり使える校正ソフトが存在するのでここは工夫で乗り越えられるポイントではないだろうか。 まとめ 原著論文１本書くのにはどうあってもかなりの時間がかかる。 研究チームが上手く機能している場合はタスクを分担して効率よくプロジェクトを進められるが、データベースに関する知識とサンプル数に大してシビアにアプローチするのことでかなりの泥沼プロジェクトを回避できると思う。 統計ソフト、コード、執筆は全て、一通り全ての手順を踏んで見て自分のテンプレートを作るのが効率化の第一歩なのではないだろうか。

臨床論文を量産する方法：まじめ編 Part 1

  前回の邪道編では、タイトルの通りとにかく数を稼ぐことだけを意識した場合の方法を紹介した。 実際にアカデミアで生き残るためにはおそらく通用しない手段なので、ネタ程度で受けとめておいてほしい。 さて本題   結論から言うと、即効性のあるテクニックや知識は存在しないのではと思う。 というよりは、回避可能な落とし穴を避けながら何をどう頑張ればいいかを追求する、というような上達論的な話   ただ、僕がこの記事に需要があるのではと思う理由は、   僕自身が書き始めたばかりの頃、忙しい指導教官に放置され 採択までのイメージが全く湧かずありとあらゆる落とし穴にハマりまくりかなり試行錯誤した のでもし似たような境遇にいる人がいれば参考になるのではと思う。   臨床論文を書きまくるには：   1. レベルは低くていいから全ての手順を自分でこなせるようになる。   これはスタディーデザイン、IRB（施設内審査の申請）、データ集め、解析、執筆、サブミット、レビュアーへの返事・反論を経てアクセプトまでの全ての行程を指す。 どれだけ質が低くても、この一連のプロセスをこなして肌感覚があるのと無いのでは、最適化へのイメージの湧き具合が全く違うと思う。 というのも、一連の流れを理解していないと至るところで落とし穴にハマりやすい。 スタディーデザインやデータ集めは解析のアプローチを意識して行わないと、さぁ解析しようかという時点でとんでもない問題が見つかることがある。   地味な例えになるが、学生時代の実体験：   n=400くらいのスタディーのために心臓手術後のエコーから拍出量やら１０個くらいの変数を集める、という作業で 数日かけてデータ集めをした後にエコーの日付を記録し忘れていたことに気付いてもう一度400のカルテをレビューし直した後 さぁ解析かというところで、複数エコーのある患者の場合どのエコーを使うかを定義していなかったので、術後最初にとられたものだったか一年後以降のものだったのかetcが標準化されておらずにもう一度定義に沿ったエコーのデータを採るために400カルテを再度レビューし直した。 時間にしてみれば１週間程度の遅れだったと思うが、データ集めを始める段階で予見していれば簡単に避けられたミスなだけに精神的にも疲弊するしプロジェクトの勢いみたいなものも削がれてしまった こういった地味なミスが重なって結局プロジェクトが頓挫する、というのは割とある話ではないだろうか。 更にあとの方で、デザイン的にはn=400から更に除外項目をかけて250くらいのもっとピュアなコホートを使った方が良いことに気づき、もっとデザインを詰めていれば差の150人分のデータ集めにかけた時間が節約できたことを軽く悲しがったり 更にもっと後の方で、この再入院の変数はどう定義したの？みたいな質問が共著者から来た時に、 前もって定義を書類化していなかったため標準化されておらず、「手術関連っぽい」理由での再入院以外はカウントしていなかったという、曖昧で再現不能な変数をアウトカムとして使っていた、とか。 こんな凡ミス経験はいくらでもあるのだが割と時間のあった学生時代にたくさん間違って経験値を稼げたのはせめてもの救いだった。 しかしかなりのミスは一連のプロセスを理解していれば避けられたものなので、おなじ間違いをあえて経験することは全く必要ないと思う データマネジメント、解析、執筆はスキルとしては全く別物だが とにかく一連の流れがイメージできて２手３手先に何が必要かが予想できるようになることは一番大事だと思う。 そしてそれを習得するには、質が低くてもいいから、この世の全てのジャーナルにリジェクトされてもいいから、とりあえず一本最初から最後までやり切るのが最短距離だと思う。 Part 2 はデータマネジメント・解析に触れる

論文を量産する方法：邪道編

科学の発展に貢献する、などのキレイゴト抜きでとにかく量を稼ぐ方法は存在する。 別の記事でも書いたように、数がモノを言う場面というのは存在するわけであって、次につながるような機会をもらえる「数」を稼ぐテクニックをまとめる。 ただ「ほとんどの臨床論文は無意味」なのでここで紹介する邪道テクニックはネタ程度で受け止めてほしい。 以上を踏まえたうえでどうぞ   1. Letter to the Editor Research letter は短いが立派なサイエンティフィックな論文であるのに対して、Letter to the editorは人の論文に対するコメント。俗に uninvited editorial (依頼されていない論説) などと言われる。 Editorialは際立ったレビュアーやそのトピックの権威にジャーナルが依頼して書いてもらうものに対して letter to the editorは読者が誰でも寄稿できる記事。 もちろん、有意義なコメントが割とフェアな観点から書かれているものが採択されるのだが、ほとんどのものが500語くらいの超短編で採択率もかなり高い。 僕は今までに５本書いたが全て採択されている。 PubMedにもインデックスされるし、もちろんCVに載る。 ただ、ファカルティークラス（助教以上）になると昇進用のCVにEditorial/Letter のセクションを論文のセクションと別に設けている人がほとんどだと思う。 原著論文 一本仕上げるのとletter to the editor 一本では労力も価値も全く違うので同じ一本として扱うのはアンフェア、という認識からだろう。 ちなみに僕は毒にも薬にもならないような letter to the editor がJAMAに掲載された経験がある。当時の研究トピックにハマった論文がJAMAに掲載されていたので、４時間くらいで仕上げて投稿した。 もちろんJAMA論文、という認識はまったくない。   また、メソッドが破綻しているスタディーを指摘するレターは有益なのではと思う。 僕も一時期使っていたNational Inpatient Sample という、全米入院データサンプルを使った論文がクリー○ランドクリニックのグループからJAMA Surgery に掲載されたが、致命的な欠陥があったのでそれに関するレターを書いたことがある。 National Inpatient Sample ではデータの性質上、併存症と合併症の区別ができないはずなのに、併存症だったかもしれない合併症をoutcomeとして行われたスタディーだったのでそこを指摘した。