ソフトウェアプロジェクトに関する最初の会話は、ほぼすべて同じ質問から始まります。費用はどのくらいか、です。もっともな質問ですが、一文で責任をもって答えられない質問でもあります。多様な企業のためにソフトウェアを25年にわたって構築してきた中で、課題が理解される前に示された金額は、見積もりではなく、後で誰かが支払うことになる推測にすぎないと学びました。
この記事では価格はお伝えしません。ここに掲載する金額は、どのプロジェクトでも正確ではないからです。代わりに、費用に実際に影響する要素の一覧をお伝えします。見積もりを受け取った際にその妥当性を判断でき、結果を損なわずに費用を抑える選択ができるようにするためです。
「同じもの」に対する2つの見積もりが大きく異なる理由
“カスタマーポータル”の見積もりを三社に依頼すると、非常に異なる金額が返ってくることがあります。これは、一社が過大請求しているからというより、各社が異なるポータルを想定しているためであることがほとんどです。ある会社は請求書の一覧付きの単純なログインを想定し、別の会社は役割ベースのアクセス、文書のアップロード、メール通知、管理画面、決済ゲートウェイを想定しています。三社目は、それらすべてに加えてモバイルアプリを想定していたかもしれません。
同じ一文で説明されるソフトウェアでも、必要な労力は桁違いに異なることがあります。そのため、誠実な見積もりで最初に行うべきことは、その一文を「作業完了時に何が存在するか」を書面にした範囲定義に置き換えることです。範囲の記載がない価格にはご注意ください。
費用の主な要因
1. 範囲：何を行うか（機能の数）
機能はそれぞれ、設計、開発、テスト、そして周囲の変化に合わせた継続的な維持管理を伴う作業です。機能同士も互いに影響し合います。例えば、5 つ目のユーザーロールを追加しても、4 つ目の場合の費用の 5 分の 1 増しになるわけではなく、権限をチェックするすべての画面に影響します。要望を挙げる際は、初日から必要なものと、後にあると良いものを分けてください。その区別こそ、費用を抑える最も効果的な手段です。
2. 不確実性：課題がどこまで理解されているか
レコードを保存してメールを送るフォームのような、よく理解された課題は、正確に見積もることができます。工程の進め方やデータの形がどのようなものか誰も確信がない課題は、そうはいきません。不確実性があっても作業が不可能になるわけではありませんが、固定価格は双方にとってリスクになります。供給者が不確実な部分を見込んで価格を膨らませるか、プロジェクトの範囲をめぐる争いに発展するかのどちらかです。短い探索フェーズ、プロトタイプ、実データのサンプルなどで、事前に少し時間をかけて不確実性を減らすほうが、通常は費用以上の効果があります。
3. 連携：関わる他のシステムの数
決済ゲートウェイ、会計パッケージ、CRM、配送サービス、政府ポータルへの接続は、見積もりが最も外れやすい部分です。外部の各システムには独自のルール、固有の癖、そして時にはコードとは無関係の承認プロセスがあります。ドキュメントが整備された最新の API であれば、対応は単純です。ドキュメントがない古いシステムや、ファイルのエクスポートしかできないシステムは、そうではありません。プロジェクトに連携が含まれる場合は、必要となる承認とともに、見積もりで連携を明示的に示してください。
4. 利用者、データ、性能
社内ユーザー10名向けのソフトウェアと、顧客1万人向けのソフトウェアでは、求められるエンジニアリングが異なります。利用者、データ量、同時に行われる処理が増えるほど、データベース設計、キャッシュ、ホスティング、監視により多くの注意が必要になります。多くの業務アプリケーションに特殊なアーキテクチャは必要ありませんが、想定している規模（2～3年後の目標を含む）を開発者に正直にお伝えください。そうすることで、基盤が小さすぎるという事態を避けられます。
5. プラットフォームとデバイス
デスクトップとスマートフォンのブラウザで動作するWebアプリケーションは一つの話です。ネイティブのAndroidおよびiOSアプリ、オフライン動作、プッシュ通知、ストアへの公開は、別の話です。FlutterやReact Nativeのようなクロスプラットフォームツールは、AndroidとiOSのコードの大部分を共有できます。そのため、業務アプリでは適切な選択になることが多いのですが、作業がただになるわけではありません。利用者にとって本当に重要なプラットフォームを決めてください。
6. 品質、セキュリティ、コンプライアンスの要件
テスト、コードレビュー、バックアップ、ログ記録、アクセス制御、セキュリティ強化は、追加のオプションではありませんが、その深さは案件によって異なります。決済や個人データを扱うシステムは、パンフレット用のサイトよりも慎重さが必要です。契約上または法規制上の要件がある場合は、開発の初期段階で開発者にお伝えください。後から追加する方が、最初から設計に組み込むよりはるかに高くつきます。実証できない認証の取得や保証を主張する相手には注意してください。
7. データ移行と既存システム
既存のシステムを置き換える場合は、古いデータを移行する必要があります。そのデータのクリーニング、マッピング、検証は過小評価されがちです。自由記述の入力が多いスプレッドシート、重複した顧客、不統一な日付を、きれいなデータベースに変えるには、相応の労力がかかります。古いデータのうち、本当に必要な量を早めに確認してください。
8. 公開後
ソフトウェアは、公開した時点で完成するわけではありません。サーバーにはパッチを適用し、ライブラリは更新が必要で、実際の利用でバグが見つかり、業務も変化し続けます。ホスティング、保守、そして継続的な小規模改善のための予算を確保してください。目安としては、初回リリースを購入の終わりではなく、ソフトウェアとの付き合いの始まりとして捉えることをお勧めします。
誠実な見積もりとはどのようなものか
最終的な金額にかかわらず、信頼できる見積もりにはいくつかの特徴があります。範囲を平易な言葉で説明しているため、想定していた内容と一致しているかを確認できます。「決済サービスのサンドボックスが利用可能であること」や「製品データはスプレッドシートで提供いただくこと」といった前提条件が記載されています。作業をマイルストーンに分割しているため、進捗を把握でき、必要であれば中断することもできます。対象外の内容を明記しています。そして、変更がどのように扱われるかを説明しています。変更は必ず発生するためです。
見積もりが固定価格であれば、要件が変わった場合にどうなるかを示しているべきです。時間と材料費であれば、範囲を示し、費用の状況についてどのように報告を受けられるかを説明しているべきです。固定価格と時間・材料費の選び方については、ガイドで詳しく説明しています。
価値を損なわずに費用を抑える方法
- 想定より小さく始めましょう。 焦点を絞った最初のリリースを実際の利用者が使うことで、長い仕様書よりも多くを学べます。どの機能が重要かを理解したうえで、第2、第3の段階の機能を追加できます。
- 早い段階で実例を提供します。 サンプルの文書、スプレッドシート、現在の作業工程のスクリーンショット、厄介な例外の一覧は、会議よりも速く不確実性を取り除きます。
- 不確かな点を伝えてください。 開発者は、不明な点を知らされていれば、それを前提に設計できます。費用がかかるのは予期せぬ事態です。
- そもそもソフトウェアが必要か検討しましょう。 既製ツールの設定、小さな自動化スクリプト、または工程の見直しで、より低コストに解決できる場合があります。規模の小さなプロジェクトになるとしても、優れた開発者はそうお伝えします。
率直な答え
カスタムソフトウェアの費用は、何を構築するか、その内容をどれだけ理解しているか、他のいくつのシステムと連携するか、そしてどれだけの期間運用する予定かによって異なります。これらを理解する前に確定額を提示できる人は、推測しているか、既製品を売っているかのどちらかです。
IT Labs Indiaでは、無料の初回相談と書面による見積もりを提供しています。料金は公開していません。適切な金額は、お客様の課題を理解した後にしか存在しないためです。その対話を始めたい場合は、カスタムソフトウェア開発のサービスの詳細をご覧いただくか、お問い合わせください。