大会運営メモ

ただ思ったことをまとめただけです。これが唯一解だとかそういうことを言いたいのではありません。走り書きなので読みにくくてごめんなさい。

用意するべきもの

1. 養生テープ

壁などに案内を掲示したいとき、紙を貼るためには養生テープを使いましょう。ガムテープでは綺麗にはがれません。

2. 太いマーカー

同様に紙に書いて何か示したいとき、細いボールペンなどではらちがあかないので。

3. コピー用紙

同上。あとは紙を用意してこない怠惰なジャッジにも配ってあげると喜ばれるが、だいぶたくさん必要になるので微妙。

4. 指定ごみ袋

どの自治体の指定かをよく確認すること！ たとえばICUで開催するとき最寄りの武蔵境駅は武蔵野市だが、キャンパスは三鷹市だから袋が違う。指定以外の袋ではトラブルのもとなので指定の袋を使う。大会前に自治体のゴミ捨ての規定を確認しておく。

5. モバイルルーター

特に国際大会で大学のwifiを参加者に開放する場合に重要。参加者がみんなして使用するとすぐに通信が輻輳して使い物にならなくなるので、大学wifiを当てにしてクラウド上に必要なデータを保管していたりすると悲しい事態になる。

6. テーブルタップ

タブその他多数の電子機器を使用したい場面で、大学の教室はだいたいコンセントの数が少ないうえに場所も不便なことがあるので必需品。

ランナー・ヘルパーはちゃんとrecognizeしよう

何を当たり前のことをと思うかもしれませんが、これをしていない大会が案外多いのです。パンフレットには名前を載せる、当日(予選最終日の最後のラウンドの前あたり)には出てきてもらって拍手を贈る、大会後にfacebookにふたたび名前とともに感謝を示す、などなど。これらをぜんぶすることはなかなか難しかったとしても、少なくともどれかはしましょう。もちろん個人的にメッセージなど送っているのかもしれないですが、賞賛はなるべく大勢の人の前でやるのが鉄則です。

そういった感謝とは別として、どの程度謝礼や交通費を出すかも考えるべきところではあります。少なくとも交通費の実費を支払い、昼食も支給ないしは相当のご飯代を出すことは議論の余地なく必須でしょう。(なお、弁当を注文することが慣例となっていますが、近くで買える場所があるのであれば必ずしも必要ではなく、前述のように同等の現金での支給として省力化するのはありだと思います。)その上で、これだけの待遇ではあまりにしょっぱいなという印象を持っています。もちろん予算の制約はあるでしょうが、一日費やして疲れるのだから、夜になにか食べられる程度、1000円くらい色を付けてもいいのではないでしょうか。なおこれは国際大会ではまったく変わってきます。朝から夜まで大変なのでもっとずっと増やすべきだと思いますし、ICUTではそのようにしていますが、ここでは深入りしません。

一方で、経験上、ランナー・ヘルパーを「謝礼で釣る」ようなことをするのはおすすめしません。小銭稼ぎがしたいというインセンティブで来る人は、その小銭分しか働く気がないからです。むしろそれだったら純粋に――嫌な言葉ですが――「やりがい」だけで来る人のほうがいいです。この問題は特に人員をディベートコミュニティの外(ディベートに興味のないESSの他セクション部員を含みます)から募集するときに生じます。結局のところ、ディベートについてまだあまり知らない一年生などでもがんばってくれればとても戦力になるのですが、それはディベートに関わろうというモチベーションがあるからです。そういうモチベーションで動いていない人を連れて来てもうまくいきません。例外はディベートコミュニティにいないのに友人関係などで無償で協力してくれる人たちで、そういう人はまれにしかいませんが、とてもいい人たちです。

ランナー・ヘルパーの人数を概算する

60から80チーム程度の標準的な規模の大会で、tab担当が2人いると仮定します。

• ランナー：ラウンドの部屋数を4で割った数(ただし移動距離が遠い場合はやや増やし、近ければ減らす)
• スコアシートチェック：2人(BP) 3人(NA/Asian)
• ダブルチェック：2人

ただし、タイムテーブルに余裕がない場合はダブルチェックを一人増やしたり、またスコアシートの交通整理を行う係を一人追加する。大会の規模が大きくなってきたときは全体的にさらにスケールを大きくしたいが、指揮するtab担当の経験がある程度ないと大きなチームがあっても効果的に運用できないように思われます。

さらに、以下の担当も必要

• 会場誘導：会場の構造による。計算チェックあるいはダブルチェックと兼任可能
• Swing(shadow)：NA/Asianでは1チーム分、BPでは3チーム分が最大で必要になる。もう1チーム欠けたら1部屋削って大会を進めるためこれより多くは不要。ただし、もう1チーム一人だけ欠員したというような場合にそのチームを出場停止にせず、参加させるためにはさらに補充人員が必要になる。（なおこの計算は欠員・欠席チームが朝の時点で確定し変化しないことを前提としている。もし大会途中（2ラウンド目以降）で新たに欠員が生じると、tab上で対戦を手動で組み替えることはできないためまるまるswingで埋める必要がある。特に予選が複数日にわたる国際大会ではこの問題がよく生じる）

なお、swingは計算チェックあるいはダブルチェックと兼任可能（会場誘導とは兼任不可）。また、ランナーとの兼任も条件付きで可能：スコアシート＆ジャッジ評価シートの配布と、ラウンド部屋へチームとジャッジが到着したチェックの担当をほかのランナーに移行してプレパレーション時間に仕事がないようにする。ただ、swingとランナーの兼任は端的に疲れるのでなるべく避けること。

