研究のテーマがガラッと変更になり、焦りながらも電子工作を楽しんでいます。
さて、そんなドタバタした状態でしたが、またハッカソンの振り返り記事です。
今回参加したのは、”日本最大の学生向けハックイベント”ことJP HACKS 2018、参加は東京会場です。
案の定、前回と同じくコンセプトとアイデアのチーム!kieで参加してきました。
例によって、この記事は超長文であり、あくまで僕自身の感想を述べているものであり、他のメンバーやチームの意見などは含まれていません。
それでは、始めます。
目次
今回参加したJP HACKS2018は、国内最大規模の学生向けハッカソンとして有名とのことです。
個人的に印象的だったは、
- 発表資料作成禁止
- 事前準備自由（開発分は評価外）
- 提出物が仕様書（GitHub README.md）と映像のみ
- テーマは「クロステック」（技術者にとってはなんでもあり）
の3点です。
これらの情報を知ったとき、
- 短期的開発力
- 柔軟な発表力
にコンセプトを置いたハッカソンなんだろうなと感じました。
よく公式サイトを見てみると、
- JPHACKSは，エンジニアリングで学生の皆さんにワクワクしてもらうために、
- 瞬発力のハッカソンと長期的プロジェクト遂行力のコンテストのいいとこどり
- 開発期間中の成果差分に対する評価を重視することでの公平性と敷居の低さの提供
を実現します。
とあります。
そんなわけで、このハッカソンの事前情報を見る限り、とにかく技術力を見るハッカソンなんだろうな、という印象が強かったです。
しかし、自分の所属するチーム!kieはPost not found: 初めてハッカソンに出場して考えたこと ハッカソンによっては運営に煽られるくらいにアイデアを重要視することをコンセプトにしたチームです。
だからこそ、技術力は地力に依存するものだとさっぱり考え、事前準備はアイデアづくりを主に様々な活動・議論をしました。
実際にやってたこと
事前準備
事前準備は、とにかくアイデアづくりでした。
自分たち学生の生活の分析から、時にはメンバーの母親である「主婦」の生活の分析/ブレインストーミング/コンセプト決め/制作物の議論などについて合計ざっくり19時間弱議論しました。
学校の休憩時間や放課後などを使い、日によっては午前1時まで議論していたりしました（振り返ってみると思ってたより多く時間をとってました）。
様々なことを考えました。
誰に向けた物を考えるのか。
何が嬉しいということなのか。
なんともないことを笑顔のもとにするには何が必要なのか。
アイデアとはどんなところから生まれるのか。
見つけた案について調べてみると、ほとんどの割合で既存事例だったりして、苦しい思いもしました。
そして、1つの壁にぶつかりました。
それは、後に我々のチームの中で “ハッカソン映え” と呼ばれる、我々のコンセプトとしているコンセプトとアイデアのチームという枠組みと競合する議論でした。
最終的には、JP HACKSという競技のための活動という意識の統一をすることで意思統一が取れましたが、詳しくは後ほど。
そんなわけで、ひたすらにコンセプトとアイデアを練りに練って、作るものを確定させた状態で、最低限の技術検証や提出物である動画の構成の考察をざっくり行ってからハッカソンに向かいました。
当日の活動と公開した成果物
ここまで長文を読んでいただくのも流石にアレなので、とりあえず今回のハッカソンの成果物を貼ってみます。
提出動画
提出リポジトリ（仕様書とプログラムコード）
提案物の概要
さて、チーム!kie（ピンキー）が提案する恐らく最後のプロダクトは、Pinkyでした。
口約ーー口約束を、交約ーー腕と腕を交える行為に昇華させ、それらの情報を管理しようという、提案です。
確か、人々の活動をひたすら列挙していた時にふと出てきた「約束」というキーワードがきっかけで提案しました。
リストバンド型のデバイスを使い、約束を口に出して、デバイスを付けた者同士が腕を交わす（トントン、と当てる）ことでその約束を専用アプリに登録することが出来ます。
専用アプリには、口に出した内容とそれに基づく期限日時などが記録されます。
例えば、「明日五稜郭で打ち上げ」で腕を交わせば、「明日」がその日付に変換され、「五稜郭で打ち上げ/A月B日/誰々と約束」みたいな感じで記録されます。
案外、約束をお互いに管理するアプリってなかったりするんですね（契約的な堅苦しいのはありました）。
んで、提案してみた次第です。
役割分担は、
- デバイス
- データサーバ
- 各種アルゴリズム設計（音声認識からの日時判定や、腕を交わすマッチングアルゴリズム）
- iOSアプリケーション
でした。
これらをたった2日で開発しきったエンジニア軍勢4名は本当にお疲れ様でした。
自分がしたこと
さて、それらの中で自分がしたことは、
- UIデザイン
- 図解（システムモデル図作成）
- 作曲
- はんだ付け
- 提出用映像制作
- 発表用映像制作
でした。
ハッカソンに対するもやもやの考察
ぼくは、今回のハッカソンに参加するに当たり、ある一定のスタンスを貫きました。
それは 自分が提案するものは、自分たちの世界に現実的に求められ、存続できるものであるべきであり、そのための提案の定で手段を選ぶべきだ というものです。
これは、ある意味 「ハッカソン的成果物」 とはズレたものです。
一言で言いましたが、もちろんハッカソンによって様々な評価軸と活動原理があると思います。
少し、考察してみます。
前回、初めてハッカソンに出場した時には、アイデアを考察して納得の行く提案が出るまで発案と事例調査を繰り返しました。
それにより、運営側の想定していた時間配分と大きく誤差が生じ、運営側は何度も時間を気にするよう忠告（自分の主観で言えば活動妨害）してきました。
このとき、初めてのハッカソン体験だった自分は、それを振り返ってブログにこう載せました。
僕の所感としては、ハッカソンは技術力を見せつける場所であり、提案そのものの有用性を訴える場所ではない、また、アイデアソンはハッカソンの技術を使うための題材づくりでしかなく、普段提案を考えようとしている身からすればとても浅い考察の上でとってつけるもの、という印象です。
これは、正直に当時の自分の中の葛藤を文字に起こしたものですが、今回のハッカソンを通じて、少し変化があったように感じます。
考察の鍵は、1つはハッカソン出場者ーーエンジニアの活動原理、もう1つはハッカソンの評価軸です。
エンジニアの活動原理
多くのエンジニアにとって、活動原理（モチベーション）は「この技術を使ってみたい」「かっこよく実装したい」というものにあるかと思います。
デザイナーを知る前の自分もまたこのタイプでした。
「この技術を使いたいからこれを作る」とか、「敢えてこういうアルゴリズムで組んで見る」とか、表面実装の前の段階で物事を考えることが多かったです。
しかし、そういった工夫や活動は使う人にとってはぶっちゃけどうでも良いものであることを大学1~2年で思い知らされました。
ここで、ハッカソンについて考えてみます。
ハッカソンはエンジニアの集まりであり、少なからずこういった思考（エンジニア的に言うと「技術駆動開発思考」とでも言いますか）をもって参加しているかと思います。
しかし、もしそうなのであればアイデアソンや各自の提案は必要でしょうか。
ハッカソンでは様々な提案をそれぞれのチームが提案していますが、大抵の提案が実際に商業的価値を持つものにならないという話はよく聞きます。
いっそ、全参加者が同じ提案物をそれぞれの手法で開発し、挙動の軽さやコードの美しさ、マネジメント手法などを評価したほうが良いのかもしれません。
ハッカソンの評価軸
エンジニアの活動原理的には技術に偏ったほうが良いと言いましたが、多くのハッカソンでは「開発力、アイデア、発表」を評価軸にしています。
事実、今回参加したJP HACKS2018東京会場では、実装できていない提案が最優秀賞を取りました。
これは、技術力を差し置いてアイデアが評価されたことを意味しているかと思います。
上に書いたとおり、僕個人はこのハッカソンについて「短期的開発力」「柔軟な発表力」にコンセプトを置いたハッカソンだと考えていたため、予想外の結果でした。
事前準備でさらっと触れましたが、これがハッカソン映えと勝手に呼んでいるものに繋がります。
我々のチームでは、まず現代の日本人の生活を分析し、その生活に欲しいものということで約束を管理するツールというアイデアが生まれました。
正直、これだけではスマートフォンのみで実装できますが、それだけでは”ハッカソン映え”しないということでリストバンド型のデバイスを提案しました。
ここでのハッカソン映えというのは、1つは開発力的アプローチ、もう1つはアイデア的アプローチに分けられます。
つまり技術力をアピールするため、あるいはぶっ飛んだものを提案するために提案物を考え、それそのものが議論に発展したというわけです。
ぶっ飛んだものを提案するため、と記述しましたが、これに関しても考察します。
ハッカソンに入賞するものは、たいてい今すぐ評価されるものと言うよりいつかどこかの世界で評価されるような「スペキュラティブデザイン」的評価軸を持っています。
つまりアイデアという軸は決して現代に合わせたHuman Centered Designでは無く、別世界或いは数十年後の社会に使えるような、或いは素頓狂なものが評価される傾向にあります。
これもまた、ハッカソンが難しくなる要因でしょう。
1つの曖昧な評価軸で評価されることはよくありますが、それが複数になるともう訳がわかりませんから。
競技としてのハッカソン
さて、つらつらと長文を書きましたが、ここまで書くとハッカソンが以下に複雑な競技であるかはなんとなく分かるかと思います。
評価者は、開発力とスペキュラティブデザイン的アイデア力、さらに発表力を評価します。
参加者は、この評価者の複雑な軸をなんとなく分析しつつ、それに合わせた提案を開発します。
これが、競技としてのハッカソンです。
ある意味妥協なのですが、
- ハッカソンとは「そういう競技」であるため、ハッカソン出場者はその競技に勝てるように開発を進める
- 決して提案について深く考察しないのではなく、そういった競技のための提案をしているに過ぎない
というのが自分の2度のハッカソンから得たハッカソンに対する印象でした。
敢えて僕がハッカソンを運営するとしたら、全員が同じものを作ってそのクォリティを見る「技術力特化ハッカソン」か、本当に使えそうなアイデアを最低限の技術力で実装する「アイデア特化ハッカソン」を提案しますかね…。
そんな機会無いですが。
感想
正直、大学院に入った頃はこんなにハッカソンについて考察する機会があると思ってませんでした。
また、ハッカソン中の僕の根本的疑問に本気になって考えてくれたり僕のデザインに意見をくれてより良いものを作ろうと話しあってくれたりと、チームメンバーには本当に感謝しています。
なんだかんだでハッカソンとアイデアソンに僕が3回（チームは4回）関われたこと、そしてその全てが何かしらに入賞しているのは嬉しかったです。
反省点
自分の「デザイナー」としてのスタンスを強く貫いたこと
上にも書きましたが、僕は今回のハッカソンで、確固たる意志を持ってデザイナーであろうとしました。
自分にとってのデザイナーであるということは、一言で言えば誰かのためにモノづくりをする存在であるということ――もっとややこしく言えば、自分の主観において特定の層の人たちが幸せになれると考えられるものを提案する存在であるとすることです。
すなわち、自分のスタンスはハッカソンにおける評価軸として挙げられるであろう「開発力」、それから「奇抜なアイデア」という二点を無視していました。
事前準備におけるアイデアづくりでは、必要以上に強く粘り、議論を停滞させたことも事実です。
また、それによってエンジニアメンバーに対してハッカソンの矛盾点を強く意識させてしまったと考えています。
実際、議論の中では「ハッカソン映え」という言葉が出ました。
すなわち、アイデアを重視するというチームのテーマがありながらも、上に書いたとおりあくまで競技としてのハッカソンで評価されそうなものを作ろうとしている 必要でないかもしれないものを増やそうとする活動を強く認識したということになります 。
その上で、プロダクトのコンセプトとして目先の必要なもの以上のものを求めるということを議論して決定したため、自分の中で必要でないという考えは払拭されています。
表現力不足
今回のハッカソンで発表した提案とその開発内容は、他のどのチームにも引けを取らないものだったと考えています。
けれども、それで賞を取れなかったという事実は、すなわちその魅力を伝える発表内容ーー自分が準備した発表用映像が原因だったと反省しています。
もっと提案を魅力的に伝える演出はあったはずだ。
もっと開発内容を魅力的に主張する方法はあったはずだ。
それが出来なかったのは、はっきりと自分の作業効率と時間配分に起因しています。
何でもやろうとして破綻しているだけじゃない、できる範囲のことだったはずのことが出来なかったということを、悔しく思います。
アイデアづくりの手法分析不足
アイデアってどうやって作るのか、本当にわからなくなることがあります。
今回のアイデアづくりは本当にそんな感じでした。
結果的にはとにかく分析して、頭の中で日常を分解して、ふと湧いたものが本実装のアイデアになりました。
浮かんで良かったけど、今後こんな苦労はしたくないなあ。
ちょっと考えものです。
おわりに
今後、ハッカソンに参加することがあるのかどうかすら怪しいですが、今回の経験は少なからず自分のためになったと確信しています。
ありがとうございました。