どの地点にいつ、どのくらいの雨が降るのか、わかりやすくアップデート
今回大幅アップデートを行った開発経緯は、スマホの大画面化や高性能化でよりリッチな表現が可能となり、快適で使い心地のいいUI表現が可能になってきたことだと大前氏は語る。
雨雲の情報をマップ上に表示する雨雲レーダーの機能は従来もあったものだが、これまでは雨雲がどこにあるかを地図上に表示し、それをユーザーに読み取ってもらう必要があった。それらの情報を計算によって整理。どの地点にいつ、どのくらいの雨が降るのか、必要な情報をわかりやすく伝えることを心がけたという。
「1mmの雨が降りますと言われても、具体的にどのぐらいの雨なのかわかりにくい。そこで、『ポツポツ』や『ザーザー』、『しばらく雨が続きます』というように、いつまで雨が続くのかの表現や雨量変化のグラフを表示し、ひと目でわかるようなUIにしました」
リファクタリングすべきは今！ リアクティブプログラミングを導入
この雨雲レーダーはもともと十分に多機能な状態で、凡例表示やモード切り替えボタン、雨雲を表示するマップ、タイムシーク、SNSシェア、APIアクセス、さらに雨雲や雷、雪、台風の状況を表示するレーダーなど、さまざまなモードを持っていた。ほぼ全ての機能が一つのクラスで実装され、機能の全容が見えない巨大オブジェクト状態を、大前氏は「FatActivity」アンチパターンにおける神のオブジェクトと表現した。
一つのクラスにまとまっているため、機能の密結合が発生する。各機能が複雑に絡み合って、簡単にはがせない。継ぎ足し開発の限界が来ていた。だが大前氏は、このような設計が必ずしも悪かったとは言えないという。
「最適な設計とは時代背景や、機能の規模によって変わってくるもの。その時代や機能の規模に合わせて、リファクタリングをする必要があります。先延ばしにしてもレガシー構造に引っ張られるだけなので、一時的にスケジュールを遅延させてでも、リファクタリングすべきは今だと決断しました」
完璧を目指しすぎるとコストは無限に跳ね上がってしまう。大前氏は費用対効果を考え、適切な妥協点を設定することにした。その方針は以下3つとした。
- 機能ごとにいくつかの単位に分割する
- リアクティブプログラミングの導入
- 雨雲レーダーの範囲に限定する
実際に進めてみると、想像していたよりも容易に分割できた。これは機能的に独立していることに加え、これまでも改善に向けて努力してきた背景があったのではないかと大前氏は語る。分割することで見通しが良くなり、作業効率がアップした。案ずるより産むが易しと、やってよかったと振り返る。
リアクティブプログラミングはネットワーク周りでは使っていたが、今回は複雑になってしまったUI部分にも導入することにした。コールバックの制御では、モード変更ボタンが押されたらどんな処理を行うかをプログラミングしていく。機能があちこちに分散するという弊害もあるため、モード変更ボタンが押されたときのイベント発行と各モジュールが自律的に動くようにプログラミングすることで、処理がまとまり、見通しがしやすい形でリファクタリングを行った。
ライブラリはViewModelとLiveDataを採用。ほどよくこなれたモダンな技術で使いやすかったという。最初の1週間はリファクタリングに時間を割いたが、その遅延分は開発ブーストで返済。リファクタリングの結果、レガシーコードに足を引っ張られることなく、新機能の実装やブラッシュアップに集中して時間を使うことができた。
新機能は「作ってみたから始まるフィードバック」で開発
新機能の開発は、開発前に仕様をかためてからとりかかるのでなく、まず作ってみることから始めた。「百聞は一見にしかず、百見は一触にしかずで、触ってみて気づくことも多い。部分的にでも動くものを作って、関係者で触ってみることを何回も繰り返した」と大前氏は強調する。
ヤフーの天気アプリは、「Yahoo!天気」と「Yahoo! JAPAN」にAndroid版とiOS版の4つがあり、開発チームも4つに分かれている。それぞれ個別に開発しており、コードや仕様の共通化は行っていない。Yahoo!天気アプリのAndroid版は大前氏がフルコミットで担当、もう一人は50％の関わりのため、エンジニア数としては1.5人と非常に少人数となる。
ヤフーでは全員がリモートワークのため、直接顔を合わせない環境で開発している。そのため、SlackやZoomなどのツールを活用しながらフィードバックを行っている。実装したパッケージを共有し、各メンバーは手元の端末にインストールして、実際に触ってみてフィードバックを続けた。そのフィードバックもテキストのみではなく、スクリーンショットを貼り付けたり、場合によっては動画を使ったりしながら行った。
フィードバックの例もいくつか紹介された。例えば、今回追加したボトムシートのグラフはドラッグによって上下に動かすことができる仕様だが、同時にシークバーを動かして、雨雲の情報を切り替える操作にも使える。
「このグラフの部分は、シートの上下の移動に使うべきか、シークバーの横の移動に使うべきかという議論がありました。実際触ってみると、シークバーがあっても、上のグラフの部分が見えていると、グラフの部分を触ってしまう人が非常に多かったんです」
そこで、縦方向ならシートの移動で、横方向ならシークバーの操作に割り当て、この2つは排他で同時に制御することにした。
もう一つ紹介されたのは、ボトムシートのフリック操作についてだ。この部分は、ドラッグで上下に動かすことができるが、任意の場所で止められるわけではなく、3段階の高さに対して吸いつき動作をさせている。最初は吸いつき動作なので、座標が近い場所に移動させればいいと考えていたが、実際触ってみると、直感的には動かせないということがわかった。
加速度を加味してみると、ある人にとってはイメージ通りになるが、別のある人にとっては、合わせられない。人によってフリック動作の操作が違うため、ちゃんと真ん中に停められるアルゴリズムを模索して実装した。
今回大幅アップデートを行った4つのアプリは、それぞれの目的やOSの表現方法に合わせて、完全に同じ仕様にはせず、それぞれが最適なUIを目指したが、相互にレビューやフィードバックを何回も行っている。おかしなところは指摘し、良い部分に関しては、「よし！ うちもやろう」と取り込む形で進めた。その結果、細やかなアニメーションや、使ってみて心地よい機能が実装できたと、大前氏は満足そうに語る。
フィードバックに活用したSlackとZoomの使い分けについても紹介された。Slackは主にパッケージを共有して、見てもらうフィードバックの募集に使っていたが、そのメリットは同時に全員集まらなくても、業務の合間にそれぞれの時間軸や環境でフィードバックを行うことができる。それが功を奏し、たくさんの改善案を集めることができた。
Zoomは、集中的にバグを探す取り組み「集中バグバッシュ」で大活躍した。最初は、全員が沈黙して自分のスマホを操作するシーンを映すという奇妙な状態からスタートする。だが、誰か一人が何かおかしいところを見つけると、別の人が再現方法を発見したり、新たなバグを見つけたりする。かなりレアケースのバグを見つけることもできて、完成度を上げることができた。
アップデート後は「非常に使いやすくなった」「操作しやすい」「もうすぐ雨が降るという予測が当たった」といったポジティブな感想や、逆に厳しい意見など、たくさんの反響があったという。最後に大前氏は、今後の展望について以下のように語り、セッションを締めた。
「今後も表現の磨き込みを行い、よりわかりやすく認識の齟齬のないものにしていきたい。また、低スペックの端末でも快適に利用できるように、パフォーマンス面の改善も行っていきます。まだまだ改善していく余地はあるので、より便利なアプリを目指して、これからも改善していこうと思います」
