大規模アプリ開発系コンテストでの生存戦略
ここで言う 生存戦略 とは、いかにコンテストで勝ち抜くか、という点に焦点を当てたものだ。コンテストでの優勝にはある種の運、例えば発表する環境や審査員のバックグラウンドなども関わってくるため、優勝を目指すのではなく、いかに優勝に近付くことができるかという記事。
本題
大規模なアプリ開発系のコンテストでは、単純なアプリを作るだけでは審査員の目に止まらない。
こういったコンテストでは大概、そのアプリを使うことによって 日常に起き得るどのような問題を解決できるのか という点が最も重要視されており、これをクリアすることが開発者にとっての最初のハードルになる。(中小規模のコンテストでは純粋な面白さが重視されることもあり、この限りではない)
だからといって、ただ単純に問題を解決できるアプリを応募しただけで勝ち抜けるという話でもない。
自分がいくつかのイベントに参加し、実際に多くのチームの発表や作品を見て感じた、勝ち抜くためにアプリに組み込むべき基本的な要素は次の4つだった。この何れかが抜けているだけでコンテストで勝ち抜くことは難しくなる。
- 問題提起
- 解決方法の提案
- 結果と規模
- フィードバックと反映
この要素は必ず必要なもので、ほとんど例外はない。(ハッカソンは別)
また、コンテストで会場展示・プレゼンを行う場合は、この4つの要素を端的に分かりやすく伝えるためのトークスキルなど、マーケティング能力のようなものも必要になってくる。優勝しようと思うのであれば、ここまでの準備を完璧にこなす必要がある。
以下の項目では、各要素で何を行うか・どんな点に注意すれば良いかを記載している。
問題提起
アプリを開発する前に、まずは身の回りでどのような問題が発生しているかを探る必要がある。そしてコンテストに応募するアプリはその問題を解決するものであるものが好ましい。具体的な問題へのソリューションであることで説得力をもち、審査員に納得感を与えることができる。
さらに、ここで提起する問題はグループの日常的な問題であればなお良く、ターゲットは若ければ若いほうが良い。なぜなら若い世代のグループ、例えば学校のクラスの間で話題になれば、利用者は特に爆発的に広がりやすいからだ。より広い範囲で問題を解決できるものはそれだけ評価が高い。
コンテストではそのアプリが正式に公開された後の道筋が見えるかどうかも一部では評価の対象となる。ただ問題を解決するだけでなく、利用者をどのようにして増やすかも考えなくてはならない。この時、例えばターゲットが若い世代のグループであり、実際に問題解決を行えており、口コミで広がりそうなものであれば評価はより高いものとなる。
ポイント
- 身の回りの、誰もが感じるような問題を提起する
- グループか若い世代、またはその両方が抱える問題を提起したほうが良い
- 提起される問題は誰もが納得できるものである必要がある
- ニッチな問題でも、具体的な例を見せるなどでカバーは可能
解決方法の提案
提起した問題をどのようにして解決しようとしたかという部分。この部分が実際にアプリ開発を行うフェーズになる。
まず、提起した問題をどのようなアプリで、どのような機能で解決に導くかを考えなければならない。そしてここで提案する解決方法は確実に現在の問題を解決、または緩和できるものでなければならない。この解決方法は難しい技術や最新の技術を使うよりは、簡単でも 現実的 であるほうが好ましく、結果として納得感も与えられる。(作るのも楽だし、展示やプレゼンをする場合は質疑応答も答えやすい)
実際のアプリ開発だが、ここではできるだけUI/UXに拘るべきだ。審査員は背後の技術やコードにはほとんど興味を持たず、問題に対して得られるソリューション、そして扱いやすさや操作感でアプリを評価する。APIの設計やソースコードのロジックに拘るならば、その時間をできるだけフロントエンドの開発に当てたほうがコンテスト的には良い。
ポイント
- 問題を確実に解決・緩和できる解決方法を提案する
- 簡単でも現実的な解決方法と技術を提案する
- バックエンドには拘らず、フロントエンドにできるだけ時間を割く
結果と規模
提案した解決方法を実施した結果、実際にどれほどの規模で問題を解決することができたかの項目。具体的にはユーザーテストを行うフェーズ。
多くの作品は 解決方法の提案
で止まってしまって、ユーザーテストまで行われていないことが多い。しかしこのユーザーテストはコンテストで勝ち抜くためには必須と言っても良い項目であるため、必ずやっておいたほうが良い。ユーザーテストを実施していないのであれば、その作品はユーザーテストを実施した他の作品に敗北することになる。
なぜ重要かというと、このフェーズをこなして具体的なテストの年齢層や手応えを提示することでより強い納得感を審査員に与えることができるからだ。ここで得られる納得感は何よりも重要で、単純なユーザーテストの結果だけでなく、例えテストだとしても 実際に運用された事実 を審査員に印象付けることができる。幅広い年齢層にテストしてもらえたならなお良く、得られる納得感も強いものになる。
他にもアプリ以外の面だが、開発者の行動力やマーケティング能力、広域的なコミュニケーション能力などを評価してもらえる可能性がある。これは公開後にアプリを広めることができるか、ユーザーが望むものを作ることができるかなど、先述した そのアプリが正式に公開された後の道筋
と繋がっている。
ポイント
解決方法の提案
で終わらないこと- ユーザーテストを行い、提案する解決方法の納得感を与える
- ユーザーテストを行った事実、実際に運用したという事実で印象を与える
フィードバックと反映
ユーザーテストは 結果と規模
で終わりではない。フィードバックはそれに対してのアクションとセットだ。実際にユーザーテストを行いどのようなフィードバックを得たか、そのフィードバックをどのような形で実現したか(または、どのような理由でフィードバックを実現しなかったか)も重要な点になる。
ユーザーテストの結果どのようなフィードバックを得たか、そしてそのフィードバックに対しての自分のアクションをセットにして提示することでより強い納得感を審査員に与えることができる。自分のアクションをセットにできないのであれば、そのフィードバックは提示しないほうが良い。
これもアプリ以外の面となるが、フィードバックの反映は実際、フィードバックから問題点や妥協点を探り、自分のアクションに落とし込めるかを問われる。これは先述したように、ユーザーが望むものを作ることができるか、またはアプリそのものの寿命にも関わる部分であるので、このあたりも評価される可能性がある。
ポイント
- フィードバックは必ずアクションとセットで提示する
- フィードバックに対してどのような改変を行ったか、行わなかった場合はなぜそうしたのかを提示する
- 協調性を求められる部分なので、そのアクションに至った結果もあったほうが良い
おわりに
納得感、納得感としつこく言ってきたが、これは本当に重要な点で、コンテストで勝ち抜こうと思うなら最も意識しなければならない点になる。なぜなら、どれだけ良い物を作ってもその意味や熱意を相手に伝えることが出来なければ、絶対にコンテストを勝ち抜くことができないからだ。
コンテストを勝ち抜く作品には単純に問題を解決する力(アプリの品質)のみならず、今後実際に広く運用される未来が見えるか、その際に確実に様々なシチュエーションで問題解決に貢献できるかも問われる。この部分をクリアするには幅広い層の実際のユーザーテストとフィードバックが必要不可欠であり、これを行うためのマーケティング能力や広域的なコミュニケーション能力も必然的に求められる。
最後になるが、企業のAPIを活用したコンテストの場合、その企業の全てのAPIを使う必要はないということをアドバイスしておく。LINE BOOT AWARDSは LINE Messaging API
と LINE Clova
を使ったコンテストだったが、最優秀賞の2作品はどちらもMessaging APIしか使用していなかった。結局求められているのは、どのような問題を解決できるか、ということだったのだ。