ONE TOKYO APP

f:id:unibainfo:20180517193123j:plain

onetokyo-app.org

ONE TOKYOスマートフォンアプリケーション

iOS (App Store)

Android (Google Play)

概要

ランニングの記録と共有が可能なスマートフォンアプリケーション。GPSの位置情報をもとに走行位置、距離、ペースを算出して表示する。記録はサーバに保存することでいつでも確認できるほか、ユーザ同士で共有したり ランキング形式で競い合える機能が盛り込まれている。iOS版とAndroid版のアプリ開発、ランを記録管理するサーバ構築運用、毎月開催のマンスリーバーチャルマラソンの運営サポートをユニバが担当。

システム構成

f:id:unibainfo:20180517193111p:plain

開発者コメント

Keiichi Tanifuji Keiichi Tanifuji

本プロジェクトには2017年4月より各方向との窓口役として参加しました。毎月開催される大会の運用・Android版アプリの開発・ルール改定に伴うシステム改修・管理画面のメンテナンスなど様々な計画が並行して進むため、社内外に向けた能動的なスケジューリングとタスク管理の重要性が一層高まり、確実な進行と効率化を常に心がけました。

本年度で印象的だったのは、Android版アプリの動作検証を行うフェーズです。機能や状態ごとのバリエーションを含めると80超の画面が存在する規模のアプリをデバッグする経験は初めてで、画面設計書・動作指示書・画面遷移図など一連の資料を用意した上で、それらを開発の進行に合わせてアップデートしながら、外部のデバッグ専門業者と都度コミュニケーションを取って進めるのは、スピードと精密さが同時に求められるという意味で、想像以上にデリケートな進行が求められました。

最終的には開発チーム・デザインチームの協力のおかげで、アプリの根幹であるランの記録と閲覧に関する機能は大部分を網羅できました。しかしながら「実際に長距離のランを行うと挙動が重くなる」という現象の修正をリリース後に行うなど、ユーザ視点のテストが若干不足していたのが反省点で、"いまは誰の視点で動作をチェックしているのか" という、一種のコンテクスト・スイッチのスキルの習得が今後の課題として浮上しました。そういった部分も含め、常にチーム内でフィードバックを送り合い、それを改善する動きを継続していきたいと思います。


Haruma Kikuchi Haruma Kikuchi

ONE TOKYO APP iOS 版の UI は2014年にデザインしたものですが、今回ほぼ同様の機能を持った Android 版のために、Material Desgin のマナーで過去のデザインを翻訳する、という仕事をしました。

iOS 版のデザインを制作していた2014年は、 前年に iOS 7 がリリースされ、iOS 6 までのような立体感を多用した UI からフラットな UI へインターフェイスパラダイムが変化しつつあるタイミングでした。当時としてはフラットが当たり前になっても通用するデザインになるよう頑張りましたが、そのデザインを2017年のいま、直接 Material Design に翻訳しようとすると、曖昧さや、冗長な表現がかなり見つかりました。 そもそも、流行 (ブラーの深さやアイコンのフォルムやブロックの境界の処理など) も変わっていて、機能的には移植でも修正すべき点は多くありました。

それを再構築してクリアにしていく作業は、視覚的な質を追求しているというよりも、よりメタな用語や UX のクリアさを求めて作業をして、それに引っぱられて目に見える要素も整っていくような感覚でした。逆に、その視点で iOS 版をみると、アップデートを早くやりたいという気持ちにもなりますが…。

また今回は、デザインデータのバージョン管理を全て Abstract で行いました。この規模の制作 (スクリーン数でいうと60くらい?) で使ったのは初めてでしたが、最高に気持ちがいい…。UI デザインは 3人+αのチームでしたが、互いの平行している作業が Sketch のアートボード上に組み上がっていく感覚は、ようやく GitHub のフローにデザインフローが追いついたなという感じがしました。忙しくなる前に Photoshop から Sketch への移植を進めておいてよかった!! (小出マン松本マンありがとう) もっと膨大な UI パーツのあるプロジェクトもガッツリやれそうです。

最初のリリースから3年が経って、マラソンを愛するランナーの皆さんの気持ちが少しだけわかってきたように思います。ようやく iOSAndroid の両プラットフォームを揃えられたので、さらに楽しんで走っていただけるよう、 UI は透明でシャキッと、大会やメダルはやりがいや楽しさを感じてもらえるように、今後もアップデートしていきたいです。


Yu Koide Yu Koide

今回アプリをデザインするにあたって、Sketch + Abstract + InVision という強力なツールのおかげで作業効率を高めながらデザインすることができました。