バスの輸送力に配慮した計画を

駅から近いキャンパスと違い、某大学のように駅から離れていてバスで移動が必要なキャンパスの場合は考慮する必要があります。特に曜日、時間帯と周囲の学校が学期中かどうかなどで大きく混雑状況が変わることに留意しましょう。限られた経験からなので正しいかどうかはわかりませんが、バスの運転士はどうも乗客数よりも定時運行性のほうが重要なようで（おそらく査定にかかわるのでしょう）、多くの人が押し寄せると乗車を拒否されることがあります。ということで複数の代替ルートを案内できると望ましいです。バスの増便をバス会社に依頼するというオプションもありますが、時間がずれたり人の動きが予想と違ったりするリスクがあるので熟慮のうえ決めてください。

スコアシート・評価シート必要数の計算式(Asian/NA)

• スコアシート：ジャッジの人数分（トレイニーにはいらないけど数が不明だし無視）
• ジャッジ評価Debater to Adjudicator：チームの数と同数
• ジャッジ評価Chair to Panel：[ジャッジの合計人数] - [部屋の数（＝チーム数の半分]（部屋の数だけチェアがいて、その残りがパネルになって一人一枚分評価されるからこの計算）
• ジャッジ評価Panel to Chair：同上（パネルも一人一枚評価するので）

以上1ラウンドあたり。ただしジャッジ評価シートは(私の作ったものは)A4の紙1枚に2枚つなげて印刷できるようになっているので印刷枚数は半分になる（二ページを一枚にまとめて印刷する設定忘れずに！）。4ラウンド目をサイレントにするならそこではディベーターからジャッジへの評価は不要。

スコアシート・評価シート必要数の計算式(BP)

• スコアシート：部屋数と同じ（コンセンサスベースのジャッジのため）

このほかはAsian/NAと同じです。

他大学を使う時の配慮

JPDU大会などでもそうですが、とりわけそれ以外の大学主催の大会で、他大学の施設を使うときは、その使い方に配慮しましょう。貸出の名義はその大学のディベート部になっているので、利用時間や利用方法に問題があると今後のその部の存続にも関わります。

ゴミの始末は覚悟

これはもはやtipsでもなんでもないですが、大会をやると残るのはゴミの山です。ほんとうに、ゴミの山です。全く信じられませんが、それだけ不届きな参加者がいるということです。やればわかります。覚悟しておきましょう。

レジ落ちなどのポリシーはきちんと決めておくこと

朝のレジストレーションは何時が限界なのか、また本戦でたとえばPre-Octが免除だったらあとから来ていいのか、などあらかじめ決めておきましょう。

運営コミ内での連絡手段

コミ内での連絡はいまどきですからLINEを使用、というのが普通ですね。だいたいの人が使えるし、みんなすぐに応答するのが普通になっている。ただ、実際のところ使いにくいことが多いのも事実です。なぜかというと：

1. 個別のタスクごとに話題を分割して、期限や担当者を設定することができない
2. 古い話がどんどん流れていって、忘れ去られるばかりだし検索性もない

そのため、LINEでやりとりしていると「何をいつまでに決めるべきか」がはっきりせず、決断しないまま流れていってしまうことがよくあります。そのため、特に注意して決めるものを決めるように促していく必要があります。その点、グループウェアのたぐいを使うと機能は優れているのですが、だいたいみんな使い方がわからない、まめにチェックしない、そして発言しないという三重苦になって機能不全に陥るので、大会運営コミにおいてその手のものを使うのは難しいという結論に至りました。慣れているメンバーだったらいけるかもしれませんが。facebookのグループはlineよりも話題の分割ができるという点でましなので、適宜活用していきましょう。もし可能そうならSlackなどを使ってみられるとよいかなと思います。

組織運営

一般的なことはそのへんの書籍とかにもいろいろ書いてあるのでいいとして、考慮しないといけないのは学生団体による活動はいろいろと特異な点があり、特にメンバー間で温度差が問題になりがちです。リーダーになるような人は運営を何よりも優先するつもりでいたとしても、メンバーのやる気はばらばらです。「バイトして、レポート書いて、テレビ見て、あと最近出たゲームやって、そこまでやってからまだ時間あったらやるかな」、くらいの優先順位かもしれません。そういう人は何かにつけて「忙しいから」、と言います。そりゃそうでしょう。だってほかにやることはたくさんありますから。けっきょく生活をどこまで削るかしだいなわけです。もちろん本当に忙しくてたまらない人もいるでしょうが、そういう人は通常メンバーになりません。ただむずかしいのは、人によって優先順位が違うことを責めることもできないということです。そこでリーダーが空回りしてしまうのが悪いパターンの始まりです。人間関係が崩れていくとどんどん悪い方に進んでいってしまいます。

けっきょく、こういうところでいわゆる「仕事術」みたいなものはなかなか通用しません。みんながフルタイムでやってるわけじゃないからです。一番意識しないといけないのは"everyone is on the same page"であること。つまりみんながゴールの意識を共有して、現状認識も共有することです。学年や下だったり経験が少ないメンバーが傍観者的にならないように、また優先順位を高くしてくれないメンバーもきちんと関わるようにする必要があります。その点、一般には会って会議するのは無駄だと言われますが、この手の活動ではまめに顔を合わせたほうがいいと考えます。もちろんだらだらと会議を続けるのはよくありません。特に少数しか発言していないときには。そのへんはファシリテーションの技術が問われます（ディベートに関わる人でもそういった他の議論の技術に関心を持っている人はあまりいないように感じます。私もなにかわかるわけではありませんが）。

