Android案件を見積もる場合に考えておくことリスト

アプリ自体のコーディング見積もりのみに注力してしまうと忘れがちで、たまにつらい目に遭うので、必要に応じて追加していく予定。

アプリ仕様

仕様はそもそも決まっているか

「仕様は決まっている。動かない」「移植なのでこれ以上はありません」と言ったな。
それは嘘だ。

既に仕様がガッチリ確定していることはありえない。要求仕様（必要機能リスト）がある程度固まっているならばまだ良い方で、「今から仕様を一緒に考えていきましょう」「アイディアレベルです」まで様々。

その他にも、GCM/FCM等のアプリ外サービスと連携する場合、遅延コスト等どの程度許容できるかも事前に確定させる。特にプッシュ系サービスでは、ありえないレベル（全端末遅延1秒以内必須、とか）を既定路線に含めないように留意する。

改修か、新規開発か

これは見積もりの前提として大きな影響力をもつ。

テクノロジーや設計の自由度・柔軟性をある程度コントロールできる新規開発と違い、改修は既存コードとの互換性やメンテナンス性に大きく左右される。

ファミコン版FF3が「コードが高度すぎて移植不可能」と言われたように、あまりに高度すぎる（逆に低品質すぎる）既存コードの改修は簡単に予算を倍々ゲームにするパワーを持っている。

もし改修であるならば、できるだけ早いうちに見積もりに関する契約（機密保持など）を結び、ソースコードを手に入れ、内容を確認すべきだ。

それができないのなら、「すべての機能を新規で作る」判断をする程の見積もりを提出するしかなくなってしまう。

「既に既存コードがあるから、ちょっと機能追加するだけなら簡単でしょ？」と言われたのなら、「簡単かを決めるのは開発者であり、企画者や営業ではない」と言い切ってしまおう。

「クソの富士山のようなソースコードを、クソの山のまま改修することが必須条件」となり、新規開発を受け付けないというパターンもある。これは早期撤退・そもそも案件から手を引くことも考慮に入れたほうがいいかもしれない。

政治的要素をクリアできるか

お金が絡むところには、大なり小なりの政治が絡んでくる可能性がある。
例えば「特定の技術（サービス）を必ず使わなければならない」等だ。その場合、「その技術（サービス）にはこのような制限があるから別なものを選択しよう」ということが出来なくなる恐れがある。

最悪の場合には、「政治的な面をクリアするために、既存コード（過去資産）が流用できなくなる」という点も起こりうる。

政治的な要素は、一介の開発者の意見で覆ることは少ないため、プロジェクトの可能な限り早いうちに聞き出し、反映を行おう。

Google Playの規約に則っているか

アプリ名

アプリ名に"Android"や"アンドロイド"、さらには"あんどろいど"から始まる語句が含まれていると、Googleのリジェクト対象となる。それらをGoogle Playでリリースしたい場合、事前にGoogle Playの規約及びアプリ名のすりあわせが必要となる。

また、アプリ名が多くの文字列に含まれている場合は全てのリソースのチェックも行う必要がある。

著作権

Google Playでリリースされるアプリが著作権を侵害していないか、Googleは機械的に巡回してチェックしている。
自社が正しく著作権を保持していることを示す書類（ライセンス保持者との契約書等）を事前に用意したり、BANされた場合の保守サポートについても見積もりに含める必要がある。

アプリがGoogleによってBANされた場合、最大で72時間程度アプリは配信不可能になる。それに対して発生した損害をどのように処理するか、契約段階で決めておいたほうがトラブルになりにくいと思われる。
（特に土日を挟んでしまい、BANに気づかなかった場合、配信できない期間は増大することになる）

Androidバージョン

サポートすべきAndroidバージョンは、あらゆる条件の前提になるので、必ず最初に確認する。
開発のしやすさ、予算、配布規模等で異なるので、案件ごとに議論が必要となる。

Androidは、メーカー各社がほぼ間違いなく独自のカスタマイズを行っている。そのため、それに起因したバグやレイアウト崩れに対応するコストが間違いなく発生する。

契約時、サポートするOSバージョンと共に動作保証端末も設定する方が良い。逆に、動作保証外端末の場合は別契約（もしくはサポート外）とする。

• ざっくりとした切り捨てライン