Sketch で UI デザイン、InVision でフィードバックや問題点の洗い出し、Abstract でバージョン管理など、作業を進めていくなかで必要なパートを各ツールに落とし込むことによって、デザインに齟齬が起きないような体制を整えられたかと思います。

ただ、色やアイコンなどの決め事に関して、どこかに記録があるわけでもなく、脳内にのみ存在するというふんわりした状態で進んでいってしまい、デザインチーム内でどれが正しいのか混乱してしまう状況も時々発生していました。そういった決め事もしっかりとドキュメントなりデザインファイルなりに残して参照できるように管理していくことが必要だという学びがありました。

また、今回 Atomic Design の思想を導入・実践し、パーツを効率よく使い回せる体制も整えたおかげで、たくさんの画面や状態などのデザインも効率よく制作することができました。 今回得た知見や技術を活かしながら、今後もよりよくアップデートしていければと思います。


Ryo Murayama Ryo Murayama

2014年にリリースされたONE TOKYOもサービス開始から丸3年を経過して、弊社がお手伝いした案件の中でも比較的息の長いサービスとなりました。ONE TOKYOにおけるサーバサイドのミッションは、すでにユーザに使われているアプリの動作を保証しながら継続的な機能追加やリファクタリングのサイクルを回していくことで、サービス成長のための実装面えのテンシャルを維持していく点にあると考えています。

とりわけ今年度は、Android版アプリのリリースはもとより、新しいクラスルールの適用、ウェブサイトのリニューアルなど、節目となるリリースをいくつも経験した年でもありました。幸い大きなトラブルもなく、また順調にユーザ数も増え続けており、ウェブサービスの開発と運用を支える裏方の役割を果たすことができたと感じています。体制面においても新たなメンバーを迎え、よりチームとして組織的な動きができるようになりました。iOS/Android/Webと看板が揃ったONE TOKYOの今後の発展にご期待ください。


Sei Kataoka Sei Kataoka

2014年のiOS版初回リリースからの開発を担当しております。2014年当時は、Swiftが発表・リリースされたタイミングでもあり、初期の段階からiOS版のONE TOKYO APPはSwiftで開発を進めてきました。

これまで、Swift自体やCocoa Touch APIのアップデートも何度かありましたし、それにつられてサードパーティのライブラリも栄枯盛衰を繰り返し、FRPフレームワークはReactiveCocoaからRxSwiftへ、データベースはSQLiteやCoreDataを使ったものからRealmへ、HTTPネットワークライブラリはAFNetworkからAlamofireへとトレンドが目まぐるしく変わっていく中で、取り込めた技術もあれば、泣く泣く対応を諦めた技術もあります。また、開発からテスト、リリースまでの作業を効率良く、かつミスなく進めるには、多くの部分を自動化する必要がありました。

現在では、BitriseとFastlane、GitHubを組み合わせて、テスト、関係者へのデバッグ版の配信、iTunes Store申請用のビルド作成などを自動化しています。今後1年はiPhone X対応やデザインのアップデートも含めて、「見た目もソースコードもきれいに」をスローガンに、引き続き改善や新機能のアップデートをリリースしていきたいと思います。


Seiya Konno Seiya Konno

今回 Android 版の開発を担当した今野です。2014 年に iPhone 版をリリースする際には、インフラの構築及びサーバサイドの実装とテクニカルディレクションを担当していました。これまでは「なぜ iPhone しかないのか」というユーザさまの問い合わせをいくつかいただいておりましたが、それから丁度 3 年後、Android 版をリリースし、期待に応えることができてよかったと思います。

せっかくなので、開発の裏話をいくつか。弊社ではこれまで、単機能な Android アプリの開発の経験はありましたが、今回のような中規模以上のアプリの設計・実装については今回が初めてでした。また複数人でアプリの様々な機能を並行して開発することも初めてでした。

中規模以上の構造物を何人かで並行して開発する際、重要になるのはアーキテクチャの選定です。特に Android については歴史が 10 年以上あるため、時代によって採用されるアプローチが全く異なったりしていました。時代遅れなアプローチを採用してしまうと、アプリの改修が難しくなり、中長期的に見たときに、ユーザの不利益となってしまいます。アプローチがモダンかそうでないかはリサーチ時に特に注意しました。いくつかのオープンソースAndroid アプリの事例を参考しましたが、特にDroidKaigiのアプリのソースコードが参考になりました。この場を借りて謝辞を申し上げます。

