メリークリスマス🎄
こちらは GLOBIS Advent Calendar 2019 25日目の記事です。
自己紹介
こんにちは、@mshrwtnbです。1ヶ月ほど前にGLOBISに入社し、現在、GLOBIS学び放題のアプリ開発を担当しています。iOS版GLOBIS学び放題を使いやすくすべく、チームメンバーとともにゴリゴリ書き直しています。ご期待ください💪
直近まではソシャゲを主力とする企業で、複数サービスのアプリ開発、マネジメントをしておりました。
記事の目的
これまでのアプリ開発・運用の経験をもとに、アプリ開発着手からリリースまでにやっておくと後々役立つことをご紹介します。想定読者は**サービス運用の経験が少ないアプリエンジニア1**とします（経験を積まれている方に既視感強めの内容かと思います）。チョイスは独断と偏見です。他にやっておくと、便利そうなことがあればコメントいただけると幸いです。
やっておきたいこと10選
以下、開発着手〜リリースの時系列順に掲げていきます。
- プロジェクトの目的を知ろう
- [コードに秩序をもたらそう ~設計~](#コードに秩序をもたらそう ~設計~)
- [コードに秩序をもたらそう ~コーディング規約~](#コードに秩序をもたらそう ~コーディング規約~)
- チームで用語集を作成しよう
- 継続的インテグレーション(CI)を導入しよう
- アプリのテスト配布の仕組みを導入しよう
- 開発者メニューを導入しよう
- 強制アップデート、メンテナンスの仕組みを作っておこう
- 分析ツールを導入しよう
- クラッシュレポーティングツールを導入しよう
プロジェクトの目的を知ろう
最初にアプリによって実現したいこと、解決したい課題などを企画者に聞いてみましょう。このアプリがないとどんな不便をユーザーが被るのか。競合にはどんなアプリがあるのか。SWOTなど自分たちの置かれた状況は客観的にどうなのか。これにより機能やUIの作り込みの際に、やるべきこと/やらなくていいこと、力を入れるべきところ/入れなくて良いところが判断できるようになります。
コードに秩序をもたらそう ~設計~
MVC、MVP、MVVM、Clean Architecture、VIPERなどから、設計パターンを選びましょう。どのようにコードを組み立てていくのか、どこに何を置くのか、クラスはどんな振る舞いや責任を持って良いのか（持たないのか）を決定することでコードに秩序が生まれ、変更容易性が高まります。前提として、設計に絶対解はありません。求められる事業成長のスピード、事業の変更可能性、関わる開発メンバーの人数や習熟度、技術的な意欲といった複数の観点から、何が最適と考えられるかを考えていきます。決まったら思考のプロセスをしっかりドキュメントに残しましょう。なお、iOSではMVCやMVVMが最もポピュラーなようです。
#iosdc サイバーエージェントブースにてアンケート実施中🙆
— CyberAgentDevelopers (@ca_developers) September 16, 2017
「現在開発しているアプリの設計は？」 pic.twitter.com/50srbC5q6A
コードに秩序をもたらそう ~コーディング規約~
コードの書き方をチームで統一することにより、理解負荷を下げることができます。
観測範囲だとeureka Swift Style Guideが日本語で公開されていることもあり、有名な気がします。他にもGoogleのコーディング規約なども存在します。ルール違反したコードを教えてくれるSwiftLintや、自動で修正してくれるSwiftFormatといったツール群に頼るのも有効です。
チームで用語集を作成しよう
企画、開発、デザイナー、運用といった関係者が、皆同じ言葉で同じ事柄を指せるように用語集を作っていきましょう。みんなで名前を付けていくと理解のズレが減ります。DDDではユビキタス言語とも呼びます。
また、英語表現を統一することで、フロントエンド/バックエンド/アプリエンジニア間でコードの相互理解がしやすくなります。
不思議なことに組織構造や普段のコミュニケーションがコードに反映される傾向にあります。例えば、アプリ、サーバーといったコンポーネント別でチームが組成されている場合、仕事が独自完結的になりがちで、各チームが同じ概念に対して別々の命名したまま独自進化を遂げていた、なんてことがあります。開発でもコミュニケーションは超重要です。
継続的インテグレーション(CI)を導入しよう
レポジトリへのPushやPR作成などをトリガーとして、ビルドやテストを自動で行ってくれる仕組みがCIです。導入により、コード変更によるエラー検知が早くなります。最近だと、アプリ開発界隈ではBitriseがメジャーですね。
アプリのテスト配布の仕組みを導入しよう
関係者に開発中のアプリを確認してほしいタイミングが来ます。ある機能を作ったのでPO/PdMにチェックしてほしい。QAに確認してほしい。社外の人からフィードバックを得たいなどです。そんなときにスマホと開発機をつなげて、人数分ビルドして...というのは大変です。Firebase App Distributionや先のBitriseからのダウンロードなど、配布の仕組みを作っておくと、この手間を省くことができます。
開発者メニューを導入しよう
開発時のみ表示される開発者メニューを作成し、課金状態の切り替え、API接続先の切り替えや、DBのデータ一括変更などをGUIから行いやすくしておくと便利です。
強制アップデート、メンテナンスの仕組みを作っておこう
アプリはWebと違って、ユーザに所有されます。
実際に運用してみると、アプリのバージョンアップをしないユーザーが一定数いることに気づきます。サービス進化の都合上、そのようなユーザーにも強制アップデートをかけたくなるタイミングが訪れます。強制アップデートの仕組みを導入しておき、アプデ対象ユーザーをApp Store/Google Playに案内してあげましょう。また、サーバーメンテなどを告知する仕組み（場合によって、利用をブロックする仕組み）も作っておきましょう。ないと「なんかエラーが表示される、利用できない」と問い合わせが殺到することになります。
分析ツールを導入しよう
サービスをグロースにはユーザーの行動ログと向き合うのが欠かせません。
昔、分析ツールが導入されないまま2年ほどサービス運営されていたアプリがありました。「俺にはユーザーの動きがわかるんだ！」というPOの言葉とは真逆の結果が、分析ツール導入で浮き彫りになったことがあります。
ユーザーはこちらが期待する行動フローや、偉い人のゴリ押し機能を無慈悲にスルーしてきます。一方で、自分たちの解決策の提案を喜んでくれることもあります。サービス運営で嬉しくなる瞬間です。
ツールでいうと最近はFirebase Google Analyticsがポピュラーです。
Web, Android, iOSでログ設計を揃えると分析がしやすくなります。ここでもコミュニケーションが重要になってきます。
クラッシュレポーティングツールを導入しよう
「起動しない。星1です」といったレビューが殺到しても、ヒントがなければ絶望するしかありません。クラッシュレポーティングツールを導入すること、原因究明が圧倒的に楽になります。User IDを設定することにより誰が、どんなデバイス条件で、具体的にどのファイルの何行目で、どんなエラーによりクラッシュが発生するのか把握できるようになります。また、リリース直後のエラー監視としても使うことができます。Firebase Crashlyticsが人気です。
以上、アプリ開発の現場からでした。他にやっておくと、便利そうなことがあればコメントいただけると幸いです。
-
過去の自分です ↩