| 必要機能 | OSバージョン | 特徴 | リファレンス | ヤバイ検証機 |
| --- | --- | --- | --- | --- | --- |
| - | 4.0.3 | 2011年発売端末まで広くサポート。機種依存たくさん | - | Galaxy S2/S3 |
| V-Sync | 4.1 | 描画の滑らかさが必要ならこのライン | - | Galaxy Note |
| BLE / GLES 3.0 | 4.3 | 機種によっては搭載してたりしなかったり | Galaxy Nexus | Galaxy S3a |
| 開発しやすい | 5.0 | 一部Drawableの追加が不要になる | Nexus 7(2012) | Zenfone |
| 忘れて差し上げろ | 2.x | 忘れて差し上げろ | 忘れて差し上げろ | Googleですらサポートを完全に打ち切った |
| 忘れて差し上げろ | 3.x | 忘れて差し上げろ | 忘れて差し上げろ | 忘れて差し上げろ |

端末ごとの苦労ごと（思い出せる分）

| 端末名 | 内容 |
| --- | --- | --- |
| Galaxy S2 | 「Galaxy S2でバグが出ました！」 → それはS2無印か、S2 LTEか、S2 WiMaxか？|
| Galaxy S2 | Galaxy S2だけレイアウトが崩れる（当時としては普通だが、現代としては超低dpi） |
| Galaxy S3 | 「Galaxy S3で動きますか？」→ 「S3aならインスコできます」→「S3にインスコできません」→「それはS3であってS3aではない」 |
| Galaxy Note | 単純にくっそ重い端末 |
| Galaxy Nexus | 特定条件下のテクスチャが原因でアプリが無言で死ぬ |
| Zenfone | x86、64bitのように見えて実は32bit、Android 5.0、独自デザインのUI |
| 殆どのSnapdragon機 | BLEで重大な不具合。普及してるので対応が厄介 |
| Nexus6p | EGL周りに依存挙動があり、複数スレッドからテクスチャロードすると死ぬ可能性がある |

アプリデザイン

アプリデザインは2016年現在、大きく４種類に分類できる。

1. マテリアルデザインを踏襲する
2. 旧来のHoloデザインを踏襲する
3. iOSのような見た目を追求する
4. そんなのかんけーねー。独自のデザインを使う

下に行くほどデザインコストは大きく見積もる必要がある。
Material Designは多くのライブラリも、たくさんの情報も溢れている。Holoデザインも、情報が多い。
iOSデザインは、世界中の開発者がつらい目にあってるので、まあライブラリが無いわけではない。
独自のデザインの場合、全てを１から作るしかないので一番大変な目に遭う。よって、工数もそれなりに追加しなければならない。

最も大変なパターンとして、OpenGLやCanvasを使って本当に1から（既存のViewパーツを使用せず）構築したこともある。

デザイン自体を別な会社に発注しているケースが有る。その場合「こんな感じで作ってね」とPNG画像だけが送られてくる場合がある（レイヤー結合されて！）。
デザイン会社が別に存在する場合、Androidアプリリソース作成ができるのかの確認が必要となる。誰がDrawableリソースを作るのか（Photoshopから切り出すのか）は見積もり時点で確定させておくほうが良い。

Runtime Permission

ちゃんと最初に仕組みや遷移を作っておかないと、色んな所で権限周りの問題が出て、実質的にtargetSdkVersionを22固定ということになりかねない。将来的なアップデートに不安が出るので、長い目で見れば必ずRuntime Permissionは対応しなければならない。

が、それなりにコスト（テストも）かかるし、例えばカメラアプリなのにユーザーがカメラ権限をリジェクトしまくったらどうする？みたいなチェックを延々と考えないと行けないので仕様的な（企画的な）問題も追加する。

辛いので、ちゃんと期間と予算に盛り込もう。

画面分割（for N）

Android Nからは画面分割ができるが、サポートするとonPause/onResume周りで問題が多分起きる（あと画面リサイズも）ので、それに対するテストや例外対応についても契約時に盛り込んだほうが良いだろうね。

まだPreviewなので、実際の開発でどういう扱いになるかはわからないけどね。

縦横レイアウト、Phone/Tabletレイアウト

Androidは縦横レイアウトを変更でき、さらにPhone/Tabletでも切り替えが行われる場合がある。
大雑把に下記のテーブルにしたがって工数を見積もる必要がある。

縦横共通レイアウトで、かつ縦横切替時に特別な処理が要らない場合は、Manifestのorientation changeで簡易対応で済ませられる場合がある。