そういった観点で、大まかにデータ層・ドメイン層・プレゼンテーション層といった実装のレイヤリングを行い、プレゼンテーション層では MVVM アーキテクチャを採用し、DataBinding と ViewModel を連携させる方向で実装を進めていきました。データ層からプレゼンテーション層へデータを受け渡す際には RxJava の Observable をフルに活用し、データの変化に合わせてリアクティブに UI が変わるような設計にしました。これにより、チーム内でたくさんの学習コストを支払わなければならず、開発の初期ではスピードが思うように出ず苦労しましたが、今から当初を振り返ると、最初に方針を決められて本当に良かったと実感しています。これらの設計なしにはクオリティを担保することができなかったと思いますし、開発をスケールさせることはできなかったと思います。

開発の初期には Google I/O にて Kotlin のオフィシャルサポートが発表されたり (当初開発言語として Kotlin も検討しましたが、Android 開発および Java に不慣れなチームで Kotlin を採用するのはリスクと判断し今回の開発では Java を採用しています)、開発後期に Android Architecture Component の正式版がリリースされたりち Android 開発事情の先端は変わってきています。今後もそういった波に乗り遅れないよう技術的なアップデートをしつつ、サービスを開発していきたいです。

技術的な内容にだいぶ偏ってしまいましたが、私からは以上です。


Jun Mori Jun Mori

普段の業務では Web のフロントエンドエンジニアとして過ごしている中、今回初めてアプリのフロントエンドの大半を実装する。ということに挑戦しました。 結果としては、なんとかなった。ということで、全国の Web フロントエンジニアの方には Android 開発に積極的に関わっていけるということが証明されました。

具体的にはどんな役割だったか?という話ですが

  • レイアウトの実装 (xml)
  • レイアウトのインタラクションの繋ぎなど (ビューモデルの中身)
  • アクティビティ、フラグメントの初期化 (リサイクルビューとか Menu とか)
  • カスタムビューの実装(今回は Map 周り)

という感じです。 今野さんが主にベースを実装する中で、どちらがどこまで実装をするかという線引きが重要になるわけですが、 今回は MVVM というモデルに則った実装になっていたので、線引きが非常にやりやすかったのが印象的です。

デザインに関しては、 Web より楽だったかもしれない。 というのも、マテリアルデザインに則った構成だったので(とはいえここはデザイナーの実力が大きいわけですが)、 あとはそれを具体化するようなクラス設計を行えば残りは頭を使わずにコピー&ペーストで行ける部分が多いです。 最初は頭の中でレイアウトを分解するのに一苦労しましたが、慣れると Web と変わらないスピード感で実装できました。

アニメーションなど、素の実装が面倒そうなとこは Lottie というライブラリに丸投げしました。 本来、これは Vector のアニメーションをするためのライブラリですが、今回は連番画像をアニメーションさせるために用いてます。 AE から書き出したものをそのまま流用できるため、社内の3D担当の太田くんと協力してメダルのアニメーションなどを製作しました(私は流し込むだけ)。 そういう意味では Lottie のおかげで随分楽ができたなぁという感じです。リリース直前まで差し替えが容易という点でもおすすめです。 ただ一点。ちょっと重いなぁ(スクロールが入る画面とかは特に)という印象なので、ケースバイケースで使っていきたいですね。

ハァ〜疲れましたわ〜


Takahiro Yasui Takahiro Yasui

Androidアプリのラン機能の実装を主に担当しました。この部分はアプリの根幹となる部分であるため、アプリとしての強度を高めることを意識して設計思想の練り込みと細部の作り込みに力を注ぎました。

機能としてはGPSから位置情報を取得してランの軌跡をマップ上に表示させるという単純なものですが、スマートフォンというバッテリー駆動前提で、かつ限られたメモリ空間の中でひとつのアプリがリソースを専有して動き続けるためにはOSからの厳しい制限を受けます。そのためバックグラウンドで長時間動き続ける処理の実装にはとても苦労しました。その他にもAndroid特有のActivityやServiceのライフサクル、パーミッションの扱いにも注意を払う必要があり、リリース版に至るまでにこの部分は3回ほど大幅なリファクタリングを行ってあります(私の技術力不足...)。

大変だった部分も多々ありましたが、今回のAndroidアプリ開発ではチーム開発による自分の想像を超えてモノが出来上がる醍醐味とRxJavaを使ったリアクティブプログラミングの思想に触れられ、とても良い体験ができたなぁと思います。🌱

CREDITS

Client: Tokyo Marathon Foundation
Creative Agency: DENTSU INC., DENTSU SPORTS PARTNERS INC.
Project Management: Keiichi Tanifuji
Art Direction / Designer: Haruma Kikuchi, Yu Koide, Kohji Matsumoto, Tetsuro Shimura, Genki Ota
Front-end Development: Jun Mori
Back-end Development: Ryo Murayama, Satoshi Mochizuki
iOS Development: Sei Kataoka
Android Development: Seiya Konno, Jun Mori, Takahiro Yasui