ネクストイノベーション株式会社(以下弊社)に所属している藤井(@syo_sa1982)です。
担当は主にAndroidアプリの開発とビールとかカレーについて薀蓄を垂れ流すことです。

今回の記事では元々Webエンジニアだった私が入社してから、未知の領域であるモバイルアプリ開発にアサインされてから現在に至るまでの話とこれからの話をいくつかの時期に分けてご紹介させていただきます。

また、モバイルアプリ開発を行うことになった経緯などは前回までの記事に詳しく書かれているかと思うので、そちらをご覧ください。

執筆者とアプリ開発チームについて

アプリ開発チームは現在私を含めて2名体制で開発しており、相方のメンバーはモバイルアプリ開発の経験が長いのですが、一方の私は…

• 前職まではPHPer
• Webフロントエンドも少しやってた
• アプリ開発についてはAndroid4.x時代に軽く勉強してたり、趣味でUnityやCocos2d-xを触った程度
• 前職でモバイルアプリ開発に関わっていたが、CI/CDの整備がメイン

…と、このようにモバイルアプリの開発については、ほぼゼロの状態でスタートしていました。
ですが、相方のメンバーとチームを組んで知識を吸収しつつ開発に臨んでいたので、ここまでやってこれたのかなと思っています。

これまでのAndroidアプリ開発を振り返って

さて、ここからが本題です。
このようにWeb開発メインだった私が現在までAndroidアプリを経験してきてどうだったか、これから今後どの様に開発していくのかを下記の時系列で紹介していきます。

1. 技術選定
2. 開発初期〜画面量産期
3. REST API実装
4. 大規模仕様変更

尚、現在までの話については以前、モバイルメソッド大阪という勉強会にて登壇した時の資料もありますので、興味がある方は併せて御覧ください。

技術選定

モバイルアプリ開発を始めるにあたって、弊社ではまず最初にクロスプラットフォーム技術で開発するかどうかの検討が行われており、主に3つの選択肢が挙げられていました。

• ReactNative
• Xamarin
• ネイティブでAndroid/iOS別々に開発

これらの選択肢の採用可否をモバイルアプリ開発の経験が長い相方のメンバーと共に調査を行った結果、クロスプラットフォームとはいえどもAndroid/iOSの知識は必要など様々な理由でAndroid/iOS別々に開発することに決まりました。

開発初期〜画面量産期

開発当初、まず相方のメンバーがアーキテクチャ/ライブラリの選定を行いました。
当時採用されたアーキテクチャはMVPにDataBindingの仕組みを取り入れたものです。

役割分担としては相方のメンバーは実装難易度の高い機能の開発・調査を担当し、
私自身は採用されたアーキテクチャをなぞるようにひたすら画面を量産し続けていました。

その中でも特に以下のようなところで苦労していました。

• Layoutの実装
• Rx・DataBindingの理解
• Model層の実装の手間

Layoutの実装については、特にConstraintLayoutについて慣れるまでが大変だったなと記憶しています。
Rx・DataBindingについても今まで触れたことがなかったので、慣れが必要でした。
ただ、いずれも慣れてからは使い所を見誤らなければ、使いやすいなと感じています。

Model層の実装については後にも書くのですが、画面の表示に使うためのModelとAPIで使用していたレスポンスModelを使い回していた事もあり、ビルドが失敗しない単位でプルリクエストを出すまでに必要なクラスの数が多かった様に思います。

逆に良かった点としては、開発言語にKotlinを採用して私自身も初めてKotlinを書いたのですが、今まで触ってきた言語と比べて、非常に書きやすく良い言語だったなと思います。

REST API実装

一通り画面を作り終えた頃にサーバーサイドと通信するためにREST APIの実装を始めたのですが、今にして思えばこの頃が私にとって一番つらい時期だったと思っています。
というのも、この時期になって以下のように様々な実装上の問題が浮き彫りになってきたからです。

• ModelイコールAPIレスポンスと想定していたがために、APIレスポンス変更に対応できずにエラーを吐き出してデータを取得できない
• MockAPIをアプリ内に作っていたためにAPIの結合に伴う修正を行うとMockAPIも修正しないとビルドが通らない
• 問題解決のためにリクエスト/レスポンスを扱う実装が必要になるが、設計をミスると修正範囲が膨大になりかねないリスクがある

このような問題に立ち向かうためにチームで協議して無理な共通化をやめてMockAPIの修正範囲を抑えるなどの実装ルールを策定してAPIレスポンスを扱うクラスを実装していきました。

そこから先はリリースへ向けてひたすらAPIとの結合を進めていくだけでした。
ここまでは上述した登壇資料にも書いているとおりです。

大規模な方針転換

リリースへ向けて開発を進めていたある日、ビジネス上の都合によりサービスの仕様が大幅に変わるという決定が下されました。
そのため、開発中のアプリケーションはほぼ全て作り直す事になりました。
代わりにリリース時期にも調整が入ったため、チーム内ではアーキテクチャを変更する決断を行いました。

この頃になると私自身Androidアプリ開発について様々な情報をキャッチアップしており、AAC(AndroidArchitectureComponent)とMVVMアーキテクチャに興味を持っていました。
そのため、チームの二人で設計方針について議論を重ねながらペアプロしました。

特に前回のアーキテクチャで問題になっていたModelとAPIの密結合に対処するために、データ層・ドメイン層・プレゼンテーション層を用意し、最終的にCleanArchitectureとMVVMを合わせたアーキテクチャが完成しました。
このアーキテクチャについての詳しい説明は相方のメンバーが後の記事で説明してくれると思うので、ここでは割愛させていただきます。

最後に

入社するまではモバイルアプリ開発について未知の領域ですが、半年近く経験してきてある程度私自身一人で実装できるところまで上達してきたかなと自負しています。
今回はAndroidアプリ開発における歴史的な話に終始しましたが、今後は技術的に掘り下げた話題や勿論iOSアプリについても投稿していこうかと思うので楽しみにしていただければ幸いです。

ネクストイノベーションではモバイルアプリやマイクロサービスに興味があるエンジニア募集中です！