縦横対応	縦横別レイアウト	Phone / Tablet切り分け対応	対応コスト
無	無	無	無
対応	無	無	Manifest変更で簡易対応可能
対応	対応	無	デザインコスト増
対応	無	対応	プログラム / デザインコスト増
対応	対応	対応	プログラム / デザインコスト大増

Android Nから 縦横という概念自体がなくなる ので、デザイナーが対応できるかも考慮が必要。(-land就職子はdeprecated。-sw320などを使う)

WebView有無

WebViewをアプリの一部として使う場合、レイアウト崩れを誰が解決するかを確定させておく必要がある。Android 4.3以下、4.4、6.0でそれぞれWebViewの挙動が多少変わったため、必ずOSバージョン選定と一緒に、WebViewの挙動チェックを行う端末も選定しておく。

「既存コンテンツをWebViewで表示する」案件

これは多くの場合炎上する。

なぜなら、そのように「既存コンテンツを再利用」するということは、モバイルコンテンツに対するコスト意識が希薄で、「簡単に考えている」からだ。

大抵のリスク説明は「そんな風には考えていない」「簡単でしょ」とと言われる傾向にある。

例えばレイアウト崩れの問題があり、例えばコンテンツ間の結合であり、例えば外部コンテンツへの誘導のハンドリング（SNS投稿機能なんて普通にあるよね？）であり、場合によってはJavascriptの連携を増設しなければならず、なおかつ誰がそのコスト（仕様策定も含めて）を払うかを意識していないことがほとんど。

「既存コンテンツ」は別なチームが開発している場合もあり、その場合の連携コストも発生する。「既存コンテンツ」の開発チームが何らかの理由で協力できない場合もありうる。

Web用のヘッダ・フッタとアプリ用のヘッダ・フッタは全く異なる構成を求められるが、誰がそれを作るのか。要求仕様を誰がまとめるのか？

結論として、「同様のAndroid nativeアプリを作る程度」のリスクは覚悟しなければならない。有り体に言えば、「WebViewだけのアプリ」を持ってくるのは巨大な地雷である。

サーバーAPI開発有無

サーバーAPIを必要とするアプリで、誰がサーバーAPIを開発するかによって当然だが考えるポイントが変わってくる。
サーバーAPIの開発までセットで請ける場合はサーバーAPI開発要員のコストが必要。運用コスト節約のため、BaaSを使うという提案もできる。お客さんで開発する/すでにiOS版のがある場合は、「いつまでに提供されるか」「ステージング環境はあるか」などの確認が必要。

フォントサイズ変更をどこまで対応するか

Android 4より、アプリユーザーがフォントサイズを変更できるようになった。アプリユーザーが大きなフォントを選んだ際のレイアウト崩れをどこまで許容するかは仕様検討時に盛り込んでおく。

「バッテリーの持ちがいい端末」対策

市販されている端末の中には、「バッテリーのもちの良さ」を宣伝している物があります。

Androidシステム標準が提供している省電力（Doze等）以外にも「独自のカスタマイズ」を宣伝している場合、ターゲット端末から外す、もしくは個別対応とすることを検討したほうが良いです。

例えば、Huaweiの一部の端末ではServiceのForeground化が行えない（正確には、API的には使えますが、すぐにKILLされます。また、CPU WakeUpも無効です）ため、一部の重要なServiceを常駐することができません。これは業務用アプリでは致命的になる恐れがあります。

依存ライブラリ

Androidアプリ開発ではOSSライブラリを複数個組み合わせる必要がある。アプリデザインにはライブラリの「権利表示」を必ず含める必要がある。

ただし、アプリのそもそものポリシーとして「OSSライブラリ使用禁止」というプロジェクトも存在しないわけではないので、必ずプロジェクト開始前にチェックすること。

Apt / Multi Dex / Debug-Proguardの有無

上記ライブラリは便利だが、ビルド時間が飛躍的に大きくなる。開発において、一度のビルド時間が長くなるため、インストール -> 実行のイテレーション回数が少なくなる。開発時の「待ち時間」が長くなるため、既存アプリの改修では必要に応じてコストを高くする。

PC性能で殴れるなら良いが、そうでない場合は致命的となりうるので注意する。

写真撮影の有無

写真を撮影/ギャラリーから選択機能がある場合、アプリ内でカメラ機能を実装するか、Intentを投げるだけでよいかは工数に大きく影響する。アプリ内で実装する場合、Android 5以上をサポートするのであればCamera2のみでよいが、そうでない場合はバージョン分けが必要。