3tabでリプライランキングを出す

3tabにはリプライのスコア一覧を表示する機能や、ましてやそのランキングを出す機能はありません。tabbycatにはありますが、動作環境、運用の習熟度、その他の問題で手軽に使えるとはまだ言えない状況のように思われます。

ということで、3tabからそれでもリプライのランキングを作る方法を以下に示します。なおこの方法は無保証です。本来そんな機能はないものですし、以下の手順に問題がない保証はないので、あくまで参考値を出すものと考えてください。

以下、pgAdmin3とExcelなどの表計算ソフト、また正規表現による置換を行えるテキストエディタを使います。ExcelのVLOOKUPやAVERAGEIF、また相対参照と絶対参照などについての知識は既知とします。

1. speaker_score_sheetsから2列目から6列目までを切り出す

2. セミコロンをタブに置換、またspeaking_integerが4のエントリ以外を削除する（正規表現で言えば^.*[1-3]\nを削除）

3. debate_team_xref_id integerのidを使ってdebates_teams_xrefsテーブルのエントリと対応付け、さらにdebate_teams_xrefsのdebate_id integerからdebatesテーブルのエントリともう一段階対応付けをして、debatesテーブルのround_id integerを取り出し(excelでvlookup使えば簡単)、各リプライスコアがどのラウンドのものなのかをわかるようにする。

4. ここまでで手元にはspeaker_score_sheetsのadjudicator_allocation_id integer, debates_teams_xrefs integer, debater_id integer, score double precision, そして追加したround数の表があるはず。

あと一歩のように思えるがそうでもなく、3人ジャッジのラウンドのマイノリティマジョリティの処理をしないといけない。

5. team_score_sheetsテーブルからadjudicator_allocation_id integer, debates_teams_xrefs integer, score integerを取り出す。ここを見てやれば同じラウンドに三人入っていることと、そのときどのように票が割れたかがわかる。

6. adjudicator_allocation_id integerとdebates_teams_xrefs integer, score integerを使って、手順4までに作った表と手順5の表を対応させ（要ソート）、あるリプライのスコアと、そのときのvote先をひとつの表にまとめる。

7. マジョリティ判定を行う。B列にdebates_teams_xrefs integer, F列にvoteが入っているとして、G列にmajorityかどうかtrue or falseを表示したい。そのときたとえばG2セルに入る数式は=IF(IF(COUNTIF(B:B,B2)=1,1,0)+IF(COUNTIFS(B:B,B2,F:F,F2)>=2,1,0),"T","F")となる。

8. そしてminorityの点数は無視されるので、簡単のためexcel上でフィルタして削除してしまう。空行を残しておくと何かとめんどくさいのでつめておく。

9. これで元データとなるテーブルは完成したので、ここからスピーカーごとにデータを抽出するテーブルを別途作る。この手順は比較的簡単。説明を読むよりも成果物を見たほうが早いだろう。同じラウンドの同じスピーカーに対して最大三件スコアのエントリーがあるので、averageifsを使ってスピーカーとラウンドの二つを絞込みの条件として平均点を取り出す（たとえばこんな感じ：=IFERROR(AVERAGEIFS($D:$D,$C:$C,$O6,$E:$E,"Round1"),"")ここでD列はスコア、C列はdebater id、O6にはそのディベーターのidがあり、E列にはラウンド数が入っている）。さらにその4ラウンドでの平均も取る。また、かならずしも同一のスピーカーが4回リプライを行うわけではないので、count関数も別の列に入れておく。さらに、名前がIDのままではまずいのでdebatersテーブルから拾い出してやる。さらにチーム名も表示したら親切だろう。そして点数で降順にソートしたら完成。

（作業時間：やり方を模索しながらやって一時間。わかっていればたぶん15分くらいで作れる）

大会運営の注意点

振り返ってみると、いままでに当日コミ2回、Tab9回（？）、Media2回、VTD1回、AC5回、Photographer1回くらい大会運営にかかわってきたことに気づきました。コミュニティへの貢献という意味ではもう十分だろうと思うし、あまりこれ以上やるつもりはないのですが、得た暗黙知をいくらか書いて残すことは務めだろうと思い、思いつくことから書いてみます。なおこれは将来のために残すことが目的であって、過去の失敗の教訓を含んでいることはあっても、それを非難することは意図していません。次回があるのかはわかりませんが、今回は大会運営全般でありがちなミスについて書きます。

1. 名前の間違い

人の名前は手動で入力しなおすべきではありません。打ち直すときっとどこかで間違いが生じます。レジストレーションフォームで入力されたデータをそのままコピー＆ペーストしてTabにも、スライドにも、あるいは賞状を書くときにも用いるべきです。

ただ、やっかいなのはレジストレーションフォームに入力される名前がしばしば間違っていることです。特にこれが生じやすいのは、登録を行う現役生と、登録される参加者が遠いとき、たとえば二年生の渉外担当がほとんど面識のない卒業生をジャッジとして登録するときなどです。可能な限り運営側でも目を通し、間違っていそうな名前は問い合わせることができると望ましいもののなかなか難しいでしょう。とはいえ、登録段階で間違っていたものは運営側の責任ではないですから、まずは少なくとも打ち込みによるミスだけは撲滅しましょう。

