VOYAGE GROUP エンジニアブログ

voyagegroup_techのブログ
VOYAGE GROUPエンジニアブログです。

スマートフォン

Google Tag Manager for MobileでABテストをしてみたかった

こんにちは。android事業室エンジニアの@shinbashi です。
 
8月中旬にGoogle Tag Manager (以下GTM)がモバイル・アプリ向けに対応したことが正式に発表されてから久しいですが、きちんと見ていなかったのでせっかくなので調べて使ってみた時の事を書こうと思います。

さて、 GTMってなんだ?という方もいらっしゃるかもしれないので、簡単に紹介させていただきます。
こちらが正式発表がされた際のブログの日本語訳から、分かりやすそうな部分の抜粋になります

ボタンを押してイベントを追加するのを忘れた? それは、まいったな!

キャンペーン終了直前にコンバージョン追跡を追加しなくてはいけない? それはひどい!

大事な設定を変更しなくてはいけないことに気付いた? 残念だが、それは無理だ。

これは、今までの話! 今年初めにGoogle I/Oで予告したように、今日、当社はモバイルアプリ向けのGoogleタグマネージャをローンチします。

モバイルアプリ用Googleタグマネージャを一度導入してしまえば、設定変更は可能になり、分析、リマーケティング、コンバージョントラッキングを、対象のアプリをアップグレードせずに追加することが可能になります。
 

引用元:モバイルアプリ向けGoogleタグマネージャ登場! 

おお、なんだかすごく便利そうですね!予めSDKを仕込んでおけば、ある程度GTMからいろいろなところにフック出来そうな感じがします。
何はともあれ、とりあえずヘルプを見てみます。

モバイル アプリ向け Google タグマネージャ

Google タグマネージャを使用すると、変更予定のある設定値や、条件に応じて変える可能性のある設定値を簡単に管理できます。具体的には、アプリ内の値を定数ではなく変数として定義して、これらの値を指定するルールを Google タグマネージャで管理します。例として次のものが挙げられます。

  • アプリに掲載する広告のサイズや位置(画面サイズに応じて広告バナーの縦のサイズを変更する場合など)
  • ゲームの設定
  • ユーザー インターフェースの設定(プラットフォームに応じて変更する場合など)
  • デバイスの言語によってローカライズする文字列

引用元: Google タグマネージャについて - Tag Manager ヘルプ

・・・、なんだか入れ忘れたイベントを追加したり、コンバージョンを追加したりするのはどうやるのかイマイチわかりません。予め設定をGTM経由で取得するようにしておけば、設定変更を行えそうだということはわかりました。
  • イベント追加忘れ→そいつは参ったまま
  • 急なコンバージョンの追跡→それもひどいまま
  • 大事な設定の変更→残念じゃないかもしれない!予め仕込んで置けば無理じゃないかもしれない!
 といった具合のようです。
記事を書き始めた当初はイベント追加し忘れたよ!GTMで新しく追加したよ!みたいな記事を書こうと思ったんですが、完全な見切り発車でした。
 
なのでここで大きく方向転換をして、近々ABテストが実装できるとの事なので、おそらく現在の機能でも頑張ればABテストできるんじゃないかと思ってABテストのようなものを実装してみることにしてみました。 
続きを読む

Androidアプリをテストする際の端末の選び方!!


ZucksでAndroidエンジニアをやっている橋本(@hi6484)です。

 先日行われたABC2013sで登壇させてもらいました。
その時の資料はこれです
VOYAGE GROUPエンジニアブログなので、ABC2013sでは話せなかった事を!!
この場を使って公開してしまいます!

■端末の選び方 序章
まず、端末を選ぶ基準として動作が異なる可能性が高い端末を選定しましょう。
選定するためのポイントとして、下記2つのことを調べましょう。
 ・OSの占有率
 ・人気端末

【OSの占有率】
OSの占有率はGoogleがココで公開してます。
これを見ることである程度の占有率はわかります。
2012年3月から2013年3月の遷移はこんな感じです。
Android_OS占有率