旧カメラAPIだけサポートで問題ないか、その場合将来的にカメラAPIが削除された際の責任についても確認する。

GPSの有無

GPSを使う場合、検証で外を歩く場合がある。その場合、開発機材を持って出歩かなければならない場合があるので、「お出かけ時間」を開発時間に盛り込む必要がある。特にライフロガーのようなアプリやジオフェンシングの実地検証が必要であれば留意が必要。

TextureView+GLの有無

TextureViewにはメモリリークの不具合があり、大なり小なり時間と共に確実にリークする。
アプリの仕様上、どうしてもTextureViewが必要な場合はメモリリークの恐れがある点の説明と、不可避な点の同意を取る。

Android 8.0以降のputExtra仕様

独自にimplementsしたParcelableをputExtraして、Intent.createChooser()するとClasNotFoundExceptionで落ちるようになりました（Pixel2, Xperia XZ1Compactで確認）。

既存プロジェクトの改修の場合はこの処理が入っている場合は注意です。
また、サードパーティ製のSDKがこういったことをやっていないことも確認したほうが良いでしょう。

Proguardの有無

多くのプロダクトは「Proguard必須」と言われるが、Proguardは開発時とリリース時で意図しない挙動変化を引き起こす恐れがあるので、検証期間を追加する。

Proguard設定の書き方は度々変わり、かつ書き方が複雑なので、必要に応じて工数を取らなければならない。

開発環境

ビルド環境

新規の開発案件の場合、Android Studio + Gradle一択となる。

引き継ぎ案件の場合、未だにEclipseプロジェクトや、Antビルドのアプリは存在する。そのため、新規に開発を行う際にGradleプロジェクトへのマイグレーションコストを見積もる必要がある。

旧来のビルド方法と共存が可能であるため、渋い顔をされたらその点を説明する。

フォーマッタ

使用しているIDEや環境によっては、フォーマッタの内容が異なる場合がある。可能であれば、AOSP標準のフォーマッタを使用する。

引き継ぎ案件で、既に独自フォーマッタが適用されている場合はそれを最初に共有する。また、プロジェクトの最初に全ソースコードにフォーマッタを適用する。

フォーマッタが無いプロジェクトの場合、かつフォーマッタ導入が行えない場合、コーディングコストの増加を見積もる必要がある。

リポジトリ

2016年現在のデファクトスタンダードはGitだが、引き継ぎ案件では熟成されたSVNリポジトリを渡される可能性がある。その場合、Git-SVNを使うことで回避可能。

ただし、Gitをそのまま使うより管理コストが多少増える（複数人でやってると、たまにコンフリクトしたり、そもそもSVNからclone失敗することすらある）。多少なりとも管理コストは積むべきである。

IPアドレス制限

セキュリティ上の問題で、特定のIPアドレスからしか開発サーバーのAPIが叩けない場合やリポジトリにつなぐことができない場合がある。

アプリ開発する上では、3G/LTE回線でのテストがしにくくなるので、必要に応じてProxyを設定する等の工夫が求められる。特に新規でそのような事案が発生した場合は、追加の開発環境構築コストも見積もっておく。また、そういった回避手段をとっても良いかどうかも事前に確認が必要となる。

CI

githubで管理できるのであれば、Circle CI等のクラウド上のサービスを利用するのが楽で良い。納品物（プロジェクト.zipとか）もCI上で作成できる。

プロジェクトの都合により、Circle CI等のクラウドサービスが利用できない場合がある。その場合は社内等に立てたJenkinsで代用できる。基本的にはシェルが動作すれば、ほぼ同様に使用できる。

CIは構築するだけではなく、CI運用とワンセットであることにも注意する。例えば、「構築時に別プロジェクトから詳しい人を借りてくる」ような見積もりでいると、運用の変化（Deploy方法変更、開発環境のアップデート等）に対応できず、開発自体にも影響を及ぼす。

Androidの例では、AS2.x系列 -> 3.x系列アップデートでgradleメジャーバージョン変更と、それに伴うプラグインの統廃合がおきた。Deploygate等のサードパーティ製プラグインアップデート等で、Task名が変わる等の変化に対応する必要があるが、それができないならばAS3.xの恩恵を受けないままプロジェクトを進めるしかない。

プロジェクトにCI運用が行える人員がいることが望ましいが、そうでないならば社内で柔軟に対応できるように予算・スケジュール共に前提条件として組み込むべきだ。

