Sansan Androidのこの1年の変化

SansanでAndroidアプリケーションエンジニアをしている山口です。4月からリードエンジニアになりました。

私は昨年7月に入社し、先日無事勤続1周年を迎えたのでSansan Androidにおけるこの1年間の変化について書こうかなと思います。

f:id:phicdy:20190712100728p:plain

メンバーの増加

昨年入社したときには「Androidエンジニア」はおらず、iOS/Android 両方を担当するエンジニアが一人いただけでした。

社内でモバイルの重要性が高まる中で、この体制ではスピードが出ないということで中途採用の強化、社内エンジニアのモバイルへの転向が進みました。中途採用はすぐに結果が出るわけではないので地道な活動をしてきました。日々書類選考をしたり、カジュアル面談をしたり、採用面接をしたといった活動です。結果今年4月に1名入社していただくことができました。8月にも新たにメンバーが増える予定です。1年間活動してきて2名入社という状況がモバイル採用の厳しさを示しているかと思います。

さすがにいつ決まるかわからない中途採用をいつまでも待つ訳にはいきません。社内からのモバイル転向がエンジニアリングマネージャー中心に始まりました。ある程度入社年数、エンジニア歴が長いメンバーを中心に声をかけ希望者に転向していただくという流れです。対象であるSansanのWebエンジニアは日頃C#で開発を行っており、後で聞いた感じKotlinとの親和性は高いようです。そこまで違和感なくKotlinにも馴染みむしろKotlinのほうがいい！というメンバーもいます。

こういった活動の結果、7/12時点で私を含めて6人（1人PM兼、1人リモート業務委託）まで大きくなりました。そろそろリードエンジニアをもう1人増やし、チームを分割する時期なのかもしれません。

開発環境の変化

ユニットテスト

入社してまず私が注目したのは、ユニットテスト（Androidで言うところのLocal Unit Test）が1件も無い点でした。幸いにも2017年のフルリニューアルによってアプリとしてはMVPのレイヤードアーキテクチャで構築されておりテストが書きやすい状況ではありました。

f:id:phicdy:20190712103739p:plain — 名刺取得の例

基本的に私はテストがないことは許さない派で、テストがある方がスピードが上がると考えているため、この状況を変える必要がありました。テストを書く理由として、複雑なロジックを問題なく実装できているか確認するという点が大きいかと思いますが、それ以外の重要な点としてテストがないコードはリファクタリングができない、もしくは変更に大きな時間が必要になるという問題点があります。

使い捨てのアプリではなく何年も保守・運用していくアプリでコードを変更しないことはありえないです。実装時は素早くコードが仮に書けたして、将来テストがない箇所に変更を入れるとき既存の仕様が崩れていないことをどう確認するのでしょうか。

テストがないということはコードをビルドし、実機にインストールし、挙動が変わっていないことを確認するしかありません。これには非常に時間がかかります。既存のコードを変更するだけでなく、新規開発中であっても、こういったフローを何度も行うことは開発スピードが大きく落ちる原因になります。テストがあることで既存のコードを変更しても既存の仕様が崩れていないことが常に保証され、内部構造の変更が容易になります。またテストがないことでそのコードを変更すること自体が億劫になります。視認性が悪く、効率の悪い書き方をしていたり、責務が異なる処理をしていたとしても変更すること自体がかなりのコストになってしまい、優先度が上げにくくなってしまいます。

既存コードを変更しにくい未来にならないように、まず自身が手本となって積極的にテストコードを書くようにしました。既存の箇所全部にテストコードを入れるのは現実的ではないので新規部分には必ずテストコードを書き、必要であれば既存部分のテストコードも追加するという流れで進めていきました。モックを使ったテストの書き方や必要な設定をJUnitのルールとして共通化することで新しく来たエンジニアがテストコードを書きやすくなるようにも整備しました（Androidテスト全書付録A.5のRxImmediateSchedulerRule使わせてもらってます）。

その結果、7/12時点で178件のテストが追加されており、1~2日に1件はテストが追加されるようになっています。

CI環境

テストを書くと、GitHubのPR上でそのチェックをしたくなるのは当然の欲求です。Sansan AndroidではBitriseを利用しており、PRでプッシュするたびにユニットテストとAndroid Lintを実行しています。Android Lintでは可能な限り abortOnError をtrueにし、不正なコードが入らないようにしています。

昨年後半にはDeploygateの導入も開始し、Bitriseと連携することでQAやデザイナーがすぐビルドをチェックできるようになりました。スクラムの振り返りの中で「Slackでポストされるチェック結果にダウンロードのURLが表示されなくて不便」という声が上がったため、QRコードを生成するようにメンバーが対応してくれました。

f:id:phicdy:20190712160023p:plain

現在はリリースの自動化を積極的に進めています。メンバーが増え、リリース回数も徐々に増えてきました。リリースブランチの作成やGoogle Play Consoleへのアップロードなど、時間がかかる、または手動でやることで間違いが発生すると特にまずい箇所から徐々に自動化しています。

色の管理

これは少し前にあったMobile Engineer Meetup by Sansanにて発表させていただきました。

speakerdeck.com

今までは色の管理が煩雑になっており、 colors.xml の中でも同じカラーコードのものが定義されてどれを使っていいいか迷うという問題がありました。そこで colors.xml をカラーパレットとして使い、 style.xml で機能としてまとめるといった内容です。使用される色が整理され、現状はこれで問題なく運用できているのですが、DayNightテーマを使ってダークモードを実装しようと思ったときにはうまくいきません。これはもしダークモードを実装すると決まったときには考え直す必要があります。

Android技術戦略の立案

4月にリードエンジニアになってから、アプリとして向きあうべき課題はなにか？どういったアーキテクチャを選択するか？技術的に何を採用していくか？といったものに向き合っています。なぜかというと

4月のリニューアルリリースが完了により、落ち着いて向き合える時間ができた
チームメンバーの増員
技術的にどこへ向かっていくかを決めないと都度議論が発生し、メンバー間のコミュニケーションコストが増えてくる
つらみや課題がたまってきた感
最新技術採用によるエンジニアのモチベーションアップと、採用などにおける対外的アピール

といったところが理由です。

解決に向けたアクションとして、まず全員で時間を取って現状の整理をし、みんなが課題に思っている点を上げました。今は上がった課題に対してどう向かっていくかを検討しているところです。そもそもの機能的な問題は案件として扱い、アーキテクチャの変更やライブラリの使用で解決できるところは徐々に適用する形を取っていく予定です。

B1グランプリ＆Bug Fix Dayの開催

B1グランプリはKyash社で行っていた細かいバグや改善点を一気に洗い出す取り組みです。

blog.kyash.co

とてもいい取り組みだと思ったので、Kyash社に倣い、SansanのAndroidチームでも6月に初開催しました。

f:id:phicdy:20190712162200p:plain

バグ・改善点を見つける時間を45分取ってSlackの専用チャンネルに報告し、その後15分でPMが有用性を判断して合計点で競いました。結果、約50件のバグ・改善点がIssueとして登録されました。

Kyash社では見つかったものをすぐ修正していたようですが、優先度が高いプロジェクトが走っていたこともあり次月にBug Fix Dayとしてメンバー全員で1日中バグ・改善点を直す日を作りました。これにより相当数の改善が1日で行えました。B1グランプリは不定期ながら、直近ではまた来月開催する予定です。Bug Fix Dayに関しては毎月あっても良いかなと思えました。