2. 同率の表彰漏れ

スピーカー、ジャッジ、あるいはブレイク制でない大会ならチームの上位者の表彰などで、たとえば10位まで表彰するとき、同率10位が複数いるときに表彰漏れがよく生じます。excelで並べてみていて、単に上位10件だけを取ってきてしまうことによるものです。くれぐれも気をつけましょう。

追記：注意しろと書いておきながら先日自分でもやらかしたので反省です。ジャッジブレイクを点数順で一定人数取ってくるときも同様の注意が必要です。特にジャッジブレイクは予選の終わったときに処理し、翌朝、あるいは早ければその夜のブレイクナイトで案内しなければならず落ち着いて見直す余裕がないので、注意力が切れていることが多いので、タブだけでなくACなどを含め複数人で確認するようにしましょう。また、スピーカーランキングなど本選の終わりに開示すれば間に合うものについても複数人での確認とともに、頭を冷やしてからの再確認をしましょう。

3. トーナメントの組み方の間違い

ブレイク制度のある大会ではここにきわめて慎重になる必要があります。本当に取り返しのつかないミスになってしまうので、念には念を入れて確認しましょう。

4. スライドのサムネイルによるネタばれ

PowerPointなどでスライドを流すとき、左側のサムネイル表示でその先で何が出るのかがばれてしまうことがよくあります。モーションや勝敗、あるいは表彰の際など、くれぐれもうかつに見せないようにしましょう。一般論として、確実に見せる準備ができた場面以外ではスクリーンに投影すべきではありません。接続して映し出したまま「どのファイルだったかな……」と探すようなのは最悪です。

5. スライドの操作ミスによるネタばれ

上と類似です。スライドを何枚進んだら結果が表示されるのかなど、きちんと認識しないでポンポンと進めた結果としてまだ見せてはいけないものが見えてしまう事故がよく生じます。単に気をつけて扱うというのはもちろんですが、スクリーンに映す前に一度通しでスライドショーを流してみて確認するようにしましょう。また、操作する人は一人だけ（ないしは確実に内容を把握している人だけ）に限定するべきです。よくわからないのに横から手を出して操作するとだいたい事故を起こします。

6. ビデオを流そうとしたら音が出ない

このトラブルは本当に多い！ 朝のうちにあらかじめ当たり障りのないテスト用のもので確認しましょう。教室の機材の操作にも習熟しておきましょう。

また、大会運営側でなく、動画を持ち込んで宣伝する場合でも注意が必要です。この場合は複数の代替手段を用意することを意識しましょう。自分のPCを持ち込むのは第一ですが、接続できるか、また接続できてもうまく再生できるかはわかりません。そのためUSBメモリなどでデータも持ち歩いておくべきです。しかしこれも再生するPCによってコーデック（ここでは説明しません）の都合などでうまくいかないことがあります。また、youtubeなどにアップロードしておくのもきわめて有用な方法ですが、必ずしもネットにつなげられる保障はありません（特に海外）。ですので、確実に再生するためには複数の手段を用意しておくことが肝要です。

賞状の"Certificate"のfとiは合字にしよう

非常に些末なことなのですがでも個人的にはとても大事なので。ディベートは競技ですから成績がつくわけで、そうすると賞状が出ますね。あるいはADIなど参加賞もあります。さてそこで賞状の頭には大きくCertificateと書くでしょう。そこで次の画像を見てください。

画像：合字ありの場合となしの場合の見栄えの比較

フォントはTimes New Romanでイタリックにしています。丸で囲った部分を見てください。上の合字なしの場合はfとiの頭同士がぶつかっていてかっこわるいです。それを解消するのが合字で、下の場合ではうまいことfとiが融合してすっきりしています。ということで、賞状をかっこよくするために合字を使いましょう！

合字の使い方は用いるソフトウェアによって違うので調べてください。

MS Wordなら http://www4.synapse.ne.jp/yone/word2013/w2013_pre7.html 、

Adobe Illustratorなら http://tech.kihon.jp/illustrator/3436 あたりを挙げておきます。

なお、フォントによっては合字が用意されていないこともあります。また合字があったほうがいいかないほうがいいかは文字間隔などの要素によって変わってくるのでいつでも使うのではなく個別にどちらのほうが美しくなるかを判断してください。

合字に限らず、フォントの選択、カーニングの調整などなど、タイポグラフィやデザインはかじってみるととてもおもしろいのでぜひ本など読んでみてください。

Google Form用自動返信スクリプト

大会レジストレーションフォームとか自動返信を仕込みたいときがあるはず……ということで前から使ってるものをここに貼っておきます。わかる人用。わからない人は聞いてください。

