なぜB2Bソフトウェア開発は本番直前で破綻するのか
企業やAgency・SIer様が開発パートナーを選ぶ際、「どのようなご要望も実装可能です、AI連携も低予算・短納期でお任せください」という言葉をよく耳にします。契約時にはこの言葉は安心材料に聞こえますが、実はここに多くのプロジェクト破綻の起点があります。
多くの場合、これは悪意によるものではありません。受注を優先するあまり、技術的な制約を十分に確認しないまま「まず契約を結び、難しい部分はあとで考える」という判断をしてしまう開発会社が少なくないのです。ただし、制約そのものは消えるわけではなく、リリース数週間前になって表面化することがほとんどです。
実際によく見られる場面は3つあります。要望されたリアルタイム同期が、実は既存データベースの構造と両立しないと分かる場合、当初の見積もりが「想定外の技術的複雑さ」を理由に2倍から3倍に膨らむ場合、そして「正確に回答するAIチャットボット」として導入したものが、本番環境で顧客に誤った情報を伝えてしまう場合です。
技術的な制約を隠すと、誰が損をするのか
「できないこと」を最初に伝えないことは、関わる全員に負担をもたらします。
発注企業は、相応の予算と時間を投じた末に使えないシステムを受け取ったり、切り替え当日にシステム障害を経験したりします。間に入るAgencyやSIer様は、技術リスクを見極められなかったベンダーを選定した責任を問われ、エンドクライアントとの信頼関係を損ないます。そして開発会社自身も、最初から実現困難な約束を追いかけることになり、現場の負担が積み重なって、プロジェクトが途中で止まってしまうことがあります。
開発会社が「できません」と言いにくい理由の多くは、競合に案件を奪われる不安と、制約を早い段階で見抜くだけの設計力がまだ十分でないことにあります。これは特定の一社の問題ではなく、業界でよく見られる営業のパターンだと私たちは考えています。
VAONの考え方：契約前に「やらないこと」を伝える
VAONはこの逆を行います。相談の段階、つまり契約を結ぶ前に、「やらないこと（スコープの境界）」を明確にお伝えします。
具体的には、規模に応じて2〜4週間の「仕様確定フェーズ」を独立した工程として設け、費用はあらかじめ提示した固定額です。このフェーズの終了時には、要件定義書、画面設計、データベース設計、そして開発フェーズの固定見積もりをお渡しします。
このフェーズに伴う約束は次のとおりです。開発フェーズで手戻りが発生し、その原因がVAONが作成した仕様書の誤りや漏れに遡れる場合、その費用はVAONが負担します。仕様確定後にお客様のご要望が変わった場合は、この約束の対象外とし、書面による変更管理のプロセスで別途対応します。
実例1：CPU専用・132MBの多言語OCRエンジン
あるお客様から、日本語とベトナム語の文書を高精度に読み取る多言語OCRシステムのご要望をいただきました。市場でよく見られる方法は、大規模なAIモデルをクラウドGPUサーバー上で稼働させるというものです。
着手前に、VAONは2つの「やらないこと」をお伝えしました。クラウドGPUに依存する構成は採用しないこと、そしていかなるAIモデルであっても、事前の画像処理を行わずに完全な精度を約束することはしない、という点です。
代わりに、VAONは独自開発のCPU専用・132MBのOCRエンジンを、50万件を超える実際のベトナム語文字データでファインチューニングしました。ある実プロジェクトでは、この方法によりデータ抽出の精度が70%から、検証済みのデータセット上でエラーが確認されない水準まで向上し、同じ処理量をGPUで行う場合と比較してインフラコストを80%削減しました。処理はすべて自社内のインフラで行い、第三者のクラウドAPIにデータを送信しない構成のため、日本の個人情報保護法（APPI）の要件にも対応しています。
実例2：データベースに手を加えない20年物CMSの刷新
20年間運用され、数百万ページを抱えるCMSの刷新をご相談いただきました。この種の案件でよく提案される方法は、データベースとアプリケーションをすべて作り直すフルスクラッチで、通常1〜2年を要し、切り替え時のダウンタイムのリスクも現実にあります。
VAONは着手前に2つの「やらないこと」をお伝えしました。20年間安定して稼働してきたデータベースには手を加えないこと、そして移行の過程で1分たりともシステムを停止させる方法は採用しないこと、の2点です。
採用した設計はStrangler Figパターンによる段階移行です。既存のデータベースと編集ワークフローはそのまま維持しながら、バックグラウンドで静的HTMLを自動生成し、Edge CDN経由で配信します。プロジェクトは4か月で完了し、ダウンタイムはゼロ、表示速度（TTFB）は50ミリ秒未満、フルスクラッチと比較して開発期間を66%短縮し、インフラコストを70%削減しました。稼働率99.5%というSLAは、この静的配信アーキテクチャに対してVAONが提示している水準であり、すべての案件に一律で適用される保証ではありません。
「やらないこと」を先に伝えると何が変わるのか
「やらないこと」を先に伝えるのは、遠回しな断り方ではありません。これは要件範囲を設計する取り組み（スコープエンジニアリング）であり、実際のリスクを減らします。
技術的な境界を早い段階で合意しておくことで、開発途中の追加費用や納期遅延は起こりにくくなります。双方があらかじめ範囲の内と外を理解しているためです。AIやデータベースの限界を先に言葉にしておくことも、本番環境になって初めて表面化するような不具合を防ぐことにつながります。自社ブランドで案件を進めたいAgencyやSIer様にとっては、限界を先に言う技術パートナーのほうが、あとから説明に追われるより、エンドクライアントに対して説明しやすい立場になると考えています。
この考え方でも解決できないこと
ここで紹介した内容は、あらゆる案件にそのまま当てはまる公式ではありません。事前に知っておいていただきたい限界もあります。
CMS実例の4か月という期間や改善率は、この案件固有の規模と複雑さに紐づく数字です。より小規模なCMSであれば短縮できる可能性がありますし、社内システムとの連携が深い場合はより長くかかることもあります。同様に、OCRエンジンの「エラーが確認されない」という結果は、特定の検証済みデータセット上で測定したものであり、あらゆる文書種別や業種での精度を保証するものではありません。金融・小売向けに構築した辞書フィルターも、医療や金融といった別業種に適用する場合は、その業種の用語に合わせて作り直す必要があります。
VAONが手戻り費用を負担する約束にも、契約上の明確な境界があります。仕様確定後にお客様のご要望が変わった場合や、法律や第三者APIの仕様変更など外部要因が変化した場合は、この約束の対象外です。
おわりに
「やらないこと」を先に伝えることは、提案の魅力を下げるものではありません。提案を実態に近づけ、あとになって高くつく修正が発生する可能性を下げるものだと考えています。
システム開発やAI導入をご検討中で、ご自身の案件における具体的な技術的制約を事前に知りたい方は、VAONにて初期的な確認をご案内できます。OEM形式での協業先を探していらっしゃるAgencyやSIer様も、進め方についてお気軽にご相談ください。
公式サイト：https://vaon.com.vn/ja