LoginSignup
7
5

More than 5 years have passed since last update.

[Ionic] RPGのモックアップをつくって、小さいリリースサイクルのために重要なことに気付いた話

Last updated at Posted at 2018-03-22

RPGゲームのモックアップをIonicでつくってみました。
「ゲーム感覚でまちに関わるアプリ」を考えてまして、プロジェクト自体はまだ構想段階なのですが、モックアップがあると高い解像度で議論できるかと作ったものです。

levelup.png

実際に操作できますので、ぜひお試しください。

(GoogleMap APIは無料枠の範囲で利用しておりますのでアクセスが集中すると表示されない場合があります。その場合、時間を置いてから再度お試しください)

小さいリリースサイクルのために重要なことに気付いた話

前置き:Ionicとは

IonicはHTML5でモバイルアプリをつくるためのプラットフォームで、1ソースでWeb / iOS / Androidアプリを同時につくることができます。
海外ではよく使われており、「Webアプリをつくって人気がでたら、そのままiOSアプリもリリース!」といった仮説検証に基づいたプロダクトサイクルを持てることから日本でも有名になってきており、ニコニコ動画で有名なドワンゴ、イラストSNSのpixivといった有名企業も採用しています。

今回、これをつかって制作しました。

モックアップがプロダクトになるIonic

今回つくったRPGゲームは開発者サイドからすると、完成度3%程度です(1%と言わなかったのはただの意地)。WEBでしか動かせないし、デザインは手抜き、クエストは発生しない、そもそも自サーバーと通信すらしません。ただ関係者に見せるためのハリボテで、マップの移動ですらボタンを連打しないと動きません(「押しっぱなし」未実装)。なんたって12時間程度の制作時間しかつかっていません(し、うち4時間程度はデザインの試行錯誤)

けれど、見せた人に「もうここまで出来たんですか!?」と聞かれました。ユーザ登録して、ちゃんと上下左右にキャラクターを移動することができて、「完成したらこういうことができるのか」と体験することができるからです。

「今までこんなことなかった」と言われ、何が違うのかなーと考えたところ「制作プロセス」かなと思いました。
多くの現場では、モックアップ、プロトタイプ、プロダクトがそれぞれ別々のツールを使って作成されます。モックアップはPhotoShopでつくって、プロトタイプはXD、プロダクトは本番用の言語といった感じです。このような場合、モックアップとプロトタイプ、プロダクトのそれぞれには大きな断絶があります。

xd.png

ですが、Ionicでつくるとモックアップからプロダクトリリースまで一つの軸にすることが多いです。

知り合いの書いたブログで恐縮ですが 「Webデザイナーが3日でスマホアプリを公開した方法」 ではSketchをつかってワイヤーフレーム書いてますが、そこからはIonicのコンポーネントを積み木みたいに組み立ててモックアップにして、機能を具備してリリースしています。完成度60%ぐらいでリリースしたと本人言ってました。
「Ionicでブランドをまたいで服のコーディネートを選べるアプリを作りました」なんてワイヤーフレームは手書きでそこからいきなり作り出しています。こちらも未完成といってました。

モックアップからプロダクトリリースまで一つの軸に載せると、完成度が低い状態でプロダクトリリースしてユーザからフィードバックをもらうことが容易になります。

ionic.png

アメリカの「comSCORE Mobile App Report」という調査がありますが、そこではスマホアプリの新規インストールがどんどん減っていており、「アプリをつくってリリースしたら使ってもらえる」時代は終わったことを示唆しています。
これからは完成したものではなく、早い段階からユーザと向き合ってプロダクトを育てていく重要性がよくわかります。その工程において、モックアップからプロダクトリリースまで一つの軸に載せることはかなり重要な要素になるのではないでしょうか。

これからの実装予定

これからこのRPGモックアップをどう育てていくかなーという覚書です。

1. 最低限の機能の具備

とりあえず、テストしててイライラするボタンの「押しっぱなし」を実装します。キャラを移動させるのに、ひたすら連打するのUIが悪いとかそれ以上に開発しててストレスなので・・・。とはいえ、まだプロジェクトが構想段階なので、これすら数ヶ月以上は先になりそう。

2. Ionic Viewでの配布

Ionic Viewというアプリ配布機能がありまして、これを使うとネイティブアプリとほぼ同様の形でサーバからアプリケーションをダウンロードしてユーザに利用してもらえます。起動時アニメーションやヘッダー・フッターがネイティブアプリ同様になりますので、これを利用してもうちょっと本番に近いかたちで利用・ユーステスとをしてもらおうかなと思っています。

3. クエストのデモ機能の作成

そうしたら多分次にクエスト機能の仕様策定に入ることになりそう。どうやってクエストが発生するのか、ユーザはどこをタップするのか、そういうの決めてデモ機能をつくることになりそうです。これができた段階で制作関係者ではなく、もうちょっと広い範囲の関係者に「こういうプロジェクトを進めてる」と企画書と一緒に送ることになりそう。

4. 最低限作る

実地でどのようなクエストを発生させるのか、キャラクターイラストやアプリアイコンなど「利用する上で最低限必要な機能」を作らないとだめですよね。使えないし。

5. リリース

そういう意味ではモックアップでなくなるのはこのプロセスが完了した段階で、かつプロトタイプ兼プロダクトとしてどこかで実証実験的なユーザテストを実施することになると思います。とりあえずWeb版をだすことになりそう。iOSやAndroidもだしてもいいけど、ユーザテストで「手元のデバイスにインストールしてください」だとWebが楽なんですよね・・・。(※ IonicはコンパイルするとWebだけではなく、iOS/Androidアプリとしてもリリースしてストアアプリとして配布できます)

6. それ以降

サーバサイドをつくってデータを集約する機能いりますかね、とかそういう細々とした「ないよりあった方がいいかもしれない機能」をつくりはじめることになりそう。でも、基本的にはユーザには4.の段階で提供していて「あれもほしい」「これもほしい」という要望がある中でユーザを観察して、提供者サイドの意図と調整しながら優先順をつけていく形になりそう。

バズったり大きな収益化ができるようになったら、Swift/Kotlinといったネイティブ言語で書き直すかも。

まとめ

ネイティブアプリはネイティブ言語で書くのが、速度はもちろんのこと、最新のAPIを使えるし、ハマり箇所も少ないのは当然のことなのですが、反面、デザイナーとエンジニアのプロセスの断絶はもちろんのこと、エンジニアでもiOSエンジニア、Androidエンジニアが別で必要で人材確保に困ってるプロジェクトは大小問わず、仮説検証を繰り返すところまで実現していない話を聞きます。

HTML5はデザイナーが習得していることも多いスキルですので、「デザイナーはデザインだけ」「それをエンジニアがネイティブに実装」と断絶させる必要はありません。またHTML5を書ける人は、他言語の10倍以上の市場がありますので(なんていったって汎用言語で中学校・高校ですら授業で教えます)、アプリのモックアップ、プロトタイプをHTML5でアプリをつくることのできるIonicでつくって、ユーザの反応と開発現場を観察しながらネイティブ言語に書き換える、といったすすめ方はありなのではないでしょうか。初心者向けの日本語書籍もでています。

参考: WebはHTML/CSSから学びはじめるべきか|HTMLも知らない人にIonic本をさせた知見

この記事が、小さいリリースサイクルを実現する一助になりましたら幸いです。

7
5
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
7
5