Androidアプリ新規開発の技術選定
はじめに
こんにちは。令和トラベルでAndroidアプリ開発を担当している赤池です。
令和トラベルは2021年12月現在、スマートに海外旅行を予約できるアプリ「NEWT（ニュート）」のリリースに向け邁進中です。
僕自身は創業直後である半年ほど前に入社し、新規アプリ開発の技術選定に携わりました。
これから新規でアプリを開発される方などへの一つの参考に、NEWT-Androidアプリにおける技術選定の事例を紹介します。
技術選定の観点
開発言語/フレームワーク/アーキテクチャなどの技術選定をおこなう際は、例えば以下のような複数の観点から多角的に評価すると思います。
- 機能実現性
- ビジネス要件を満たしていけそうか？
- OSやライブラリの機能にはすぐ対応されそうか？
- プラットフォームに適したUIは構築できそうか？
- 開発効率
- 既存の戦力を活かせるか？
- 学習コストはどれくらいか？
- 導入や連携はしやすそうか？
- 共通化はしやすいか？
- ビルドやデプロイはしやすいか？
- その他品質
- パフォーマンスはどうか？
- セキュリティ面はどうか？
- 堅牢なシステムを構築できそうか？
- テストしやすいか？
- 開発環境は安定しているか？
- 費用
- 利用料はどれくらいかかるか？
- 採用
- 人材の母数は十分ありそうか？
- エンジニアのモチベーションは上がるか？
- サポート
- 提供元は信頼できるか？
- 公式ドキュメントは充実しているか？
- コミュニティは活発か？
さらにはここに将来性といった時間軸も掛け合わされます。
新規開発の場合、複数の項目ごとにいくつか候補を出し調査していくわけですが、それぞれ個別に評価していくと、全体最適な判断が難しくなってしまうこともあるかと思います。
そこで助けになるのは、おかれている状況において重視すべき軸を持っておくことです。そうすることで局所的ではなく全体感をもった判断がしやすくなります。
NEWT-Androidにおいて重視したこと
弊社の場合は創業直後でプロダクトもユーザーもまだほとんど無い状態でしたが、ミッション・ビジョン・バリューは明確に定められています。
ミッション
あたらしい旅行を、デザインする。
ビジョン
令和時代を代表する、デジタルトラベルエージェンシーを創る。
バリュー
Be Inclusive（多様を受け入れる）
Bet on Fire（情熱にベットする）
Go First（高速でやろう）
また、最適なユーザー体験の提供や旅行手配のDXのためにテクノロジーに投資するといった方針・文化も既に根付いていました。
これらを拠り所に、NEWT-Androidの技術選定では大きく分けて3つの軸を重視してます。
スケーラビリティ
NEWTは中長期にわたる継続した価値提供を志向しているので、リリースしたら完了ということはなく、その後も細かい変更や大きな拡張などがあることを前提としなければなりません。
システム的な観点では、堅牢で保守性が維持できるアーキテクチャパターンやフレームワークが確立しているか、テスタビリティはどうかといった点もポイントとなります。
人的な観点では採用のしやすさが重要となるので、経験のあるエンジニアが既に多数存在しているかや、エンジニアにとって魅力的なチャンレジとなりそうかも考慮に入れました。
また、プラットフォーマーであるGoogleの動向などから今後主流となり発展していきそうかどうかも重要です。
UX
会社のバリューでBe Inclusiveと掲げているように、多様なユーザーの多様な使い方の受け入れを想定する必要があります。アクセシビリティへの配慮、さらに今後はMaterial Youへの積極的対応なども考えられます。
使いやすさを追求する上では、プラットフォームに適したUIの提供もポイントになります。
また、ツアー予約機能だけでなくタビマエ・タビナカ・タビアトまでサポートするプロダクト構想から、OSの機能のフル活用が必要となる可能性もあります。
開発スピード
とはいえ立ち上がったばかりのスタートアップです。技術選定の時点では、フルタイムエンジニアはiOS1人、Android1人、バックエンド0人(!!)、プラスそれぞれPPさん(業務委託)[1]数名という体制でした。
プロダクトを早く世に出すために目標としたリリース期日（市況により後に変更）までそれほど猶予もありません。間に合わせるにはメンバーの現アセットが活かせることも重要です。新しい技術を採用する場合は、その学習コストや検証期間を意識する必要もありました。
結果、採用した技術
| 技術スタック | |
|---|---|
| 言語 | Kotlin |
| UIフレームワーク | Jetpack Compose |
| 画面構成/遷移 | Navigationコンポーネント |
| API規格 | GraphQL |
| 非同期処理 | Coroutines |
| DI | Hilt |
| 決済 | Stripe |
| 分析/通知/認証等 | Firebase |
| CI | Bitrise |
| アーキテクチャ | MVVM、レイヤードアーキテクチャ |
Why not クロスプラットフォーム？
2021年現在のアプリ新規開発における最初の大きな岐路は、ネイティブでいくのかFlutterなどのクロスプラットフォームでいくのかの選定かと思います。
そのメリット・デメリットに関しては、弊社iOSエンジニアの記事や他の比較記事を参照してもらえればと思いますが、NEWT-Androidではネイティブでの開発を選択しています。クロスプラットフォームはゆくゆくの開発効率などの面で非常に魅力的だったものの、前述のスケーラビリティやUXの実現性やネイティブに慣れた現戦力で期日に間に合うかという面で難しさがあり、そのリスクを避ける選択をしました。
ただこの選択はまさにおかれている状況において重視すべき軸によって大きく変わるので、クロスプラットフォームを選択する方が適しているケースも多いかと思います。
令和トラベルにおいても、今後の進展や環境の変化によっては新しいアプリをクロスプラットフォームで開発することやKMMの導入なども考えられます。個人的にも、ホットリロードなどの開発体験が感動レベルなFlutterは、チャンスがあれば業務レベルでも使ってみたいと思っています。
主なアーキテクチャ構成
一方でJetpackCompose等のネイティブ開発における新技術は思いきった利用方法をとっています。
- UIはシングルActivityにフルJetpackCompose
- 画面構成と内部の画面遷移はNavigationコンポーネントのみで定義
- ViewModelはNavGraphに連携させてスコープを管理
- APIはバックエンド構成との兼ね合いもありつつGraphQLを使用
- 認証にはFirebase、決済にはStripeと、信頼性高い3rdパーティ製の機構は積極的に活用
JetpackComposeに関しては、選定時点ではまだStableではなくAndroidStudioもCanary版での開発でした。開発途中でまだ一部非対応な機能に気づくなどもありましたが、リリースまでには何とかなると信じ、シンプルな構成の維持を優先しました。（正直だいぶ不安ではありましたが、幸いその後のアップデートで対応されました）
JetpackComposeは再利用性や堅牢性などにも優れていて、慣れると実装スピードも速くなるので、これからネイティブで新規開発するならまずお勧めです。
MVVMに関しては、不要論もあるViewModelもhilt-navigation-composeを使ってNavGraphと連携すると非常に便利に利用できたので、現時点では割と従来通り一般的な階層構成にしています。ただ機能単位でUIをモジュール分割するとしたら詰まりそうなところもあったりと、改善したいポイントは既にいくつか。このあたりの話はまた別の機会に紹介できればと思います。
おわりに
技術選定ではその状況で重視すべき軸を持っておくの大事って話でした。
とはいえまだまだ課題はたくさん、令和トラベルでは一緒にNEWTを発展させていく仲間を募集しています！
Androidアプリ開発の話してみたいって方はMeetyからも！
-
業務委託で入っていただいているみなさんを、雇用形態に関わらず共に働くプロフェッショナルとして「プロ・パートナーさん、通称PPさん」と呼んでいます ↩︎
Discussion