インフィニティソリューションズ株式会社ブログ

モバイルアプリ開発でよくある落とし穴に嵌まらないようにするには?

Mashableのサイトでこんな記事を見つけた。

How to Avoid the Common Pitfalls of Mobile App Development(モバイルアプリ開発でよくある落とし穴に嵌まらない方法)

mashable

1. Android or iOS?(AndroidかiOSか)

A common issue developers run into is deciding which operating system to run first: Android or iOS. Developers should think about the audience the app is meant for when making a decision.

開発者がよく陥る問題は、どのオペレーティングシステムを最初にするかを決めることだ。AndroidかiOSか。意思決定するためには、開発者はアプリが意図するユーザのことを考えないといけない。

White Pages, Inc.のCOO、Kevin Nakano氏はこう語っている。

“I would never say you have to launch on iOS, but you need to think about what the app needs to do and which platform is going to help you deliver on the value prop that you want to give consumers.”

「iOSでローンチすべきとは絶対言わないが、アプリは何をしなければならず、顧客に提供したい付加価値を提供するためにはどちらのプラットフォームが良いかを考えなければならない。」

— まあ当たり前のことなのだが、よく見誤ることでもある。

ScrollMotionでテクニカルプロダクションのヘッドをつとめるRolando Garcia氏によれば、

“The Android Market is fragmented, and when we’re developing that becomes an issue. No two devices on the Android are necessarily the same, so you have to start thinking from a design and front-end angle, ‘Well okay, this one has a different screen ratio and which ones are we going to release on?’ Whereas with iOS, you can just release on one.”

「Android市場は断片化しており、開発するときにはそれが問題になる。Androidのどのデバイスも異なっており、設計および前の方向から考えなければならない。オッケー、こいつはスクリーン比率が異なっている。どれをリリースすることになっている?という具合だ。iOSでは、1つだけリリースすれば良い。」

— これも言われるまでもないのだが、弊社でも議論のネタになる。ディスプレイのことだけでも、相当頭の痛い話だ。

2. Testing the Waters With Your App(アプリをテストする)

Nakano氏いわく、

“You can still do a mobile application. Just start with a mobile website first so you can learn about the design, functionality and user experience needed before building an app. The downside of an app is that the consumer has to upgrade to get new versions, while a mobile website can simply be updated,”

「モバイルアプリも作れる。アプリを構築する前に、まずはモバイルウェブサイトを作れば、デザイン、機能、ユーザエクスペリエンスを確認できる。アプリのマイナス点は、新しいバージョンを手に入れるにはアップグレードしなければならないこと。モバイルウェブサイトならシンプルにアップデートできる。」

— これもある意味常套手段。

Scroll MotionのCOOで共同創設者のJosh Koppel氏は、

“Test your app outside of your office. If your app has anything to do with receiving information remotely, test it in different places around the city: in subways, in a lot of different conditions. Just make sure your developers get outside of their offices,”

「アプリをオフィスの外でテストすること。アプリがリモートで情報を受信することがあるのであれば、街のいろんな場所でテストすること。地下鉄の中とか様々な異なる条件下でだ。開発者がオフィスの外に出るようにすること。」

— モバイルの場合、ネット接続が切れる場合があることを前提にしないとね。オフィスの中だけじゃわからない場合も。

Garcia氏が強調することは、

“Make sure that your client or you haven’t changed any pieces before the thing goes live,” says Garcia. “Make sure that the developer and environment that you’re pulling your stuff in both front-end and back-end is not experiencing any kind of changes. Lock everything down when you go into Quality Assurance (QA). And then once it gets approved by QA, you stay on that lockdown. That’s really, really important and we try to stress that to our clients.”

「クライアントやあなた自身、本番運用開始する前にどこも絶対に変更しないこと。開発者やフロントエンドとバックエンドの両方の環境に何か変更が生じていないこと。QAが始める時には全てをロックすること。そしてQAの承認が得られたならば、ロックしたままにしておくこと。これはとても、とても重要で、顧客に強く言っている。」

— これも当たり前なのだが、守られないケースが多々あって、後で痛い目をみることになる。

3. Discover of Your App(アプリの発見)

Before your app has launched, two important things to think about are marketing and consumer discovery — how users will find your app.

アプリを世に出す前に、考えるべき2つの重要なことがある。マーケティングと顧客の発見、すなわちユーザがいかにしてあなたのアプリを見つけるかだ。

Nakao氏いわく、

“It is very important to determine what category you want to place your app in as well as the keywords you use to describe your app.”

「アプリをどのカテゴリに入れるか、アプリを説明するキーワードを何にするがとても重要だ。」

Koppel氏はさらにこんなことも言っている。

“Never send out a press release until the app is in the store and tested,” says Koppel. “I can’t tell you how many times I’ve seen press release go out before an app is even approved, and that makes it disappointing for everybody. ”

「アプリが店頭に並び、テストが完了していない限り、プレスリリースを送らないこと。アプリが承認される前にプレスリリースが出されのを何度見たことか。それはあらゆる人にとって失望なのだ。」

— だいたいこういうのは、いい結果に結びつかないものだ。

4. Pleasing the Customer(顧客を喜ばす)

Impending社のCEOであり共同設立者、またiPhone向けClearの共同クリエータであるPhil Ryu氏いわく、

“When you are subsisting off of a trickle of customers, their support emails and feature requests are difficult to ignore, so you start thinking about features to add in the next update,” says Phill Ryu, CEO and co-founder ofImpending, and co-creator of Clearfor iPhone.

Ryu says this plan of action is usually a bad idea, because adding an extra feature that might add value for 30% of your users is going to, in turn, take away value for the 70%.

「顧客なしで生きていけない時、サポートメールや機能要求は無視しがたい。そのため、次のアップデートで追加する機能のことを考え始めてしまう。このような行動計画は通常良くない考えである。なぜなら、追加した機能はユーザの30%に付加価値を提供するかもしれないが、70%にとっては、価値が下がるからだ。」

Koppel氏はこう語る。

“I believe that you’re going to hear more about what’s wrong with your app from a customer review than you are from your QA group, because they’re actually using the thing,” says Koppel. “If you’re hearing the same thing over and over in reviews, you have to listen and you have to adjust if you want to have customers.”

「アプリのどこがダメなのかは、QAグループからよりも、カスタマーレビューから聞くほうが間違いなく多いはず。なぜなら、彼らは実際に使っているからだ。レビューで何度も同じことを聞いているなら、顧客を必要としているなら、よく聞き、アジャストしなければならない。」

5. Development and Design(開発と設計)

開発と設計の協業について、

Realmac SoftwareのプロダクトマネージャNik Fletcher氏は、開発に入る前にデザインを磨くことが重要と説く。

— いまいちピンボケのような。

前出のGarcia氏は、

開発と設計のチームからそれぞれ1人づつ選出し、物理的に常に一緒に働けるようにする。そうすれば両者が共同して事にあたるようになり、アプリのクオリティが全然変わってくる、と。

Nakano氏は、

まずデザインから始める方が好きだと。デザインの重要性を語っている。

— なんだか5番目は全体的にイマイチだが、1から4まではひょっとすると耳が痛い話だったりするかも。