スマートフォンアプリの受託開発で、特に見積の時点で気をつけておくべき話です。これらがあいまいだと必ず言った言わないのトラブルになりますので、不毛な時間を費やさないためにも事前に見積書や契約書に明記しておきましょう。
1. 対応OSとバージョン
まずは当たり前のところから。OS の対応バージョンです。特に iOS だと iOS6 と iOS7 の境目でビューの構成が変わっていて、バージョン一つの違いで結構な手間がかかる場合もあります。最低動作バージョン、推奨バージョンは事前にハッキリと決めておくべきです。
あとそもそもの要件が、iOS と Android のどちらの OS の話なのかハッキリ明記されていない場合は必ず確認しておきましょう。笑い話のようですが、iOS だと思っていた話が Android だったり、Android だけだと思っていたら両方だったり、ということも少なくはありません。
iPhone は iOS6 未満の端末の入手が困難ですね。今はダウングレードも出来なくなっていますので、最低動作バージョンについてはなるべく引き上げてもらうように、それが出来ない場合は入手困難端末の実機購入費も見積に含めてよいか交渉しましょう。
各 OS のシェアについての公式ソースはこちら。あまりにも古い端末が要件にあった場合はこの資料を元に説得するとよいでしょう。
- iOS https://developer.apple.com/support/app-store/
- Android http://developer.android.com/about/dashboards/index.html
さらに、スマホアプリとは言え最近はアプリ側で完結することは少なく、サーバにデータを置いたりいわゆる mBaaS 的な実装は不可避です。これら mBaaS 部分の開発は要件には含まれていないが、実は後から必要だった、ということが多く、納期前にサーバ側の開発も巻き取ることになるケースも少なからずありえます。サーバ側の開発リソースが社内で空いていれば良いのですが、その部分をまるっと外注することになれば赤字にもなりかねません。こちらも合わせて確認しておきましょう。
2. 対応デバイス
デバイスも重要ですね。iOS だと 32bit/64bit 両対応だと古いライブラリが動かなかったりということもあったり。Android だと市場に出回っている全ての端末の対応、というのは余程スケジュールに余裕がないと難しいと思います。
また、当然これらの対応幅によって工数が変わります。画面に関しては iOS でも AutoLayout が採用されたことで解像度固定で開発することは無いですが、意外とかかるのが実機検証工数です。画面よりも機種依存で発生するバグなど、特に Android はベンダー固有の仕様などでハマることが多く、戻しの工数が見積を超えることは多々あります。
あとは縦横対応も確認しておきましょう。縦画面だけだと思って安く見積り、よくよく仕様書を見たら縦と横で全く構成が違う、なんてことがプロジェクトの中盤で判明したら炎上不可避です。
3. デザイン
これも明記がないと担当範囲があいまいになりがちなパートです。最近は一口にデザインって言ってもそう簡単では無く、ボタンが作れる、キャラクターが作れる、というだけではダメで、UXの視点から画面構成を提案できるところまで出来ないと難しいです。これら提案も含めて請け負う必要があるのか、ちょっとしたボタンを作る程度なのか、そもそも標準のUIでよいのかどうか、もしくはデザインは別の会社に発注となるのか、といったところを確認しておきましょう。
iOS/AndroidでUIを統一するかどうか。各OSの作法に沿ったUIかどうか。特にiOS/Androidのガイドラインを無視したデザインが上がってくることがあるので、デザイナさんに事前に確認してもらった方が無駄な工数が発生せずに済みます。
-
Apple Human Interface Guideline
https://developer.apple.com/library/prerelease/ios/documentation/UserExperience/Conceptual/MobileHIG/ -
Design | Android Developers
http://developer.android.com/intl/ja/design/index.html
あと、デザインを請け負う場合でなくても、先方や他社のデザイナさんからPSDでデータを納品してもらう場合は Photoshop や Illustrator で画像を切り出す工数も含めておきましょう。切り出しは意外と工数かかるものです。
4. スケジュール
当たり前ですがスケジュールはちゃんと確認しておきましょう。リリース日すら決まってないのに見積を出すと後から後悔することになるでしょう。通常、稼働時期によって金額は変わるものです。弊社の場合非常にタイトなスケジュールの場合は特急料金を設ける場合もありますし、他の案件が重なりやすい時期は繁忙期の料金設定で提供させていただく場合もあります。
また、デザインデータが先方または第三者から提供される場合、それがいつ届くのか。届いてから何営業日にその機能が完成するのか。届かなくても進められるところがあるのか、デザインが遅れた場合は開発期間も後ろにずれるのか、ということは最低限確認しておきましょう。先行タスクであるデザイン作業が遅れることで、そのタスク待ちの開発作業のスケジュールが圧縮するのは避けたいところです。
5. 納品データ
通常は、ソースコード納品か、バイナリ納品かのいずれかになります。ケースごとに注意点が異なります。
ソースコード納品の場合
納品後のソースコードメンテナンスは発注元に引き継がれる可能性が高いです。なので、開発環境や実装手段については事前に細かく決めておく必要があります。
よくある決めごとの例として、
- コーディング標準。
- サードパーティ制ライブラリの使用可否。
- Eclipse か Android Studio など IDE の指定。
- Storyboardを使うべきかInterfaceBuilderかそもそもビューはコード書くべきか。
- CocoaPodsなどのパッケージ管理ツールを使ってよいか。
などがあります。これらの決め事を先方の開発スタッフと打ち合わせる工数も必要かもしれません。
バイナリ納品の場合
バイナリ納品の場合はわりと開発環境や実装手段を気にする必要は無いですが、リリースビルドバイナリ生成のための証明書を貰えるかどうか事前に確認しておきましょう。
バイナリ納品だがビルドはお願いされる場合
納品後に発注元でソースコードをメンテする気はないが、証明書を社外に出したくないのでリリースビルドは発注元でおこなう、というケースです。ソースコード一式を送って先方でビルドする必要があるので、CocoaPodsなどのパッケージ群もソースコード一式に含めておいた方が良いです。開発者でない先方の Mac に cocoapods の環境を作ってもらい、納品ごとに pod install させるのは面倒がられることが多いからです。
あと、これはソースコード納品でも同じですが、CocoaPods や Carthage などのライブラリ管理システムを使っている場合、それらのライブラリが削除されたり、リリースビルド時に GitHub が落ちているということも考えられます。そうなると納品漏れというトラブルにもなりかねませんので、ソースコードをgitに入れ、納品物に含めるようにしておく方が無難です。
6. ストア申請作業
これもなかなか見積時点では忘れがちです。いざ納品して「じゃ公開お願いします」と言われ、しかもよくよく聞けばデベロッパーアカウントすら取得していない、なんて事になったら最悪です。事前にどちらがどこまで行うべきかというところは確認しておきましょう。
作業としては、デベロッパーサイトへの証明書作成やアプリ登録、ストアへのスクリーンショット作成、場合によってはアプリ紹介文の文章作成なども。また、最近はスクリーンショットに訴求ポイントなどの文言を入れてポップな感じにデザインする場合もあり、こういった作業も誰がやるか、ということを明確にしておかなければなりません。
7. 定例・打ち合わせ出席
意外とバカにできない費用です。打ち合わせ頻度は予め確認し、見積には「週n日まで」と言った但し書きがあると良いでしょう。金額ですが、単に交通費というだけでなく、参加するための往復の時間、また、その定例での報告のために書類を作ったり、デモ版を作ったりというのは、地味ながらも積み重なって時間を取られるものです。2時間程度の打ち合わせでも移動やその準備に費やす時間を合わせると半日分以上の人件費は見ておいたほうが無難です。
8. 開発期間中のOSアップデート対応
iOSだと毎年10月にメジャーアップデートが行われますが、開発期間がこのタイミングをまたぐ場合、そのOSバージョンを含むかどうかで大きく見積と行程は変わってきます。10月中旬にメジャーアップデートがリリースされるのに対し、開発の納期が10月下旬だとしたら、中旬から下旬の間にアップデート対応が必要になります。これはさすがに品質に影響する可能性があるので、納期の調整か、外部の検証会社に出す費用も想定しておきましょう。
9. リリース後の保守
瑕疵対応期間を設けた場合はその期間内の明らかなバグについては無償での修正が必要な場合もあります。それとは別に不可抗力のバグが発生する場合があります。例えば OS のマイナーバージョンアップでの仕様変更や、Facebookなど連携サービスの仕様変更によって起きる不具合です。こういった変更は突然訪れるわけではなく、必ず提供元から事前にアナウンスがあります。こういった情報を常にチェックしてそのアプリに影響がないかどうかを検証しておけば回避できます。とは言え、これも無償で出来るわけではなく、こういったメンテナンスが必要なのであれば、初月から保守費用が発生する旨を事前に交渉しておきましょう。
ちなみに保守費用というのは、何も作業が発生していなくても支払われる費用です。（AppleCareなどと同じような追加保証といった感じです）。これは何かあったときに対応できるように常時人員を確保しているという人権費に近いものなので、今月保守作業が無かったから来月これだけの作業お願い、という繰越しは普通成立しません。
10. 案件の秘守義務
通常は事前に交わした機密保持契約の元、案件に携わった事すらおおっぴらに出来ないケースが多いです。ただ、受託専門の企業としては開発実績として大きなタイトルを紹介できれば、受注金額以上の利益をもたらす場合もあります。ダメ元で言ってみるのもアリでしょう。（ちなみに弊社では実績案件ということでの契約であれば若干割引させて頂くこともあります。）
逆にこういった約束事なしにうっかりSNSなどにアップした写真に開発中の画面が写り込んで機密情報が漏れるケースもありますので注意しましょう。
おわりに
先方にアプリのリリース経験があればよいのですが、そうではない場合には、誰が何をどこまでやるかが明確にならないまま物事が進み、最後の最後でトラブルになるケースが多い気がします。こうなったらもう誰も幸せになれないので、多少うるさく思われようが事前にきっちりと線引をしておくことが重要です。