1年前からAndroid2.3の占有率が非常に高いのがわかります。
Android2.2に関しては25.3%から7.5%と急降下しています。
Android4.0に関してはわずか1.2%から28.6%と急成長していますが、
ここ3ヶ月間で伸びが止まってます。
Android4.1は1年前にはリリースされていないため0%でしたが
ここ最近非常に伸びていて14.9%となっていることがわかります。

【人気機種】
人気機種に関して2012年10月から2012年12月までの人気機種はこんな感じです。
Android_201210_201212











人気機種に関して2013年1月から2013年2月までの人気機種はこんな感じです。
Android_201301_201302











ここ最近の傾向としてAQUOS PHONEシリーズとXperiaシリーズが売れ筋です。
以前はGALAXYシリーズやARROWSシリーズが圧倒的な人気を誇っていたのですが、
現在は、AQUOS PHONE・Xperia・GALAXY・ARROWSの4強時代と言ってもいいと思います。


■端末の選び方 派生機種を把握する

派生機種(兄弟機種)での無駄なテストを省くためにも、下記3つの観点から端末を分類します
 ・メーカ
 ・OS
 ・チップセット

3つが合致する端末は、端末の挙動は同じであるため派生機種と考えましょう。
※カメラやディスプレイの解像度は異なる可能性はありますので注意してください。

たとえば、人気機種のARROWS X LTE(F-05D)であれば、
下記の4機種とメーカー・OS・チップセットが合致します。
 ・ARROWS Tab LTE(F-01D)
 ・Disney Mobile on docomo(F-08D)
 ・REGZA Phone(T-01D)
 ・ARROWS Z(ISW11F)

テストを行うのであれば、上記1機種をテストすれば十分なのです。

■端末の選び方 FluctのUserAgentから割り出したOS占有率
日本市場はGoogleが公開しているOS占有率とは少しことなります。
日本最大級のSSP(Sell-Side Platform)であるFluctのUser Agentを解析した結果、
Android2.3とAndroid4.0でほぼ市場は占められていることが判ってます。
 Android_Fluct_OS










Android2.3とAndroid4.0で約87.87%占められており、Google資料とは日本市場は占有率は異なってます。 
なお、今年の冬モデルからAndroid4.1の端末が発売され始めたため、Android4.1はこれから伸びて行くことが予想されますがアプリケーションをリリースする時に、Android2.3以上のサポートで約93%以上のAndroidユーザに届くという事が判ります。

■端末の選び方 FluctのUserAgentから割り出した人気端末
ABC2013sでFluctのUserAgentから解析した結果を機種名は伏せてお伝えしていましたが、
公開してしまいます!!!

Android_Fluct_人気端末











4.1%ある人気機種は!!
  GALAXY S3(SC-06D)

機種単体ではGLAXY S3なのですが、
実は裏のNo.1機種がありまして、チップセットがKDDIとdocomoで異なりますが、
単純に通信方式がちがうため、動きとしては同じ??かな?と思っている
Sonyの
  Xperia acro HD(SO-03D/IS12S)
この2機種の合計は!!
  約7.0%

尚且つ、現在も顕著に売れてます。
売れている理由として、後継機が発売されたことで、端末の値段が下がっているけど
スペック的には非常に良く、後継機と比べて端末の大きさが一回り小さいなのがあげられるのではないかと思ってます。

■端末の選び方 FluctのUserAgentから選定するTop10
  1位 GALAXY S3
  2位 GALAXY S2
  3位  Xperia acro HD(IS12S)
  4位  Xperia acro HD(SO-03D)
  5位  ARROWS X LTE(F-05D)
  6位  AQUOS PHONE ZETA(SH-02E)
  7位  Xperia AX
  8位  ARROWS X(F-10D)
  9位 GALAXY S2 LTE
10位  HTC J
 
