![見出し画像](https://assets.st-note.com/production/uploads/images/39400831/rectangle_large_type_2_c68b46476e112c6fff8d4b5e517c01ff.jpg?width=800)
どれだけアイデアが優れてても作りあげないと評価されないモバイルアプリハッカソンで講師した話。
日本大学の学生のモバイルアプリ開発ハッカソンです。前回は参加者募集チラシに「成長するまで帰れまてん」と書かれていて、「モバイルアプリ開発を体験してみよう」みたいなノリできた学生に
「誰が使うの?誰も使わないものって意味あるの?」
みたいな指導をすることを主催者に求められ(※ 求められたからやむなくです。嬉々としてないよ!)、泣いてた学生もいたので「このイベント次はないだろうなぁ」と思ってたんですが、まさかの2回目。しかも前回参加者も結構いる。なんで?
今後も引き続き開催するような雰囲気だったので、このイベントの特徴と今回の振り返りをご紹介します。
今回のイベントは、株式会社エイチアイ、株式会社ゆめみにスポンサードいただいたことによって開催することができています。大学生の学びにご支援いただきありがとうございます。
アイデアは新規性で評価しない
イベント名に「ハッカソン」を銘打ってますが、自由度の高いハンズオンみたいなものです。ペルソナ、解決する課題などを都度、それぞれ講師と参加者相互がレビューします。
#nucamp
— たなかゆうた (@nayuta999999) November 14, 2020
プロにアプリ案ボコボコに言ってもらえるの本気でありがたいな~
ボコボコにした記憶はないんですが(※)、人間中心設計になるように指導はします。
人間中心設計は簡単にいうと「こういう人がこういう困りごとがあるからこれで解決しよう」とユーザを観察して設計することです。この逆は機能を中心にして「こういう機能は誰かにとって便利なはず!すごい機能だったら誰かが使ってくれる」と設計します。
もちろん「どういうアプリをつくろう」という思考上、機能を先に思いつくことは当たり前にあるのですが、アプリのユーザを聞いて「使いたい人が使う」と答えると酷評されます。ちゃんとペルソナを立てましょう。
これにはふたつの意味があって、まず判断基準をつくることができます。「AとBの機能どちらがいいかなぁ」ってなった時、ペルソナがあれば「このペルソナユーザならBであるべきだ」と判断基準が生まれます。
ペルソナとコンセプトが固まってると話し合いで迷った時に戻ってこれる
— 織田 (@Oden612) November 21, 2020
もうひとつはまともなプレゼンができます。「誰が、何に困ってて(ペルソナ)、それを解決するアプリが必要。この機能で解決して、こういう世の中をつくる」と話そうと思ったら、スタートラインであり土台部分であるペルソナがちゃんと固まってないといけないんですよね。
新規性がある!とか、マーケット性がある!みたいなことは一切評価されません。ユーザのペルソナがちゃんと設定されていて、それに対するアプローチの軸にぶれがないことがアイデアとして評価されます。
ちなみに、「〆切をやぶったことを自分で記録しつづけて反省することで、〆切を破ることを防ぐ」みたいな都合のいいストーリーを描くとこういうツッコミが入ったりします。
去年の卒研発表会で、片付けのできない人がいかに何をやっても片付けできないか語り、先日の #nucamp では〆切を守れない人がいかに何をやっても〆切を守れないかとうとうと語ってしまったんだけど(もちろん自分の経験談として)、こんなことを偉そうに語る俺はちょっと頭おかしいのではないか。
— Tetsuro Kitahara (@tetsurokitahara) November 16, 2020
「ないよりあった方がいい」というレベルは最初の方で没られます。
地獄への道が善意で舗装されているように、世のクソアプリはみんなの「あれば良さそう」って無責任な善意から生まれてくるんだぞ #nucamp
— Yosuke Onoue (@_likr) November 14, 2020
動作しないと評価されない実装
実装することを考えなかったらどれだけでも大法螺をふくことができます。
例えば「スマホで野菜や魚を撮影したらAIが野菜の品質を評価してくれるのでスーパーとかで賢くお買い物!」とかいうのは簡単なんです。実際には、「評価の教師データは?」「精度ってどれぐらい?」「品目どうする」みたいなところからスタートして山のように課題があるんですが、言うのは無料。ちょっとしたHTMLを書くことができれば、モックもそれっぽく動かすことができる。すごーい。
では何の意味もないので、ちゃんと動作しないと評価されません。アイデアと実装は両輪です。ちゃんと動いても、http://localhost だとこんなこと言われます。
ハッカソンをlocalhostでデモするやつはデモじゃねえ。デプロイしてからが本番。 #nucamp
— 奥野 賢太郎 / Crescware (@okunokentaro) November 22, 2020
Ionic Frameworkを推奨
採用技術にはIonic Frameworkを推奨しています。知らない人向けに説明すると、Web技術でモバイルアプリをつくるためのライブラリです。Capacitorと組み合わせることで、WebアプリをAppStoreやGoogle Playでモバイルアプリとして配信できます。
まぁ、書けるなら、SwiftでもReact Nativeでもいいんですが、IonicだとWeb技術なので当たり前にWebでサービスを配信できるんですよね。つまり、最終プレゼンで審査員や聴衆に実プロダクトをさわってもらうことができる。特定画面しか動かさずに誤魔化すことができないので評価はもちろん高いです。
どういうチームが優勝したか
勝ちにきたチームが優勝しました。この記事をみれば、勝ちに来て、順当に買ったということが伝わると思います。
ハッカソンで勝ちにくることと、プロダクトのユーザ体験を高めることは往々にして一致しないので、前者だけを優先したら評価をぐっと落とそうかなーと思ってたのですが、ちゃんと勝ちにきた先にユーザがいたので減点はなかったです。
ニーズ調査したり
プロダクト開発途中にユーザテストしたり
独自ドメイン取得してリリースしたり、大学の就職課に導入営業したりしてて、うん。順当に優勝だった。
昨日のハッカソンの優勝チームは、本当に納得の優勝だったし、接戦の2位も優勝の可能性あるクオリティだった。惜しくもデモがトラブルで出せなかったチームもポテンシャル感じたし、これは絶対に次回楽しみですよね。 #nucamp
— 奥野 賢太郎 / Crescware (@okunokentaro) November 23, 2020
ちなみに全5チームあったのですが、上位2チームは接戦でしたし、トラブルなくデモだせてたらそこに食い込めたのではとか、あー、実装がもっと・・・!みたいなチームとかだって、別に優勝したチームだけが突き抜けてレベル高いわけではなかったです。
当たり前のことを当たり前にできるように
大学の授業では採点の都合でどうしても「答えのある課題」を課すことが多いです。しかし、マーケットにおいては答えがあることの方が少なく、自分自身で指針を立ててそこに向かって仮説検証を繰り返していく力が必要になっていきます。
このハッカソンでやるようなことは、Webサイトやアプリ制作をやってる人にとっては当たり前に身に着けてる基礎能力ですが、そういう能力を現場にでる前に身につけるために「ハッカソン」というスタイルはすごくいいのではないかなぁと前回・今回を通して感じています。
3月から成長は出来てるのが分かったけど全然力量不足。ちゃんと言語理解すべきだしエラーを自力でやっつけられるようになりたい。#nucamp
— みさと/Tsubame (@Tsubame_misa) November 22, 2020
自分の課題を明らかにしたり
おつかれさまでした。
— Kazuki.O (@kazuki_496) November 22, 2020
去年の作品を見て恥ずかしくなるくらいには成長できててホッとした。#nucamp
自分の成長を実感したりする中で、当たり前のことが当たり前にできるようになっていく機会として、ハッカソンに参加したり、こういうスタイルのハッカソンを開催したりしてみませんか?
それでは、また。
この記事が気に入ったらサポートをしてみませんか?