大規模アプリ開発系コンテストでの生存戦略
ここで言う 生存戦略 とは、いかにコンテストで勝ち抜くか、という点に焦点を当てたものだ。コンテストでの優勝にはある種の運、例えば発表する環境や審査員のバックグラウンドなども関わってくるため、優勝を目指すのではなく、いかに優勝に近付くことができるかという記事。
本題
大規模なアプリ開発系のコンテストでは、単純なアプリを作るだけでは審査員の目に止まらない。
こういったコンテストでは大概、そのアプリを使うことによって 日常に起き得るどのような問題を解決できるのか という点が最も重要視されており、これをクリアすることが開発者にとっての最初のハードルになる。(中小規模のコンテストでは純粋な面白さが重視されることもあり、この限りではない)
だからといって、ただ単純に問題を解決できるアプリを応募しただけで勝ち抜けるという話でもない。
自分がいくつかのイベントに参加し、実際に多くのチームの発表や作品を見て感じた、勝ち抜くためにアプリに組み込むべき基本的な要素は次の4つだった。この何れかが抜けているだけでコンテストで勝ち抜くことは難しくなる。
- 問題提起
- 解決方法の提案
- 結果と規模
- フィードバックと反映
この要素は必ず必要なもので、ほとんど例外はない。(ハッカソンは別)
また、コンテストで会場展示・プレゼンを行う場合は、この4つの要素を端的に分かりやすく伝えるためのトークスキルなど、マーケティング能力のようなものも必要になってくる。優勝しようと思うのであれば、ここまでの準備を完璧にこなす必要がある。
以下の項目では、各要素で何を行うか・どんな点に注意すれば良いかを記載している。
問題提起
アプリを開発する前に、まずは身の回りでどのような問題が発生しているかを探る必要がある。そしてコンテストに応募するアプリはその問題を解決するものであるものが好ましい。具体的な問題へのソリューションであることで説得力をもち、審査員に納得感を与えることができる。
さらに、ここで提起する問題はグループの日常的な問題であればなお良く、ターゲットは若ければ若いほうが良い。なぜなら若い世代のグループ、例えば学校のクラスの間で話題になれば、利用者は特に爆発的に広がりやすいからだ。より広い範囲で問題を解決できるものはそれだけ評価が高い。
コンテストではそのアプリが正式に公開された後の道筋が見えるかどうかも一部では評価の対象となる。ただ問題を解決するだけでなく、利用者をどのようにして増やすかも考えなくてはならない。この時、例えばターゲットが若い世代のグループであり、実際に問題解決を行えており、口コミで広がりそうなものであれば評価はより高いものとなる。
ポイント
- 身の回りの、誰もが感じるような問題を提起する
- グループか若い世代、またはその両方が抱える問題を提起したほうが良い
- 提起される問題は誰もが納得できるものである必要がある
- ニッチな問題でも、具体的な例を見せるなどでカバーは可能
解決方法の提案
提起した問題をどのようにして解決しようとしたかという部分。この部分が実際にアプリ開発を行うフェーズになる。
まず、提起した問題をどのようなアプリで、どのような機能で解決に導くかを考えなければならない。そしてここで提案する解決方法は確実に現在の問題を解決、または緩和できるものでなければならない。この解決方法は難しい技術や最新の技術を使うよりは、簡単でも 現実的 であるほうが好ましく、結果として納得感も与えられる。(作るのも楽だし、展示やプレゼンをする場合は質疑応答も答えやすい)
実際のアプリ開発だが、ここではできるだけUI/UXに拘るべきだ。審査員は背後の技術やコードにはほとんど興味を持たず、問題に対して得られるソリューション、そして扱いやすさや操作感でアプリを評価する。APIの設計やソースコードのロジックに拘るならば、その時間をできるだけフロントエンドの開発に当てたほうがコンテスト的には良い。
ポイント
- 問題を確実に解決・緩和できる解決方法を提案する
- 簡単でも現実的な解決方法と技術を提案する
- バックエンドには拘らず、フロントエンドにできるだけ時間を割く
結果と規模
提案した解決方法を実施した結果、実際にどれほどの規模で問題を解決することができたかの項目。具体的にはユーザーテストを行うフェーズ。
多くの作品は 解決方法の提案
で止まってしまって、ユーザーテストまで行われていないことが多い。しかしこのユーザーテストはコンテストで勝ち抜くためには必須と言っても良い項目であるため、必ずやっておいたほうが良い。ユーザーテストを実施していないのであれば、その作品はユーザーテストを実施した他の作品に敗北することになる。
なぜ重要かというと、このフェーズをこなして具体的なテストの年齢層や手応えを提示することでより強い納得感を審査員に与えることができるからだ。ここで得られる納得感は何よりも重要で、単純なユーザーテストの結果だけでなく、例えテストだとしても 実際に運用された事実 を審査員に印象付けることができる。幅広い年齢層にテストしてもらえたならなお良く、得られる納得感も強いものになる。
他にもアプリ以外の面だが、開発者の行動力やマーケティング能力、広域的なコミュニケーション能力などを評価してもらえる可能性がある。これは公開後にアプリを広めることができるか、ユーザーが望むものを作ることができるかなど、先述した そのアプリが正式に公開された後の道筋
と繋がっている。
ポイント
解決方法の提案
で終わらないこと- ユーザーテストを行い、提案する解決方法の納得感を与える
- ユーザーテストを行った事実、実際に運用したという事実で印象を与える
フィードバックと反映
ユーザーテストは 結果と規模
で終わりではない。フィードバックはそれに対してのアクションとセットだ。実際にユーザーテストを行いどのようなフィードバックを得たか、そのフィードバックをどのような形で実現したか(または、どのような理由でフィードバックを実現しなかったか)も重要な点になる。
ユーザーテストの結果どのようなフィードバックを得たか、そしてそのフィードバックに対しての自分のアクションをセットにして提示することでより強い納得感を審査員に与えることができる。自分のアクションをセットにできないのであれば、そのフィードバックは提示しないほうが良い。
これもアプリ以外の面となるが、フィードバックの反映は実際、フィードバックから問題点や妥協点を探り、自分のアクションに落とし込めるかを問われる。これは先述したように、ユーザーが望むものを作ることができるか、またはアプリそのものの寿命にも関わる部分であるので、このあたりも評価される可能性がある。
ポイント
- フィードバックは必ずアクションとセットで提示する
- フィードバックに対してどのような改変を行ったか、行わなかった場合はなぜそうしたのかを提示する
- 協調性を求められる部分なので、そのアクションに至った結果もあったほうが良い
おわりに
納得感、納得感としつこく言ってきたが、これは本当に重要な点で、コンテストで勝ち抜こうと思うなら最も意識しなければならない点になる。なぜなら、どれだけ良い物を作ってもその意味や熱意を相手に伝えることが出来なければ、絶対にコンテストを勝ち抜くことができないからだ。
コンテストを勝ち抜く作品には単純に問題を解決する力(アプリの品質)のみならず、今後実際に広く運用される未来が見えるか、その際に確実に様々なシチュエーションで問題解決に貢献できるかも問われる。この部分をクリアするには幅広い層の実際のユーザーテストとフィードバックが必要不可欠であり、これを行うためのマーケティング能力や広域的なコミュニケーション能力も必然的に求められる。
最後になるが、企業のAPIを活用したコンテストの場合、その企業の全てのAPIを使う必要はないということをアドバイスしておく。LINE BOOT AWARDSは LINE Messaging API
と LINE Clova
を使ったコンテストだったが、最優秀賞の2作品はどちらもMessaging APIしか使用していなかった。結局求められているのは、どのような問題を解決できるか、ということだったのだ。
2018年の振り返り
2018年も残り1週間ちょっと、今こそ今年の振り返りの時期ではないでしょうか。
この記事では自分の今年の振り返りを行います。とはいっても今年は大したことしてませんでした。来年は頑張りたい気持ち。
仕事
そのうち転職するという意思表示まではしましたが、どこに転職するとかしたとか、そういうのは今のところありません。退職エントリーも書いてないし…。
業務では相変わらずサーバー周り(バックエンド、フロントエンド、AWSとかIoTとか)を担当することが多くて、そのへんの知見は貯めさせてもらったかなと感じます。特に、インド人のエンジニアと1週間ランチ行ったのは刺激的でしたね(料理も)。
イベント
小さなところには何度か顔を出させてもらいましたが、今年はやっぱり LINE BOOT AWARDS
でしょうか。このためにわざわざ東京まで行きました。(秋葉原を練り歩き、唐揚げ食べ放題を食べて帰った思い出)
優勝できなかったけど、いろいろと学びはありました。1125作品中の30作品くらいに選んでもらえたのも嬉しかったし、コンテスト型発表会の生存戦略とか、そういうところを自分で考える良いきっかけになりました。(これの感想の記事書いてないですね。下書きのままだった…)
あと技術関係ないけど、12/13のSPYAIRの大阪ライブに行ってきました。テンション上がっていたのか、今となってはもう何も思い出せないライブです。
技術
AWS
やはり自分の中で外せないのはAWSで、仕事でも個人でも開発は1年中AWSと共にありました(去年もそうだったかも)。特にハッカソンみたいなスピード感が必要な開発のときはAWSに助けられっぱなしで、やっぱりちょちょいって作る時の Lambda + API Gateway + DynamoDB
は強いんですね。
去年・一昨年くらいからAWSを初めてもうだいたい一般的なWebアプリとかストレージとかには小慣れてきたくらいでしたが、今年は特に画像解析とかAWS IoTとKinesisで大量データ処理とかちょっと変わり種を触らせてもらう機会が多くて、流行りの技術にちょっとは乗っかることが出来たかなという印象です。
- CloudFormation
- Kinesis(Data Streams、Data Firehose、Video Streams)
- Redshift
- Rekognition
- AWS IoT
- EKS
- etc
GitHub
公開したリポジトリはプラクティス的なものが大半でした。リポジトリの整理と称して雑多なものを削除したらだいぶスッキリしてしまったのでちょっと思いついたやつをぽこぽこ生やした次第です。
- GitHub - shiopon01/shiopon.net: My Resume
- GitHub - shiopon01/handbook: a handbook
- GitHub - shiopon01/redux-starter-kit: Small modular style template of React/Redux. (Action, Reducer and Action Creator are write to one file.)
- GitHub - shiopon01/line-bot-frame: line bot frame - text and image echo bot
- GitHub - shiopon01/cloudformation-chain: Create multiple stacks in CloudFormation. (is not nested stack)
- GitHub - shiopon01/express-controller-pattern: This is the most practical Express implementation pattern.
以下思い出。
shiopon.net は自分の公開Resumeとして作成し始めたページですが、文章を考える段階で燃え尽きました。つまり未完成ですがこれはGitHub Pagesで公開中。来年迎えるまでには書ききってしまいたい。。。
handbook は 自分なりの攻略本を作ろう
という個人的な企画で作り始めていて、最初はGitBookでHTML生成して個人のドメインで公開して〜ってやっていました。正直面倒くさかったのでGitHubのリポジトリでmdファイルをまとめる形で作りなおしてます。今の所GitBook時代の遺産を多く書きなおしている状態でまともなページは少なく、荒削りなページも多い…。
redux-starter-kit は自分がReduxに熱かった時に作っていた自分用のテンプレートです。公開しているのは「俺はRedux派の中でも modular style
教の人間だ」というのを主張するためでもありました。Nuxt.jsが生まれた今、自分の中でのこいつの存在意義は…。
line-bot-frame はAWS上で簡単にLINE BOTの環境を作成できるCloudFormationのテンプレートとLambdaのコードです。LINE BOT作るハッカソンで活躍します。(レスポンスのメッセージタイプにいろいろ対応したらみんな使ってくれるかな)
cloudformation-chain は自分がCloudFormationのテンプレートを死ぬほど書いていた頃、ネストしないスタックを連続で作成するソリューションが欲しかったので作ったものです。これを使えばネストしてないスタックを沢山作れる。
express-controller-pattern はExpressのコントローラーパターンを試した例。これはExpressのベストプラクティスとなり得るか…。
その他
大雑把に、今年は特にこれ触ったなあと印象に残った技術(AWS除く)。
- LINE Messaging API
- Kubernetes
- Nuxt.js
- Redux
- Express
- FFMpeg
LINE Messaging API は実際にハッカソンで使ったってのもありますが、考えられる限りで最強のユーザーインターフェースだと感じました。手軽に実装できるし、ありがちだけど煩わしいデザインの作成がいらない、メッセージを表示するための様々な機能が存在するなど。開発者にとっても楽できる部分が多くて、良い物でした。LINE BOTを作成する際は line-bot-frame も参考にしてください。
Kubernetes は個人で勉強していましたが、結局実際の業務で使うことは無かった…。来年は開発環境とかに組み込んでいけたらいいなと。
Nuxt.js は年末に触り始めたフレームワークで、なんというか、Webアプリとかマイクロサービス作成における銀の弾丸な印象。 今からWebアプリ作るんならとりあえずこれ使っとけ!って言えるくらい、いろいろな管理がとにかく楽で、VueとVuetifyのおかげもあってロジックを書けないデザイナーとかでもとっつきやすいのも嬉しい。あんま使えてないので来年も使っていきたい。
さいごに
振り返ってみると、今年はずっとNode.jsでWeb(主にSPA)やってましたね。スーパープログラマーである皆様の振り返りと見比べると、随分見劣りするものですが…。来年はもう少し活動して、いいかんじのこと書けるように頑張りたい気持ちでいっぱいです。
来年はとりあえずKubernetesとKnative使ったOSSなんか作りたいなあと思ってたら、 GitLab Serverless に先を越されていました。知覚動考ですわ…
GitHubリポジトリのTopicsが少しずつアップデートされてた
GitHubリポジトリのTopicsが少しずつアップデートされてた話。
Topicsは出た当初から使っていたが、登録する時、初めは半角スペースで区切られた単語がただトピックとして登録されるだけだった。
それが知らぬ間に、予測変換的な機能が追加されていて
さっきトピックを付けようと思ったら、なんとサジェストの機能まで実装されていた。たぶんそのリポジトリによく出てくる単語とかがサジェストされる。
リポジトリのProjectsも初期の頃に比べたら知らない間にちょっとずつ良くなっていってたし、GitHubのいつものサイレント改善を今日もまた見ることが出来た。(もしかしたらどっかで告知されてるのかもしれない。)
LINE BOOT AWARDSの最終選考に残ったやつ
MacBook Pro (2018) 15インチをついに買った!開封式とMacBook Air 13インチと大きさの比較
社会人になったら買おう買おうと思っていたMacBook Proの15インチを、ついに買った。インテルの第8世代積んだやつがつい最近出たので、次は第9世代が出回るまで新しいMacBook Proは出ない読みの購入である。
買ったのは15インチでSSD512GBのモデルのデフォルト。i9とか32GBとかはちょっと考えたけど、仕事で映像編集バリバリやるわけでもなければイラストを書くわけでもないし、そのへん考えると + ¥ 770,00 (税別) は流石に払えなかった…。
購入したMacBook Proの性能はこちら。
- 第8世代の2.6GHz 6コアIntel Core i7プロセッサ(Turbo Boost使用時最大4.3GHz)
- Radeon Pro 560X(4GB GDDR5メモリ搭載)
- 16GB 2,400MHz DDR4メモリ
- 512GB SSDストレージ
- バックライトキーボード - 英語(米国)
開封
ダンボールを開けた時。
いつもの真っ白なAppleの箱に入ったMacBook Pro。この箱を開ける時だけ、オレは少年の心を取り戻す。
本体の下には付属アクセサリーのコンセントに挿す電源と、充電用?のUSB Type-Cケーブル。薄い入れ物には説明書とAppleのりんごマークのシールが入っていた。
この付属アクセサリーを見ると、電源ポートが USB Type-C になったことを実感させられる。話では聞いていたし店頭でも見たことあるけど、MagSafeの時代はもう終わってしまったのかと…。(実際に使ってみると、左右どちらでも充電できるし意外と便利だった。でもやっぱり、磁石のカチッっていう感覚と、ケーブル足に引っ掛けた時の電源ポートへの負担を考えると、MagSafeが名残惜しい。)
試しに、手持ちのMacBook Air (2011〜2014モデルのどれか) 13インチを箱に入れてみた。これくらいのサイズ差があるらしい。やっぱり15インチは大きいが、ディスプレイの大きさこそ正義なのだ。
実際に開いてみると、トラックパッドのデカさが個人的には衝撃だった。(英字キーボードだから?)
静音化されたという改良バタフライキーボードは改良前をちゃんと使ったことがないため比較はできないが、気になるほどうるさくはない。音の質は違うが、タイピングの音量はMacBook Airのキーボードと同じくらいな気もする。最初はちょっと気持ち悪いバタフライキーボードも使っていけばすぐ慣れそうなかんじ。
(MacBook Proから投稿!)
P.S.
本当は9/6に届く予定だったけどちょうど台風21号の影響が大きい頃で、関税手続きの遅れとか諸々あって3日遅れて届いた。(9/9到着)