■端末の選び方 FluctのUAと人気機種から選び出すと
ABC2013sでも発表したとおり下記13機種です。
Android_結論1
 









Android_結論2










Android_結論3 

お手軽Androidプログラミング入門

はじめまして、2012年新入社員のPeX菅谷です。

エンジニアブログなので技術的なお話メインで、ということらしいのですが・・・
いかんせん経験・技術力の無い僕は書ける内容が少なくて困りますねorz
 
とりあえず今回は、僕がお遊びでAndroidアプリを作るときどのようにしているかをお話したいと思います。
内容的には入門の入門くらいの初歩的なものになりますので、Android書けるよ・書いてるよという方々には益の無いお話になるかもしれません。予めご了承ください。

さて、プログラミングを始めようとするとき、みなさんはまず何をしますか?

僕はサンプルコードを探します(笑)。
勉強や業務でプログラムを書くのでしたら、一から学んで、設計して、コツコツ作って・・・とやるのですが、
趣味で書く場合にはとりあえず早く動かしてみたくてサンプルコードを探します。

そこでサンプルコードの探し方なのですが、普通だったらきっと皆さんググりますよね。
そしてよさげなものがあったらそれを読んで、使えそうな部分を参考に書いたりするんじゃないかなと思います。

ところがAndroidでは・・・

開発環境の構築時、Android SDKディレクトリの中に大量のサンプルコードが何気なくダウンロードされているのです。
これが結構充実していて、こういう機能使いたいなーと簡単に思いつくようなことは、およそ網羅してくれています。 
AndroidアプリはIDEで開発するのが一般的なためsdkディレクトリ内を見ることが少なく、見落としている方もいるんじゃないかと思います。
Windowsならばデフォルトではおそらく、
C:\Users\ユーザー名\AppData\Local\Android\android-sdk\samples\android-○○
に存在すると思われますので、是非使ってみてほしいと思います。
Macの場合は・・・探してみてくださいorz 

僕が最もよく参照するのが,Android APIの利用例を集めた『ApiDemos』というアプリです。
この中には、
  • アクティビティの操作
  • 画面レイアウトやボタン、ダイアログの使い方
  • 各種センサ、カメラの使い方
  • ViewやOpenGL、アニメーションなどグラフィックス関連の機能 
といった基本的な機能のサンプルや、
  • Webブラウザ
  • 動画プレイヤー
  • 画像ビューア
  • ペイントツール
などのように凝ったものまで、大小様々なサンプルが200個弱ほど存在します。
まずはこれらを見てみることで、何ができるのか、どうすれば良いのかがある程度把握出来ると思います。

また,Android SDKのバージョンにもよりますが、ApiDemosの他にもう少し複雑なものや完成度の高いものが数十個ほど用意されています。
例えば、USB,BlueTooth,Wi-fiなどの通信のサンプルやゲームのサンプルなどがあります。

これらを参考に機能を組み合わせ、足りない部分はIDEの補完機能にお願いしてしまうだけでわりと簡単に色々なものができます。

勿論、もっと複雑なものを作るには不足している部分は多々あるでしょうが・・・。
「よくわかんないけどAndroid触ってみたい!」とか「なんかちょこっとスマホで作ってみたい!」という方々には、是非お試しいただきたいなと思います。

さて、あまり技術的なお話にならなかったので、代わりと言ってはなんですが実際にちょこっと開発をしてみました。
ApiDemos中のTouchRotateというサンプルをチラ見しつつ、我らがアイドル「ナビック」くんと戯れるアプリ『なびっくいじり』をさくっと作ってみました。

このアプリではナビックくんを突っつき回して遊ぶことができるのです!楽しい!

navic_01navic_02navic_03

こんな可愛らしく楽しいアプリをさっくり作れるのもAndroidの楽しさの一つですね!

Google Playにて公開予定ですので、 「遊んでみたい!」という好奇心旺盛な方がいらっしゃいましたら「なびっくいじり」で調べてみてください。
※SO-01C(Android 2.3.4), SO-04D(Android 4.0.4)のみ動作確認済みです。

