‘開発のハナシ’

Android Testing Bootcamp #6 でLTしました

こんにちは、Androidエンジニアの瀬戸です。
Android Testing Bootcamp #6でLTしてきました。

ノハナはテストが全てkotlinですが、これはプロダクトにKotlinを入れるという目的で始めたことです。
まずはKotlinに慣れるために新規テストをKotlinで書き始め、ある程度慣れてきたあたりで古いテストをj2k変換してすべてkotlin化しました。
最近はプロダクトの新機能をkotlinで書いていますが、想像以上にすらすらと書けています。
かなりオススメです。

UIテストはないとスライド内では書かれていますが、実際にはQAチームと相談しつつJake Whartonが昨年発表していたTesting Robotsのような設計で書き始めています。
将来的にはQAさんもUIテストのコードを書くような環境を目指しつつ、試行錯誤をしています。
形になったらまた勉強会で発表をしたいと思っています。
乞うご期待ください。

ありがとう、さようなら Parse.com。ノハナがParse.comと共に過ごした4年間の話。

ノハナで主にサーバーサイドを担当しているエンジニアの武市 (@tacke_jp) です。

Parse.comが1年後にサービスを終了することをアナウンスしたのが2016年の1月28日 。それから約1年が経った本日未明にParse.comは完全にサービスを終了しました。これまでノハナを支えてくれたParse.comに感謝を述べつつ、ノハナがParse.comと共に過ごした4年間を振り返りたいと思います (※1)。

Parse.comとノハナ

ノハナがサービスインしたのは2013年の2月13日でした。サービスの立ち上げ時からParse.comをフル活用していたため、そこから考えると約4年間Parse.comを使っていたことになります(※2)。 利用していた機能は多岐にわたり、データベースはもちろんのことユーザー認証やプッシュ通知、さらにはファイルストレージもParse.comのものを使用していました。サービス開始から4年が経ち、レコード数は4億ほどになりファイルストレージに保存している写真は約1.5億枚になりました。しっかりと調査したわけではありませんが、恐らく日本中を探してもノハナ以上にParse.comを使い倒していた企業はなかったのではないかと思います。

Parse.comとの出会い

ノハナが開発初期にParse.comを全面的に採用して開発することになったのは、タイトなスケジュールと限られた開発リソースという制約からでした。ノハナは株式会社ミクシィの社内公募制度から生まれた企業内スタートアップ(後に子会社化)で、当時の公募制度の事業化の条件が「開発開始から3ヶ月でのサービスイン」でした。このタイトなスケジュールの中でiOSアプリの開発、クレカ決済機能、フォトブック印刷用画像の合成機能など様々な機能を開発しなければなりませんでした。また、サービスの立ち上げ時は(どんなサービスでも最初はそうだと思いますが)開発リソースが限られており、エンジニアは2人しかいませんでした。このような状況の中では開発がとても間に合わないということで、Webサーバーの開発にかかる時間を極力短縮することを目的としてParse.comが導入されました。

Parse.comの提供するSDKを組み込めば、コードを2,3行書くだけでデータベースへのクエリやデータを保存する機能が作れました。コンソールからボタン1つでプッシュ通知を送信することが出来ました。開発者はアプリのUXに時間を掛けることができ、ノハナのフォトブックサービス特有に必要な機能の開発に専念することができました。こうして開発は無事期限内に完了しノハナは無事リリースされました。

ノハナとParse.com、それぞれの成長の痛み

リリースから半年後、全国放送のテレビに取り上げられた際に事件が起こりました。テレビに取り上げられた際の膨大なトラフィックに耐えきれずParse.comがポータルごと全て落ちてしまったのです。復帰したもののデータには大量の不整合が残り、やむなく注文を1ヶ月ほど停止させて頂きデータの復旧作業と注文頂いたユーザーの方々への対応を行いました。またその後も2,3ヶ月ほど新規登録が不安定となる期間が続き、その間一日に新規登録を受け付ける時間を制限させて頂くなど、苦渋の対応を行っていました。