テスト

テスト記述範囲

全ての処理に対して自動テストを書くのが理想的だろうが、テストの書きやすさはそれぞれのclassごとに異なるので、「書けるところは書く」「バグが出たところは追加でテストを追加する」程度の気持ちに抑えておく。

設計は可能な限りテスタビリティを考慮するが、気張り過ぎない程度にする。社内やプロジェクト参加者内でポリシーのすり合わせは行う。

CIでのテスト範囲

エミュレータや実機を使ったCIでのテストは謎の実行エラー等で「なぜか落ちる」ということを経験しているので、JUnitでできる範囲（Robolectricで流せる程度）は行い、それ以外はOptionalで考える（テストをしない、テストで落ちたら警告のみ出す、等）。

JUnitテストは安定して実行できているので、そこで落ちたら確実に直すことは心がける。

人力テスト

最終的には、アプリを実際に利用して正しく使えるかをチェックする。特に描画（見た目）周りで自動テストが困難な場合は必ず人間がテストに関わることになる。

アプリ規模に応じてテスト期間を見積もる。その際、その人力を誰がコストとして支払うのかを事前に確定させる。テスト仕様書をどの程度の粒度で書けばよいのか（適当に書いても程よくテストしてくれるすげーテスターもいる）も確認しておくと良い。

ドキュメンテーション

納品に対してドキュメントを求められる場合が多い。ドキュメント内容も粒度も様々なので、事前にどの程度の粒度や内容が必要なのかを確認する。ドキュメントは納品担当者やチェック部署のさじ加減で変わる（大きな会社ほど厳密さが増す）ので、おおよそ契約規模の正比例で考えておくと、ざっくりと見積もれる。

Excelと戦うコストを考える

そもそもMac使いが強い弊社では、Excelはレイアウト崩れとの戦いになりがち。そのためにWindowsマシンを使う（慣れてないOSとなれない作業なので、効率は悪い）ことも期間に見積もるべきである。

Wordと戦うコストを考える

全Classの解説一覧等、割りと「Javadocでいいのでは」と思われるものも、詳細なドキュメントが求められる場合がある。

Javadocと戦うコストを考える

「Javadocを出力し、規定の内容をヘッダに必ず含める」と言われる場合がある。多少なりとも出力にカスタマイズが必要な場合は最初に確認しておき、CI構築時に最初からやってしまうほうが楽である。

管理コスト

プロジェクトには打ち合わせがつきもので、それは「開発コスト」とは別に追加で見積もる必要がある。例えば、定例で週１回×２時間としても、１ヶ月で１人日は消費する。参加人数ぶんだけ、会議によるコストは増加する点を必ず考慮にいれる。

納品

納品物は相手会社によってポリシーが変わるので、それに合わせる。

• gitやSVNのリポジトリにコミットして納品とする
• apkのみを送付して納品とする
• プロジェクト一式をZIPでFTPにアップロードして納品とする
• プロジェクト一式を物理メディアに焼いて送付して納品とする

納期は動かせるか

あらゆる案件に納期はつきもの。
だが、その納期が動かせるかどうかは案件によって事情が異なる。
例として、「自社案件」であれば（損害は別として）動かすことはかなりあり得る。ゲームが良い例で、「3年1age」という言葉もある。
だが、動かせない案件は存在する。例えば、「受託」かつ「別なプロジェクトとの連動（物理的な動員を伴うGoogle I/Oのようなイベント等）」はどうやっても自社権限で動かすわけにはいかない。
その場合、十分な余裕を持って終了できるようなマージンを見込む必要がある。もし動かせないことが確定した場合、そしてそれが納期直前である場合は追加動員もできず、最悪の場合はアプリを「落とす」こともありうる。
そうなった場合はコストどころの話ではない。

納期が絶対に動かせないか、土下座で動くかは最初に見極め、必要な人員数や工数の見込みを調整する。

チェックリスト

• 仕様は決まっているか
  • 仕様確定や「相談」レベルにもコストがかかることを提示し、見積もりに含める
  • 政治要素があるなら、それも見積やリスクとして計上する
  • GCM/FCM等の別サービスとの連携の場合、遅延コストやサービス停止中の挙動について事前同意を取る
  • アプリ名に"Android"系の語句が含まれている場合、そのアプリ名を回避するか、代替案を用意しておく