皆さんも、意外と簡単なAndroidアプリ開発に挑戦してみてはいかがでしょうか?
ご清覧ありがとうございました!

androidとiOSで共通で使える暗号方式

こんにちは、VOYAGE GROUPのしんばし(@shinbashi)です。

昨今何につけてもスマートフォンですよね。
かくいう僕もPDAからのW-ZERO3という王道を通って来ました。

さて、最近は特にスマートフォン対応とか、アプリ化する機会が増えてきたと思います。
android版を作ればiOS版も出すよ!みたいな話になりますよね。
「android版だけでいい」
なんて言葉を信じて設計すると、後で痛い目を見るのは火を見るより明らかです。

前フリが長くなりました。
android版だけだと信じて僕が痛い目を見たのは暗号化・復号処理の部分です。
Javaはともかく、Objective-Cをよく知らなかったのでライブラリに頼るわけですが、
Objective-Cの暗号化・復号処理をしてくれるライブラリでは扱えないアルゴリズムとかあるんですね。

ざっくり調べた感じだと以下な感じです

表1 アルゴリズム比較表
AES ARCFOUR Blowfish DES DESede ECIES RC2 RC4 RC5 RSA CAST
javax.crypt(android)
CCCrypt(iOS)

表2 パディング比較表
no padding PKCS7 PKCS5 PKCS1 PAEP
javax.crypt(android)
CCCrypt(iOS) ※1

※1 PKCS7 ≒ PKCS5 (ブロック長の違いなのでPKCS7でPKCS5形式のものをunpad出来る)

実際、パディング処理は暗号化前、復号後に自前でやってしまえばいいのでなんとでもなりますね。
こうしてみると、暗号化アルゴリズムはAESで実装するのが妥当そうです。
Objective-Cで自前でPKCS5でunpadする場合は以下な感じになると思います。
+ (NSData *) pkcs5_unpad:(NSData *)data
{
    int pad = [[[NSString alloc] initWithData:[data subdataWithRange:NSMakeRange(data.length - 1, 1)] encoding:NSASCIIStringEncoding] characterAtIndex:0];
    if (pad > data.length) return nil;
    return [data subdataWithRange:NSMakeRange(0, data.length - pad)];
}
ざっくりまとめると
  • アルゴリズム:AES(鍵長は128でも256でもいいと思います)
  •  ブロック形式:CBC(EBCも使えます)
  • パディング:PKCS5(独自で実装できるのでお好きにどうぞ)
な感じで暗号化しておけば、android(java)でもiOS(Objective-C)でも取り扱いできます。
javax.cryptやCCCryptの使い方は色々な方が解説していらっしゃるのでそちらを参考にしていただければと思います。決してJavaのコード長すぎて写すのを面倒臭がっているわけではありません。

また、僕の場合だけかもしれませんが、CCCryptを使った時に、末尾に改行コードが含まれていて、NSDataからNSStringに変換しようとした時にエラーが発生したので、トリムする必要があるかもしれません。
また、WindowsPhoneに関してですが
「C#だし」
ってことで割愛させて頂きました。


おまけ

mixi Engineers' Blog » OpenSSLの暗号文をJava/Perl/Rubyで開く
http://alpha.mixi.co.jp/blog/?p=91

こちらでJavaでOpenSSLのパスフレーズから鍵を導出する処理が書かれていたので、せっかくなのでObjective-Cで実装するとどうなるのか書いてみました。