function sendMailFromForm(e){
  var itemResponses = e.response.getItemResponses();
  var message = '';
  var username = '';
  var mail = '';
  for (var i = 0; i < itemResponses.length; i++) {
    var itemResponse = itemResponses[i];
    var question = itemResponse.getItem().getTitle();
    var answer = itemResponse.getResponse();
    if (question == '＊＊＊名前欄の欄の名前＊＊＊'){
      username = answer;
    }
    if (question == '＊＊＊メールアドレス欄の欄の名前＊＊＊'){
      mail = answer;
    }
    message += (i + 1).toString() + '. ' + question + ': ' + answer + '\n';
  }
  var orgcomaddress = 'xxx@yyy.com';
  var title = 'Automatic Reply: 00th xxx Cup Application Form';
  var content = username + '様\n\nこの度は00th xxx Cupアプリケーションフォームにご回答いただきありがとうございます。以下に内容を確認いたしますので、内容の変更などございましたらメールにてご連絡ください。\n' +
'Thank you for your response to the Application form for 00th xxx Cup. The following is the detail of your response. Should there be any change to it, contact us via email.\n\n'
    + 'ご記入内容 Details of your response\n'
    + message
    + '\n\n'
    + ' --\n'
    + '00th xxx Cup Organizing Committee (xxx@yyy.com)';
  GmailApp.sendEmail(mail, title, content);
  GmailApp.sendEmail(orgcomaddress, 'COPY' + title, content);
}

(↑かなり適当に書いてるのでわかる人は適宜改善して使ってください)

*2016年10月22日追記
やっぱりいろいろな大会で登録したかどうか不透明なケースが生じていたり、あるいは手動で送っていて手間がかかっているように見受けられるので、プログラミングなどをまったくしたことがない人にもわかるように以下解説します。

手順1: 適当にフォームを作ります。名前とメールアドレスの記入欄があればまずは十分なので、そのように作ります。おまけで適当な欄もつけました。ここで名前欄は"Your name"、メールアドレス欄は"Your email"となっています。この二つを一字違わずあとで使うので把握しておいてください。e-mailとかなったり、あるいはスペースが余計に入ったり、とにかくいかなる差異もないようにしてください。
本題とは関係ないですが、このときメールアドレス記入欄については黄色く塗った「…」ボタンから「データの入力規則」を選択し、最初は「数値」となっているところを「テキスト」に変更、そして「次を含む」を「メールアドレス」に変更して、メールアドレスとして成り立つもののみを受け入れる入力規則を付けるようにしましょう


手順2. 次に右上の「…」ボタンから「スクリプトエディタ」を開きます


手順3. コードを編集します。

function myFunction() {

} 

 とすでに入っていると思いますが、すべて消して上に書いたコードを貼り付けてください。そして以下の編集をします
15行目:＊＊＊名前欄の欄の名前＊＊＊とあるのを、ここではさっきYour nameとしたので、そのとおり書き換えます。もともとシングルクオーテーションマークに囲まれているので、この引用符を消さないように、またそのほかに余計な引用符をつけないようにしてください。もちろんさっきYour nameじゃなくてほかの名前をつけたなら、それに対応させてください。
18行目:メールアドレスについてもYour emailと書き換えます。まったく同様です。
23行目：自動返信メールが相手方に送られるときに運営側にもコピーがほしいということで、運営側のメールアドレスを入れます。xxx@yyy.comを書き換えてください。
24行目：自動返信メールのタイトルです。大会にあわせて適宜書き換えてください。
25行目以降：本文です。適宜書き換えてください。逆スラッシュとnの二文字で改行になります。また、あくまでシングルクオーテーションの中に書いてください。シングルクオーテーションの外で+記号を使うと文字列の連結になります……この先説明していくとややこしいのであまり踏み込みません。
31行目：本文の末尾です。問い合わせ先のメールアドレスを入れてあるのでこれも編集してください。

以上でコードの準備は完了です。

手順4. 「リソース」メニューから「現在のプロジェクトのトリガー」を開きます。

(上の画像でもともとあったmyFunctionが残っているのはミスです。存在しないのが正しいです。)
するとプロジェクト名を入れるように求められるので、なんでもいいので入れてOKで進みます。

手順5. トリガーが設定されていません……のところをクリックして進み、「フォーム送信時」となっている（最初からなっているはず）ことを確認して「保存」。





手順6. アクセス権を要求してくるので許可




以上で手順は完了です。いまは運営のメールアドレスがないので自分のアドレスを設定してみます。


すると↓登録者へのメールと、運営へのコピーが両方届きました。


内容はどちらも同一で、確認すると記入項目がすべて表示されています。


めでたしめでたし。動作確認はきっちりするようにしてください。

回答をチェックするともちろんきちっと入っています。

スプレッドシートにしてもこのとおり


以上です。大会運営のお役に立てば幸いです。もちろんその他どんな場面でも使えます。

いわゆる"Principle Argument"とis-ought problemについての考察を試みる

※最初に断わっておきますが内容が当を得ている保証はありません。エジュケ用ではなく1年生などにはかえって混乱をきたす可能性があります。

