概要
まずは、このご時世に新規のアプリ開発を出来るというチャンスに感謝しましょう。
もちろんすでにあるアプリの追加開発や運用で得られる経験値はとても素晴らしいですが、同じように新規開発も胸踊るものがあります。
あなたのRoleがDeveloperなのか、あるいはProject Managerなのか、Product Managerなのかで主に考慮すべき点は変わってきますが、それはそれとしてすべての点を理解して、抜け漏れがあったら指摘あるいは巻き取る覚悟を持っておきましょう。
ラストマンシップは良い資質です。具体的にはラストマンシップがあるだけで業界で生き延びられます。
見積もり
作るアプリについて
- 商用か、デモなのか
- デザインは外注か、内製か
- アプリのリリースタイミング
- 想定プラットフォーム
- iOSは直近2バージョンで良いか
- iPad含むタブレットは考慮に入れるか(最近のAndroidはfoldable対応を進めて欲しそうですね)
- Androidはどのバージョンまでサポートするか
- 非GooglePlay端末はサポートするか(XiaomiStore対応、などもありますが国内の非GooglePlayのHuawei端末のサポートなど)
- Web版、あるいはデスクトップ版を作る可能性はあるか
- 想定されるユーザ規模
- 想定されるリリース地域
- 欧州向けならGDPR対応必須
- 多言語対応は予め考慮しておくと良い
- アプリ特有の要素があるか
- 後述するように、例えばDRMを採用したり、実績のないライブラリの採用など
- この場合はPoCの期間を別途設けるか、専門家の招聘を検討してください
- ユーザのログインは何を使うか
- クラッシュレポートやAnalyticsは何を使うか
- アプリの暗号化やアンチチートはどのくらい行うか
- 難読化だけでよいか、Pairip protectionsなどを入れるか
- マネタイズ手段は何か（最近のiOSアプリはストア課金以外を許容します！決済SaaSを使うかどうか）
- 使うクラウドインフラサービスが何か（Google CloudだとMainland Chinaでリリースできない、など）
- SaaSを何か使うか、使っていけないものはあるか
- ユーザグロース系
- AB Testは使うか
- サーバスイッチは使う可能性はあるか
- メンテのシステムはどうするか
- 無停止のみ、と言われると身構えます
- メンテのAPIだけ独立した仕組みにしておくと良い（サーバをメンテしててメンテAPIが使えない、というジョークがあります）
- 強制アップデートは必要か
- 往々にして絶対に必要になります
- 管理画面は必要か
- 管理画面Webは誰が使うか（エンジニアなのか企画担当者なのか）
- 例えばユーザ通報やお問い合わせ窓口用に別の管理画面は必要か
- プッシュ通知は何を使うか
- 全体プッシュ通知だけでなくユーザ層別の通知を使うか、個別ユーザ通知を使うか
- ローカルプッシュ通知は使うか（つまり、スタミナが回復しました！とかです）
などをヒアリングしておきましょう。
また、これらが不確定の場合はやや余裕を持った見積もりを立てるようにしましょう。
そして商用アプリの場合は
- 宙に浮きがちなタスク
- ユーザ規約などは誰が決めるか、いつ決めるか
- ストアページのスクショや文言は誰が作るか、いつ決めるか
- LPやサービスサイトは誰が作るか、いつ作るか
- SNSアカウントは誰が作るか、だれが運用するか
- キャンペーンを行うなら、どのようなものが想定されるか
- 個人情報を預かるか、預かるなら個人情報保護は開発者も見えないようにするべきか、規約はどうするか
- セキュリティ診断はどのようなものを行うか（アプリ、サーバ、インフラそれぞれの想定人月を計上して、それを超える場合は追加発注を行う、という形にしておくとスムーズです）
- 負荷試験はどのようなものを行うか（もし行わない場合、勘で見積もることになって非常に危険です）
- QAはどのようなものを行うか（もし行わない場合、雰囲気で安定動作を確保することになって非常に危険です）
- 試験の粒度とエビデンスの様式についても合意を取っておきましょう。一番無難なのは人月で計上して、それを超える細かさや回数の場合は追加見積もり、としておくことです。
- 特に外部システムとの連携、たとえば他サービスとの相互送客などは見積もりしにくい点です。
- ユーザテストはどのタイミングで行うか（もし行わない場合、致命的な導線の欠如やわかりにくさについて気付けないです。開発中期には行うことをおすすめします）
- SLAの大雑把な要素（24時間監視するのか、平日昼間のみか、信頼性はどのくらいを要求するか、つまりマルチAZなどをやるか）
- サービスイン後の運用体制
- 自分たちで保守するのか、別の人たちが保守するのか
- 監視体制は平日昼間で良いのか、毎日か（SLAと被りますが）
- どちらにせよ、監視しやすい仕組みを作っておくと良いです(最小だとAWSでCloudWatchとCloudTrailとかでポチポチしましょう)
などについて、相手が「えええ、それも必要なの？？？」とうんざりするかもしれませんが根掘り葉掘り聞きましょう。
この時点で「どう考えてもキツキツなスケジュールや予算だよね…」という雰囲気が出てきたら、何を諦める、サボるかを相談しておきましょう。そしてログを残しておきましょう (未来のあなたが助かると思います)
開発初期
少なくともアプリのモックで良いのでfigmaでもvibe codingでもいいので超特急で作りましょう。
相手がイメージしやすくしてあげましょうね。
インフラの構成まとめ
どこで負荷を吸収するか、どこはスケーリングができそうか、どこが刺さって死にそうか、などの見積もりを立てておきましょう。
典型的なバックエンドシステムは先人がAWS構成図を出してたりするので、調べる努力をしましょう。
(特に昨今はDBの選定をミスると大変になりがちなので、お値段と想定負荷からいい感じのものを選定しましょう
開発環境整備
- あとあとで効いてくるので、開発環境、検証環境、本番環境を（最低でも開発と本番）用意しましょう。
- コーディング規約やリポジトリのレビュー体制、CI/CDについては開発初期から用意することをおすすめします。社内有識者に手伝ってもらうことを強く推奨します。
- アプリ固有の技術について（たとえば映像を扱うなら著作権保護のDRMや、リアルタイム通信を行うならリアルタイム通信サーバとプロトコル、XR系なら固有の審査基準など）早めに要素を洗い出して目処を立てておきましょう。これも社内有識者に手伝ってもらうことを強く推奨 します。
開発中期
認証系やマネタイズ系、サーバ側は正常系を作り終わったくらいです。仮の素材を駆使して、一応アプリの正常系のコア機能が動くくらいの段階をイメージしています。
ストア審査に出す
正常系が動いたタイミングで一度ストア審査に出しましょう。
そうすることで本番向けサーバがデプロイ可能であること、ストア情報が確定すること、など副次的にうっかり抜けてると困りそうなことに気付けます。
各種診断向け情報をまとめる
- セキュリティ診断
- 負荷試験
などはこのタイミングで回し始めることをおすすめします。出来上がったアプリを診断してもらうより、診断担当者と伴走しながら作り上げる方が良いです。
課金やログインのテスト
課金はサーバ側のレシート検証も必要で、Sandbox検証が必須だったりするので急いでここでやりましょう。
インフラコストの見通しを出す
おおよそのランニングコストが出せるタイミングとしてはこのあたりかも。
キッチリした感じじゃなくて良いので月間10万人利用だと30万円くらい。100万人利用だと60万円くらい。などを明らかにしておくと安心です。
開発終盤
QAやセキュリティ診断、負荷試験を回しながら各種対応を進めていきます。
この時点で便利ツールを作っておいたり、管理画面を便利にしておくと大変嬉しいです。
最後に
こういうノウハウがあんまりない状況で困ってたら、わかってる人を助っ人で呼ぶと良いです。
お仕事は募集していませんがスポット料金で相談に乗る、くらいは（僕含めて）多くの人が対応してくれると思います
より開発者側にフォーカスした記事として以下も参考にすると良いと思います！
プロジェクト管理のタスクリスト
https://qiita.com/nsym__m/items/fdc0cece2ac7f888fadb