新規アプリ開発を請け負う時の流れ #tips – Qiita

まずは、このご時世に新規のアプリ開発を出来るというチャンスに感謝しましょう。
もちろんすでにあるアプリの追加開発や運用で得られる経験値はとても素晴らしいですが、同じように新規開発も胸踊るものがあります。

あなたの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でもいいので超特急で作りましょう。
相手がイメージしやすくしてあげましょうね。

インフラの構成まとめ