*Principle Argumentとis-ought problem
Principle Argumentってなんでしょうか？ たぶんPractical Argumentと並置されるタームであろうことは合意が得られると思うのです。でもどう定義しましょう？ PrincipleとPracticalの区別がはっきりしないということはSheng Wuによってすでに言われています(http://trolleyproblem.blogspot.jp/2012/12/there-is-no-coherent-distinction.html)。だからリフレクでPrincipleとPracticalの単純な二分法で話すのが好まれないわけです。

でもここでis-ought problemに関するヒュームの議論(http://en.wikipedia.org/wiki/Is%E2%80%93ought_problem)を踏まえて考えてみると少しばかり整理が付けられるように思うのです。批判を恐れずに説明してしまえば、これはつまり「～である(価値判断を伴わない事実のステートメント)」というステートメントをどれだけ重ねていっても「～すべき(価値判断のステートメント)」という結論は導けないということです。たとえば「人を刺したら肉が切れる」、「肉が切れたら出血する」、「出血したら体内の血液が減る」、また「血液は脳などの臓器の維持に必須」、「臓器が損傷したら死んでしまう（可能性がある）」→結論として「人を刺したら死んでしまう（可能性がある）」は"is"のステートメントを重ねていけば順当に導けます。でも「だから人を刺してはいけない」と"ought"(shouldとだいたい同じ意味を持つ助動詞です)に移行することには明白な論理の飛躍があります。あらかじめ「人を殺してはいけない」というoughtのステートメントが与えられているときには正しいですが、それはさっきまでの"is"のつながりからは永遠に導かれないわけです。

このisからoughtに移る壁がディベートに大切になるのはなぜでしょうか？ それはディベートはほとんどの論題において結論としてoughtを求めるからです。ポリシーモーションにおいては1.未来がどうなる「べき ought」か、2.その政策において未来が「どうなるか is」が必要です。「景気を回復させるべき ought」と「この政策をとれば景気が回復する is」の二つによって「この政策をとるべき」が言えます。そしてThis House WOULD do Xにyesあるいはnoという答えを出すためにはThis House SHOULD(SHOULDN'T) do Xを示すことが必要十分条件だと考えます。

（蛇足）なおこの「べき」はよい・わるいの価値とは必ずしも対応しませんが、以下では説明の都合で混同して用います。なぜ対応しないかというと、ある行為が「よいこと」あるいは「正義」だったり「善」だったりしても、だからある主体がその行為を「するべき」かは明らかではなく、それは主体の性質、立場や役割によるからです。たとえば命をかけて国のために戦うことはよいことでしょう。そして軍人はそれをするべきでしょう。しかし同じよい行為でも民間人がそれをするべきとは言えません。行為自体は同じなのに主体が違うと「べき」だったりそうでなかったりするわけです。

もちろん例外はあります。ポリシーでないモーション、たとえば"THBT the world was better off during cold war."のようなものは直接的には"is(was)"の結論を求めます。しかしこれにしても、"the world SHOULD be in this way"というoughtのディベートと、現実はどうであったかというis(was)のディベートが組み合わさっているという点では変わりません。あるいはregret系のディベートも過去を向いている点ではこの種のものですが、やはり原則は同じです。

ですから「どうなる」のisだけディベートしてもけっきょく結論は導けないわけです。一方でoughtだけディベートしようと思ってもあまりうまくいきません。というのはほとんどの「～べき」論は「～になるから、～すべき」というふうにできていて、isの部分が欠かせないからです。たとえば「電車の中では携帯電話で通話をしないべき」という主張は「人の迷惑になることをしてはいけないから」という理由でサポートされるでしょうが、それが成立するためには「電車の中で携帯電話で通話すると人の迷惑になる」（isのステートメント）という前提が真である必要があります。ですから「いやいや電車の中で会話しているのと一緒だろう」と言われて反論できなかったら「人の迷惑になることをしてはいけない」というステートメントが手つかずで残っていたとしても「迷惑にはならない」→「通話してもいい」となってしまうわけです。

（蛇足）oughtの結論につなげるためにどのようなisのステートメントが証明される必要があるかはモーションとoughtの「距離」によって変動します。例で説明します。「人を殺してはいけない」というoughtのステートメントを使ってモーションを否定したいとします。そのときにはつなげるために「政策をとる」→「事象Xが起きる」→「事象Yが起きる」→「事象Zが起きる」→「人が死ぬ」、「だから政策をとってはいけない」と結論するわけです。このときには政策をとってから人が死ぬまでの矢印で示した"is"の連鎖を全部守りきらなければなりません。何ステップもあれば守りきるのはなかなか骨が折れるでしょう。一方で距離がない場合もあります。政策そのもののアクションが行うべき・間違っていると言える場合です。極端な例ですが、たとえばTHW push the man（あの例の橋から太った人を突き落して列車を止めてほかの人を救うというやつです）においてモーションの文脈で押したらその人が死ぬことはすでに仮定されているので、「人を意図的に殺してはいけない」というoughtは間にisのステートメントを挟まないわけです。ただ今度はそれはそれでなぜ殺してはいけないのかを問われだしてしまいますが、それはあとで触れるought同士の対立の問題になります。

*oughtに到達する
では実際のディベートではどのようにoughtの結論にたどり着けるのでしょう？
**1. コンセンサスとなる
これは起こってしまえば一番手っ取り早いです。相手もoughtの部分に同意してしまえばその点は争いになりません。たとえば"THW trade with oppressive regime"において両サイドともoppressiveな状況から市民を救うことをゴールとした場合、残る争点はどちらの政策がoppressiveでなくせるかというisの争いだけになります。

とはいえこれは相手サイドの出方に依存しますからoughtにたどり着ける方法として自分の意思で利用できるわけではありません。

**2. 既存のoughtとつなげる
相手とのコンセンサスにならなくてもまだ方法はあります。私たちの即興ディベートは一般の聴衆を説得するものです。だからこそジャッジはaverage reasonable person略してARP(average inteligent personだったりglobal informed citizenだったりしますがなんでもいいです)だということになっています。そういう一般の価値観はまったくの白紙ではありません。人が死ぬことは悪いことだというのはほぼすべての場合において認められます。また差別も悪いことです。平和や公平はいいことに違いありません。そして抽象的ですが「幸福」は多くの場合で否定しがたいゴールであり、"is"をつなげていってどちらが幸福により近づけるかを争うことになるディベートは非常に多くあります。何が幸福なのかで争いになることはしばしばありますがそれはまた別の話です。そして個人が選択の余地を持てば幸福になれるという考え方から自由が重んじられます。このへんは常識的に考えてあたりまえですね。この「あたりまえ」の感覚がけっこう大事で、このような「ジャッジとの間でコンセンサスになる」ような価値判断を利用していくことが説得につながるわけです。ですから政策を行った・行わなかった結果をこういった一般の人たちがもともといい・わるいと認めている帰結につなげて、逆に相手がつなげようとする試みは妨害していくことになります。いわゆる「Practicalなディベート」は上の1番かこのパターンかに属します。たとえばTHW introduce carbon taxで、Govサイドから「APでは環境を守れるが、経済は悪くならない」と主張していき、Oppはその逆を主張するものの環境と経済のどちらを守るべきというような議論はないような場合です。

（蛇足）この「つなげる」という行為はさらに二つに分類できると考えます。一つにはcausation、もう一つはsimilarityです。政策がすでによい・わるいとみなされていることを引き起こすように事象と事象の間で因果関係を作るのがcausationです。たとえばdeath penaltyのモーションではdeterranceという概念を用いて犯罪減少（＝よいこと）との因果関係を示そうとすることでしょう。一方でsimilarityは政策やそれによって引き起こされる事象がすでによい・わるいとみなされている事象に類似し、等価であることを示すわけです。たとえばoffencive art規制に関するモーションではそれがhate speech（＝わるいこと）に類似していることを示そうとするでしょう。よく線引きの議論と呼ばれるやつですね。

とはいえ実際のディベートではそこまで簡単にはいきません。よほどチームの間でレベルの差がある場合でもない限り、APではきっと環境は守れるかもしれないけど経済にはいくらか悪影響はある、といったところに至ってしまうでしょう。こうなるとジャッジは困ります。環境は大切、経済も大切、どちらも既存のoughtですが、二つ比べてどっちが大切かとなるとARPのレベルでは判断できません。もう少し現実的な言い方をするとジャッジとしてはそこまで踏み込むのは過剰な介入ととらえられるのでやらないということです。

**3. 既存だが説明が必要なought
人が死ぬ、といった明らかな悪いことだけがディベートの主題ではありません。人が死ぬのはいついかなる場合でも避けるべきこと（極限的な状況（刑罰・安楽死）や境界線（中絶・脳死）などではディベートになる余地はありますが）ですが、世の中にはもっと微妙な価値があります。たとえばプライバシーが侵害されるというようなharmを出すとすると難しいでしょう。たしかにプライバシーってなんとなく一般の人が分かる概念でなんとなく大切そうだということは知られています。でも、抽象的なので1.そもそもプライバシーって何なのか、そして2.それが今回の状況でどう害されるのかの両方が必要です。これは人が死ぬという話より込み入った話になりますね。さらに、「人が死んだらどうして悪いのか？」という問いはなされない一方で、「プライバシーが害されたらどうして悪いのか」という問いは飛んできます。これはつまり、プライバシーは間接的な価値にすぎず、ほかのものを守るために守られるけれど、それ単体として絶対に守られるほどの価値は認知されていないということです。少なくともジャッジにそれを期待するのはかなり危ういのです。ですからけっきょくプライバシーは本当の意味でのoughtとは言えないわけで、3.幸福や自由などのより否定されにくいoughtにisでリンクしていく必要、も出てきてしまうわけです。これはデモクラシー、文化、宗教などにかかわるディベートに多いパターンです。

**4. 新しいoughtのステートメントを作れるか？
既存でないoughtのステートメントをディベートの中で打ちたてていけるのでしょうか？ 基本的にはディベートの中でde novo(はじめから)でoughtのステートメントを作ることはできないと考えます。価値の創造は一朝一夕にはできないのです。たとえば環境保護という考え方は20世紀の途中から支持を得ていったわけですが、それは環境が人の命や生活など人がすでに認めている価値を守るために必要だという意味で間接的に価値を認められた（つまり、環境が壊れる→人に害というisのステートメントの接続が生じた）だけにすぎず、環境が直接に守られるべき（ought）とは必ずしもみなされていません。つまりちょうど上の2番のパターンですね。環境が失われれば人にも影響があることが暗黙的な了解になっているため一見すると直接的に環境を守っているように思えてしまいますが、なぜ守らなければならないかと問えば実際は間接的な理由なのです。

けれども他方では人の生活への影響を問わず環境そのものを守ることに価値を見出す人たちもいるし、そういう考えが拡大していることは事実です。でもそれは美しい環境が無残に破壊された様子のセンセーショナルな写真が報道されるなどして起こった現象で、ディベートの中でそこまで新しい思想を生み出すことはできません。

別の例としてAnimal Rightは人に影響しないし間接的な価値として生まれた感はありません。しかし人間との類似性、同じように痛みを感じるsentienceを持っているのだから守られるべきだというところから発展してきています。上で説明したsimilarity、つまり人の権利を土台にして拡張しているわけです。ですからoughtをまるっきり何もないところから生み出しはいません。人の権利は守られるべき（ought）→人と動物にはある程度類似性がある（is）→動物の権利もある程度守られるべき（ought）、という構図なのです。実際、人権思想がないところで動物が守られることは考えにくいですよね（生類憐みの令みたいな反例がぱっと浮かびますが、支配者がたまたま動物好きだっただけで社会として動物を守る価値観を共有していたわけではありません）。

またその人権を例にとって考えてみても、人々が権利を勝ち取るまでにどれほどの闘争を必要としたかを振り返れば、人の信じる価値というものはよほどのことでないと変わらないことが分かります。ですからディベートの中ではあくまですでにあるoughtを使うことしかできません。

5. 組み合わせて新しいoughtを作る
まったく新しくoughtのステートメントを作れないとしても、すでにあるものを組み合わせていくことはできるはずです。それはどのように可能なのでしょうか？

A. 複数のoughtが存在して優先順位をつけるとき
ここはある種のpracticalな、言い換えれば功利主義的な比較においてどちらが重要かを主張することができるはずです。規模とか、時間とか。あるいはどっちのほうが弱い、どっちのほうが責任がないなどの功利主義以外の価値観に基づく比較も可能で、それによりある種の新しいoughtのステートメントが作れるはずです。たとえば国家はプライバシーを守るべきというoughtと、国家は国民の安全を守るべきというoughtがあったら、後者がないと前者も成立しないのだからプライバシーと安全を天秤にかける時は安全を優先すべきというoughtができるわけです（反論の余地はもちろんありますし雑な議論ですがあくまで例として）。

B. 目的・役割分析を行うとき
これも上に似ているかもしれません。学校教育においてどうすべきとか、あるsocial movementがどうすべきとか、そういう話が出てくる場面においてはその団体や組織のuniquenessというか、目的を考えるとこれを追求すべき、といった主張が出てきえます。

（この辺未完ですが数か月放置してしまっているのでもう見切って書き終えてしまいます。）

唐突ですがメタファーを導入しつつまとめに入ります。

ディベートではたいていoughtの価値判断が必要になります。「oughtの水」みたいなものが地表の泉から湧き出ていると想像してください。ちょっと言い換えれば「正義」とか「善」がなぜか液体で湧いているのです。そして政策はどこかの地点に位置します。目指すのは湧いている水を自分の政策まで引いてくることです。別のところでought not(不正・悪)が湧いているのでそれを相手の政策に送る（harmを生じさせる）こともします。

Principle Argumentは新しく泉を作るわけではないですが、すでに湧いている泉を大きくしたり手入れする道具になります。そしてPractical Argumentは泉からモーションまで水を引いてくる水路の役割を果たすわけです。しかしある一つのArgumentが両方の働きをすることもあり、厳密に分けることはできません。

ときにPrincipleはコンセンサスとなります――両サイドが泉を共有して、どちらが自分の政策へより多くの水量を引けたかを競うわけです。でもそうでないとき、別々の泉を使うときもあります。そのときには、きちんと水路で水を引くことはもちろん必要ですが、どちらの泉のほうがいい水なのかを競うことも必要になります。ですから泉を手入れしてよりきれいにする必要があり、逆に相手の泉は汚染しようとするわけです。これがPrinciple同士の争いです。

Tab覚え書き

ほんとにただの覚え書きです。わかる人にはわかると思うけどそういう人はこれ読まなくてもわかるはず。

Tabbieについて

・セットアップは展開して実行するだけなので超簡単
・起動してブランクのデータができた時点でチームなどの入力を始める前にバックアップを作る。作った.sqlファイルはテンプレートとしてテキストエディタなどで編集できる。
・チームの登録はtabbieからブラウザ上でやっていると入力ミスしてチーム消しても消えなかったりしてトラブルの元。.sqlファイルを直接編集してレジのデータを整形したものを入れたほうが楽→簡略化するためマクロとか作りたい。
・ということで大学、チーム、部屋、スピーカー、ジャッジの登録は直接編集しよう。コンフリクトはブラウザ上で入れていってもいい。
・いったんドローを引いてしまうと戻せないので要バックアップ。
・外部からアクセスさせるには.htaccessを編集（これで解消できるのは403が出てるときのみ。そもそもつながらない時はほかの原因）ファイアウォールなども要確認。
・同じジャッジが繰り返し同じチームを見る問題は別途カウントするしかない→excelつくったのでuploadする予定。

3tab

外部からのアクセスを実現するにはTabbieのときと同様の.htaccessをwamp\www\に放り込む。
NAに使うときは3人目を適当な名前で登録し、0点にしておいて発表するタブでは消す。

データをクリアしたいときはとりあえずバックアップして、そのファイルから「スキーマのみ」をチェックしてリストア。

スコアレンジとかの設定ファイルはwamp\www\3tab\apps\3tab\config\app.ymlとwamp\www\3tab\cache\3tab\test\config\config_app.yml.php。二つがどう効くのかは不明だが少なくとも前者だけ書き換えても意味なし。

.cssいじったらマッチアップ見やすくできる？

オンラインジャッジ評価構想

Google Formから入力がおそらく一番無難。アクセスできない人はほかの人の端末借りるorコミで対応（この場合個人フィードバックを聞いてからになってしまう可能性があるが、反映しないようにお願いするしかない。現状でもRFDが短ければ評価シート回収前にフィードバック聞く可能性あるし大きくは変わらない）。入力したものはaccessのDBに貼り付ける。問題は提出漏れ。ディベーターは必ず提出するので一覧から提出がないところはすぐ見つかる。ジャッジは出てないのが1人ジャッジのせいなのか3人ジャッジなのに忘れてるのかの検出が困難→ディベーターからの評価にジャッジ人数を書かせれば一覧上で気づきやすいはず。重複提出はすぐわかるので問題ない。