GROUPエンジニアブログです。MobileでABテストをしてみたかったこんにちは。(以下GTM)がモバイル・アプリ向けに対応したことが正式に発表されてから久しいですが、きちんと見ていなかったのでせっかくなので調べて使ってみた時の事を書こうと思います。GTMってなんだ?という方もいらっしゃるかもしれないので、簡単に紹介させていただきます。残念だが、それは無理だ。I/Oで予告したように、今日、当社はモバイルアプリ向けのGoogleタグマネージャをローンチします。モバイルアプリ用Googleタグマネージャを一度導入してしまえば、設定変更は可能になり、分析、リマーケティング、コンバージョントラッキングを、対象のアプリをアップグレードせずに追加することが可能になります。おお、なんだかすごく便利そうですね!予めSDKを仕込んでおけば、ある程度GTMからいろいろなところにフック出来そうな感じがします。何はともあれ、とりあえずヘルプを見てみます。タグマネージャを使用すると、変更予定のある設定値や、条件に応じて変える可能性のある設定値を簡単に管理できます。タグマネージャで管理します。例として次のものが挙げられます。ヘルプ・・・、なんだか入れ忘れたイベントを追加したり、コンバージョンを追加したりするのはどうやるのかイマイチわかりません。設定をGTM経由で取得するようにしておけば、設定変更を行えそうだということはわかりました。イベント追加忘れ→そいつは参ったまま急なコンバージョンの追跡→それもひどいまま大事な設定の変更→残念じゃないかもしれない!予め仕込んで置けば無理じゃないかもしれない!といった具合のようです。記事を書き始めた当初はイベント追加し忘れたよ!GTMで新しく追加したよ!みたいな記事を書こうと思ったんですが、完全な見切り発車でした。ここで大きく方向転換をして、近々ABテストが実装できるとの事なので、おそらく現在の機能でも頑張ればABテストできるんじゃないかと思ってABテストのようなものを実装してみることにしてみました。:GoogleTagManagetandroidvoyagegroup_tech2013年04月01日13:47カテゴリスマートフォンAndroidAndroidアプリをテストする際の端末の選び方!!ZucksでAndroidエンジニアをやっている橋本(@hi6484)です。先日行われたABC2013sで登壇させてもらいました。序章まず、端末を選ぶ基準として動作が異なる可能性が高い端末を選定しましょう。選定するためのポイントとして、下記2つのことを調べましょう。OSの占有率】OSの占有率はGoogleがココで公開してます。これを見ることである程度の占有率はわかります。2012年3月から2013年3月の遷移はこんな感じです。1年前からAndroid2.3の占有率が非常に高いのがわかります。Android2.2に関しては25.3%から7.5%と急降下しています。Android4.0に関してはわずか1.2%から28.6%と急成長していますが、ここ3ヶ月間で伸びが止まってます。関して2012年10月から2012年12月までの人気機種はこんな感じです。人気機種に関して2013年1月から2013年2月までの人気機種はこんな感じです。PHONEシリーズとXperiaシリーズが売れ筋です。PHONE・Xperia・GALAXY・ARROWSの4強時代と言ってもいいと思います。派生機種を把握する派生機種(兄弟機種)での無駄なテストを省くためにも、下記3つの観点から端末を分類します・メーカ・OS・チップセット3つが合致する端末は、端末の挙動は同じであるため派生機種と考えましょう。※カメラやディスプレイの解像度は異なる可能性はありますので注意してください。下記の4機種とメーカー・OS・チップセットが合致します。Z(ISW11F)テストを行うのであれば、上記1機種をテストすれば十分なのです。日本市場はGoogleが公開しているOS占有率とは少しことなります。Agentを解析した結果、Android2.3とAndroid4.0でほぼ市場は占められていることが判ってます。Android2.3とAndroid4.0で約87.87%占められており、Google資料とは日本市場は占有率は異なってます。今年の冬モデルからAndroid4.1の端末が発売され始めたため、Android4.1はこれから伸びて行くことが予想されますがアプリケーションをリリースする時に、Android2.3以上のサポートで約93%以上のAndroidユーザに届くという事が判ります。HD(SO-03D/IS12S)この2機種の合計は!!約7.0%尚且つ、現在も顕著に売れてます。売れている理由として、後継機が発売されたことで、端末の値段が下がっているけどスペック的には非常に良く、後継機と比べて端末の大きさが一回り小さいなのがあげられるのではないかと思ってます。FluctのUAと人気機種から選び出すとABC2013sでも発表したとおり下記13機種です。voyagegroup_tech2012年08月29日14:56カテゴリprogrammingスマートフォンお手軽Androidプログラミング入門はじめまして、2012年新入社員のPeX菅谷です。エンジニアブログなので技術的なお話メインで、ということらしいのですが・・・いかんせん経験・技術力の無い僕は書ける内容が少なくて困りますねorzとりあえず今回は、僕がお遊びでAndroidアプリを作るときどのようにしているかをお話したいと思います。内容的には入門の入門くらいの初歩的なものになりますので、Android書けるよ・書いてるよという方々には益の無いお話になるかもしれません。プログラミングを始めようとするとき、みなさんはまず何をしますか?僕はサンプルコードを探します(笑)。趣味で書く場合にはとりあえず早く動かしてみたくてサンプルコードを探します。そこでサンプルコードの探し方なのですが、普通だったらきっと皆さんググりますよね。よさげなものがあったらそれを読んで、使えそうな部分を参考に書いたりするんじゃないかなと思います。SDKディレクトリの中に大量のサンプルコードが何気なくダウンロードされているのです。これが結構充実していて、こういう機能使いたいなーと簡単に思いつくようなことは、およそ網羅してくれています。AndroidアプリはIDEで開発するのが一般的なためsdkディレクトリ内を見ることが少なく、見落としている方もいるんじゃないかと思います。Windowsならばデフォルトではおそらく、C:\Users\ユーザー名\AppData\Local\Android\android-sdk\samples\android-○○に存在すると思われますので、是非使ってみてほしいと思います。APIの利用例を集めた『ApiDemos』というアプリです。画像ビューアペイントツールなどのように凝ったものまで、大小様々なサンプルが200個弱ほど存在します。これらを見てみることで、何ができるのか、どうすれば良いのかがある程度把握出来ると思います。SDKのバージョンにもよりますが、ApiDemosの他にもう少し複雑なものや完成度の高いものが数十個ほど用意されています。USB,BlueTooth,Wi-fiなどの通信のサンプルやゲームのサンプルなどがあります。これらを参考に機能を組み合わせ、足りない部分はIDEの補完機能にお願いしてしまうだけでわりと簡単に色々なものができます。複雑なものを作るには不足している部分は多々あるでしょうが・・・。「よくわかんないけどAndroid触ってみたい!」とか「なんかちょこっとスマホで作ってみたい!」という方々には、是非お試しいただきたいなと思います。技術的なお話にならなかったので、代わりと言ってはなんですが実際にちょこっと開発をしてみました。ApiDemos中のTouchRotateというサンプルをチラ見しつつ、我らがアイドル「ナビック」くんと戯れるアプリ『なびっくいじり』をさくっと作ってみました。「遊んでみたい!」という好奇心旺盛な方がいらっしゃいましたら「なびっくいじり」で調べてみてください。4.0.4)のみ動作確認済みです。GROUPのしんばし(@shinbashi)です。昨今何につけてもスマートフォンですよね。いう僕もPDAからのW-ZERO3という王道を通って来ました。最近は特にスマートフォン対応とか、アプリ化する機会が増えてきたと思います。android版を作ればiOS版も出すよ!みたいな話になりますよね。「android版だけでいい」なんて言葉を信じて設計すると、後で痛い目を見るのは火を見るより明らかです。前フリが長くなりました。android版だけだと信じて僕が痛い目を見たのは暗号化・復号処理の部分です。Javaはともかく、Objective-Cをよく知らなかったのでライブラリに頼るわけですが、Objective-Cの暗号化・復号処理をしてくれるライブラリでは扱えないアルゴリズムとかあるんですね。(ブロック長の違いなのでPKCS7でPKCS5形式のものをunpad出来る)実際、パディング処理は暗号化前、復号後に自前でやってしまえばいいのでなんとでもなりますね。してみると、暗号化アルゴリズムはAESで実装するのが妥当そうです。Objective-Cで自前でPKCS5でunpadする場合は以下な感じになると思います。pad)];}ざっくりまとめるとアルゴリズム:AES(鍵長は128でも256でもいいと思います)ブロック形式:CBC(EBCも使えます)パディング:PKCS5(独自で実装できるのでお好きにどうぞ)な感じで暗号化しておけば、android(java)でもiOS(Objective-C)でも取り扱いできます。javax.cryptやCCCryptの使い方は色々な方が解説していらっしゃるのでそちらを参考にしていただければと思います。Javaのコード長すぎて写すのを面倒臭がっているわけではありません。僕の場合だけかもしれませんが、CCCryptを使った時に、末尾に改行コードが含まれていて、NSDataからNSStringに変換しようとした時にエラーが発生したので、トリムする必要があるかもしれません。WindowsPhoneに関してですが「C#だし」ってことで割愛させて頂きました。OpenSSLの暗号文をJava/Perl/Rubyで開くhttp://alpha.mixi.co.jp/blog/?p=91こちらでJavaでOpenSSLのパスフレーズから鍵を導出する処理が書かれていたので、せっかくなのでObjective-Cで実装するとどうなるのか書いてみました。:JavaAndroidObjective-CiOS暗号化voyagegroup_tech2012年04月04日10:14カテゴリスマートフォンJumvoの作り方genesixの永野です。デザイナーとエンジニアの連携」と題して、Jumvoをどうやって作ったのかを発表しました。当日のSlideはこちら。JumvoとはJumvoはgenesixからリリースしている、簡単に言えば声のSMSができるiOSアプリケーションです。声を送りあうことに特化しているため、シンプルな操作性が売りになっています。こちらから無料でダウンロードできます。発表はデザイナーの伊野と二人で行ったのですが、この記事ではプログラマーの立場から、Jumvoで取った開発方法を紹介します。具体的には、Jumvoでは「プロトタイピング」と「UXデザイン定義書に法った開発」を行いました。最初に、これに到るまでの経緯をお話します。自己紹介とこれまでにやってきたことgenesix入社前は、フリーランスで通販サイトを作ったり(PHP/Java)、時間とお金があればMacのアプリを書いたりしていました。genesix入社直前の1年ぐらいはMac/iOS系会社で主に受託案件をやっていました。受託という性質上、仕様の受け入れ、工数見積もり、というようなことがよくありましたが、その中で感じていたのが「iOSアプリは仕様を決めるのが難しい」そして「仕様が頻繁に変わる」ということです。「仕様」が決まらないそんなのiOSに限ったことじゃないだろう、と思われる方もいると思いますが、Webアプリケーションの受託案件と比べても変更が多い印象でした。実際に画面に触ってみないと分からない点が後から色々出てくる、のが一番の理由だと思われます。象徴的な話としては自機を触って操作するシューティングゲームで、完成してみると、自機が指で隠れてしまうのでお蔵入りになった、という冗談みたいな話も聞いたことがあります。そのため、いつも「後で変更しやすいようにしておかないと、納品前に仕様が変わって間に合わなくなるだろう」とか「この見積もりでは変更できないからクライアントが納得しないだろ」「最初にこの操作だけは決めておかないと完成前に変わると全部がひっくりかえる」といったよく心配をしていました。全画面の構成程度の仕様が決まったと思っても、使っているうちに問題点が浮き彫りになり、修正したくなる。あるのが、ここの仕様が曖昧だと思っていると、後でデザイナーから(もしくはクライアントから)指摘がある。仕様が決まりさえすれば、たいていのものは作るのは難しくありません。どんなに優秀なデザイナーでさえ、動かなければ分からないことが多い、どうすればいいだろう?ということをずっと考えてきました。「ユーザー」とは誰なのか?もう一点、仕様を決めていくプロセスにおいても問題を感じていました。クライアント、エンジニア、デザイナーで新しいアプリの仕様を検討していても、それぞれがそれぞれの立場で、この機能が必要だ、これはこの位置だ、という話になりますが、その主張の根拠が「ユーザー」という正体不明なものであることでした。何を言っているんだ!と言う方もいらっしゃると思いますので説明します。何かBtoCのサービスを作るのであれば、それは顧客であるユーザーのためである、これに異論がある方は居ないと思いますが、その「ユーザーのためを考える」のは各人共通であったとしても、実は対象としているユーザーがそれぞれ(の立場)によって異なるのです。iOSアプリを作るとすれば、対象ユーザーの範囲は多岐に渡るにも関わらず、ある人は若い女性を想定しているかもしれませんし、ある人は中年のサラリーマンを想定しているかもしれません。ある人は非常にリテラシーの高い人を想定、もしくは逆、ということがあり得ます。対象をきっちり決めていない場合はほぼそうだと考えるべきだと思います。そのため、ある機能を決定する場合でも、想定しているリテラシーが異なるため、ある人はこれぐらいは分かると言い、ある人は逆にこれは理解できないはずだと言い、という出口の無い議論をすることになります。実際、前職で「ユーザー」という参加者全員が頻発する言葉に、それって誰?と言ったことがあります。各人の「ユーザー」像を少しでも近づけるべく実際に使ってくれているユーザーに来てもらって話を聞こう、と提案したりしました(それは叶いませんでしたが)。1.0では、以上の二つの問題に対して次のような方法で解決を試みました。1.「仕様」が決まらないこの点については、最初から「仕様をかちっと決めてから開発する」ということは不可能である、という前提で開発することにしました。仕様は決まらないので、決めずにやるということです。何も決まらなければ進まないので、いつでも変更される前提のプロトタイプをベースに、動くものを見ながら意見を交換し、進めました。具体的には、iPhoneの実機で実際に動作するものを基本に進めました。これは簡単に言えばプロトタイピングと言えると思います。Jumvoは最初から他のiPhoneと声を送りあえる状態から作っていったのです。下の写真のように紙にメモを書きながら、最初は僕が必要な機能を考え、UX/UIデザイナーと意見を交換しながら、実際に動作するものを修正しつつ進めていきました。これによって実際に手に取って声を発して、それを実際に相手に送信する、という一連の操作と、何よりその操作性が重要であるということをチームのメンバーに最初に伝えることができたと思います。それはその後のスムーズな開発(のための仕様の検討)に繋がったと考えています。プロトタイプベースで進めることによって、ユーザー体験のコア部分が速い段階で検証できた、ということになります。事業責任者やプロデューサーに、Jumvoが面白いのかどうか、最初の段階で確認してもらえたことも大きな利点であったと思います。このようなプロトタイピング期間が1ヶ月程あった後、UIデザイナーが正式にアサインされ、それまでのプロトタイプを元に、具体的なデザイン案が出来てきました。その案も実際に実機で動かし、再度修正し、またさらに動かし、という工程を1ヶ月で3度ほど繰り返し、最初のv1.0が完成しました。ここまでで2ヶ月ほどの時間がかかっています。2.「ユーザー」とは誰なのか?これは実は当初は想定していなかったのですが、genesixには選任のUXデザイナーがおり、UXデザインにおいてペルソナを採用していました。アプリは「アプリケーション定義ステートメント」にそって作られる、という一環した手法を採用していたのです。アプリケーション定義ステートメントとは、詳細はこちらを参照いただきたいのですが、簡単に言えば、誰が何を達成するため(=使う人のゴール)のアプリケーションなのか、を1行程度で表したものです。Jumvoの場合「もっと気持ちを伝え合いたい人のためのもっと気軽で手軽なボイスメッセージングアプリ」がそれであり、仕様等で迷ったときには定義ステートメントはこれだから..と復唱することで目的を、もっと言えばユーザーのゴールを確認することができます。僕はこの開発手法を聞いたときに正体不明のユーザーから逃れる方法だ!と目からうろこが落ちました。実際にこの手法で開発をしてみると、チーム全員が「アプリケーション定義ステートメント」に向かっており、「ユーザー」ではなくペルソナを対象として話をするため、仕様の検討でばらばらな方向を向くというとが皆無でした。アプリの目的が明確だったというのもあると思いますが、このユーザーは分かる、分からない、という議論はまったくありませんでした。あったのはどうやればゴールに近いか、という議論だけです。その中では多くの方法が話し合われましたし、ときには難航もしましたが、誰かがひらめいたときの全員の「それだ!」という意思統一の速さはこれまでに経験したことのないものでした。いったことを考えずに自由に発言できたこと、また出た案を常に手に取って使いながら判断できたことも、議論がスムーズに進んだ一つの要因だと考えます。問題点さて、上記を振り返るといいことづくめなように思えますが、問題点としては以下が考えられます。あれば、それこそどれだけでも開発できてしまうため終りがやってきません。現実的にはそのようなことは無いため、いつか終わりがきます。Jumvoの場合その制約はリリース目標日でした(具体的には7月頭)。目標日までに作るには、プロトタイピングといえども、明確に何を決めたくて、今何を試しているのか、を意識する必要があると思います。面白いかどうかだけを試していたら、何パターンもアニメーションを動かしてみて時間がすぎていく、ということもあるでしょう。Jumvoの場合、具体的な例としては、送信相手を複数選んで送信する、それを最も簡単に少ない操作ステップ数で行えるUIは何か、ということを何パターンも試しました。分かりやすさと操作性を軸に判断していきました。コーディング量が増えるJumvoの完成形のコード量を1とすると、少なく見積もっても3倍ぐらいのコードを書きました。そのためには時間がかかります。プロトタイピングに2ヶ月かかっていては、それは機能しないでしょう。そのため、必要な箇所を的確に判断し、最低限のコード量で最大の効果を発揮するいわば”勘”が必要になると思います。Jumvoは目的が明確なアプリであったため、それに必要なコア部分も分かりやすく、プロトタイピングに向いていたと考えられます。Jumvoに限らず、iOSアプリは目的が明確であるべきだと考えますので、プロトタイプベースでの開発に向いていると言えるかもしれません。プロトタイプに仕様決定の主導権が移ってしまう実際に動くものがあるため、その説得力は非常に高く「うん、これで動いているしいいんじゃない?」となる可能性が高くなります。実際、Jumvoでもプロトタイプにデザイナーが引っ張られ、最終的な判断ができない、という状況がありました。これを回避するには、モノを判断するモードと、モノを作るモードの切り替えが必要です。UXデザイン定義書は判断するモードに戻るために非常に有効でした。まとめこれまで述べてきた僕が考える問題点とそれに対するやり方を振り返ると、そもそも市場調査は的確だったのか、それで実際にアプリがヒットするのかどうか、といった根本的な問題はあります(実際、Jumvoが大ヒットしているわけではありません)。そのために最低限必要な条件である(と僕が考える)、よいものを作るための近道の一つが試せたと思いますし、実際に効果がありました。2011に選んでいただきました!(実機のiPhoneで動くものをベースとした)プロトタイピングはコーディング量が増えるため導入の敷居は若干高いかもしれませんが、UXデザイン定義書は、採用しやすいのではないでしょうか。以下の記事などを参考に採用を検討してみてください。スライドの後半では、genesixのUXデザインについて具体例を交えながら書いてあるので、参考にしていただければ幸いです。genesixデザインプロセスも公開されていますので、合わせてごらんください。