伊藤直也氏が語る、モバイルアプリケーション開発のいまとこれから（前編）～Salesforce Developer Conference Tokyo 2013

いま多くの開発者が取り組もうとしているモバイルアプリケーションの開発は、経験の面でも技術の面でも、コンシューマ向けの開発現場が大きく先行しています。

9月6日開催されたSalesforce Developer Conference Tokyo 2013のセッション「B2Cからみたモバイルアプリケーション開発のいまとこれから」では、コンシューマ向けサービス開発の現場に身を置いてきた伊藤直也氏が、モバイルアプリケーション開発を成功させるための方法を、これまでの経験や現在の開発現場で得たノウハウなどを基に語っています。

試行錯誤の回数を増やす、iOSとAndroidは同じように作ってはいけないなど、モバイルアプリケーション開発に関わるエンジニアやデザイナーにとって非常に参考になる内容が込められたセッションの内容を、ダイジェストで紹介しましょう。

B2Cからみたモバイルアプリケーション開発のいまとこれから

伊藤直也と言います。これまで10年くらいかな、BtoCの開発をやってきたので、セールスフォースのデベロッパーの皆さんにそういう経験を踏まえてお話をしたいと思っています。

私はもともとNiftyで働いていて、そのあとではてな、そしてGREEで働いてきました。最近はDevOpsの話をすることが多くてDevOpsの人と思われているのですが、モバイルアプリケーションの開発もやっています。

モバイルOSのシェアは増えていまして、出荷数はPCをタブレットが追い抜いているという話です。最近のBtoBでの話を聞いていても、建築現場で設計図をiPadで見ているとか、BYODで仕事でもスマホを使うといった感じになってきていると。

そういった中で、今後の開発はモバイル対応でやりたい、という話が増えてきているのではないかなと思います。

このとき、いままでの開発とは違う部分があります。それは、人々がモバイルアプリで思い浮かべるのは、普段使っているアプリと似たものだということ。

モバイルは普段みんなが使っているので、エンドユーザーが普段使っているアプリと同じように（使えるものに）してほしい、というリクエストが出てくることになります。

じゃあ、こういうアプリをどうやって作ったらいいのか。これまでの経験からお話したいと思います。

モバイル開発は従来の開発と違う

まず、モバイル開発は従来の開発と違う、というのを認識していただきたい。

デスクトップとモバイルではユーザー体験が全然違っていて、実感としてはモバイルのアプリ開発では80％がUXの開発で、まあちょっと盛ってますが、本当にインターフェイスをいっぱい作っているという感じです。ここが従来の開発と違うところですね。

なので、開発計画のときにUXの部分に時間をとらずに見積もっていると、（できあがったアプリの）評価は悪くなってしまうのではないかと思います。

どういう開発手法がいいかというと、試行錯誤を繰り返し、ユーザーに使ってもらったりして正解に近づいていくのがいいと思います。

「リーンスタートアップ」は昨年評判になった本で、最小限の機能を作ってユーザーに見せながら開発を回していけと。なんでそういう試行錯誤がたくさん必要かというと、スタートアップはビジネスモデルが確立していないので、何度も方向転換を繰り返すことになる。その方向転換の回数を増やしていけば、正解にたどりつく確率が上がるはずだ、ということです。

BtoCの開発では、試行錯誤の回数を増やすのが全体の傾向で、リーン、アジャイル開発、テストも自動化して品質も保証しながらどんどんアップデートしていくと。

なぜリリース頻度をあげるのかというと、開発の軌道修正を細かく行いたいから。

こうしたプロセスを人手を介さずに速く回していく、こういうことを最近のWeb系サービスの会社はやっています。

Instagramは、現在はFacebookに買収されていますが、2012年の時点でユーザー数が700万人と言われていました。700万人のユーザーを何人のエンジニアでサポートしていたか、分かりますか？ 4人なんです。

