自分がやっているiOSアプリの受託開発をするうえでの開発フェーズとフローのまとめです。クライアントから案件の依頼があり、見積→契約成立→要件定義→設計→実装→テスト→検収作業という流れです。
| フェーズ | カテゴリ | 内容 |
|---|---|---|
| 見積 | Q&A | 企画書や画面イメージ、参考になる他アプリを提示してもらえるか |
| 見積 | Q&A | 細かな仕様の要件がある場合はRFP（Request For Proposal:提案依頼書)があるか |
| 見積 | Q&A | iTunes Connectを利用してアプリの更新を行うAppStoreのアカウントについて整理 |
| 見積 | 明記すること | 機能一覧 |
| 見積 | 明記すること | 見積有効期限 |
| 見積 | 明記すること | 動作確認するiOSのバージョンや端末を前提条件に |
| 見積 | 明記すること | 納品完了（検収）条件を見積書前提条件に |
| 見積 | 明記すること | リジェクト時対応 |
| 見積 | 金額 | |
| 要件定義 | 要求まとめ | リリースするiOSアプリの目的、何をもって目的達成（ダウンロード数や会員数増加）とするか |
| 要件定義 | 要求まとめ | 機能一覧に優先度を付ける |
| 要件定義 | 方式検討 | 技術的な課題がある部分のプロトタイプの作成 |
| 要件定義 | UI | 画面イメージやワイヤーフレームの検討 |
| 要件定義 | UI | デザインを発注 |
| 設計 | 内部設計 | SQLiteのDB設計またはCoreDataのエンティティを設計しておく |
| 設計 | 開発指針決め | NSNotificationやdelegate, blocksなどを利用する場合はあらかじめ方針を決める |
| 設計 | 開発指針決め | ライブラリの選定 |
| 実装 | 環境 | 接続するサーバー環境を切り分ける場合はDEBUG, RELEASEマクロ定義などで分けられるように |
| 実装 | CI | Jenkinsを使って楽を出来るようにする |
| 実装 | 実装中の提案 | 仕様の曖昧な部分に対して提案しながら確認 |
| テスト | 異常系 | 通信速度制限 |
| 検収 | 受け入れ | 発注側に問題ないかを確認してもらう |
| リリース | リリース準備 | iTunes Connectに登録するアプリ情報やスクリーンショットを決める |
それぞれのフェーズの詳細を書いておきます
見積フェーズ
見積り用のQ&A
見積フェーズでは発注側に企画書や画面イメージ、参考になる他アプリを提示してもらい見積金額を提示します。見積用の資料としてRFPがあれば曖昧な仕様にならずに見積もりを行うことも出来るかもしれませんが、発注側がRFPを用意してくれることは稀です。もし発注側が大手で契約を頻繁に行なっているようであればRFPを作成して頂くほうがスムーズに進みますとダメ元で言ってみるのも有効です。
そもそも、発注側はまずは規模感を知りたい、他社と比較したい事が多く、技術的に難しい場合があっても大きな工数や金額を出してしまうと話が進まなくなってしまうので、見積書には技術的に課題があるポイントや開発する上でのリスクを明示し、それを説明し工数・金額の数字の妥当性を理解してもらいましょう。またこの段階で仕様認識の齟齬がある場合も、上記のやりとりで早めに齟齬をなくすようにするのが良いでしょう。
早めにクライアントの予算も確認したいところですね
参考：
【はてな匿名ダイアリー】やり手クライアント VS 初心者SEの場合
- 対応させたいiOSのバージョンはiOS6からかiOS7からか- iPadも専用に対応させたいか（もしくはiPhoneと同じ見た目で良いか）- 企画書や画面イメージ、参考になる他アプリを提示してもらえるか- サーバーと連携する必要があるか
- 細かな仕様の要件がある場合はRFP（Request For Proposal:提案依頼書)があるか- アプリの申請を行うのはどちらか- 納品完了（検収）条件は何か（開発期間、アプリの検収、ソースコードの納品、AppStoreでのリリースのいずれか）
参考に2014年1月末現在でiOSの利用率はiOS7が80%、2013年12月1日はiOS7が74%だった旨も伝え判断基準にしてもらうと良いかもしれません。
見積書に明記してはっきりさせておく事
見積有効期限
提出することになる概算見積もりはあくまで概算です。詳細見積のための打ち合わせを重ねているうちに明らかになっていなかった仕様が出てきたりもしますので、見積書には見積有効期限を明示することで、提出した概算見積もりから再度詳細な見積もりを出すことを念押しすることができます。
動作検証
また、動作確認するiOSのバージョンや端末を見積書に明記しておくことで、あらかじめやるべきことに線引をすることができます。当然、新しいiOSや端末が出た場合は別途見積をしその動作確認をすればよいのであって、そのiOSのバージョンや端末だけで動作すればいいようなプログラムは作るべきではありません。
納品条件
- AppStoreでリリース
- AppStoreへの申請。発注側にソースコードを納品（発注側のsvnもしくはgitへのコミット）
- 稼働日での換算
- レベニューシェア
1はAppleの審査によってリジェクトされると納品できない状態になるため、もし金額を多めに交渉できるとしてもまったくオススメ出来ません。Appleの審査に通ると思える仕様変更を手探りで行う場合もあり、審査方針の規約変更になど心理的に負担が大きくなります。
2は申請できる状態になった=発注側の受け入れで問題がなかったという状態なので審査に依存しないため1よりはオススメです。また、ソースコードの納品形態として発注側のsvn/gitにコミットして納品完了とするパターンもあります。
3は受託というよりも業務委託のパターンです。このパターンでは仕様変更や追加などについて稼働日が変わらなければ再見積ができない、つまり開発者の努力によって貰える金額が増えないためオススメしません。
4はやったことがないので分かりませんが、開発側で判断する材料として企画が優れていてリリース後に回収できる見込みがどのくらいかという目安を計算する必要があるでしょう。発注側に有利なので、開発側はその他の条件を交渉しやすい気もします...。
リジェクト時対応
リジェクトされた場合に、作業に再見積が発生するのかなど想定しておくのもよいでしょう。開発側の不適際なのか、発注者の要求などで仕方がなかったのか等で切り分けることになりますが、あらかじめリジェクト事例を別途提示すると親切です。リジェクト事例を持ち合わせていない場合は、最低予算1万ポイントで。iPhoneアプリの審査でリジェクトを食らった事例をお教えくださいなどのリジェクト集を発注側にも情報共有しておくのもいいかもしれません。
金額
見積で算出する数値は、機能ごとの工数とし、その工数を金額に変換したものを提示しますが、見積する工数については見積ポーカーと2点見積を複合したやり方で見積を行います。それらのメリットを詳しく知りたい場合は【PDF】ゲーム開発 プロジェクトマネジメント講座 - SQUARE ENIXを参照してください。
AppStoreで公開するためのアカウントについても、あらかじめ整理しておく必要があります。発注側にソースコードを渡せば全てやってくれる場合もありますが、こちらで代理として申請を行うのか、こちらのアカウントを使って全ておまかせで公開するかなど細かいことですが見積に関わってきますので確認しておきます。
要件定義フェーズ
要求まとめ
発注側とコミュニケーションをしながらリリースしようとするiOSアプリの目的やそのための要求を詰めていくフェーズです。要件定義として打ち合わせを行い、要求を優先度順にまとめるなどドキュメント作成作業の間、技術的に課題がある部分を洗い出すためのプロトタイプ作成を進めておくことも重要です。
方式検討
また、複数の方法で設計と実装が出来る場合、発注者に方式検討のメリットデメリットやそれらの方法を選んだ場合の制限を提示しましょう。方式検討はメリットデメリットをわかりやすくした表にすることが有効です。トラブル時などに、なぜこの方法を選んだのか、もうひとつの方法を選ばなかったのかということをすぐに振り返ることもできます。
UI
画面の要件決め
発注側と開発側で画面イメージやワイヤーフレームをさらに詳細にしていく際には、必ずAppleの[【PDF】iOS ヒューマンインターフェースガイドライン](iOS ヒューマンインターフェイス ガイドライン)を参照するようにして下さい。これは使いやすいアプリのためのドキュメントでもありますし、ヒューマンインターフェースガイドラインに沿っていないことでリジェクトされるのを防ぐためです。
デザイン
デザインの発注が必要な場合、慣れているデザイン業者に頼むのが一番楽なのですが、発注者がiOSアプリのデザイン経験がないデザイン業者に発注する場合など、どのように納品物定義をしていいかわからないこともあるので、その場合は【Qiita】iOSアプリ開発でアプリデザイン経験のない人にデザインの納品物をお願いするときのリストを参考にしてもらうようにしましょう。
設計フェーズ
内部設計
SQLiteを使うのであれば、テーブル定義書を残しましょう。他にはNSUserDefaulstsを素直に使わない場合や、ファイル保存が必要になったが、圧縮したり分割したりする場合など、コードを追えば分かるものの、なぜそのような設計をしなければいけないのかという理由を明記されていると嬉しいものです。
開発指針
設計フェーズではざっくり言うとiOSアプリをどのように作っていくかを決めますので、外部ライブラリの選定や、開発指針（NSNotification, blocks, delegateをどのような場合に使うかなど）を固めておくのも良いと思います。開発指針に関しては開発メンバーの力量を加味したり、優先度をあらかじめ決めておくと楽でしょう。
次のトピックが参考になります。
【Qiita】nilとNSNullの違いとNSNullをnilのように振る舞うようにする
また、要件定義フェーズで決まりきらなかった内容や後回しになった事を設計と並行して決めることになります。異常系の動作仕様などは、優先順位が低く要件定義フェーズに時間的余裕もない場合も多いでしょうから設計時に決めても良いでしょう。実装フェーズに入ってからでも問題ない場合が多いのではないかと思います。
実装フェーズ
実装フェーズでは前のフローで決めきれなかった異常系の処理や、曖昧な仕様のままの正常系の処理などを決めなければいけなくなるはずです。そのような部分は大抵イレギュラーな動作だったりクライアントの判断がつけづらい事であったりするため、都度都度クライアントにどのような仕様を望んでいるかを確認していては話が進まないことも多いでしょう。ここでも開発側であらかじめ提案できるドキュメントまたは実装を進めてから問題があるかの確認をするほうが良いでしょう。
実装中の提案
UIの改善に関しては、開発者のほうが最近のアプリを日常的にも使っていて同じ事が簡単に出来るよと提案が出来ることも多いと思います。【Qiita】UIWebViewの上下フリックでツールバーを表示したりしなかったりのようなあっさりと出来るテクニックはさくっと実装してクライアントに確認すると喜ばれますのでお勧めです。
テストフェーズ
ネットワークが関係するアプリの場合、テストには必ず通信速度を制限して行いましょう。【Qiita】iPhone実機(iOS6.x)で通信速度を制限するが参考になるはずです。
検収フェーズおよびリリース準備
審査用にiTunes Connectにあらかじめ各種情報を登録することができます。最終的にアプリをXcodeを使ってアップロードしますがあらかじめ登録をしておくほうが良いでしょう。
おわりに
他にもこんな事をやったほうが良いとかその順序でやるのはセンスがないわー、とかアジャイルだともっとこうなるわーとかあればコメントに書いていただけると楽しいかなと思います