マイニフティアプリ開発チームにおける 開発スタイルの紹介

Transcript

1. Copyright © NIFTY Corporation All Rights Reserved.
 マイ ニフティ アプリ開発チームにおける
 開発スタイルの紹介
 川上 倫人
 会員システムグループ 第二開発チーム

2. Copyright © NIFTY Corporation All Rights Reserved.
 2
 自己紹介 ニフティ株式会社 システム統括部 会員システムグループ 第二開発チーム 川上 倫人（かわかみ みちと） 新卒4年目
 アプリ「マイ ニフティ」の開発・運用を担当
 アプリ開発歴は8ヶ月

3. Copyright © NIFTY Corporation All Rights Reserved.
 3
 マイ ニフティ @nifty 会員向けアプリ
 iOS版 ：2021年12月リリース
 Android版 ：2022年3月リリース
 https://csoption.nifty.com/myapp/ 

4. Copyright © NIFTY Corporation All Rights Reserved.
 4
 マイ ニフティの全体概要 チーム人数3名 + 技術アドバイザー1名
 iOS/Android/APIを担当分けなく開発・運用
 スクラムによる進行

5. Copyright © NIFTY Corporation All Rights Reserved.
 5
 マイ ニフティチームの抱える課題 インフラ / API / iOS / Androidと必要なスキルが幅広く
 実装方針が人により異なるときがあった
 新規プロジェクトかつ人員が流動的に入れ替わったため、
 アプリ開発経験がないエンジニアが多くいた
 今後も多くのニフティサービスと連携する可能性があり柔軟性が大事になる
 メンバーが少ないため、品質のチェック方法に工夫が必要になる
 柔軟な共通アーキテクチャと技術共有できる土壌が必要

6. Copyright © NIFTY Corporation All Rights Reserved.
 共通化できる拡張性の高い アーキテクチャってなんだろう...？ 6

7. Copyright © NIFTY Corporation All Rights Reserved.
 7
 アーキテクチャに共通する概念 API / iOS / Android共に の考えを導入 Clean Architecture
 各レイヤーにより関心の分離する
 DIP(Dependency Inversion Principle)により依存の方向を一方向にする
 フレームワーク/UI/データベース等を変更・交換しやすくする
 Clean Architecture DB
 UI
 Devices
 Controllers
 Entity
 Use Cases
 Gateways
 DataSouceInterface DataSouceImplement Repository(呼び出し側)
8. Copyright © NIFTY Corporation All Rights Reserved.
 8
 アプリアーキテクチャ Repositoryパターン
 Repository層にデータをキャッシュしてHTTP通信を減らす
 永続化したいデータはLocalDataSource経由でローカルDBに保存する
 View側からはローカルかリモートのどちらにデータがあるかを意識しないで良くなる
 View ViewModel Repository LocalDataSouce RemoteDataSouce ローカルDB HTTP Client Model iOS / Android共に を採用 MVVM + Repositoryパターン
9. Copyright © NIFTY Corporation All Rights Reserved.
 9
 アプリアーキテクチャ データフローの統一
 RepositoryにあるデータをSingle Source of Truthとする
 Repositoryにあるデータの変更を検知してデータを自動的にViewに反映する
 Usecaseにアプリケーションロジックを記載する
 イベント・データの流れを にする 一方向 View ViewModel Usecase Repository DataSource Model イベント（タップ・pull等） 
 データの変更

10. Copyright © NIFTY Corporation All Rights Reserved.
 10
 アーキテクチャの利点と課題 利点
 課題
 概念を理解するとAPI/iOS/Androidの
 区別なく実装方針が共有しやすい
 パッケージが綺麗に分割され、
 レイヤーごとの役割が明確で混乱しない
 誰が書いても似たようなモジュール名と依 存関係になりやすい
 Clean Architecture自体の
 学習コストが高め
 実装が冗長になることがある
 （UsecaseがRepositoryをつなぐだけ等）
 油断するとViewModelまたはUsecaseが 肥大化してしまう

11. Copyright © NIFTY Corporation All Rights Reserved.
 アーキテクチャはできたけど どのように継承していこうか...？ 11

12. Copyright © NIFTY Corporation All Rights Reserved.
 12
 オンボーディングの整備 基本的にはオンボーディングや仕様書を充実させていく
 実際のコードの設計意図やアプリ初学者の疑問等を反映しきれない
 言語、アーキテクチャ設計の参考書籍・サイト
 swaggerをはじめとした各APIの仕様や設計ドキュメント
 開発環境の前準備

13. Copyright © NIFTY Corporation All Rights Reserved.
 13
 属人化をなくしていくために 週一でコード解読会を実施 資料を全て残すことでオンボーディング化
 改めて実装内容の意図や改善案を
 洗い出せる
 API/アプリ初学者視点のQAも残る

14. Copyright © NIFTY Corporation All Rights Reserved.
 14
 技術を継承していく タスクに応じてモブプロを実施 タスク難易度や新規メンバーの加入状況によってモブプロを実施
 （全タスクではない）
 実装方針が統一される
 異なるスキルセットを持ったメンバー間の技術共有が可能
 気軽に質問がしやすい

15. Copyright © NIFTY Corporation All Rights Reserved.
 品質はどう保っていこう...？ 15

16. Copyright © NIFTY Corporation All Rights Reserved.
 16
 品質を保つために マイ ニフティチームの課題を考える 少人数の開発のため、端末ごとの実機テストや利用感を多く試すのに時間がかかる
 iOS/Android/APIで多くのログやメトリクスを集めているが
 必ずしも確認できていない
 SLO低下や障害のアラートはあるが、アラート起こる前の潜在的な問題に気付けない

17. Copyright © NIFTY Corporation All Rights Reserved.
 17
 テストパターンと使用感のフィードバックを増やす リリース前に社内全体で内部テストの実施 社内全体で希望者を募り、TestFlightやGoogle Playの内部テスター機能で配信
 機種固有の問題を洗い出すために実施（特にAndroid）
 フィードバック例
 画面サイズが極小の端末でスクロールができなくてログインできない
 Xiaomi端末でスプラッシュ表示がおかしい
 アプリ背景色と被っていて入力欄のカーソルが見えづらい

18. Copyright © NIFTY Corporation All Rights Reserved.
 18
 品質を確認する 月一で API / アプリのパフォーマンス会を実施 メトリクスやダッシュボードを見る機会を創出
 エラー率やレイテンシー、画面エンゲージメント等で気になる点を確認
 UI / UXの改善点やバグ、潜在的な問題点、運用改善(Toil削減等)を検討
 Firebase Performance Monitoring 
 Cloud Watch
 (SLOダッシュボード/各種メトリクス) 

19. Copyright © NIFTY Corporation All Rights Reserved.
 19
 まとめ マイ ニフティチームの取り組み API/iOS/AndroidにClean Architectureの考えを反映
 意図の共有や属人化解消、技術継承のため、コード輪読とモブプロを実施
 定期的な品質チェックに社内テストやパフォーマンス会を実施
 それぞれのコードの理解しやすさを共通化
 メンバー間で実装方針のブレをなくす

20. Copyright © NIFTY Corporation All Rights Reserved.