Hack Dayで三冠→四冠したチームがもう一度優勝はできなかった ——Digital Hack Day 2021 参加記
2021.09.25-26&10.10開催の「Yahoo! JAPAN Digital Hack Day 2021」にて、僕の属するチーム「ポピポポピピプピリロピロリププププピーポ」が予選で「Happy Hacking賞」をいただいて決勝進出したものの、決勝で最優秀賞を手にすることはできなかった。悔しい。
本番のプレゼンは以下より。
予選↓
決勝↓
今回は決勝で負けてしまったというのもあって、今までとは違ってちょっと真面目なテイストのnoteとなっている。皆さんだって、上手くいった時のnoteより上手くいかなかった時のnoteの方が気になるでしょう。そうでもない？
ここから先は例に漏れず、私視点での今大会と私たちのチームの振り返りを行なっていく。推敲など行っていないから支離滅裂である。むちゃくちゃ長いが、ぜひ諦めずに最後まで読んでほしい。読みやすいように画像マシマシにしたので。
ズッ旅イッヌ？
そもそも我々が何を作ったのかという話だが、プロダクトがデカい上に利用する視点も3種類あるため、一言で言い表しにくい。これが敗因の一つだと思っている。
我々が作ったプロダクトは3種類あり、それぞれが情報を収集して互いに共有することで全てのUXの質が上がるという仕組みになっている。順を追って説明する。
本番プレゼンより
① ズッ旅イッヌは、あなたとずっと一緒に旅をしてくれる犬である。
この犬はあなたと一緒に旅をしながらあなたの好みを学習し、あなたの旅行をもっと楽しいものにする提案をしてくれる。
犬は「こっちにいい道があるよ！」と物理的に引っ張ってくれるし、近隣の店から招待チケットやクーポンをもらってきてくれる。
引っ張りには「振動スピーカを用いた力覚提示手法の知覚特性
(K. Tanabe et al., 2017)」と同じ振動デバイス／技術を用いた。
② 旅行客が触れるデバイスはもう一つあり、地図案内板である。犬は引っ張ることしかできないので、ビジュアルが必要なものはここに表示される。
顔認証でログインすると、現在地、通ってきた道、他の人のいいね地点のマップ、行くべきおすすめの道が数パターン、近隣店舗一覧とその混雑状況などが一画面で確認できる。
また、店舗からの招待チケットや限定クーポン(後述)なども表示され、タップすることで受け取り、席の予約まで終わる。更には顔認証決済もできる。
膨大な情報量をUIデザインの力でねじ伏せている
③表示されている店舗たちは、近隣の店や観光地がズッ旅イッヌのLINE公式アカウントを友だち登録することで表示されている。LINE Bot上で限定クーポンを登録して配ったりできる他、リアルタイム混雑度を登録することで、旅行客に混雑度を伝えると同時に空席を解消するように自動で旅行客に招待チケットを飛ばす。また、近くの地図案内板を用いて顔認証決済もできる。
こだわり
面白いプロダクトというだけで終わらせず、実際に導入しようとした時にどんなハードルがあるのかということに向き合った結果、以下の3条件にこだわって開発を行なった。
・導入の初期コストを極限まで下げることで、すぐにでも使ってもらえるプロダクトにすること。特に旅行客はスマホや財布も使わず、身一つでこのプロダクトを利用できるということ。
# 導入コスト
## 犬
まち: 駅とかに置くだけ
旅行客: 駅とかで受け取って持つだけ、初回登録は免許証と犬を地図にかざすだけ
## 地図案内板
まち: 街じゅうにタブレットを置くだけ
## 店舗用LINE Bot
店舗: 公式アカウントを友だち登録するだけ
・UIを極限まで簡素化することで誰でも簡単に、日常的に使ってもらえるようなプロダクトにすること。
またそれにより、ユーザーのささやかな情報(旅行客の「いいね」や店舗の「ちょっと混んできた」など)をできるだけ多く拾えるようにすること。
# UI
## 犬
input:
鼻を押す: いいねが記録される
output:
耳を触る: 触覚デバイスによるナビ
## 地図案内板
input:
画面を見る: 顔認証ログイン、顔認証決済
画面をタップ: 招待チケット受け取り
output:
地図: 地図、いいね地点ヒートマップ、ナビ、店舗混雑状況、招待チケット状況
## 店舗用LINE Bot
input:
リッチメニュー: 店舗登録、メニュー登録、混雑状況登録、クーポン発行
output:
LINE Bot: 予約通知等・データが溜まって行くごとに、リアルタイムにプロダクトに反映され、ユーザー全員のUXが向上していくこと。
# UX
## いいねヒートマップ
他の人が実際にいいねと入力した地点が一覧で表示される。
## おすすめ道
いいねスポット履歴から学習するので、自分が押しても他の人が押しても自分の道の精度が上がる。
## チケット
受け取った／受け取らなかった履歴から学習するので、旅行客は自分に最適なチケットが送られてくるし、店は受け取ってくれる可能性が高い旅行客にチケットを送れる。後述するが、前々回が「"Fun"のポピ」、前回が「"Hack"のポピ」だとするならば、今回は「"課題解決"のポピ」になろうと決めたのだ。今までと違って、実際の社会にインストールするということを強く意識して開発を行なった。
再現性のあるイノベーション
申し遅れてしまったが、我々がYahoo!のHack Dayに出場するのはこれが3回目で、前回がこれで、
前々回がこれである。
終わった後は「もう二度と出ねぇ〜〜〜」と言っているのに大会が発表されたら「応募するか〜〜」となる流れも2回目である。そして、今回も「前回が華々しかったから今回出場するのは蛇足では？」という部分に悩んだ。
開催発表直後の感想
それもあり、「人工の狂気」というテーマは自分の中で変わらずあるものの、今回はより「再現性のあるイノベーション」という部分にフォーカスした大会だった。
前回も前々回も、原案の部分は私が出したものが採用され、結果的にうまくいっていた。しかし、「天才的なアイデアを思いついて解決する」というのは非常にサステイナブルでない。より価値があるのは、「天才的なジャンプに頼らずとも、あるプロトコルに沿って思考／試行していけば良いものができる」というものである。
そのために、アイデア出しの際に自分の思考プロセスも含めて共有したり、着想を得やすいワークショップ的なことも行なった。具体的には、シンプルなブレインストーミングや、2人*3チームに分けての1on1ミーティング、最新の技術トレンドへのキャッチアップなどである。
「日本における未来志向型インフラ・テクノロジーの
ハイプサイクル：2020年」出典：ガートナー ジャパン
これが功を奏したのかは分からないが、今回の原案は私ではなくしう(@grouse324st)であるし、その他の大部分のアイデアに関して、みんなから積極的な意見が出た(後述)。そういう意味では再現性というのは一つ達成された目標かもしれない。
誰も取り残さないデジタル化とは何だったのか
この大会の開催が発表され、ホームページで今回のテーマを確認した時、私は愕然とし、心の底から絶望した。
この「課題を解決」の一言が、これまでにどれだけのイノベーティブなアイデアを潰してきたか、みんなわかっちゃいないのだ。「『2位じゃダメなんですか？』」「文系不要論」をボコボコに叩きまくっていたあの頃を忘れてしまったのか。
しかし絶望してばかりもいられないので考えを進めよう。とりあえず最優秀賞を取る事しか考えていないので審査基準を見る。
なんと、「課題解決」の中に「誰も取り残さないデジタル化」があるではないか。これがどれほどヤバいことを言っているかお判りだろうか？？？
「誰も取り残さない」というのはデジタル庁のスローガン「No one left behind」、さらに言えば持続可能な開発目標（SDGs：Sustainable Development Goals）の「Leave no one behind」から来たものと思われる。
平井大臣「高齢者や障がいを持っている方にも扱えるUI・UXを目指し、誰も取り残さないこと。徹底的に、あらゆる人がアクセスできる省庁システムをつくる。これが最も重視するビジョンです。
それでもシステムにアクセスできない人は出てしまうでしょう。カバーできない人々を一人でも減らしたい。そのため、デジタルだけに注力せず、アナログ空間でもサポートを行っていきます」
ーSTARTUP DB "「誰一人取り残さないデジタル社会」の実現。平井卓也大臣に聞くデジタル庁のビジョン"
つまり、「誰も取り残さない」はアクセシビリティの観点なのである。誰もが使えるプロダクトにするということ。既に便利な、恵まれている人がより恵まれるのではなく、
決勝の生放送の導入で「スマホ一つでなんでもできる世の中になりました」というフレーズがあった。たしかにこれは間違っていないが、個人におけるスマホの普及率は2019年でも67.6%だ。国民の3人に1人はスマホを持っていないのだ。
「課題解決」に対する答え
「課題解決」とは誰かの課題を劇的に解決することであって、それ以外の人にとっては関係のないことである。
対して「誰も取り残さない」とは、全員が同じスタートラインに立てるプロダクトであり、誰かに劇的な効用があるわけではないが、その分、全員に緩くメリットがあるということである。
この二つは端的に言って矛盾している。私は静かに怒り狂っていた。誰かがめちゃくちゃ困っていることは、他の人にとっては全く課題ではないし、逆に国民全員に共通する課題となればかなりインパクトの薄いものになるだろう。
(国民全員がむちゃくちゃ困っていることがあるとすれば、もうすでに多くの人や国、自治体が必死に取り組んでいるものであろう)
怒り狂いつつ、これらの矛盾を解消する中で導かれた結論が、「全員が、さまざまな関わり方ができるプロダクト」であった。課題もバックグラウンドも違うさまざまな人々が、一つのプラットフォームに対してアクセスし、たくさんの機能の中から自分の課題にあった使い方をしてもらう。人それぞれに、思い思いの価値を見出してもらう。そんな多面的なプロダクトであれば、このテーマに対する答えになりうるのではないかと思った。
原案「観光地DX」のメモ。
観光に関わる全員をデジタル化する
今回観光地をターゲットとした背景としては、まず都市開発のデジタルツインの話をしていた時に、「街がオープンソース化して、例えば看板の多言語表記やバリアフリーのデザインなどの改善案をみんながバーチャル世界の街にコミットし、それがリアルの街にマージされたらいいよね」という案が出たのがきっかけだった。
ただ、このプロダクトをそのまま作っても、使える人々が限られたり、全員が継続的に使ってくれる方法が難しかったりというのがあり、まずは始まりと終わり(旅行期間)が決まっている「観光」というイベントならみんな使ってくれるのでは、という流れであった。
観光に関わる主体は大きく分けて「旅行客」と「観光地」に分けられ、さらに観光地は「まち(行政)」と「店・観光スポット」に分けられる。
いい感じのイラスト
これら全員がお互いに最適化しあい、UXを高め合い、全員で街を作っていくというビジョンである。うわーデベロッパーっぽい！！ヤベ〜〜
戦い方
今回の目標は最優秀賞に絞っていたので、どう戦おうかということも色々と考えていた。
ポピらしさとは何かと考えた時、「変なことを全力で」というのが挙げられると思う。寿司を爆速で提供したり、年賀状を超圧縮したり。現実の課題に則していないようで微妙に則していて、実用性ではなく、こういうプロダクトが世にあったとしたら夢が広がる、というようなもの、そういうものを作ってきたつもりである。
その心意気は寿司が走っていた頃から変わらない。
しかし今回は大会のテーマにデカデカと「課題解決」と書かれてしまった。めちゃくちゃ正直に言うと、決勝進出の10チームが発表された時、「そら言わんこっちゃない、みんなお行儀よく課題解決しとるやないけ、おもんな！！」と思った。
結局、採点基準に明記されているというのもあり、「そのお行儀良さの中で正面から戦ってやろうやないけ」という結論になった。後から考えれば、最優秀賞を取るということに最適化するならこれが得策でなかったのかもしれない。
〜〜〜
ここからは、今回の開発の内容やその中での気づき、もう少しメタにチームビルディングの話などを書き殴っていこうと思う。
圧倒的成長①
ふと後ろを振り返った時、前提となる技術レベルが爆上がりしていることに気づく。
学部生だった2年半前にhackdayに参加した時はサーバーサイドってどの部分？reactって何？gitでチーム開発どうやるの？という感じだったけど、今回はflaskサーバーを作ってherokuへデプロイし、postgresを読み書きし、APIを作ってドキュメントを書いた。成長を感じる。
— たかはま (@grouse324st) September 28, 2021
当時は(私以外)全員学生だったところから、全員社会人になり、単なる開発技術以上に、チーム開発やプロジェクトマネジメントなどの知見を得た。
ブロックチェーンや分散台帳、暗号DB、秘密計算、量子コンピュータなどの最新の技術から、ハードウェアの回路設計や組み込みコードの低レイヤのアーキテクチャ、VercelやHeroku等のDevOpsツール、更には外部APIをwrapするサーバーを立ててマイクロサービスとしてシステムに組み込んだり、NotionとSlackを活用してドキュメントとコミュニケーションをマネージしたりと、エンジニアリングのあらゆる分野に対して目を向けられるようになった。これでもみんな新卒1年目の代なのである。
前々回の「都会のオアスシ」の技術スタック
今回の「ズッ旅イッヌ」の技術スタック
それ自体が素晴らしいことであるというよりは、何か機能を追加したい時に取れる選択肢の幅が広がったことで柔軟な設計が可能であった。
API駆動開発
今回は本格的に開発を進める前に、誰が何をするのかの線引きを行うことで責任範囲を明確化し、「ボール」が落ちていることがないようにした。
実際に作成した図。赤い線がシステム境界で、青の矢印が主要なAPI。
具体的には上のようにシステムの地図の上にインターフェースの線を引き、それぞれの領域に人を配置して、API設計は関与する2人に任せ、APIを明確にしてから個々のシステムの開発を行うこととした。
これはかなり効果的で、開発の早い段階で各人が「あとは一人で頑張るだけ」のタスクを得ることができたと思っている。
イッヌ
ここから個別のプロダクトの話に入ろう。
一番苦しんだのはハードウェア(犬)であった。提供技術からWio LTEを使用したが、ストレージ1MB/RAM192KBというスペックや、端子の規格などの制限があった。(Arduinoを使えという突っ込みはご法度である。)
イッヌのシステム構成。端子的にもギリギリの構成。
最低限で言えば、いいねを記録するためのボタンひとつ有ればよかった。しかしそれだと持つインセンティブも押すインセンティブもない。だから何かのボタンである必要があった。カメラという案も、自撮り棒という案も出た。しかし、どれもその後のインセンティブに欠けた。冷静に、スマホの下位互換になってしまう。
それならいっそ、今までにない新たな体験を生むしかないとなった。このデバイスと一緒に旅するという新たな旅行体験。旅の相棒。そのためには愛着が必要であった。ゆえの犬なのだ。犬ならば鳴くべきだとか、ご飯を欲しがるべきだとか、ウンコすべきだとか、愛着を持ってもらうためにさまざまな案が出された。予選の時点では、鼻を押すと鳴いたり光ったりして喜んだ。(光る？)
その中で最終的に選ばれたのは、「変な方向に引っ張っていく」であった。
元々の「おすすめの道を提案する」という案の性質上、別に行こうと思っていない道に進んでもらう動機が必要で、「犬がわがままを言う」はそこにバチっとハマったのだ。
触覚デバイス部分はこの研究と同じスピーカー、同じ波形を用いた。
予選の段階では、地図案内板にルートが出ることを持って「引っ張っていっている」としていたが、もっと直接的にイッヌが引っ張ってくれたたら画期的だろうということになった。中で重りが動くとか、重りを回転させた反作用のトルクという案なども出たが、最終的には振動アクチュエーターによる牽引力錯覚を用いることにした。要するにスピーカーから特殊な音を出すと、引っ張られている錯覚を感じるという研究である。
9軸センサー(加速度、ジャイロ、地磁気)で姿勢と方角を取得、またサーバーから自分の行くべき方角を取得し、水平に保持された時に、正しい方角に向くまで右や左に引っ張っていくという実装にした。
スピーカーから音声を出す部分が原始的な実装しかできなかったので、最終的な理想の触覚までは辿り着けなかったが、最近ちょうど音響系のハードウェアについて調べていたのもあり、問題の特定がスムーズだったのは個人的な嬉しいポイントだった。
他にもGPSモジュールがパッシブ型であり、衛星からの信号があまりにも貧弱で全く通信できなかったり、電源部分の端子の規格がドキュメントを見ても分からなかったり、さまざまな困難を乗り越えた。
GPSモジュールの動作テスト。パラボラを手作りしてようやく通信できた。
ちなみに、予選の段階では犬にNFTを発行していた。つまり、旅行が開始したら犬NFTはサービス側に委譲され、魂がIoTデバイスに宿り、逆に旅行が終われば旅行客の個人Walletに戻るというものである。モンスターボールのようなイメージだ。
犬FT案は犬のかけがえのなさやズッ友感があって、私はかなり推していたのだが、UXに全く反映されないのと、無くてもプロダクトに全く支障がない、というか実態はNFTが独立にやり取りされるだけになるため、決勝プレゼンでは削ぎ落とされてしまった。本当は暗号化と組み合わせて、NFTの所有者だけが自分の過去の旅行履歴にアクセスできるなどとすれば、実際的な価値が生まれると思う。
秘密分散の理解を深めた時のメモ。天才っぽい。
また、本当に時間があれば、今サーバーでやっている処理をエッジに持たせるというのもやりたかった。道推薦などをエッジで、もしくは秘密分散によって計算だけ外部に委託するなどができれば、よりナウいプロダクトになった気もする。どれほどの意味があるかはあまり分からない。
地図案内板
実装が集中したのは地図案内板であった。Mapboxが素晴らしかったので、基本的に全ての処理がブラウザ上で走り、適宜外部APIなどにクエリ/ポーリングしつつ全てをブラウザ上に重ねて表示するという実装になった。カスタムデザインされた地図上にヒートマップを重ねて表示する、などというのはMapboxの十八番であるようだ。
顔認証ログインした際の挙動
おすすめ道は、まず近辺のいいねポイントに対して協調フィルタリングを用いて自分へのおすすめ度を算出。現在地から全方角に向かう道の中で、通るいいねスポットたちのスコアを合計した道スコアが最大となるような道を上位3パターン提案する。協調フィルタリングは映画のレコメンドなどにも使われている、原始的な割に直感的かつ機能的なアルゴリズムである。
顔認証は、まずTensorFlowで顔検出を行い、顔が検出され次第LINE eKYCに投げて特徴量を算出、類似度が閾値を越えるかで個人を特定している。LINEの顔認識はかなり優秀で、ちゃんと前に立った時に人を間違えることは一度もなかった。(端っこで映り込んだ人を間違えたりはあった)
LINE eKYCはLINE Face(顔認識)とLINE OCR(文字認識)からなり、通常の利用用途でいうと免許証やマイナンバーカードを読み取って情報を取得し、さらに顔も取得することで本人確認を爆速で終わらせるという技術である。今回は特に、初回登録を免許証で行うことで、顔データや氏名などを一度に登録させることとした。
UIは今回のテーマカラーである緑を中心に、基本的にはモノクロームとし、色ではなく濃淡やオブジェクトのサイズ、形などを用いて情報を表現した。
これは色覚バリアフリーの観点もさることながら、大量の情報を一つの画面に置く必要から、できるだけ無駄を削ぎ落とすという意図も大きい。
というかそもそも、元々は旅行客が使うスマホアプリも用意するつもりだった。今回の地図案内板と同じような内容をいつでも確認できる便利アプリで、盛り盛りの高機能にさせようとしていた。しかし、今回の主旨としてスマホアプリを最強にするのは全く面白くないと思い、スマホを捨てるという選択をした。
原案(抜粋)
ちなみに決勝プレゼンの時に用意した27インチカメラ付きは、弊社①の株式会社東京が実際にサイネージとして現場に設置しているもの(のジャンク)をお借りした。
[PR] 株式会社東京はオフィスビルのエレベーターホールにサイネージを設置して物件価値を向上させるメディアです。
LINE Bot
店舗がチケットを発行したり、混雑状況を伝えたりするUIが必要である。これも様々な方法が考えられ、IoTガジェットを席に置いたりカウンターに置いたりする案も出たし、シンプルに赤外線で取得するというソリューションであればこの世に既に存在する。
しかし、「デバイスを置くにはデバイスを用意しなければならない」という導入のハードルがあるため、今回は、LINEをやっていれば友だち登録するだけで使えるLINE Bot(公式アカウント)を使うことにした。
全てメッセージベースの対話型のコミュニケーションで操作してもらえる点、デザインをリッチにしようと思えばインプットも(リッチメニュー)、アウトプットも(カルーセルなど)も簡単に綺麗にできる点、あとはメンバーの大半がもうすでに何度も使ったことがあるため開発に馴染みがある点など、かなりコスパが良いプロダクトとなった。
自分はここのインフラの部分(LINE Messaging APIからGoogle Apps Scriptのサーバーを呼び、SpreadsheetをDBにして読み書きする部分)を担当したが、個人で開発して常用している家計簿アプリのコードをそのまま流用したので1時間くらいで一通り動かすことができた。
一番のこだわりの機能は、混雑自動緩和である。
店側がすることは、混んできたら「混んでいます」、空いてきたら「空いています」をタップするだけ。現在の混雑状況が地図案内板にも反映され、旅行客にリアルタイムの混雑状況が伝わる。
状況に応じてタップするだけ
丸の大きさで混み具合がわかる
それだけではない。店の混み具合に応じて、最適な人数の最適な旅行客に招待チケットを送るのだ。
「最適な人数」というのは、あらかじめ店のキャパシティを登録しているので、「混んでいます」だとその0%、「ぼちぼちです」は50%、「空いています」は100%の人数を集客するということである。
「最適な旅行客」というのは、まず店からいい感じの距離にいるかどうかを判断している。まず遠くにいる旅行客は呼んでも来るまでに時間がかかり、その頃には混雑状況が変わってしまうだろう。また、店が空いてから集客しても遅いので「そろそろ空いてきそうだな」という時に集客したいというのを考えると、呼んで即来るわけではなく、10分とか15分とか、少し経ってから来てくれることが望ましい。
後から見直しても何も分からないメモ。
これらを考慮して、「店から徒歩15分ぐらいのところにいる旅行客」にチケットを出している。これには、タクシーの配車アプリが「30分後に〇〇駅に着きたい」と予約すれば適切な車を配車してくれるアルゴリズムをHackして、旅行客をタクシーとして登録することで「配人」をを行っている。
MONETの皆さん、DBをむちゃくちゃにしたことをお許しください。また、Hackyな部分をうまいこと処理してくれたkamoには頭が上がらない。エラー吐くたびに口から「Macでファイルをドラッグ&ドロップした時の音」みたいなのが出ていた。お疲れ様でした。
予選スライドより。僕たちでも1時間ぐらい考えないと
分からなかったので、プレゼンで伝えるには無理がある。
「最適な旅行客」にはもう一つの観点があって、店と客との相性である。データベースにはその旅行客がどの店のチケットを受け取り、どれを受け取らなかったかという履歴があるので、おすすめ道の時と同様に協調フィルタリングを用いて「より受け取ってくれそうな旅行客」にチケットを出すことができる。店側からしてもターゲティング広告ができていることになるし、客側からしても興味のないチケットがどんどん減っていき、まちが自分に最適化される体験となるので嬉しい。
顔認証決済も、LINE Botと地図案内板ですぐに導入することができる。LINE Messagingでリクエストを送り、CLOVA eKYCで認証し、LINE Blockchainで支払いが行われるのは全てLINEの掌の上な気がして少々癪だが仕方がない。
思えばBlockchainの機能を普通にコインとして使ったのは初めてかもしれない。すぐFTを作りたくなるので。
圧倒的成長②
プロダクトの話はこの辺りでおしまい。もう一度チームの話に戻る。
前回から圧倒的に変わった点は、メンバーが自分から「もっとこうしたら良くなる」を提案してくれるようになった点である。
本番数日前にてんやわんやしている時に
先回りして決めること決めよと言ってくれた図
「ここのアルゴリズムはもっと良くあるべき」「これではまだ〇〇ができているとは言えないので改善すべき」「このプレゼンではメッセージが伝わらないからこうすべき」みたいな案がたくさん出てくるようになった他、「UIをいい感じにしておいたよ」「推薦アルゴリズムを改善しておいたよ」などと自発的に実装まで終わらせるメンバーもいた。
偉いことをした人には「偉し」と言います
途中から、「これはみんなモチベさえ保つことができればあとは勝手にいいプロダクトができるな」と思い、各メンバーとのコミュニケーションと、メンバー同士のコミュニケーションの活発化のアシストに徹することにした。マイクロマネジメントはモチベーションの低下につながるどころか、お互いの工数が勿体ないと思う。
HPを削らないコミュニケーション
予選がオンラインでの開催というのもあり、コミュニケーションのハードルを極限まで下げることが課題であった。
ミーティングの予定一つ立てるだけでも、「ミーティングしたいんですけど明日の夜空いてますか？」だと全員からの返事を待った上でさらに「それではカレンダーに書いておきます！」みたいな往復が発生する。それが、
だと、うまくいけばこれだけで全て確定するし、参加できない人はリスケのモチベーションがあるので爆速で返信してくれる。
基本的に、「判断をする」というのは人間のHPを削る行為なのだ。
何というか、自分が社会人になったんだなと思う部分は多々あって、かつてのガムシャラなパワーみたいなものはだいぶ減ってしまったような気はするのだが、その分年相応のスキルをもって新たな武器を作り続けているとも言えるのかもしれない。何のこっちゃ。
敗因分析
いい加減何の話をしているのか分からなくなってきたので、そろそろ敗因の分析に移ろうと思う。「最優秀賞を取る」という目標を立てただけに、「最優秀賞は取れなかったけど自分たちの作りたいものが作れたし楽しかったからオッケー」などと片付けるつもりはなく、今後のために反省をしてゆく。
90秒のプレゼンに収めるとは
このプロダクトは大変魅力的なプロダクトであると自負しているが、登場人物が旅行客・まち・店舗と3人いるのも、プロダクトが3つあるのも、90秒に収めるには情報過多だったと思う。
我々は「沢山の人がそれぞれの関わり方をしてそれぞれの価値を享受する」ことを目標としていたが、視点の切り替えは脳に負荷がかかる。断腸の思いで、ある一つの視点に絞った方が刺さったと思う。
特に、普段のHackDayでは展示の時間が存在し、プレゼンで伝わらなかった部分は審査員が直接訊きに来てくださった。しかし決勝はプレゼン90秒が全てだったため、カオスをカオスのまま放置してはいけなかったのだと思った。
決勝プレゼンの左のメニューはカオスと秩序のいいバランスだった気がする
結局「自分ごと」じゃないと伝わらないかも
ビジネスの現場でも、「こういうところでこういう人が困ってるんです！」というプレゼンをしたところで、相手がそのペインを実際に抱えていないと全然刺さらないことが多い。
今回の決勝進出チームの中でも、FAXを片側だけ全てLINE Bot化させたり、オープンデータ作成の際のlinterをエクセルのプラグインで実装したり、実際の現場の課題にぶっ刺さりかつ鮮やかな方法で解決したチームがあった。正直にいうと、負けるとしたらそのどちらかに負けると思っていた。
課題解決感を優先させるために決勝プレゼンでは行政の視点で、観光開発支援プロダクトとして推したが、視点をわかりやすく一般人(今回で言う旅行客)に固定して、旅行客のカスタマージャーニーに沿ったストーリーの方が脳に優しかっただろう。ちなみに予選ではそのようなプレゼンであった。
イッヌ「見て見て！チケットをもらってきたよ！」
審査員の視点に立つ
これは上二つと重複していると言えなくもないがあえて独立させた。
今回、予選は割と「いつものHack Day」だったと思う。提供技術を使いこなすことはそれだけで評価されるし、プレゼンはみんな徹夜明けの顔で来る。展示の時に実際にプロダクトが動いている様子などはそれだけで大変趣深い。
しかし決勝はむちゃくちゃあっさりしていた。24時間どころか追加で2週間も開発したにもかかわらず、その工数は全てカプセル化され、どんなプログラムもプレゼンでは5秒程度で流される。その「軽さ」に関してあまりにも無頓着だった。
提供技術をうまく活用などは予選の話であり、決勝には全く関係ない。予選の際に他のチームがどんなことをしていたとか、このアイデアは実はもう世の中にあるよねみたいな議論なども全てリセットされ、全く知らない人間の全く知らない90秒プレゼンを10個観て、それだけから1チームを決めるのだ。
実は技術的な話すら全部捨てて、
機能だけに絞ってもよかったのかもしれない。
逆に言えば、あのカオスなプレゼンから、全く言及しなかった「UIを徹底して洗練することで全員に導入してもらう」という意志を汲み取ってくださったことは奇跡に近いと思っている。審査員の方々には大変頭が上がらない。
敗因分析まとめ
敗因分析の中にプレゼンの話しか出てきていないのは、プロダクトが素晴らしいものになったという自負があるからである。やり切ったという自負もある。3つの選考基準に対しても、自分なりに納得のいく答えを出せたつもりである。
すごい量のドキュメント。プレゼン案もいっぱいある。
プレゼンは何度も根本から見直したし、原稿はver.10くらいまでできた。これで伝わるのかという議論もたくさん出た。プロダクトの存在意義まで立ち返って議論するというのも幾度となくやった。
それでもまだまだ想定外のことがあるというのは、世の中の面白い部分でもあると思うし、もっと成長しなければと思う部分でもある。
総括
前々回が「"Fun"のポピ」、前回が「"Hack"のポピ」だとするならば、今回は「"課題解決"のポピ」になろう
という部分は、かなり達成できたのではないかと思う。実際このプロダクト、どうですか？手前味噌ながら、かなり面白い試みだと思うんですけど。
最優秀賞を獲ることだけを見据えてきたのに獲れなかったことは素直に悔しい。最優秀賞を獲った「もっちり」の皆様、おめでとうございました。
最後になりましたが、応援・投票してくださった皆様、
毎回このすばらしい大会の運営をしてくださる事務局の皆様、
プレゼンを観てくださった予選・決勝の審査員の皆様、
そして膨大な時間を共に過ごしたチームメイトのみんな、
本当にありがとうございました。
24時間でも大変なのに2週間もあると無限に寿命を削ってしまうので、運営の方々におかれましては、次回大会は是非とも24時間でお願いしたい。いや、次回はないかもしれない。あるかもしれない。
それではまた。おやすみなさい。
