ハッカソン審査員の視点で解き明かす 伝わるプレゼンの核心
ハッカソンの審査員を何度か務める機会がありました。短期間でつくり込まれたプロダクトを前にすると、開発にかけた熱量そのものが伝わってくる発表と、残念ながら技術力が十分に伝わらない発表とがあります。両者の差はどこにあるのかという問いは、登壇する側だけでなく審査する側にとっても興味深いテーマです。
私は元々福岡でデザインを学び、今は東京でウェブやアプリの開発に携わっています。その過程で、ハッカソンや勉強会、発表の場に関わるうちに、審査の現場で繰り返し観察されるパターンが見えてきました。完成度の高いプロダクトが思ったほど評価されない事例や、開発途中の発表でも記憶に残る事例には、共通する特徴があります。
本稿では、私が審査員として大切にしている観点や、現場で感じた気づきをまとめていきます。ハッカソン参加者だけでなく、デザインの発表や技術イベントの登壇を考える方にとっても、ひとつの参考になれば嬉しいです。
プレゼンの質は、構成を少し見直すだけで大きく変わります。審査員として心に残った ハッカソン優勝チームの舞台裏 は、私がここで語る内容を裏付けるヒントが多く含まれていました。
審査の冒頭で評価の大半が決まる
審査員は連続する発表を聞き続けるため、集中力には限りがあります。中盤以降に退屈な発表が続くと、前後の記憶が曖昧になりがちです。だからこそ、最初の数十秒で聞き手の関心を掴むことが極めて重要になります。
冒頭では、プロダクト名よりも先に「誰の、どんな課題を解決するのか」を提示するのが効果的です。審査員は好奇心旺盛であると同時に実用性を重視する傾向があり、想定ユーザーの解像度を上げると、その後の説明がその枠組みで理解されやすくなります。
逆に、技術スタックの列挙から入る発表は、聞き手の注意が散漫になりやすいです。技術的な詳細は中盤以降に譲り、最初の数十秒はプロダクトの存在意義に集中するのが得策です。
ストーリーテリングが説得力を生む
機能紹介をそのまま時系列で語る発表は、情報を並べているだけに聞こえてしまいます。対して、解決したい課題から始めて、開発経緯、そして現状の到達点を語る流れは、聞き手を自然と惹きつけます。
審査員が共感しやすいのは、開発者自身が経験した困りごとから始まる発表です。ハッカソンの限られた時間では、開発メンバーがそのままユーザーであることも珍しくなく、そうした実体験は説得力を一段引き上げます。
技術選定の理由も、ストーリーに乗せることで重みが増します。「別の方法を試みたが締切に間に合わず、最終的にこの手段を選んだ」といった経緯は、技術選択の必然性を感じさせます。
審査で評価される発表の共通項
- 解決する課題が冒頭で端的に示されている
- デモが単なる機能紹介ではなく体験として語られる
- 数字やログなど検証可能な根拠が含まれている
デモは発表の生命線
発表にデモを取り入れるチームは多いですが、その完成度がそのまま評価に反映される場面を何度も見てきました。動作が重い、エラーで止まる、想定通りに動かないといったデモは、内容が良くても残念な印象を残してしまいます。
逆に、細部まで作り込まれたデモは発表全体の説得力を大きく引き上げます。画面の遷移ひとつにこだわっている姿勢は、開発全体のクオリティを示唆するためです。時間が限られていても、デモだけは入念にリハーサルしておく価値があります。
スクリーンショットや動画を用意しておくことも、安定に繋がります。ネットワークが弱い会場や機材のトラブルでデモができない状況でも、代替手段があれば慌てずに済みます。普段から Google Analyticsのデバッグ記録 のような検証ログを残しておくと、こうした準備にも活きてきます。
質疑応答で信頼が問われる
ハッカソンの質疑応答は、発表の本質が改めて問われる場です。審査員からの質問は、想定していなかった角度から来ることも少なくありません。用意していた回答を読み上げるだけの発表は、説得力を損ないやすいと感じます。
大切なのは、分からない点に誠実に答える姿勢です。即答できない質問には「持ち帰って検証します」と明言する方が、曖昧に取り繕うよりも信頼されます。技術的な誠実さは、質疑の場でこそ最も評価される要素です。
質疑の時間を効率化する工夫も見られます。よく聞かれる質問を最終スライドにまとめておくチームは、時間を有効に使えるだけでなく、気配りの良さでも印象に残ります。
チームの一体感が発表の説得力に反映される
ハッカソンは個人戦ではないため、発表時にもチームとしてのまとまりが問われます。全員が同じ内容を繰り返す発表と、役割を分担して語る発表とでは、見え方がまるで違います。
技術、デザイン、ビジネスといった役割でパートを分けるやり方は有効です。ただし、形式的に分担されると、それぞれが独立した発表のようになり、流れが分断される危険があります。発表全体を通した一本の筋を意識することが大切です。
審査員はチームの一体感も見ています。誰が話していても、他のメンバーが頷いているか、補足を加えるタイミングが自然かどうかといった細部に、協働の質が表れます。技術力だけでなくチームとしての完成度が伝わる発表は記憶に残りやすいです。
発表で気をつけたい典型的な落とし穴
- コードやログを映したまま解説が止まってしまう
- ユーザー視点が語られず仕様説明に終始する
- 想定外の質問に答えられず曖昧な返答になる
審査員としての反省と次への学び
審査員として登壇者を見るたびに、自分自身の発表経験と照らし合わせて反省することが多くあります。人の発表を見ることで得られる気づきは、登壇者として自分の発表を見直すときにこそ活きてきます。
普段の暮らしの中でも、発表の質を高めるヒントは転がっています。かつて iPhone5s購入 をきっかけに感じた、道具を丁寧に選ぶという姿勢は、発表で取り上げるプロダクトや資料の細部へのこだわりに通じます。小さな選択の積み重ねが、最終的な印象を形づくるのです。
ハッカソンの場に限らず、勉強会や社内の発表でも、今回紹介した観点は応用できます。聞き手の時間を預かるという意識を持つだけで、構成の組み方は大きく変わるはずです。
ハッカソンや勉強会で発表を控えている方は、私のブログもぜひ覗いてみてください。デザインや開発に関する日々の気づきを綴っています。発表準備でお悩みの方は、過去の発表レポートもご参考になれば嬉しいです。審査員として心待ちにしているのは、作り手の想いがまっすぐ届く発表です。