また、ノハナは「フォトブック毎月1冊無料」(※3)というビジネスモデルのため、1冊無料の権利がなくなる月末にトラフィックが集中します。特に末日のピークタイム(23時頃)には通常の5倍~10倍のトラフィックがあり、Parse.comから大量のエラーが返ってくることがしばしばありました。月末に注文が集中するため我々にとって月末にサービスが安定しているかしていないかは死活問題であり、月末になると毎月のようにチームはざわつきました。毎月月末はエンジニアが張り付いて監視し、パフォーマンス障害が発生した際にすぐに対応できるようにしていました。

このようなことが続いたため、実は社内でParse.comから別インフラへの移行を検討してはいましたが、Parse.com終了のアナウンスまでに実際に移行に踏み切ることはありませんでした。理由には、どうロックインから逃れるかという大きな技術的困難があったためです。ストアに配信されているアプリに組み込まれているSDKは固定されたParse.comのエンドポイント(api.parse.com)に対してリクエストを送るようになっていました。そのエンドポイントのURLを書き換えて独自のものにすれば新たに配信されたアプリについては移行できますが、以前のデータも参照できるようにしなければならないためデータの同期が必要になります。しかし、api.parse.comに書き込まれたデータを整合性を保ったまま独自のDBに同期させる方法は当時は提供されていませんでした。そのため移行するためには、(1)一旦api.parse.comをプロキシするエンドポイントを別に用意する。(2)そのプロキシサーバーに向き先を切り替えたアプリをストアにリリースして十分ユーザーに浸透するまで待つ。(3)api.parse.comと互換のAPIサーバーを開発する。(4)一旦リクエストを全てストップし、Parse.comからデータを全てダンプし新DBに入れ直した後エンドポイントの向き先を変える。という手順を踏まなければなりませんでした。そのための開発に膨大な開発リソースが必要なのは想像に難くないかと思います。ノハナにとって、既存のサービス開発を止めずにこの移行を行うのは事実上不可能でした。

そのため、無駄なクエリをなくすなどノハナ側でできる範囲で対応を行っていました。またParse.comのAPIサーバーがRuby on RailsからGolangにリライトされたあたりからだいぶ安定したように思います。おかげでサービス開始から2年が経ったぐらいから月末になっても落ちることもなくだいぶサービスが安定してきました。そんな矢先の昨年1月28日、Parse.com終了の衝撃の一報でした。(※4)

Parse.com終了という衝撃の一報

出社すると社内はざわついていました。Parse.comへの依存度が高いことは社内のエンジニア全員が把握していたため事の重大さとこの先の困難についてはすぐに認識することが出来ました。すぐにParse.comからの移行のためにエンジニア3人からなる特別チームが結成され、移行の具体的な方法についての検討が始まりました。

Parse.comから提示された移行のシナリオはこうでした。まず、データの移行先として新たにMongoDB用意します。そのIPアドレスと認証情報をParse.comのコンソールに入力するとParse.comからMongoDBへデータのスナップショットが大量にinsertされて来ます。スナップショット書き込み中のデータの更新は別途キューに入れられスナップショットのコピーが完了したタイミングでそれらが流し込まれてきます。両者にラグがなくなりほぼデータを同期し終えたタイミングで「finalize」ボタンを押すとDBのread/writeクエリの向き先が切り替わるという仕組みです。その後自分たちでオープンソースのParseAPI互換サーバーであるParse Serverを立て新しいDBを向くようにします。そのAPIサーバーに対してクライアントの向き先を切り替えれば移行は完了、という流れです。

当時は「Parse.comがオープンソース化された」と報道されましたが、実際に公開されたParse-ServerはParse.comの中で動いているものとは別のただの互換APIで、クオリティが高いとは言えませんでした。(その後コミュニティの努力によってこの1年でだいぶ改善されています。)(※4)また、データベースの切替は後戻りの効かない一発作業だったため、恐怖がありました。また、ノハナ社のシステムでapi.parse.comに依存していないものはありませんでした。つまり、iOS / Androidのネイティブの他に注文WebView画面でのJSが依存していたり注文APIのWebサーバーも依存していました。また、画像合成サーバーや写真の代理アップロードサーバーなどバックグラインドジョブを行うサーバー類の依存も解消しなければなりませんでした。

