はじめに
誰かがこれに似たテーマの記事を書いてくれてたような気がするものの、見つからなかったので自分で書きました。
この記事のターゲット
- 「○○クン、そろそろ我が社でもスマホアプリを使った事業をやろうじゃないかね」と言われた
- 非技術者である
- アプリ開発や運用、事業化のことが全くわからない
アプリ事業とは
スマホアプリ（スマートフォンアプリ/モバイルアプリ）を使って収益化を行うビジネスのこと。
定義は様々なので割愛したい。
ここでは、「あるビジネスモデルの中にスマホアプリがツールとして存在している」ケースも含む。
必要なもの、人
- 資金
- なにはともあれお金が必要
- PC
- MacのほうがAndroid/iOSアプリどちらも対応できるので良い
- 開発人員に貸与するならハイスペックモデルが望ましい
- スペックの例
- 1TB SSD(HDDに比べて読み込みが速く開発体験が良い)
- メモリ 64GB（あればあるほど良い。16GBだと結構つらい）
- CPUはM1,M2（新しすぎると稀にIDEとの相性が悪い時があるが、しばらくすればIDE側が修正されるので待つべし）
- キーボード、マウス、モニター
- スペックの例
- インターネット環境
- 人員（兼務する場合もあり/★マークはエンジニアが担当可能な範囲）
- 企画
- マーケ
- プロジェクトマネージャー
- デザイナー
- ★仕様策定
- ★工数管理
- ★開発
- ★保守、運用
- カスタマーサポート
ざっくり、モバイルアプリ開発の流れ
企画 -> 新規開発 -> テスト -> 審査 -> リリース -> 運用 -> 開発 -> テスト -> 審査...
- 企画：コンセプト設計、事業計画作成
- 新規開発：アプリやサーバサイド、LPなどの開発
- テスト：粒度は様々。内部品質を保証する
- 審査：AppleDeveloperやGooglePlayConsoleでアプリを公開（ストア配布）するための審査提出する
- この審査に落ちたらレギュレーションに沿った修正を行う
- AppleやGoogle側が誤解をしているケースもある
- そんな時は異議申し立てを行い、再審査にかける
- リリース：AppleDeveloperやGooglePlayConsoleでアプリを公開（ストア配布）すること
- 運用：レビューへの返信、不具合改修などアプリケーションの保守をしながらサービスを継続する
モバイルアプリの鉄則（開発編）
- プラットフォーム側のレギュレーションをしっかり守るべし
- iOS、Androidそれぞれにアプリ開発のルールを設けている
- デザイン面でもガイドラインが存在する
- 守らないと最悪審査が通らない・アカウントが抹消される
- 多くのOSバージョンに対応するべし
- iOSの場合はOSのサポート期限が存在するため、最新から2-3バージョンまでとしても良さそう
- Androidの場合はサポート期限がないため、例えば「リリースから5年前までのOS」など社内で規則を決めて取り掛かるほうが良い
- 個人的おすすめはAndroid8以上とか。本当は8でさえ古いけど致し方なし
- 多くの機種に対応するべし(Android)
- iOSの場合は機種が固定かつ必ずApple社製なので、手元にない機種もXCodeのシミュレータ等で検証可能
- Androidは多くのメーカーが端末を出している
- OSそのものがオープンソースなため、複数メーカーが独自のカスタム実装をしたOSを搭載している場合がある
- これが機種依存の不具合の原因となる
- 同じアプリなのに「機種Aではちゃんと動くのに別メーカーの機種Bでは動かない」なんてことがザラ
- プロダクトはより多くのユーザーに届けたい
- 開発時に、これらの差異を吸収できるような書き方にすべし
- OSそのものがオープンソースなため、複数メーカーが独自のカスタム実装をしたOSを搭載している場合がある
- 顧客からの不具合報告は速やかに調査・修正・返答すべし
- リリース直後は不具合報告が上がってきやすいタイミング
- スケジュールとの兼ね合いもあるが、不具合はなるべくすぐに調査・修正した方が良い（運用編で後述）
- 原因調査に難航していても「調査しますのでしばらくお待ち下さい」のような返答はすべし
モバイルアプリの鉄則（運用編）
- 作ったら終わりではない、むしろ始まりと心がけるべし
- 顧客からの問い合わせには速やかに返答すべし
- 前述の「機種依存の不具合」の他、「課金が二重に決済された」「サブスクリプションを解約したい」のようなお金周りの問い合わせが来る
- 当然だが、問い合わせを放置するとレビュースコアの低下や悪評が立つ
- 会社の信用に関わる
- 問い合わせにはスピーディに、なるべく真摯に対応する
- 「連絡ありがとうございます。調査するので詳細を教えてください」や「調査するので5営業日ほどお時間ください、また追って連絡します」のようなユーザーとの対話を心がける
- 末永くサービスを存続させるための内部品質向上に人的リソースを割くべし
- 作って終わりではない（二度目）
- 世の中では新しい技術がどんどん生まれる
- リリースした瞬間からアプリの内部で使われる技術は古くなっていく
- 古くなっていくのを放置するとどうなる？
- 自社サービスの中のソースコードがレガシーなものになってしまい、気付いた頃には改修不可能に...
- 作り直しにかかる費用は保守に比べて高い
- リリース後に継続的にやるべきこと
- アプリ内で使っているライブラリの更新
- ライブラリ側にバグや脆弱性が潜んでいる場合があり、なるべく最新にするのが望ましい
- 設計の見直し、書き方の見直し
- 最新SDKへの対応
- 例えばAndroidの新しいOSのバージョンが出たら、それに合わせたソースコードの改修を行うことで、最新OSに搭載された機能が使えるようになったり、ユーザー体験向上に繋がる
- アプリ内で使っているライブラリの更新
アプリ開発フェーズに必要な人数は？どんな人が必要？
- 個人的にではあるが、1事業に対してAndroid2名、iOS2名ほしい
- 急な欠員や相互補完の意味で各OS2名ずつほしい
- ここはプロジェクトの規模や難易度により変わる
- 小規模なアプリなら各OS１名ずつやFlutterエンジニア1名でも良いかもしれない
- スキルセット
- 何かしらのエンジニア（開発）経験がある人
- 未経験でも構わないが、自力で調べたり、誰かに聞ける調査能力がある人
- 完全未経験から本を読んで、公式のリポジトリやドキュメント、チュートリアルをこなすことで力をつけることも可能な領域ではある
- 未経験でも構わないが、自力で調べたり、誰かに聞ける調査能力がある人
- 他部署との折衝（話し合って相談しながら進める）や説明が得意な人
- デザイナーの思い、企画の思いを傾聴して開発に落とし込むとより良い物ができる
- ステークホルダーへの説明能力が求められる場合もある
- アプリ開発は、プロダクトに関わる人が開発者でないことも多いため、専門的な知識をなるべく噛み砕いて説明しながら合意形成できる人がいると心強い
- 英語に抵抗がない人（読み書き）
- 翻訳ソフトの存在や日本語化が進んだので、最近ではドキュメントはそこまで英文を読まなくても良くなってきた
- iOSアプリはレビューへの異議申し立て等で、かつては英語で文章を送る必要があったが、現在は日本語で書いてもOKとのこと。すごい！
- 開発環境が吐くエラーの内容など、大半は英語なので抵抗がないことは重要
- 英語ドキュメントのほうが新しく、正確であるケースが多いため英語に抵抗がないことは重要
- 何かしらのエンジニア（開発）経験がある人
アプリエンジニア、どう使う？
リリースできたからアプリエンジニアの仕事ってもう無いよね？
- NO('ω'乂)
- 前述の通り、新規開発フェーズが終わったら用済みということにはならない
- 保守段階で内部品質を担保していったり、新規機能追加や不具合改修などが必要
- 保守と別事業の新規開発は並行で進められる場合もある（保守のボリュームによる）
- （保守のボリュームによるが）対応人数は減らせる
うちそんなにアプリの仕事無いんだけど、別のことに挑戦してもらうことってできるの？
- YESだが本人の同意やキャリアパスによる
- ただしアプリの保守は必要なので、仮に他の仕事をしていても何かあったら保守に回れる環境が望ましい