ネイティブアプリ新規開発で気をつけることまとめ

はじめに

先日Androidアプリ新規開発案件のPLとして参画して無事に案件を終わらせることができました。
開発を進める中で「ここ気をつけるべきだな(だったな)」と感じたことをつらつら本記事にまとめます。
いわゆるPLとして作業するのが初めてで不明点が多かったので、
開発を進める際に事前に検討しておくべきだったことの備忘録のような感じで見ていただければ幸いです。

前提

• 私の参画した開発のプロダクトはすでにiOSアプリ製品版が存在し、iOSと同機能をAndroidとして開発するというもので、基本的にはすでに存在する要件定義書・設計書に従って開発を進め一部機能をAndroid用に調整をするというものでした。
  そのため本記事は機能要件定義や機能設計については考慮がないことをご了承ください。

• 私のチームの立ち位置としてはユーザ企業の一次受けベンダーとして、(形式上は要件定義・設計・）製造・試験・リリース作業を行いました。顧客コミュニケーションからコーディング、打鍵まで全てをチームで行なった形となります。

• 一般的なシステム開発において通ずる汎用的な事項と、ネイティブアプリ開発特有の事項に分けて記載をしています

気をつけることまとめ

汎用的な事項

1. 非機能要件の決定

どこまでを非機能と呼ぶかも案件によってまちまちですが、ここではプロダクトのメインの画面機能要件以外のユーザ・ベンダー間の取り決めのことを非機能要件と呼ぶことにします。

要件定義書がすでに存在しiOSと同一機能を作るといっても、Android特有の挙動の差や、前ベンダーとの関係性の違いなど存在するため、そこの差分をあらかじめ顧客に合意を取ることが必要でした（Webアプリからネイティブへの移行などの場合はもっと起こりうると思います）。
私の案件で取り決める必要があったことは本項2〜5と「ネイティブアプリ開発特有の事項」1〜7に記載しています。ご参考ください。
上記とりまとめをユーザ・ベンダー間でキックオフ資料として叩き台を用意し、確定したら要件定義書に明文化していく流れをとりました。

2. 開発範囲・スケジュールの決定

案件開始時点で、見積もりでの開発範囲や工数感、スケジュール感と実際に自分で確認したものに乖離がないか確認しました。
後になって予定のなかった要件が出てくることを未然に防ぐ為に丁寧に確認することが重要だと感じました。
スケジュール感に関しては、お尻は変えられなくとも明らかに実装フェーズ足りなくね...?と感じるような場合はテストスケジュールを詰めて調整するなど、チームのベストプラクティスを守るためのムーブを行う必要がありました。確定後、WBSの作成と開発チケットの作成も忘れず行いましょう。

3. コミュニケーション手段の決定

ユーザ・ベンダー間での進捗共有や質問などのやりとりの手段を決定しました。
個人的には週１回程度の進捗報告MTGの開催と課題一覧表による質問の整理がやりやすかったです。
どのワークスペースを使用するか、議事録や課題一覧表のフォーマットをどのようにするか、効率的に進められるように考えることが重要だと思いました。

4. テスト要件の決定

・単体・内部結合・外部結合・ST・UATにおいてそれぞれどのような方式で行うのか
・結合テスト移行ではテストデータの用意は誰がいつ行うのか
・テストデータ作成依頼書の作成、またいつまでに送付すれば良いのかの取り決め
・結果書・エビデンスのフォーマットと納品有無
・上記内容のスケジュール決定

上記内容を取り決める必要がありました。

5. 案件後保守対応の決定

保守契約の方針はPMや営業にお任せする前提で、
案件終了後の問い合わせフローの整備や瑕疵担保責任対応発生時の体制の検討をすることがありました。
また、案件進行中からソースコードや各種手順書などを保守がしやすいように、別の担当者が保守担当に参画してもキャッチアップしやすいように、常に考慮して整備することを気をつけました。

6. ベース構築

私の案件の場合はユーザとは言語と使用する開発ツール程度のみ案件開始前に取り決めを行い、
アーキテクチャやライブラリ選定、通信のベース実装、デザインコンポーネントのソース起こしなどベンダー側で決めることが非常に多かったです。
テックリードのエンジニアと相談しつつ、同ユーザの別案件プロダクトの仕様なども加味しながら本実装が始まる前に進めていました。

私の例：
・JetPack Compose + MVVMアーキテクチャ (後悔：ComposeとViewModelの相性が悪い場合もあるのでもう少し別のアーキテクチャを考えるべきだったかも)
・通信部：RetroFit + OkHttp + RxJavaで実装 (後悔：普通にAPI疎通部分を非同期で実装するとネストが深くなりがちなのでそこらへんもう少し考慮して選定すべきだったかも、Coroutineの活用とか）
・グラフや表などは保守性を考えてなるべくネイティブ作成orAndroid標準Materialの使用

7. ブランチ戦略の決定

複数人で開発する案件の場合は実装が本格化する前にブランチの命名規則・マージ先の整理・CIの利用などを検討し、その案件でのベストプラクティスを目指すべきでした。

8. レビューのルール決定

複数人で開発する案件の場合はレビュー観点の標準化が重要で、
これも実装が本格化する前にPRのテンプレートやレビュー観点の明文化をしておくべきだと思いました。
また、Lintの使用や(許可されれば)AIツールを使用したCIによるコミットのレビューなども取り入れると良いと思います。

ネイティブアプリ開発特有の事項

1. OSバージョンの決定

TargetのOSはその時の最新OSバージョンで良いと思われますが、
最小OSバージョン（ストアからDLできるOSバージョンの最低ライン）を決定する必要があります。以下観点からユーザと話し合って決めると良いと思います。

・リリース時点でのOSの公式セキュリティサポートの有無
・シェア率
・検証端末の用意ができるかどうか
　→基本的に最新OSで動作できていれば過去OSでも動くと言えるが、万が一を考えた過去OSでの検証の有無が必要であれば最低ラインを絞るなど会話する

2. 検証端末の決定

上記OSのバリエーションに加え、Emulator(Simulator)/実機 それぞれでの検証の有無や、Androidは特に横幅・解像度・デフォルトの表示サイズが端末によって違うため、どの機種で検証するかをあらかじめ取り決めるべきだと思います。

基本はデザイン資料の端末サイズで確認すればOKというベストエフォートの上で、現在流通している中で一番小さいスマホで検証したい、中華製スマホで検証したい、などの要望があれば、それを結合テストでやるか、UATのみでやるか、など詳細に決めるべきでした。

3. OS固有の挙動の取り扱い決定

iOSをもとにAndroid開発を行う中で以下のようなOS固有挙動についての取り決めを行いました。

• アプリアイコン
  　→Androidはホーム画面に表示するアプリアイコンの形を変えることができる為、それに合わせた画像の用意とレスポンシブ実装を行う。

• 画面ごとのバックキー(戻るボタン)押下時の挙動

• 画面回転時の挙動

• iOSでOS標準Navigation Barを使用いている際、Androidの場合のアイコンやタイトルなどのデザイン

• 生体認証の挙動
  　→Androidは端末によって複数回生体認証失敗した時のペナルティタイムや端末ロックの挙動があるため、そちらに合わせた設計を行う必要あり

• WebViewの仕様
  　→以下のようなiOSとの差異が発生しました。
  　・Compose関数内でAndroidViewによりWebViewを開いた場合、WebViewの親要素のheightとwidthを決めていないと開くサイトのCSSがViewPort指定をしている場合上手く表示されない
  　・ファイルダウンロードの挙動；例えばPDFを開く場合、ContentTypeによってDL制御するのか、外部ビューワーを開かせるのか、など
  　・許容するschemeの設定が必要；WebViewで開くサイトにtel::などhttps以外のスキームがあった場合に

その他Cookieが正しく付与されるか、JSが効いているかなど、プロダクトによっては細かなは起きそうです。

• Http通信エラー時のthrow
  　→iOSと全く同じエラーパターンではないので、エラーメッセージの取り決めがある場合は確認

4. セキュリティ設定

・アプリ内キャッシュに保存する識別子系を暗号化するか(KeyStoreを使用するか)
・秘匿情報をHttps通信する場合に別途暗号化が必要か
・秘匿情報を画面表示する場合スクショ禁止制御などが必要か
・(脆弱性試験をする場合)過去の試験結果を受領し対策を行う
・難読化対応を行い正しくビルドできるか

難読化対応は開発中失念しがちですが、基本的にProguard設定によって行うと思います。
アノテーションを付与しているコード箇所などではバグりやすいのでリリース直前で気づかないように対処しておいた方が良いです。
Proguardの記載方法は使用しているライブラリのREADMEに設定値が記載されていたりするため、確認すると良いです。

5. 本番向けビルドaab作成の準備

前述した難読化対応に加え、アップロード鍵の設定をする必要があります。
公式ドキュメントを読みながらKeyStore Ariasにアップロード鍵を設定しましょう。

6. Play Consoleの設定

以下２つの公式ドキュメント読みながらリリースのために必要なPlay Console設定をユーザに確認しながら設定する作業を行う必要がありました。

7. テストアプリ提供方法

Play Consoleの内部テスト・クローズドテストを使用するのがポピュラーな方法かと思いますが、ユーザによってDeployGateなどの配布サービスを使用したい場合などもあるかと思うので、テストが始まる前に取り決めておくと良いです。

付録：案件進行中に読んだ読み物

一般的には非機能要件はインフラ・バックエンドに関して取り決めることがほとんどで、こちらのIPAのテキストもほとんどがそのような記載となっていて私の知りたいことはそんなに書いていませんでした。
ただ、初めてPLとして要件定義について考えることになり、一般論としての知識をつけられるので一読をおすすめします。
私はChatGPTに上記テキストとプロジェクトの概要とともに「ネイティブアプリ開発案件において考えるべきことはなんですか？」のようなプロンプトを投げて整理していました。

有名な本みたいなので読んでみました、
こちらも直接的に案件作業に役立つことが書いてあるわけではないのですが、
あまり開発ベンダーとして意識しない、エンドユーザに向けたUIデザインを考慮して開発を行う意識が身につくので、一エンジニアとしての深みを出すことができたかなと思っています。読んで損なし。