一年がかりの移行作業

この4年間インフラはParse.comに任せきりだったため、社内は大規模なAppServerとDBの構築経験がありませんでした。ですが、自分たちでコントロールしたいという理由から、サードパーティの互換サービスを使わず、独自にGCP上にインフラを構築することになりました。

各種IaaS検討のため検証作業などのしていたのが春先ぐらいまで、そこから夏頃までMongoDBの環境構築と運用のための知識の獲得とデータ移行の実施、そこからparse-serverやCloudCodeのバグ修正、秋から冬にかけてiOSとAndroidのエンドポイント切替、年末から年明け早々までは細々としたParse.com依存の解消をやっていました。

Parse.comからの移行の詳細に関しては、GCP NEXTでの登壇資料GCPUGでの発表資料をご覧ください。

MBaaS採用の是非

ノハナがParse.comを採用したのは正解だったのでしょうか?それを考える上でのひとつのポイントは、「MBaaSを採用することはそれと運命を共にする」ということです。MBaaSとはモバイルアプリを開発する際に必要な全ての機能が1つにパッケージ化され、簡単にスピーディーにアプリを開発しリリースするためのものです。それを使うということはエンドポイントや認証系にロックインされることや保存しているデータにロックインされることと同義です。しかし、ロックインされないようにMBaaSを使おうとすることは矛盾しています。なぜなら、それはMBaaSの一部の機能を限定的に利用しようとすることであり、MBaaSを使う意義から外れているためです。個別の機能を提供してくれるSaaSはいくらでもあるので、初めからロックインを嫌って多少の追加の工数をかけて各種SaaSを組み合わせるというのも十分理にかなった戦略です。ノハナの場合、結果的にParse.comがクローズとなり後に大きなコストを払うことになってしまいましたが、限られたスケジュールと開発リソースという制約下ではParse.comなしではサービスは誕生しませんでした。そういう意味で、十分Parse.comを利用した意義があったのではないかと思います。

これからの話

本日をもってParse.comはMBaaSとしての役割を終えましたが、Parse.comはParse Serverというオープンソースソフトウエアとしてこれからもコミュニティの中で生き続けます。ノハナはParse.comがオープン化された利点を活かし、また自社インフラでサービスをホスティングするようになった利点を活かし、ユーザーの皆様により快適にサービスをご利用頂けるようにこれからも改善を続けていきます。

最後に改めてParse.comに感謝の意を伝えたいと思います。ありがとう、さようならParse.com。


(※1) 自分が入社したのは2014年の5月なのでそれ以前の話は伝え聞いたものです。

(※2) parse.com自体がサービスを開始したのは2011年の6月ごろなので、parse.comのかなり初期からのユーザーでした。

(※3) 送料は別途掛かります

(※4) 中の人も終了を当日まで知らなかったようです。

ノハナAndroid版アプリが新しくなりました

こんにちは、ノハナデザイナーの日野です。
約半年ぶりの投稿になります。

この度のVer4.0.0のアップデートでノハナAndroid版フォトブックアプリのデザインを全てリニューアルいたしました!
ノハナユーザーの皆さまにもっと使い易く心地よいUIにしたいと思い、Androidエンジニアと一緒に新しいデザインを制作しました。今回はこのプロジェクトについてお話させていただきたいと思います。

経緯

ノハナのAndroid版アプリのUIデザインはiOSのUIデザインをほぼそのまま使用している状態でした。私が新卒でノハナに配属される前から、Android版アプリのUIを全Material Design対応にするという企画は進んでおりました。Material Designとは、2014年にGoogleが発表したデザインのガイドラインです。
そしてiOSユーザーの私がAndroidのUIデザインを担当することとなり、Material Designの勉強をしながらデザインを制作することになりました。