自分が過去にいた会社だと、はてなはユーザー数が数十万人から100万人のときにエンジニアがバイトを入れて50人ぐらい、グリーは3000万ぐらいのユーザーに対して100人はエンジニアがいて。

700万人のユーザーを4人のエンジニアでなんでまわせるかというと、自動化の仕組みとクラウドなんですね。これらを使って、自分たちがいちばん価値を届けなければ行けないところに集中しましょう、ということをやっています。

モバイルアプリ開発の実際

最近、スタートアップというかBtoCのモバイルアプリは初期バージョンからUIに力を入れて開発しています。

なんで最初からUIに力を入れているかというと、BtoCでは競合するアプリがひしめいていて、UIがよくないと使ってもらえない、だから最初からいいものを作ろうとなっているのと、iPhoneやAndroidのUI開発コストは高くて、しかもコンセプトやグランドデザインをしっかりしておかないと途中で機能を追加していくときに破綻していくので、試行錯誤が必要であるにもかかわらず、初期コンセプトをしっかり作らなければいけないからです。

この初期コンセプトも、ドキュメントをしっかり書くといった重厚なプロセスでやっているとフィードバックを素早く反映できない。

実際にどうやっているかというと、紙に書く。はてなブックマークのiPhone、Androidアプリの開発プロセスを、本人から載せていいって言われたので載せていますが、方眼紙にしっかり書くとかではなくて、普通の紙に書いています。

ペーパープロトタイピングをすることもあります。これは、このボタンを押されたら次の画面にと、紙の上で動きを確認するものです。ユーザーにペーパープロトタイプを触ってもらい、操作に合わせて紙を差し替えて、それを動画に撮って使い勝手を調べたりします。

自分でもペーパプロトタイピングをするのですが、POPというアプリを使っています。これは紙の写真を撮って（左の画面）、緑のところをクリックしたときの飛び先の画面が設定できてシミュレーションできるので、自分でボタンがこっちにあったほうが使いやすいといったことが分かります。

最近は、画像だけでUIを作れるFlintoやFileSquareなどがあります。デザイナーさんは画像を作れるので、これらを使うことが多いみたいです。

大事なのは、戻るボタンなどの使えるコンポーネントになにがあるのかを知っておくこと。iOSのガイドラインなどをしっかり読んでおきましょう。例えば、このコンポーネントはどういうときに使うもので、どういうときに使うべきでないかなど、知っておくと変なUIのアプリを作らずに済みます。

それよりも近道は、UIKit Frameworkを普通に使うこと。UIKitというのは素直に使うとiOSらしいものになるようにできています。それは単にアニメーションがそうなるというのではなく、例えばiPhoneでボタンを押したら次の画面に移る、というボタンを作るとき、画面を移るという命令は2コか3コしかないんです。だから、画面遷移をするとしたらこういう作り方しかない、というのが分かるようになっている。

ボタンも、ここにおけるボタンはこういうボタンだけ、というのが決まっていて、その制約からはみ出そうとすると、けっこう余分なコードを書かなければ行けないとか、命令が用意されていないので自分で一から書かなくてはいけないとか。

つまり、実際には実装するプログラマはiOSのUIがどうあるべきかをよく知っています。Androidもたぶん一緒です。これを知らないと、なんとなくここにボタンがあった方が便利じゃないか、といった思いつきに引っ張られてしまうんですね。

自分もミスしたことがあって、あるモバイルアプリの開発で、プルダウンすると画面がリフレッシュする機能を便利だと思って、Androidの開発者に実装を依頼したんです。その開発者は頼まれるとがんばって作っちゃうタイプの人だったので苦労して作ってくれたのですが、使ってみるとなんか使いにくくて、開発者に聞いてみたらAndroidは画面をリフレッシュするときは下にある更新ボタンを押すんですよって言われて。普段iPhoneしか使ってない人がAndroidのことを知らないで軽くお願いするとこうした悲惨なことになってしまいます。

≫後編では、モバイル開発の落とし穴、デベロッパー向けサービスの活用などについて紹介します。