• 新規開発か、既存コードの改修か
  • 改修ならば、ソースコードは見積もり前に入手・確認可能か
  • 既存コードに手を入れる（リファクタ等）は可能か
    • 不可能であれば、増築は可能か
  • Deprecatedなライブラリを使用していないか
    • Androidで言えば、Apache http等
• OSバージョンは確定したか
  • Runtime Permissionに対応するか
  • 画面分割に対応するか
• 検証端末は確定したか
  • ハードウェアに依存するもの（BLE等）は依存が大きいため、検証機の選定を厳密化する
• プロジェクトでOSS利用は可能か
  • デザインにOSS権利表記は盛り込んだか
• APT / Multi-Dex / Debug&Proguardを使用するか
  • 開発時の待ち時間が長くなることに留意し、必要に応じてコストを追加する
• WebViewを使用するか
  • 使用する場合、必要に応じてAndroid 4.3以下、4.4、6.0以降でそれぞれ検証機を選定しておく
  • 既存のコンテンツをWebViewでラップするだけか
    • だれが既存コンテンツの改修コストを払うのか
    • Javascript等の連携インターフェースの仕様は誰が策定するか
    • 外部連携が発生している場合、どのようにハンドリングするかは確定しているか
    • コンテンツ間のリンク構成に変更が必要か
    • ヘッダやフッタは誰がどのように表示するか決まっているか
• アプリにGPSを利用する必要があるか
  • ライフロガーやジオフェンシングの場合、実地検証コストを見積もる
• アプリでカメラ機能を使用するか
  • 他のカメラアプリとIntent連携するか、アプリ内で完結させるかを確認する
  • 他のカメラアプリと連携する場合、Intentの機種依存情報を確認し、必要であれば確認コストを積む
  • アプリ内で完結させる場合は実装の機種依存とCamera1/Camera2 APIの採用を確認する
• アプリデザインは確定しているか
  • 独自デザインの場合、それなりに工数を積んでいるか
  • デザインが他社で行われる場合、切り出しコストを誰が払うのかを確認しておくべきである
    • 切り出しを行ってもらう場合でも、Androidアプリリソースの作成経験（9-patch等）有無の確認は必要
    • Drawable / 9-patch / dpi切り替えを自分で行うのであれば、見積もりに含める
• 縦横レイアウト切替が必要か
  • レイアウト切替が必要な場合、レイアウトの切替がどのレベルで必要になるかを確認したか
  • 詳細な切替が必要な場合は追加で見積る
• ユーザーのフォントサイズ変更への追従を行うか
  • 追従を行う場合、レイアウト崩れをどの程度許容するかを確認する
  • 必要であればレイアウト確認・修正コストを多く盛り込む必要がある
• アプリにTextureViewが必要か
  • 必要な場合、メモリリーク不具合があることを説明・同意を取る
  • メモリリーク不具合に同意ができない場合、仕様自体を見直す
• Proguardを行う必要があるか
  • Proguard検証コストを見積もったか
• 開発環境にAndroid Studioを利用できるか
  • ASを使っていない場合、Gradleへのコンバートコストを見積もる
• プログラマでフォーマッタが統一されているか
  • フォーマッタが使用できない場合は、コーディングコストを高く見積もる
• ソースコード管理にGitを利用できるか
  • SVNの場合、管理コストが多少上がる恐れがあることを覚えておく
• 必要なサーバが稼動状態にあるか
  • 新規対応が必要な場合、誰がいつまでに行うかを確認する
• IPアドレス制限があるか
  • アプリ仕様として3G/LTEテストが必要な場合、代替手段を打ち合わせておく
• CIの構築先を選定したか
  • CIの構築コストを見積もったか
• 自動テストポリシーを確認したか
  • CIでの自動テスト内容と、実機やエミュを使ったテストを切り離して考えているか
  • CIでのテストポリシーを確定したか
• 人力テストのコストを見積もったか
  • どの程度の期間テストするか、テスターのコストを誰が支払うかを確定させる
• 管理コストを見積もったか
  • 打ち合わせコストを見積もったか
  • 打ち合わせにより、「コーディングできない時間が存在する」ことを考慮しているか
• 納品物や納品方法を確認したか
  • ドキュメンテーションコストを見積もったか
  • ドキュメントの内容や、規模を確認したか
    • 初めての取引先の場合は規模がつかみにくいので、サンプルがもらえない場合は多少多めに見積もる
• 納期は動かせるか
  • 動かない場合、余裕を持って終了するだけの人員・予算を見込んだか