オフショア開発の見積もりを受け取ったとき、最初に見るべきなのは金額ではありません。その金額がどの前提の上に成り立っているかです。
同じ要望を伝えても、会社によって金額が変わります。理由の多くは、含めている作業の範囲が違うことにあります。前提がそろっていない数字を並べても、判断の材料にはなりません。
この記事では、見積書のどこを、どの順番で読むのかを整理します。社内で説明するときの材料としてもお使いください。
オフショア開発の見積もりで最初に見るのは金額ではない
金額は結果です。先に読むのは、その結果を生んだ条件のほうです。
読む順番は次のとおりです。
前提条件がそろって初めて、金額を比べられます。逆に言えば、前提の書かれていない見積書は、読む材料が足りていません。その場合は、前提を書き足してもらうところから始めます。
見積もりを依頼する前に用意するもの
見積もりの精度は、渡した情報の量で決まります。情報が少なければ、相手は安全側に見積もります。その結果、金額は大きくなります。
次の資料があると、前提のぶれが小さくなります。
やりたいことの一覧。 機能の名前だけでも構いません。優先度を3段階でつけておくと、段階的な進め方の相談ができます。
現在の業務の流れ。 誰が、どの順番で、何をしているかです。図でなくても、箇条書きで十分です。
既存システムの情報。 使っている製品名、連携したい相手、資料の有無を伝えます。資料がない場合は、ないと伝えることが重要です。
利用者の規模。 同時に使う人数とデータの件数です。性能の設計に直結します。
時期の希望と、その理由。 社内の都合がある場合は、背景まで伝えると代替案が出てきます。
これらがそろっていれば、見積もりの前提は具体的になります。そろっていない場合は、調査から始める形で見積もることになります。
前提条件：どこまでが範囲で、どこからが範囲外か
最初に確認するのは、範囲の境界です。次の項目が、含まれるか含まれないかを明示してもらいます。
- 要件定義をどこまで行うか
- デザインの作成を含むか、支給されたものを使うか
- 既存システムとの連携の調査を含むか
- データの移行を含むか
- テストはどの範囲まで行うか
- 本番環境の構築と公開作業を含むか
- マニュアルや操作説明を含むか
含まれないものが書かれていない見積書は、後から差分が出ます。「含まれないもの」の欄があるかどうかは、見積書の質をよく表します。
とくに注意したいのが、既存システムとの連携です。資料がそろっていない場合、調査に時間がかかります。この調査を含むかどうかで、金額は大きく変わります。
データの移行も見落とされがちです。古いシステムから新しいシステムへ情報を移す作業は、件数が多いほど手間がかかります。形式が整っていない場合は、整える工程も必要になります。
金額に差が出る理由
複数の見積書を見ると、金額の幅に驚くことがあります。差が生まれる理由は、おおむね次の4つです。
ひとつめは、範囲の違いです。テストや要件定義を含むかどうかで、作業量は変わります。安い見積もりは、その分の作業が別途になっている場合があります。
ふたつめは、品質の前提です。どこまでテストを行うか、どの端末まで動作を保証するかで、工数は変わります。
みっつめは、体制の違いです。経験のある担当者を厚く配置すれば、その分の費用は上がります。代わりに、手戻りは減ります。
よっつめは、リスクの見込み方です。不確実な部分が多い案件では、余裕を含めて見積もります。情報を多く渡すほど、この余裕は小さくなります。
つまり、金額の差は多くの場合、前提の差です。前提をそろえれば、差の理由は説明できるようになります。
工数の根拠：何を数えた数字か
次に、工数がどう算出されたのかを確認します。
多くの見積書は、画面数や機能数を基に積み上げています。そこで、次の点を聞きます。
何を単位に数えましたか。 画面単位か、機能単位か、処理単位か。単位が違えば、同じシステムでも数字は変わります。
どの程度の複雑さを想定していますか。 一覧画面ひとつでも、検索条件が3つの場合と20の場合では作業量が異なります。
テストと修正の時間を含んでいますか。 実装の時間だけを積み上げた見積もりは、後半で足りなくなります。
管理と調整の時間を含んでいますか。 打ち合わせや進捗の共有にも時間がかかります。
国内の開発における工数や期間の実績は、IPAのソフトウェア開発分析データ集で公開されています。自社の案件と規模が近い区分を見ると、提示された工数が極端かどうかの感覚がつかめます。関連する調査はソフトウェア開発関連調査にまとまっています。
これらは市場のデータであり、特定の会社の金額を示すものではありません。あくまで、桁がずれていないかを確かめる目安として使ってください。
工数と期間は比例しない
よくある誤解として、工数を人数で割れば期間が出る、という考え方があります。実際にはそうなりません。
人数を増やすと、調整の時間が増えます。設計を共有し、作業を分担し、できたものをつなぐ手間が発生します。そのため、人数を2倍にしても期間は半分になりません。
また、作業には順番の制約があります。設計が終わらなければ実装は始まりません。この部分は、人数を増やしても短縮できません。
したがって、期間を短くしたい場合は、人数ではなく範囲を調整するほうが確実です。先に公開する機能を絞り、後から追加する形にします。
契約形態で見積もりの意味が変わる
同じ金額でも、約束している内容が異なります。ここを取り違えると、後で認識がずれます。
請負契約の見積もりは、完成までの総額です。仕様が固まっていることが前提になります。
準委任契約の見積もりは、期間あたりの体制の規模です。仕様が動く案件に向きますが、優先順位を決める担当者が発注側に必要です。ラボ型開発はこの形にあたります。
どちらが適しているかは、仕様の固まり具合で決まります。契約の詳細はオフショア開発の契約で整理しています。
両者を比べるときは、同じ土俵に乗っていないことを意識してください。請負の総額と、準委任の月あたりの金額を並べても、そのままでは比較になりません。期間の前提をそろえてから読みます。
オフショア開発の見積もりならではの確認点
国内の開発と違い、海外に開発拠点がある場合は、次の点も確認しておきます。
契約の主体はどこか。 日本法人と契約するのか、海外の法人と直接契約するのかで、手続きと法務の扱いが変わります。
通貨はどうなるか。 円建てであれば、為替の変動を見込む必要がありません。外貨建ての場合は、支払い時の相場で金額が変わります。
休日はいつか。 国によって祝日が異なります。長期休暇の時期を把握しておくと、日程の計画が正確になります。
やり取りの言語と窓口。 日本語で相談できる窓口があるかを確認します。
MOHAの場合、契約と請求、窓口は日本法人が担当します。円建て、日本法準拠で取引します。
変更が起きたときの扱い
開発中に仕様が変わらない案件は、ほとんどありません。そこで、変更の手続きを先に確認します。
確認したいのは次の3点です。
ひとつめは、変更を申し出る方法です。口頭の依頼を変更として扱うのか、書面が必要なのかを決めておきます。
ふたつめは、金額と期間への反映です。どの規模から追加の見積もりになるのかを、目安として聞いておきます。
みっつめは、判断にかかる時間です。変更の可否を決めるまでに何日かかるかで、進行の速度が変わります。
この手続きが決まっていないと、変更のたびに交渉が発生します。やがて現場は変更を言い出さなくなり、使いにくい機能がそのまま残ります。
リリース後の運用・保守はどこまで含まれるか
見積書の多くは、開発までを対象にしています。公開した後の扱いは、別の条件になることが一般的です。
次の点を確認してください。
- 不具合の修正を、いつまで無償で対応するか
- 対応を受け付ける時間帯と、連絡の手段
- 障害が起きたときの、連絡から着手までの流れ
- サーバーの監視を含むか
- 軽微な修正の依頼を、どう扱うか
ここで分かれ目になるのが、不具合と仕様変更の線引きです。決めた通りに動かないものは不具合、決めた内容を変えたいものは仕様変更になります。この区別を契約の前に合意しておくと、公開後のやり取りが落ち着きます。
運用の費用の考え方は、システム運用・保守費用の日越比較でも整理しています。開発費用そのものの比較は、システム開発費用の比較をご覧ください。
金額以外に確認しておきたいこと
見積書には書かれていないものの、後で効いてくる条件があります。
成果物の権利がどちらに帰属するか。 ソースコードの扱いを確認します。
ソースコードの引き渡しの有無。 どの時点で、どの形式で渡されるかを確認します。
ドキュメントの範囲。 設計書やテストの記録が残るかどうかで、将来の保守のしやすさが変わります。
支払いの時期。 着手金と完了時の割合、検収の条件を確認します。
再委託の有無。 実際に作業する体制を把握しておきます。
これらは、金額の多寡より後から影響が大きい項目です。
見積もりを受け取ってから発注までの流れ
受け取った後の進め方も、先に把握しておくと社内の調整が楽になります。
まず、前提条件を読み合わせます。不明な点は、この段階で質問します。
次に、範囲を調整します。予算や時期に合わせて、先に作る範囲を決めます。ここで段階的な進め方を選ぶこともできます。
そして、契約の条件を確認します。支払いの時期、成果物の扱い、保守の範囲を詰めます。
最後に、着手の日程を合わせます。体制の確保には時間がかかるため、見込みが立った段階で共有しておくと円滑に進みます。
社内説明で必ず聞かれること
見積もりを社内に上げると、決まって次の質問が出ます。先に答えを用意しておくと、進みが早くなります。
なぜこの金額なのか。 工数の単位と、含まれる作業の範囲で説明します。
なぜこの会社なのか。 技術的な適合と、体制の説明が必要です。
失敗したらどうするのか。 中間の確認時点と、そこで何を判断するかを示します。
公開した後はどうなるのか。 保守の範囲と、担当を示します。
これらは、見積書の前提条件を読み込んでいれば答えられる内容です。
よくあるご質問
概算だけ先に知ることはできますか。
やりたいことの概要を伺えば、規模感の整理からご相談いただけます。個別の金額は、前提を確認したうえでご案内します。
仕様書がない状態でも見積もりできますか。
できます。その場合は、要件を整理する工程を含めた形でご提案します。
見積もりの前提が変わったら、どうなりますか。
範囲が変われば、工数も変わります。変更の手続きを事前に決めておくことをおすすめします。
円建てで契約できますか。
できます。契約と請求は日本法人が担当し、円建て、日本法準拠で取引します。
発注前に体制の説明を受けられますか。
受けられます。どのような構成で進めるかを、事前にご説明します。
段階的に発注することはできますか。
できます。要件定義までを先に実施し、内容が固まってから次の段階に進む形がよく選ばれます。
保守だけを依頼することはできますか。
ご相談いただけます。既存システムの状態と資料の有無を確認したうえで、対応の範囲をご提案します。
見積もりの有効期限はありますか。
期限を設けることが一般的です。期限と、その後の扱いを確認しておくと安心です。
開発と保守を分けて依頼できますか。
分けられます。その場合は、引き継ぎの資料と、問題が起きたときの連絡の流れを決めておく必要があります。
契約前に技術的な相談だけできますか。
できます。実現できるかどうかの確認や、進め方の選択肢についてのご相談を承ります。
MOHAにご質問いただきたいこと
- この要望だと、どこまでが範囲に入りますか
- 工数は何を単位に数えていますか
- 請負と準委任では、どちらが合っていますか
- 仕様が変わった場合、どう扱われますか
- 公開した後の保守は、どこまで含まれますか
- 成果物の権利と、ソースコードの扱いはどうなりますか
MOHAは、ベトナムのオフショア開発センターで開発を行い、日本法人が契約と請求、窓口を担当します。公開している事例では、ホテル向けの予約システムを25人月の規模で開発しました。案件の規模を具体的にお伝えできる点は、見積もりのご相談でも役に立ちます。
指揮命令はMOHA側のPMとブリッジSEを通じて行います。日本語でご相談いただけます。
見積もりの前提を整理する段階から、お問い合わせフォームでご相談を承ります。