+(NSDictionary*) pass2keyInfo:(NSData *)pass salt:(NSData *)salt
{
    int keySize = 256;
    int ivSize  = 128;
    int keyAndIvSize = (keySize/8) + (ivSize/8);
    NSMutableData* result = [[NSMutableData alloc] init];
    NSMutableData* keyAndIv = [[NSMutableData alloc] init];
    while (keyAndIv.length < keyAndIvSize) {
        [result appendData:pass];
        [result appendData:salt];
        [result setData:[result MD5Digest]];
        [keyAndIv appendData: result];
    }
    NSData* key = [keyAndIv subdataWithRange:NSMakeRange(0, keySize/8)];
    NSData* iv  = [keyAndIv subdataWithRange:NSMakeRange(keySize/8, ivSize/8)];
    return [NSDictionary dictionaryWithObjectsAndKeys:key, @"key", iv, @"iv", nil];
}
参考
Java ™ 暗号化アーキテクチャー標準アルゴリズム名のドキュメント
http://java.sun.com/javase/ja/6/docs/ja/technotes/guides/security/StandardNames.html#AlgorithmParameterGenerator

CommonCryptor.c
http://opensource.apple.com/source/CommonCrypto/CommonCrypto-36064/Source/CommonCryptor.c

Jumvoの作り方

genesixの永野です。
弊社では定期的に社内の発表イベントをやっていまして、先日
「Jumvo 2.0 における デザイナーとエンジニアの連携」
と題して、Jumvoをどうやって作ったのかを発表しました。 当日のSlideはこちら

Jumvoとは
Jumvoはgenesixからリリースしている、簡単に言えば声のSMSができるiOSアプリケーションです。声を送りあうことに特化しているため、シンプルな操作性が売りになっています。こちらから無料でダウンロードできます

icon_201201

発表はデザイナーの伊野と二人で行ったのですが、この記事ではプログラマーの立場から、Jumvoで取った開発方法を紹介します。

具体的には、Jumvoでは「プロトタイピング」と「UXデザイン定義書に法った開発」を行いました。まず最初に、これに到るまでの経緯をお話します。


自己紹介とこれまでにやってきたこと
genesix入社前は、フリーランスで通販サイトを作ったり(PHP/Java)、時間とお金があればMacのアプリを書いたりしていました。genesix入社直前の1年ぐらいはMac/iOS系会社で主に受託案件をやっていました。受託という性質上、仕様の受け入れ、工数見積もり、というようなことがよくありましたが、その中で感じていたのが「iOSアプリは仕様を決めるのが難しい」そして「仕様が頻繁に変わる」ということです。


「仕様」が決まらない
そんなのiOSに限ったことじゃないだろう、と思われる方もいると思いますが、Webアプリケーションの受託案件と比べても変更が多い印象でした。実際に画面に触ってみないと分からない点が後から色々出てくる、のが一番の理由だと思われます。
象徴的な話としては自機を触って操作するシューティングゲームで、完成してみると、自機が指で隠れてしまうのでお蔵入りになった、という冗談みたいな話も聞いたことがあります。

そのため、いつも「後で変更しやすいようにしておかないと、納品前に仕様が変わって間に合わなくなるだろう」とか「この見積もりでは変更できないからクライアントが納得しないだろ」「最初にこの操作だけは決めておかないと完成前に変わると全部がひっくりかえる」といったよく心配をしていました。

全画面の構成程度の仕様が決まったと思っても、使っているうちに問題点が浮き彫りになり、修正したくなる。よくあるのが、ここの仕様が曖昧だと思っていると、後でデザイナーから(もしくはクライアントから)指摘がある。しかし、仕様が決まりさえすれば、たいていのものは作るのは難しくありません。しかし、どんなに優秀なデザイナーでさえ、動かなければ分からないことが多い、どうすればいいだろう?ということをずっと考えてきました。


「ユーザー」とは誰なのか?
もう一点、仕様を決めていくプロセスにおいても問題を感じていました。
たとえば、クライアント、エンジニア、デザイナーで新しいアプリの仕様を検討していても、それぞれがそれぞれの立場で、この機能が必要だ、これはこの位置だ、という話になりますが、その主張の根拠が「ユーザー」という正体不明なものであることでした。
正体不明な「ユーザー」? 何を言っているんだ!と言う方もいらっしゃると思いますので説明します。

