読者です 読者をやめる 読者になる 読者になる

Lean Baseball

Engineering/Baseball/Python/Agile/SABR and more...

【雑感】PyCon JP 2016トークの外部審査員をしました&その学び

こんばんは!

最近週末は野球hackとデータを眺める時間に幸せを感じている人です.

2014年、2015年の二年間参加者&スピーカーとして楽しませてもらったPyCon JPですが、「新しいチャンジをしてみよう!」という事で、セッショントークを採択する「外部審査員」なるものを先日やってみました.

PyCon JP Blog: トークのレビュワー(外部審査員)の募集開始しました

その時のレポートと学びを自分向けメモ&「私もカンファレンスに登壇したいな!(※言語限らず)」という方に向けての学びをここに共有しようと思います.

外部審査員のお仕事

上記のエントリーからのおもいっきり引用ですが、外部審査員のお仕事は以下の2つです.

レビュアーはリンクに記載の通り、一般公募していました.*1

プロポーザルに対するレビュー

トーク一覧 | PyCon JP 2016 in TOKYOに応募されたトークの内容(タイトル・目的・概要etc...)に目を通し、+1〜-1の間で投票を行い、コメントを入れます.

また、必要に応じてプロポーザルを提出した方にフィードバック(質問や修正の提案など)を行います.

投票はすべてのプロポーザルに対して以下の点数で投票を行います.

+1 - Good proposal and I will argue for it to be accepted. (良い、採用されるべき)

+0 - OK proposal, but I will not argue for it to be accepted. (まあまあ、採用されてもいい)

−0 - Weak proposal, but I will not argue strongly against acceptance. (ちょっと弱い、採用されても文句は言わない)

−1 - Serious issues and I will argue to reject this proposal. (問題があるので、採用されるべきではない)

今年は108件のプロポーザルがあり*2、私は自分のプロポーザルを除く107件に対して投票*3を行い、いくつかのフィードバックをさせてもらいました.*4

トークを採択する

レビューおよびフィードバックを6/25(土)いっぱいまで行い、トークの採択を先日の日曜日(6/26)に行いました.

pyconjp-staff.connpass.com

今年のPyCon JPでプログラムを担当されている@shimizukawaさんを始めとしたPyCon JPスタッフ、私のような外部審査員を含め10人ちょっと(リモート参加含める)で4時間もの議論を重ね、108件のトークから採用(と予備)を決めました.*5

トークはどのように決まったのか

結果

約30人のレビュアーのレビューと採択MTGで決まったトークの一覧は以下のとおりとなります.

pycon.jp

採択された皆様、本当にホントにおめでとうございます!!!

一方で不採択(&予備)のトークも大接戦で選ぶのが本当に難しかったです.

つぶやいていないレビュアーも含め、口々に「難しい」「レベルが滅茶苦茶高い」「判断難しい」と異口同音に感想を述べていました.*6

トークを採択した基準(ただし言える範囲で)

そんな「レベルが高い」「判断難しい」トークはおおよそ以下の観点・ルールで採択されました.

ここでは「おそらく言っていいだろう」という部分のみ言及します.*7

というより、PyCon JPのブログに書かれた観点そのものとなります.

要点をまとめると、

  • 多様性重視
  • (多様性の観点で)投票数が多い「だけ」で決めているわけではない

というのが基準となりました.

