【昔語り】Google Play 2015 ベストアプリとるまで考えてたやっていたこと

会社のQiita:Teamが消滅するので、何か勿体なと思ったので当時の記事をそのままコピーしてもってきた。

何を考えて実装してきたかを振り返ってみるポエム

前提：Androidアプリ 開発者１人

基本方針はプロダクトの価値をユーザーに最大限届ける。
そのために、ユーザーフレンドリーになる。
デザイン、実装方針に意図、意思を込める。

デザイン(インタラクションを含む)

ユーザーにアプリに没入してもらうにはどうしたら良いのか。基本、有名どころのアプリはDesign Guidlineに則ってくる（絶対的なアプリの世界観を構築しているものは別だが）。開発アプリをDesign Guidlineから外れているものにすると、ユーザーは慣れ親しんだ操作とは別な動きを要求される。すると、操作時に違和感を得たり、迷子になったりして没入を阻害する要因となってしまうのではないかという考えのもとMaterial Designを推進している。独自色が強すぎると最悪使いにくいだけのアプリになってしまいプロダクトの価値を届けることすらできなくなる。また、実装コストとしても変に独自のデザインを実現するよりも少なくてすむ。

デザイナーさんがAndroidに慣れていない場合は、Material Designの啓蒙から始める。また、Androidとしてどこがカスタマイズできて、どこがカスタマイズできないのかを予め説明する。iOSが先行している場合は、Androidとの違いをレクチャーすることも忘れない。さらに、自分からDesign Guidlineにある表現方法の提案をどんどんする。但し、ただ提案すれば良いのではなくユーザーにとって意味のあるものであること。

Material Designに対応する場合、OS4系のものまでは積極的にサポートしていない。工数の問題がある。サードパーティ製のライブラリを使用すれば工数を減らすことができるが、いつまでサポートされるのか不明でありバグがあった場合の対応も発生しかねない。そのため、Googleが提供しているライブラリの範囲内で対応した。（Googleのライブラリもバグあったりするけど、そこはスルーで）
守備範囲としては、Design Support Library、support v4、support v7 Libraryで対応しきれるところまでとしている。適度にがんばらない。

デザイナーさんが考えたデザインは出来る限り実現する。出来上がったデザインにはそれぞれデザイナーさんの意図がある。勝手に変更しない。工数の問題でどうにもならない場合は、簡略化した他のデザインでも達成したい目的が達成できるなら提案、説明し、了解をもらってから変更する。Androidのデザインから外れている場合は指摘する。勝手にデザインを変えるのはチームの信頼関係としてもよろしくない。

機能

【実装方針】
実装コストがかかる機能がある場合、別の実現方法で同じ問題が解決できるなら、その方法を提案して工数削減

【最新バージョン対応】
Androidの新バージョンで実装が必要となるもの、Googleが推進するものは早めに対応する。
Android 6リリース時はNexus5X、Nexus6Pがキャリアから発売されることもあってRuntime Permissionの対応は国内キャリア発売タイミングをリミットとしていた。

【最新ライブラリの使用】
Googleから提供されたUIライブラリ（Design Support Library）は積極的に使うことにした。↑の通り適度にがんばらず推奨されているインタラクションを実装する。適度にバランス保とう。

【クラッシュ】
CrashlyticsのCrash Free Usersは常時99.n%を目指した。調子が良い時は99.5%前後を推移していた。クラッシュが多発すると当然ながらユーザーにプロダクトの価値が提供できない、没入を阻害する。低レイヤーで発生したクラッシュはCrashlyticsに飛んでこない時があるので、Developer Consoleでもクラッシュを監視している。

メジャーな端末でのクラッシュが確認されたら、新規機能追加より優先度を上げて早めに対応。ここらへんはチーム内の合意形成が必要。現状、最新メジャー端末でのクラッシュが確認されたら優先的に対応するしかないと考えている。Xperiaといった最新機種のケースを考えると、Docomo、AU、ソフトバンクで発売されていて窓口が多いため広まるのが比較的早い。その上、キャリアの契約上ほぼ2年は基本的に機種変更しないため割合は減少しない。さらに、月日が経てば端末が安くなるので乗り換えるユーザーも出てくるため、ユーザーが増えていく一方となりクラッシュ割合が増加する未来しかない。あとはレビューで★1つが付けられ評価が下がる、ランキング低下、インストール数の低下という流れになる。

【アプリ容量】
開発当初はアプリ容量制限が50M制限であったこともあり、50Mを切るように画像リソースを出来る限り削減した。但し、現時点では50M制限が解除されている。

しかし、制限が解除されていってもアプリ容量をどんどん肥大化していってよいわけではない。あまりに容量が大きいとユーザーがインストールするのに障害となり得るし、ユーザーに優しくない。50Mのアプリを2週に1回アップデートするだけで月100Mとなり、さらに開発アプリでは大量データをダウンロードまたはアップデートする必要があるので総ダウンロード容量のケアは必要であると考えている。

動作確認

動作確認はOS 4系、5系、6系で行っている。
解像度別ではhdpi、xhdpi、xxhdpi、xxxhdpi対応。
スクリーンサイズはNexus7で崩れないことまで確認。小さい画面サイズは開発当初意識していなかった（手元にある検証機で4.2インチぐらいまでは行っていた）が、問い合わせで4.0インチ端末だとデザインが崩れるのがわかったので後で対応することになった。
また、端末のメーカーはできるだけバラけさせている。SHARP、Sony、Samsung、Nexusシリーズなどなど。
程よく各種端末のサポートをする。

開発時に使用する端末は開発速度を上げるためスペック高めの端末 or Genymotion。
区切りがよいところで、低スペック端末を使用したり、異なるOS、解像度、スクリーンサイズが異なる端末に切り替えて開発を進めていた。機種別バグの早期発見につながる。QA時点で修正箇所が大量にてできても対応しきれるか不明なため。

さいごに

書いてみて思ったけど、当たり前のことを当たり前に継続しているだけだった。

何にせよ根っこのプロダクトが提供する価値、コンテンツ力があることは非常に重要で関係者の方々に感謝感謝です。