1) SIGGRAPH/UISTの論文の書き方に慣れている人に見てもらう。

なんといってもこれが一番です。 どんなに自分で完璧を期したつもりでも、 慣れている人からみると当然の間違いを犯していることが ありえます。 結局の所、判断するのは個人としてのレビューワーであり、 彼らが何をどう判断するかは、SIGGRAPH/UISTに詳しい人 （＝レビューワーになりそうな人）に聞くのが一番です。 いざというときに助けてもらうためにも、学会等で 積極的に自分の研究を紹介して、その道の第一人者と 仲良くなっておくことが大変重要です。 後は当然ですが、過去のSIGGRAPH/UISTの論文をよく読むこと。 過去10年ほどの間にどんな発表があったのかを頭にいれておき、 かつ関連性の高い論文については構成や議論の進め方を 含めて詳しく理解しておくことが前提となります。

2) 論文は時間をかけて完璧なものにする。

どんなにすばらしい内容でも、論文としての書き方がまずいと 落とされます。読みやすい文章の構成、英語の質、関連研究の正確な参照、 有効性に関する明確な議論など、どれが欠けてもだめです。 日本人であるというハンディを考えると 最低１ヶ月〜２ヶ月前には実装を終えて論文書きに専念することが 理想です。書いては書き直す作業を何度も繰り返しましょう。 ビデオも含めて、事前にSIGGRAPH/UISTに詳しい人にチェックしてもらえれば完璧です。 最後に必ずネイティブの人に英文校正をしてもらいましょう（商業サービスでも可）。

3) ビデオを作りこむ。

レビューにおける判断はビデオの内容で大きく左右されます。 インタフェースが本当に使いやすいかどうかは文章だけでは判断できないので、 必然的にビデオで動いている所を見て判断することになります。 ただ単に動いている所を漫然と撮るだけでなく、 見ただけで要点が理解でき、かつ見ている人が使いたくなるような 説得力のある例を含めることが重要です。 ビデオも論文と同様、何度も撮っては外部の人にチェックしてもらって また撮りなおすといった作業が有効です。

4) プロジェクト開始時からSIGGRAPH/UISTの査読に通すことを念頭において開発を進める。

レビュー時には「既存の手法に比べてどこが新しくかつ優れているのか」 が最大の焦点になります。逆にいうと、どんなにすばらしいシステムでも、 すでに似たものがあれば、あっさり落とされます。 落とされる論文を見ていると、この点をよく認識していないで 漫然とシステム開発をしている例が多く見受けられます。 実装時から、既存の手法との違いを強調し、差分が前面に出るように 開発を進めることが大切です。

5) 落とされる理由を理解する

SIGGRAPH/UISTは例年採択率が2割以下と大変厳しくなっており、 落とすべき理由が見つかればすぐに落とされてしまいます。 以下によくある不採択理由を列挙するので、引っかからないかどうか よくチェックしてみてください。

1. 既存手法と比べて差分が少ない。単なる既存技術の組み合わせである。
2. 有効性が明らかでない。例やビデオ、ユーザテスト等で有効性を示す必要がある。
3. 文章が読みにくい。何が新しいのかよく分からない。余分な記述が多い。
4. 技術的な内容が非常に瑣末(trivial)である。誰でも思いつく。あたりまえ。
5. 机上の空論ばかりで、具体的な実装内容が不明。何をしたのか分からない。

コメント等歓迎します。