2016-11-17

ジャッジ提供数の表記法(nとかn-1とかの話)

多くの国内・国際大会ではチームを送るにあたってジャッジ提供が必要なのはご承知の通りです。では何名のジャッジ提供が必要なのかについて、表記法がとても紛らわしいように感じます。

よい例

ジャッジ提供数:n-1
このように書いてあれば、さほど混乱する要素はありません。ただ、nがチーム数を表すことは知らないとわからないでしょうから
ジャッジ提供数:n-1 (例:1チームの場合はジャッジ不要、4チームの場合はジャッジ3名必要)
と例を書けばよいでしょう。この派生でもちろん
ジャッジ提供数:n (チーム数と同数のジャッジ提供が必要)
ジャッジ提供数:n-2 (例:2チーム以下の場合はジャッジ不要、4チームの場合はジャッジ2名必要)
などもよいでしょう。これらすべてのケースで表記法が一貫しているのが重要です。ただこれにしてもまだ十分にわかりやすいとは思わないので、何かいいアイデアがあればお寄せください。

悪い例

ジャッジ提供数:n=1
何を言っているかはっきりしません。一貫した法則性が見えないことが問題です。たとえばn=2のときはどういう意味になるのでしょうか?
ジャッジ提供数:n=n
ジャッジ提供数:n=n-1
ジャッジ提供数:n=n-2
上のよい例に等号と左辺を加えただけですが、これは等号に対する冒涜です。やめましょう。端的に不必要ですし、何も情報を付加していません。もちろん、以下のように大文字と小文字を使い分ければ問題はありませんが、そこまでする必要はないでしょう。
ジャッジルール:n=N-1 (n:ジャッジ必要数, N:チーム数)

2016-08-25

へんてこなJargonを駆逐したい

どの業界にもあるように、このディベート界隈にも業界jargonがあります。それは別にいいのですが、やっかいなのは英語のようなかっこうをしていながらぜんぜん英語じゃないものが多いことです。国際大会に行ったり、あるいは日本で国際大会を開いたりするときに英語だと誤解して通じないのが不便だし、変えてはいけない理由はぜんぜん見当たらないから、どうせだったら変えませんかという提案です。なお、このリストは完全なものではないですし、私が誤解していたりすることもあるかもしれません。足りなかったり変だったりするところがあればどんどん指摘してください。

  • Closed Round→Silent Round
  • OR→Briefing Room, Gathering Room, Main Hallなど。ORでは通じません。
  • JR→あまり見る機会多くないけど、これはそのままJudge Roomでいけるはずです。JRと略したら無理。
  • GHQ→いったいどういう経緯でこんな名前になったのでしょうね? Head Quartersというのはたしかに一般的な言葉ですが、しかしこの意味で使っているのは見たことがありません。Tab Roomというのが普通でしょうか。
  • Invitation, Application→Registration. 推測ですがInvitationというのはJPDUとか昔のKUELとかの組織で、その加盟校にだけ参加資格を与えた経緯でこういう名前にしたんでしょうが、今となっては何を言ってるのか不明です。Invited Adjudicatorと混同するのでやめましょう。Registrationに複数の段階があるのは普通で、それは大会ごとのやりかたに応じて案内すればかまいません(1st step, 2nd step etc.)
  • Shadow→Swing
  • Joint→Composite (Jointも通じるものの、compositeのほうがよく見るように感じます。若干ニュアンスが違うような気がしますがわかりません。)
  • 当日コミ→Runner, Helper, Volunteer (ただ、runnerだと全員が走る係でもないし、helperだと雑用係感が出るし、volunteerだと抽象的すぎる感があるのでなんともはやですが。)追記:最近はVolunteerがスタンダードだと思います。
  • 正規コミ→Organizing Committee (正規コミって言い方が、それ以外が「非正規」コミであることを含意するようで響きが悪いと感じるのは私だけでしょうか)
  • Score SheetBallot 紙自体はscore sheetでもいいですが、書かれた情報も含めていうならballot。
  • Judge Evaluation SheetFeedback Sheet これは特に用語化しているわけではないし通じるとは思いますが。

もっとも、必ずしも「世界標準」の言葉遣いがあるわけではありません。日本以外にも国、地域特有の言葉はあります。たとえば韓国ではAdjudication CoreのことをCAP(Chief Adjudication Panel)と言うようですが、これはたぶんほかの国では通じません。あるいは東南アジアではA-Coreと略すのを見かけますが、これもほかの地域では使われていないように思います。ただ、可能であればなるべく広く伝わる言葉にしましょうという提案です。

2016-08-24

大会運営メモ

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

用意するべきもの

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分くらいで作れる)

2016-08-22

大会運営の注意点

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

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

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

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

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

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

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

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

6. ビデオを流そうとしたら音が出ない
このトラブルは本当に多い! 朝のうちにあらかじめ当たり障りのないテスト用のもので確認しましょう。教室の機材の操作にも習熟しておきましょう。

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

2016-02-19

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

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

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

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

合字の使い方は用いるソフトウェアによって違うので調べてください。
Adobe Illustratorなら http://tech.kihon.jp/illustrator/3436 あたりを挙げておきます。

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

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

2015-01-20

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. アクセス権を要求してくるので許可




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


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


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


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

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

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


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