入社から約２年、 Money ForwardのAndroidエンジニアとしての活動を振り返る / Looking back of two years as an Android Engineer of Money Forward

Money Forward Developers' Stories で発表した資料です。
https://moneyforward.connpass.com/event/140296/

Transcript

1. 入社から約２年、 Money ForwardのAndroidエンジニア としての活動を振り返る Money Forward Developers’ Stories 2019 2019/08/23 (Fri.) @syarihu
2. Taichi Sato (@syarihu) • PFM本部 サービス開発部 ◦ Androidエンジニア • 入社歴１年１０ヶ月 • Androidアプリ開発歴９年目
3. syarihuが普段やっていること
4. Money Forward MEのAndroidアプリ開発 • 機能開発 • 技術的負債の改善 • 開発環境整備 ◦ 開発・運用フロー ◦ アプリ設計 ◦ CI / CD • 新卒育成 ◦ 困ったときにフォロー する ◦ 厚めのコードレビュー
5. 全社的にやっていること • Androidに関する技術・知 見の共有 ◦ SlackのAndroidチャン ネルへの共有 • Android周りの全社の 方針の整備 • Androidエンジニア中途採 用 • 他プロダクトのお手伝い ◦ コードレビュー ◦ 困ってそうなときにアド バイスしたり
6. 2017年10月 〜 2018年01月
7. 主にやっていたこと • MfCoreさようなら大作戦 • ホームリニューアル ◦ 入出金履歴 ◦ MY通知
8. MfCoreさようなら大作戦
13. ホームリニューアル
14. ホームリニューアル • ホームのレイアウト変更 ◦ MY通知、入出金履歴を全面に • MY通知のデザイン変更 • ドロワーのレイアウト変更 • その他・お知らせの見直し
15. ホームリニューアル • 入出金履歴 • MY通知
16. 入出金履歴 Before
17. 入出金履歴 After
18. MY通知 Before
19. MY通知 After
21. AndroidのSlackチャンネル
22. AndroidのSlackチャンネル • 以前は座談会というのをやっていたが無く なった • 当時はAndroidエンジニア間の横のつながり があまり無かった
23. AndroidのSlackチャンネル • ただ復活させても良くないなと思いAndroid の技術・知見を共有するSlackチャンネルを 作った ◦ リリース情報、開発者ブログなどを自動投 稿したり
24. 2018年02月 〜 2018年05月
25. 主にやっていたこと • RxJava 2.0へのアップグレード • パスコードロックの指紋認証対応 • デバッグメニューの実装
26. 主にやっていたこと • 開発フロー整備 • 新卒受け入れ準備
27. パスコードロックの指紋認証
28. パスコードロックの指紋認証 • 指紋認証は個人的にどうしても入れた かった • レビューなどでも要望があり需要が高そ うだった
29. パスコード Before
30. パスコード After
31. パスコードロックの指紋認証 • パスコードロック全体のデザインも刷新 し、利便性が向上した
32. マネーフォワードAndroid版の指紋認証デザインプロセス｜池内健一｜ note https://note.mu/kenichiikeuchi/n/nc64e5c06142c
33. デバッグメニューの実装
34. デバッグメニューの実装 • 2017年の年末に開催されたAndroid勉 強会で紹介されたdebug-alterという OSSの発表を見て、とても良さそうだっ た
35. デバッグメニューの実装 • RxJava 2.x対応が終わって余裕ができ てきたので実装してみることにした
38. Androidアプリのデバッグメニューを作ろう | Money Forward Engineers' Blog https://moneyforward.com/engineers_blog/2018/04/11/android-debug-menu/
39. デバッグメニューの実装 • いまはHyperionAndroidという デバッグツールと併用して使っているが とてもよい
40. デバッグメニューの実装 • ただdebug-alterは、MEに後から入れ たライブラリと相性が悪く今は動いてな い
41. デバッグメニューの実装 • debug-alterの開発者は友人なので ときどき相談しつつdebug-alterに 自分でPR出して直しているところ
42. 新卒受け入れ準備
43. 新卒受け入れ準備 • 4月に新卒が入社し、MEにも新卒エン ジニアが入ってくることになった • ドキュメントなどがほぼ無かったため、こ れを機に整えることにした
44. 新卒受け入れ準備 • 開発ツールの導入手順からAndroidア プリ開発における基礎、応用、実践の 資料を作成しつつ、新卒に基礎から教 えた
45. 新卒受け入れ準備 • Androidの基礎を教える前に作った Androidの歴史の話はエンジニアとか 関係なく社内の色々な人に見てもらえ たので良かった
47. 新卒受け入れ準備 • 開発フローやリリースフローも明文化さ れていなかったため、なんとなく運用し ていたものを整理して明文化した
48. 2018年06月 〜 2018年12月
49. 主にやっていたこと（環境整備） • アプリ設計見直し • Dagger2導入 • テストコードの環境整備 • CI環境整備
50. 主にやっていたこと（環境整備） • 各環境のアプリをDeployGateに自動デ プロイ • SonarQubeで静的解析
51. 主にやっていたこと（リファクタ） • 手入力改善（UI刷新・リファクタ） • 2つの大きなクラスの削除 • 入出金履歴リファクタ • 家計簿詳細リファクタ
52. 主にやっていたこと（リファクタ） • レシート項目編集画面のリファクタ • カテゴリ一括変更
53. アプリ設計見直し
54. アプリ設計見直し • 6月はまだ新卒エンジニアはIssueを少 しずつやって仕事に慣れてもらっている ころだった
55. アプリ設計見直し • 新卒が本格的に開発に参加する前に 設計を整えておく必要があるだろうと思 い、設計を整えることにした
58. 手入力改善
59. 手入力改善 • 手入力画面のUIを大幅に刷新すること になった
60. 手入力改善 • 新しい設計を適用する良い機会なの で、新しい設計のための準備をしてから リファクタを行った
61. 手入力 Before
62. 手入力 After
63. 手入力改善 • 新しい設計により、表示処理とビジネス ロジックが自然にきれいに分かれるよう になった
64. 手入力改善 • テストコードも書きやすくなったのでこの タイミングでやっておいて 正解だった
65. 2つの大きなクラスの削除
66. 2つの大きなクラスの削除 • 手入力画面のUI刷新に伴い、電卓のデ ザインが変わった
67. 2つの大きなクラスの削除 • 入出金履歴詳細画面にも電卓機能が あり、刷新した手入力画面の電卓のデ ザインに合わせる必要があった
69. 2つの大きなクラスの削除 • 入出金詳細画面では次の2つのクラス があった ◦ TransactionDetailFragment.java ◦ TransactionEditFragment.java
70. 2つの大きなクラスの削除 • この2つのクラスは互いに依存してお り、どちらも1,400行もあった • そのため、全体的にリファクタすること にした
71. 2つの大きなクラスの削除 • コードだけでなく仕様も複雑だったた め、コードから仕様を読み取るのが大 変だった
72. 2つの大きなクラスの削除 • この2つのクラスを完全に消し飛ばすた めに4ヶ月ほどかかったが、なんとか無 事に終わった
73. https://speakerdeck.com/syarihu/aactoiuwu-qi-woshou-ni1-400xing-falsefragment2ti-tozhan-tutahua
74. カテゴリ一括変更
75. カテゴリ一括変更 • いままでカテゴリを変更したい場合には 入出金を1件ずつ変更する必要があり 手間だった
76. カテゴリ一括変更 • その課題を解決するため、家計簿詳細 画面からカテゴリを一括で変更する機 能を実装することになった
77. カテゴリ 一括変更
78. カテゴリ一括変更 • 家計簿詳細画面はとても古い画面だっ たため、ただ一括変更機能を 付け加えるのは難しい状態だった
79. カテゴリ一括変更 • グラフ以外の部分は入出金履歴と同じ レイアウトのため共通化したほうが良い だろうと判断し、関連画面を順番にリ ファクタすることにした
80. カテゴリ一括変更 • 入出金履歴のリファクタ • 家計簿詳細画面のリファクタ • 家計簿詳細画面にカテゴリ一括変更機 能をつける
81. 運用の見直し
82. 運用の見直し（いままで） • milestone • GitHub Projects ◦ Project1つでIssueを一括管理
83. 運用の見直し（現在） • GitHub Projects ◦ リリースごとにプロジェクトを作成 ◦ テンプレでカードを自動で移動
84. 運用の見直し（現在） • レビューの状態やIssueの進捗状況が わかりやすくなった • iOS側も同じ運用方法に巻き込めたの でプラットフォームでも統一された
85. CI環境整備
86. CI環境整備 • 新卒が入ってきて徐々に新卒が機能開 発をするケースが増えてきた ◦ 明らかにレビューの負担が増えてき た
87. CI環境整備 • いまでは当たり前の存在になっている CIだが、ここまでCIを回していなかった
88. CI環境整備 • lintが警告してくれるようなことは自動で 指摘させたいという思いからCI環境を整 えることにした
89. CI環境整備 • ktlintを新たに導入 • Dangerというツールを導入し、ktlintと android-lintの警告をGitHubの コメントで指摘させるようにした
90. CI環境整備 • 人間が何度も指摘すると面倒になった りすることでもDangerが容赦なくコメント で指摘してくれるため、 レビュワーの負担が減った
91. DeployGateに自動デプロイ
92. DeployGateに自動デプロイ • Money Forward MEでは、Deploy Gate というテスト用のアプリ配布ツールを利 用している
93. DeployGateに自動デプロイ • Androidエンジニア以外の場合は検証 用にテスト環境向けのアプリを用意して ほしいと言われる場合があり、ビルド待 ちが発生してしまう
94. DeployGateに自動デプロイ • PRをマージした際にアプリを DeployGateに自動でデプロイできるよ うにした
96. DeployGateに自動デプロイ • READMEにQRコードを載せておくこと で、読み取ってダウンロードすればすぐ に使えるようになった
97. SonarQubeで静的解析
98. SonarQubeで静的解析 • テストコードが少しずつ増えてきたのと、 CIを導入したのもあってテストコードの カバレッジやコードの品質を見たい気持 ちになった
99. SonarQubeで静的解析 • 社内の別のプロジェクトでSonarQubeを 使っていたため、それに載せてもらう形 で導入してみた
100. SonarQubeで静的解析 • カバレッジなどが視覚的に見えるように なってテストを書くモチベーションが上 がった
101. 2019年01月 〜 現在
102. 主にやっていたこと • 年額課金 • AndroidX対応 • PRへのpush時にDeployGateの Distribution URLをコメント
103. 主にやっていたこと • 自動リリース • マルチモジュール化の準備 ◦ 未使用コードの一括削除 ◦ 未使用リソースの一括削除
104. 年額課金
106. 年額課金 • いままでは月額プランしかなかったが、 2019年の3月に年額プランを リリース
107. 年額課金 • 課金の実装はかなり古い実装がされて おり、複雑な実装になっていたためまず は新しい実装方法に置き換えるための リファクタを行った
108. 年額課金 • 課金周りの知見はネットにあまり共有さ れておらず、Androidも大変だったが iOSも相当実装が大変そうだった
109. 年額課金 • 年額課金でだいぶ知見も溜まってきた ため、課金周りの知見を共有する勉強 会をしたいと思いSlackにつぶやいてみ た
111. 年額課金 • 面白そうという話になり、年額課金のリ リースが落ち着いてから勉強会を開催 することになった
112. https://billing-night.connpass.com/event/125510/
113. https://speakerdeck.com/syarihu/androidfalseapurinei-ke-jin-woaacdeshi-zhuang-suru
114. 年額課金 • 集まった人数は少なかったものの、コア な層が集まって濃い話がたくさんできた ので開催してよかった
115. 年額課金 • 技術系の勉強会の開催も新オフィスで の開催実績が少なかったため知見が少 なく非常に苦労した
116. 年額課金 • 次に開催しようと思った人が同じ苦労を しないように、得た知見を社内ドキュメ ントにまとめたり、チェックリストを作った
117. AndroidX対応
118. AndroidX対応 • Androidでは、Android Frameworkの APIに下位互換性を保つために Support LibraryというGoogle公式のラ イブラリを利用していた
119. AndroidX対応 • Support Libraryはv28で終了し、今後 はAndroidXに移行する必要がある • AndroidXのバージョンはv1.0.0から • パッケージ名もandroidxになる
120. AndroidX対応 • 年額課金のリリースが落ち着いてきた のでそろそろ対応しないといけないなと 思い、やることにした
121. AndroidX対応 • AndroidXへのマイグレーションツール が用意されているが、import文以外も パッケージフルでクラス参照されてしま う箇所がたくさんあった
122. AndroidX対応 • ここでスルーすると見つけたときに都度 修正する手間が発生してしまうため、手 作業で全部直すことにした
123. AndroidX対応 • 修正はかなり大変だったが、ほぼ import文だけの差分になったので ここで対応しておいてよかった
125. https://speakerdeck.com/syarihu/androidxniyi-xing-surutameni
126. PRへのpush時にDeployGateの DistributionURLをコメントする
127. DistributionURLをコメントする • DroidKaigi 2019の公式アプリでは、push 時にビルドして生成されたアプリを DeployGateにアップロードし、 Distribution URLをコメントしてくれる
128. https://github.com/DroidKaigi/conference-app-2019/pull/437#issuecomment-453829985
129. DistributionURLをコメントする • 同じ機能が欲しいと思っていたが 時間が取れずにできなかった • ようやく落ち着いてできる状態になった のでやることにした
132. 自動リリース
133. 自動リリース • アプリの署名をGoogle Play App Signingに移行したのに伴い、アップ ロードキーを使ってGoogle Playに 自動リリースできるようにした
134. 自動リリース 1. エンコードしたアップロードキーを CircleCIの環境変数に入れておく 2. releaseブランチのマージ時にrelease のワークフローを開始
135. 自動リリース 3. Google Playにリリースして良いかの確 認をSlackに通知 4. CircleCI上で承認
136. 自動リリース 5. 承認されたらリリースビルドを走らせる 6. Google Playのベータトラックに自動リ リース
137. 自動リリース 7. 生成されたアプリを元にバージョン情報 を取得し、GitHubにreleaseタグを打つ
139. 自動リリース • マージ後にそのままGoogle Playにリ リースすることも可能だが、意図しない リリースを防ぐために念のため承認制 に
140. 自動リリース • 同じ理由で製品版への直接のリリース はせず、必ずリリース権限を持つ人間 の承認を経て製品版のリリースを行うこ ととした
141. 自動リリース • 全社的にGoogle Playのアカウント権限 の整理を行ったりなどを先に行ってから リリースの自動化を行った
142. 自動リリース • リリースノートもgit管理下におき、配信 時に一緒にリリースノートも 入れるようにすることで差分がわかりや すくなった
143. 自動リリース • リリースタグもいつも手動で行っていた ため、リリースフローの手動作業をほぼ 自動化できた
144. マルチモジュール化の準備
145. マルチモジュール化の準備 • 家計簿のマネーフォワードには、 マネーフォワード ME以外に銀行向けの 家計簿がある
146. マルチモジュール化の準備 • 銀行向けの家計簿は同一リポジトリで ブランチ運用がされており、銀行ごとに 仕様が違うなど非常に大変
147. マルチモジュール化の準備 • コアな機能と各銀行向けにカスタマイズ された機能をモジュールという単位で分 けてお互いに影響が無いように修正す ることにした
148. マルチモジュール化の準備 1. コードスタイルの統一・整理 2. 不要なリソース・クラスを削除 3. パッケージを整理 4. 循環参照を無くす
149. マルチモジュール化の準備 1. コードスタイルの統一・整理 2. 不要なリソース・クラスを削除 3. パッケージを整理 4. 循環参照を無くす ｲﾏｺｺ
150. マルチモジュール化の準備 5. コアな機能をモジュールに切り出す 6. 銀行向けのコアな機能をモジュールに 切り出す
151. マルチモジュール化の準備 7. MEのブランチに入っている2つのアプリ の機能をモジュールに切り出す 8. 各銀行向けの機能をモジュールに切り 出す
152. 未使用コードの削除
153. 未使用コードの削除 • Intellijの機能を駆使して未使用 メソッドやクラスなどを片っ端から削除し た
154. 未使用コードの削除 • 使っているように見えて実は互いに参 照していただけなどのファイルがありか なり大変だったが、結構消せた
156. 未使用リソースの削除
157. 未使用リソースの削除 • gradle-unused-resources-remover-plu ginというGradleプラグインを使って未使 用リソースを削除した
160. https://moneyforward.com/engineers_blog/2019/07/19/unused-resources-remover/
161. マルチモジュール化の今後
162. マルチモジュール化の準備 1. コードスタイルの統一・整理 2. 不要なリソース・クラスを削除 3. パッケージを整理 4. 循環参照を無くす ｲﾏｺｺ
163. マルチモジュール化の今後 • まだマルチモジュール化をするところま で至っていないので、年内くらいには循 環参照を無くすところくらいまでは進め たい…
164. おまけ: Kotlin率
166. まとめ
167. まとめ • 入社してからたくさんの機能開発や負 債改善、開発環境整備などを行ってき た
168. まとめ • 新しいメンバーが入ってきてもドキュメン トを見ればすぐに開発が始められるよう になった
169. まとめ • CIの整備によりアプリの動作がすぐに 確認できるようになったり、設計・仕様 のレビューに集中できるようになった
170. まとめ • 課題を１つずつ解決していき、改善を続 けていけば開発環境は良くなっていく
171. まとめ • これからも良いサービスをスピード感を もって提供できるように開発環境改善 や負債改善、機能開発などを頑張って いきたい
172. ありがとうございました