何かBtoCのサービスを作るのであれば、それは顧客であるユーザーのためである、これに異論がある方は居ないと思いますが、その「ユーザーのためを考える」のは各人共通であったとしても、実は対象としているユーザーがそれぞれ(の立場)によって異なるのです。

iOSアプリを作るとすれば、対象ユーザーの範囲は多岐に渡るにも関わらず、ある人は若い女性を想定しているかもしれませんし、ある人は中年のサラリーマンを想定しているかもしれません。ある人は非常にリテラシーの高い人を想定、もしくは逆、ということがあり得ます。対象をきっちり決めていない場合はほぼそうだと考えるべきだと思います。

そのため、ある機能を決定する場合でも、想定しているリテラシーが異なるため、ある人はこれぐらいは分かると言い、ある人は逆にこれは理解できないはずだと言い、という出口の無い議論をすることになります。
実際、前職で「ユーザー」という参加者全員が頻発する言葉に、それって誰?と言ったことがあります。そして、各人の「ユーザー」像を少しでも近づけるべく実際に使ってくれているユーザーに来てもらって話を聞こう、と提案したりしました(それは叶いませんでしたが)。

Jumvo 1.0では、以上の二つの問題に対して次のような方法で解決を試みました。


まず

1.「仕様」が決まらない
この点については、最初から「仕様をかちっと決めてから開発する」ということは不可能である、という前提で開発することにしました。つまり仕様は決まらないので、決めずにやるということです。しかし何も決まらなければ進まないので、いつでも変更される前提のプロトタイプをベースに、動くものを見ながら意見を交換し、進めました。具体的には、iPhoneの実機で実際に動作するものを基本に進めました。これは簡単に言えばプロトタイピングと言えると思います。つまり、Jumvoは最初から他のiPhoneと声を送りあえる状態から作っていったのです。下の写真のように紙にメモを書きながら、最初は僕が必要な機能を考え、UX/UIデザイナーと意見を交換しながら、実際に動作するものを修正しつつ進めていきました。
jumvo1


これによって実際に手に取って声を発して、それを実際に相手に送信する、という一連の操作と、何よりその操作性が重要であるということをチームのメンバーに最初に伝えることができたと思います。それはその後のスムーズな開発(のための仕様の検討)に繋がったと考えています。つまり、プロトタイプベースで進めることによって、ユーザー体験のコア部分が速い段階で検証できた、ということになります。

また、事業責任者やプロデューサーに、Jumvoが面白いのかどうか、最初の段階で確認してもらえたことも大きな利点であったと思います。

このようなプロトタイピング期間が1ヶ月程あった後、UIデザイナーが正式にアサインされ、それまでのプロトタイプを元に、具体的なデザイン案が出来てきました。その案も実際に実機で動かし、再度修正し、またさらに動かし、という工程を1ヶ月で3度ほど繰り返し、最初のv1.0が完成しました。ここまでで2ヶ月ほどの時間がかかっています。




2.「ユーザー」とは誰なのか?

これは実は当初は想定していなかったのですが、genesixには選任のUXデザイナーがおり、UXデザインにおいてペルソナを採用していました。
そして、アプリは「アプリケーション定義ステートメント」にそって作られる、という一環した手法を採用していたのです。
アプリケーション定義ステートメントとは、詳細はこちらを参照いただきたいのですが、簡単に言えば、誰が何を達成するため(=使う人のゴール)のアプリケーションなのか、を1行程度で表したものです。Jumvoの場合「もっと気持ちを伝え合いたい人のためのもっと気軽で手軽なボイスメッセージングアプリ」がそれであり、仕様等で迷ったときには定義ステートメントはこれだから..と復唱することで目的を、もっと言えばユーザーのゴールを確認することができます。