そもそも私自身UIデザインも未経験でしたので、Material Designのガイドラインを何回も読み込みました。他にもUIUXの本をたくさん読み、多くのアプリを触ってデザインを勉強しました。
まだまだ知識が足りない状態で不安もありましたが、新卒の私にAndroidのデザインを任せてもらえることはとても嬉しくもありました。

Androidエンジニアと一緒にアプリの改善するところやどんなデザインにしていくかを会議でしっかりと話し合いました。話し合いをもとにペーパープロトタイプを作るところから始めて制作をしていき、Androidエンジニアと他のデザイナー方にフィードバックをもらい更にデザインをブラッシュアップしていきました。ユーザーインタビューなども行いMaterial Design対応を進めていきました。

旧デザインと新デザイン

旧デザインと新デザインを比較しながら、新しいノハナアプリをご紹介させていただきたいと思います。

1番変わったところは、何と言ってもアップロードボタンです。今まではメニューの真ん中にアップロードボタンがありましたが、それがFloating Action Buttonに新しく生まれ変わりました。ボタンの色もAccent Colorの緑色になったことによって、1番目立ち、以前より分かりやすいデザインになったのではないかと思います。
メニューの項目にも、今まではフォトブック一覧画面に行かないと見ることができなかった注文履歴画面の項目を新たに追加しました。

フォトブック一覧画面と注文履歴画面も変わりました。まずフォトブック一覧画面ですが、今まで長押しをして「編集・注文・削除」のメニューが表示される仕様になっていて、ユーザーが気付かないなどの問題点がありました。しかし、Material Design対応をしたことにより新たに右側にオプションメニューをつけ、以前よりも簡単に「編集・注文・削除」が行えるようになりました。また旧デザインよりも表紙画像を大きく表示させ、とても見やすい画面になりました。
注文履歴画面も大幅に変わりました。今まではユーザーが注文したフォトブックの情報が、「注文済み」「発送済み」のアイコンと文字のみでしか分からない状態でした。新しいデザインではフォトブックの表紙が表示されるようになり、「注文済み」や「発送済み」などのアイコンをラベルに変更しました。こちらの画面はMaterial Designのガイドラインにもないノハナのオリジナルデザインでもあるので、私自身もとても思い入れがあります。

ホーム画面から写真をタップすると遷移する写真詳細画面も、旧デザインよりも使い易いデザインに変わりました。今までは写真を削除、コメント入力などの編集作業を行う時は、いちいちページを遷移しないと行えませんでしたが、新しいデザインでは1画面で簡単に編集・削除ができるようになりました。背景色も黒色から白色に変わり、ノハナらしさがより出ています。

その他にも、メニュー、アップロード画面、フォトブック編集画面などなど、本当に細かい部分まで全てリニューアルいたしました。是非ノハナのAndroid版アプリをアップデート、またはインストールしていただけると嬉しいです。

AndroidのUIデザインを担当して

初めは一人でAndroidのUIデザインを担当するのに不安やプレッシャーを感じていましたが、一人で取り組むことにより責任感も更に感じることができ、デザインも妥協せずに制作することができたように思います。Androidエンジニアや他のデザイナー方にも積極的に発言、質問ができるようになり、AndroidのUIデザインを担当してから勉強する時間も増え、知識も増え、デザインの力も成長したように感じます。

そして毎月行われているノハナ月例会の後に、Android版アプリについて発表をさせていただきました。無事リリースすることができたら「自分の今までの制作フローや新しくなったアプリについて発表をする!」ということは最初から決めていたので、無事発表まで終えることができて本当に良かったです。
これからもAndroidのUIデザイナーとして、成長し続けていきたいと思います。

今後について

今後の活動につきましては、ノハナデザインスプリントで行った施策やユーザーの皆さんに良い体験をしていただくために機能改善を行うなど、アプリをもっとより良いものにしていきたいと思っておりますので、これからもどうぞノハナをよろしくお願いいたします!

1 2 3