トーク・レベル・分野の多様性(Everyone's different, all are wonderful)

今年のPyCon JPのテーマである、

Everyone's different, all are wonderful (みんなちがって、みんないい)

の価値観を大切にした上でトークを採択しました.

最近Pythonでデータ分析(AIとか機械学習とか)が流行ってるからといって、データ系のトークだらけになったり、初心者向けのトークが多くなったり...という隔たりが無いよう、

  • 分野(データ・ウェブ・組み込み・コミュニティ・etc...)
  • 難易度(上級・中級・初級)
  • 言語(日本語・英語、英語の発表は30%程度)
  • ニーズ(マジョリティーなモノもマイノリティーなモノもバランスよく)

といったあたりをまんべんなく網羅できるように採択しました.

評価得点

枠が競っていたり、悩んだりしたものについては、レビューの投票数、コメント(ポジティブ・ネガティブ)を参考にしました.

ここの議論で4時間の半分以上を使っていたと思います.

ここではプロポーザルの内容を深掘りしたり、Pythonやその周辺の技術や環境、その他の観点での熱い議論があり、採択MTGは大変盛り上がりました.

学び

雑感めいた内容ですが残します.

レビュアー(私個人)として

100件ちょいのプロポーザル査読は隙間時間で頑張ればなんとか出来る

  • 移動時間
  • 食事中
  • 寝る前

この辺の時間でなんとか片付いた

フィードバックのコメントは発表者・レビュアー双方共に大切

  • 適切なフィードバックとコメント欄の議論でプロポーザルが見違えるように良くなった事例があった
  • レビュアーとしても嬉しい&発表者的にも嬉しかった(と思われる)
  • ちなみに発表者の個人(私)はフィードバックコメントがもらえず少し悲しかった

多様性大切!

  • 分野・難易度・言語・ニーズすべてで満遍なくいい感じの採択ができた
  • (結果論になりますが)常連のPythonistaから初登壇の方まで、発表者の多様性も担保されているような気がした

疲れた

  • この一週間寝不足に
  • 来年どうしよ...

「私もカンファレンスでしゃべりたい!」という方へ

PyCon JPの話ではありますが、これは他の言語のカンファレンスにも通じると思います.

ご参考にどうぞ.

フィードバックを一言でいうと

プロポーザルはちゃんと書け

  • 必須項目のみ、最低限入れられてます!的なプロポーザルはどうしても訴求力が足りないし弱い. 「コード読めばわかる」的なエンジニア気質はここでは捨てたほうが良策.*8
  • 訴求力足りない&弱いと、フィードバックのコメントも「アウトライン書いて」「もう少しkwsk」と弱くなってしまう.
  • 私個人の感想ですが、2,3個の「薄いプロポーザル」を書くぐらいなら、1個の「濃いプロポーザル」を書いたほうが採択の確率は高くなると思う.
  • とはいえ書きすぎる、文量多すぎると読むのも大変だし論理が破綻してると読み手も書き手も涙目になるのでバランスは考えましょう.
  • 参考資料や実績、絵図が入ってるプロポーザルは個人的に大変ありがたかったです.*9

Pythonの何かを発表」するのか、「Pythonを使って何かを成し遂げた発表」をするのかを明確に書こう.

  • Pythonが目的(前者)でも、Pythonを手段に目的が別(後者)でもどちらでもOKだが、「どっちを軸にしたプロポーザル」なのか明確に書こう.
  • 一見良さ気なプロポーザルでも読み進めると「え、これPythonでやる必要あるの?」「ホントにPython使うのこれ?」みたいな勿体無い内容のものがいくつかあった.
  • また、目的・手段どっちも取ろうとしている or どっちも曖昧で振り切る方向がわからないモノもあった.
  • これらもレビューのコメントに困ったなあ...
  • Pythonの例で書いていますが、これは他の言語やFWでも一緒と思われる(RubyでもGolangでもAndroidでもあるだろうきっと)

で、@shinyorkeさんのトークはどうなったの?

野球トークの行く末ですが、

お後がよろしいようで.

*1:これは自分の所感&想像ですが、レビュアー自体がPythonのプロな必要がある&レビュー開始からトーク決定まで半月も無かった関係上、PyCon JPスタッフやPythonista達のつながりを介して集められた印象があります.私もそんな中@shimizukawaさんに声をかけられました&面白そうと思い二つ返事でOKしました.

*2:PyCon JP Blog: トークの応募数をPandasで集計してみた

*3:(当然だが)自分のプロポーザルに対して投票・コメントはできない

*4:土日の隙間時間、平日の帰りの電車・晩ごはんの最中・寝る前に数十件ずつ片付けてなんとか全部読みました.

*5:採用+予備の件数はここでの公表は控えさせてもらいます.そのうちPyCon JPのサイトもしくはブログに載ると思う(例年通りであれば)

*6:14:00に始まったMTGが18:00過ぎに終わり、普通なら飲みに行く流れなのですが疲れすぎて無理でした.個人的には地元で飲みましたがw

*7:他の論点・観点も当然ありますがこれは秘密です.が、ここに書いた2つの観点、特に多様性を大切にしていたのは紛れも無い事実です.

*8:文章をちゃんと書くのもエンジニアの素養の一つだったり

*9:発表慣れしていたり、ガチの研究者だったりするんだろうなあ...