僕はこの開発手法を聞いたときに正体不明のユーザーから逃れる方法だ!と目からうろこが落ちました。実際にこの手法で開発をしてみると、チーム全員が「アプリケーション定義ステートメント」に向かっており、「ユーザー」ではなくペルソナを対象として話をするため、仕様の検討でばらばらな方向を向くというとが皆無でした。
アプリの目的が明確だったというのもあると思いますが、このユーザーは分かる、分からない、という議論はまったくありませんでした。あったのはどうやればゴールに近いか、という議論だけです。その中では多くの方法が話し合われましたし、ときには難航もしましたが、誰かがひらめいたときの全員の「それだ!」という意思統一の速さはこれまでに経験したことのないものでした。
加えて、Jumvoではプロトタイピングで仕様を決めていたため「この仕様にしたら、時間がかかるから...」 といったことを考えずに自由に発言できたこと、また出た案を常に手に取って使いながら判断できたことも、議論がスムーズに進んだ一つの要因だと考えます。


問題点
さて、上記を振り返るといいことづくめなように思えますが、問題点としては以下が考えられます。

1. いつまでも仕様が決まらない

仕様は決まらないから決めない、という前提でスタートしているため、時間的、予算的余裕があれば、それこそどれだけでも開発できてしまうため終りがやってきません。現実的にはそのようなことは無いため、いつか終わりがきます。Jumvoの場合その制約はリリース目標日でした(具体的には7月頭)。目標日までに作るには、プロトタイピングといえども、明確に何を決めたくて、今何を試しているのか、を意識する必要があると思います。
ただ面白いかどうかだけを試していたら、何パターンもアニメーションを動かしてみて時間がすぎていく、ということもあるでしょう。

Jumvoの場合、具体的な例としては、送信相手を複数選んで送信する、それを最も簡単に少ない操作ステップ数で行えるUIは何か、ということを何パターンも試しました。そして分かりやすさと操作性を軸に判断していきました。

2. コーディング量が増える
Jumvoの完成形のコード量を1とすると、少なく見積もっても3倍ぐらいのコードを書きました。そのためには時間がかかります。ですが、プロトタイピングに2ヶ月かかっていては、それは機能しないでしょう。
そのため、必要な箇所を的確に判断し、最低限のコード量で最大の効果を発揮するいわば”勘”が必要になると思います。Jumvoは目的が明確なアプリであったため、それに必要なコア部分も分かりやすく、プロトタイピングに向いていたと考えられます。Jumvoに限らず、iOSアプリは目的が明確であるべきだと考えますので、プロトタイプベースでの開発に向いていると言えるかもしれません。


3. プロトタイプに仕様決定の主導権が移ってしまう
実際に動くものがあるため、その説得力は非常に高く「うん、これで動いているしいいんじゃない?」となる可能性が高くなります。実際、Jumvoでもプロトタイプにデザイナーが引っ張られ、最終的な判断ができない、という状況がありました。これを回避するには、モノを判断するモードと、モノを作るモードの切り替えが必要です。UXデザイン定義書は判断するモードに戻るために非常に有効でした。



まとめ
これまで述べてきた僕が考える問題点とそれに対するやり方を振り返ると、そもそも市場調査は的確だったのか、それで実際にアプリがヒットするのかどうか、といった根本的な問題はあります(実際、Jumvoが大ヒットしているわけではありません)。
しかし、そのために最低限必要な条件である(と僕が考える)、よいものを作るための近道の一つが試せたと思いますし、実際に効果がありました。
一つの結果としては、App Store Rewind 2011に選んでいただきました!

25


(実機のiPhoneで動くものをベースとした)プロトタイピングはコーディング量が増えるため導入の敷居は若干高いかもしれませんが、UXデザイン定義書は、採用しやすいのではないでしょうか。
以下の記事などを参考に採用を検討してみてください。

スライドの後半では、genesixのUXデザインについて具体例を交えながら書いてあるので、参考にしていただければ幸いです。また、genesixデザインプロセスも公開されていますので、合わせてごらんください。
記事検索
QRコード
QRコード