開発会社選びで見落としがちなポイント5選

統計は冷酷です。大規模なITプロジェクトでは、納期遅延や予算超過、想定した事業価値の未達が珍しくありません。例えばMcKinseyの報告では、プロジェクトの45%が予算超過、7%がスケジュール遅延、想定価値の56%が未達という結果が示されています¹。さらに、長期の分析では成功プロジェクトは約3割にとどまるという指摘もあります²³。見積単価や過去実績のスライドだけでは炎上確率を下げにくい理由は、判断に使う軸が出力や価格に偏り、デリバリーの再現性や自社のエコシステムへの適合性を十分に測れていないからです。CTOやエンジニアリーダーが意思決定の質を上げるには、価格表の裏にある運営能力と契約上のインセンティブを、事前に定量で検査する視点が欠かせません。ここでは総保有コスト（TCO：Total Cost of Ownership）、契約の設計、チームの実力、DORA指標と品質ゲート、そして知的財産（IP）と退出設計という見落とされがちな5点を、評価の物差しに落とし込みます。

コストは見積額ではなくTCOで比較する

単価や初期見積は氷山の一角です。SaaS/クラウド費、監視やセキュリティ、QAと自動化、PMOやステークホルダー調整、データ連携や法令対応、環境構築と運用、変更要求の扱いなど、運用を含む総保有コスト（TCO）⁴で意思決定しないと、開始数か月で前提が崩れます。たとえば（以下は仮の試算例です）、初期5,000万円で12か月開発、月次の運用・改善が400万円、要件の見直し率が15%だとします。要件変化が見積に反映されるたびにコストは累積し、クラウドや外部APIの従量課金も増えがちです。結果としてTCOは5,000万円＋（400万円×12）＋変更起因の追加（仮に10〜20%）となり、ざっくり7,000〜8,000万円規模に膨らむことは珍しくありません。

重要なのは「水増し」を疑う姿勢ではなく、比較の前提をシナリオ別に固定して、各ベンダーを横串で比べることです。同じ要件変化率、同じSLO（サービスの目標値：Service Level Objective）、同じ自動化レベルを仮置きし、運用費・変更費・改善費まで含めたランレート（毎月の実質コスト）の見積を依頼します。さらに、見積の内訳粒度を合わせ、CI/CD（継続的インテグレーション/デリバリー）やテスト自動化の初期投資が後工程の不具合率やMTTR（平均復旧時間）をどの程度下げるか、公開可能な実績レンジや根拠を示してもらうと差が明確になります。

契約のインセンティブが成果に正しく向くか

契約形態は行動を決めます。固定価格は発注側に安心感がある一方で、変更に厳しく、品質よりもスコープ消化にインセンティブが働きやすい。時間準委任（Time & Materials）は柔軟ですが、可視化が弱いと工数の膨張を招きます。推奨したいのは、要件変化を前提にしたキャップ付き時間準委任＋受入基準の明文化＋段階的な成果連動の組み合わせです。具体的には、Definition of Ready/Done（着手/完了の条件）と品質ゲートを満たした機能のみを受入対象とし、未達は翌イテレーションに繰り延べる。上限工数を設定し、月次で上下5〜10%の弾力を持たせる（目安）。さらに、主要OKRやビジネスKPI（例：CVR＝コンバージョン率、獲得単価、NPS＝推奨度）を共通のメトリクスボードで可視化し、到達度に応じて成功フィーや改善スプリントの拡張をオプション化します。支払サイトは短くし、小さなフィードバックループを回せるようにする。変更要求の見積SLAや根拠（想定リードタイム、スキル構成）を契約文書で合意しておくと、双方の行動が成果に寄ります。

チームの実力は“名刺”ではなく実働で見る

提案書の肩書や認定ロゴは目を引きますが、デリバリーの実力は「誰が毎日コードを書くか」で決まります。重要なのは、アサイン予定者を名指しで提示してもらい、シニア・中堅・ジュニアのスキル分布、過去12か月の離職率、サブコン比率、バックフィル（欠員補充）のリードタイムまで開示してもらうことです。開発速度は流暢なコミュニケーションとレビュー品質に強く依存するため、コードレビューの実例とADR（アーキテクチャ決定記録：Architecture Decision Record）の雛形、スプリントレビューの録画や議事の提示を依頼すると、習慣化の度合いが透けて見えます。

発注前に有償の2週間スパイク（短期の試行開発）を設定し、現場のツール群とテーマで試走するのも効果的です。環境構築の所要時間、スループットの推移、欠陥の再現と修正の往復、説明責任の明確さ、ドメイン理解の吸収速度など、口頭では測れない差が可視化されます。ある検証では、単価が低い候補は障害復旧に数時間を要した一方、最終採用先はおおむね1時間前後で復旧でき、同一テーマでもデプロイ頻度が週次と日次で分かれる、といった差が見られることがあります。単価の差より、毎月のランレートと機会損失の差が意思決定を左右する好例です。

プロダクト思考と事業KPIへの接続を持つか

「言われた通りに作る」供給者は、要件がズレた瞬間に高速で間違い続けます。見極めたいのは、仮説検証を前提にしたデュアルトラックアジャイル（探索と実装を並走させる手法）が回っているか、そしてインストルメンテーション（計測の仕込み）計画がスプリント1から織り込まれているかです。ログの設計、イベントのスキーマ、ユーザーテスト計画、A/B実験の運用、意思決定に使う計測ダッシュボードの初期セットを、提案段階で出してもらいます。機能出荷の先にあるKPIの変化率を会話できる相手は、スコープではなくアウトカム（成果）に重心を置けます。これが契約インセンティブとつながると、短期の出力と中期の成果の両立が見えてきます。

再現性のあるデリバリーは指標と品質ゲートで判定する

卓越した現場は、速さと安定を同時に語れます。その共通言語がDORA指標（DevOpsの成果を測る4指標）です⁵。デプロイ頻度、変更のリードタイム、平均復旧時間（MTTR）、変更失敗率の4つについて、ベンダー側の実績レンジを過去3〜6か月で提示してもらいます。例えば、日次以上のデプロイ、変更リードタイムが1日未満、MTTRがおおむね1時間前後⁵、変更失敗率が0〜15%⁶といったプロファイルを安定して出せているなら、パイプラインとオブザーバビリティ（可観測性）が整っている可能性が高い。逆に、指標を把握できていない現場は、計測と意思決定のループが未成熟です。

併せて、品質ゲート（合格基準）の通過条件を確認します。SAST/DAST（静的/動的セキュリティテスト）、依存パッケージの脆弱性スキャン、SBOM（ソフトウェア部品表）の生成、IaC（Infrastructure as Code）のポリシーチェック、シークレット管理、プルリク承認の二重化、段階的ロールアウト、インシデントのポストモーテム（事後検証）などを、既存プロダクトのパイプラインでサンプル提示してもらうと良いでしょう。紙のルールではなく実稼働の証跡が要点です。監査ログ、パイプライン定義、失敗時のロールバック記録、SLO違反の検知からエスカレーションまでのトレースが出てくるチームは、障害時にも学びを積み上げて強くなります。

ベンダーロックインを防ぐIP・環境・退出設計

選定時の熱気が冷めるのは、担当が異動したときか、契約を見直したいときです。だからこそ、はじめに所有権と退出の筋道を作っておきます。コード、IaC、テスト、設計ドキュメント、チケットと議事、ダッシュボードの設定は、原則としてあなたのリポジトリとクラウドアカウントで運用し、ベンダーは最小権限で参加する形にします。ライセンスと知的財産（IP）の扱いも明確にし、第三者コンポーネントのライセンス適合証跡とSBOMの引き渡しを契約に含めます。退出時のナレッジ移管は、ドキュメントとワークショップに加え、数週間の共同ペア作業で暗黙知を手渡す計画を初回契約から入れておくと移行が滑らかです。運用をベンダーのツールに閉じないこと、実運用の権限がベンダーにしかない状態を作らないことが、ロックイン回避の最短路です。

ケースで見る見落としのコスト

仮のケースを二つ示します。ある金融系の新規サービスでは、初期見積の安さでA社を選びました。見積は他社より約1割安く見えましたが、セキュリティ自動化や負荷試験が後回しになり、ローンチ前の追加対応で数週間の遅延が発生。変更見積と臨時体制の追加によって、TCOは当初計画を2〜3割上回る結果となることもあります。後から別案を見返すと、パイプラインやSLO監視への初期投資は重く見えたものの、DORAのベースラインが高く、運用ランレートを抑えられる構造だった、と評価し直せる場合があります。

別のEC領域では、候補3社に同一テーマの有償スパイクを依頼し、データ計測とA/Bテストのセットアップ速度、改善サイクルの速さ、レビュー品質を比較。最終的に選んだC社は単価が中位でしたが、2スプリントでCVRが数％改善し、その後の機能追加も日次で出荷可能に。繁忙期のインシデントでもMTTRは1時間未満、変更失敗率は1桁台〜1割台に収まり、事業側の施策速度が上がった——こうした結果につながる例もあります。価格優位に見えた選択肢ほど、見えないコストの罠を抱えがちであることを示す対比です。実際の効果は前提や体制により変動するため、スパイクなどの小さな実測で確かめることが肝要です。

まとめ：選定を“検証可能な仮説”に変える

開発会社選びは、魅力的なスライドよりも、検証できる指標と行動に落とし込んだときに精度が上がります。見積の表面ではなくTCOの前提を揃えて比較し、契約のインセンティブを成果に向け、名指しの実働チームでスパイクを回し、DORAと品質ゲートの実績を開示してもらい、IPと退出設計で将来の選択肢を守る。この一連の流れが定着すれば、選定は賭けではなく、再現性のある意思決定になります。次のRFPでは、要件表だけでなく、ここで触れた評価軸をスコアカードにして同条件で提出を求めてみてください。もし今進行中の選定に不安があるなら、小さなスパイクを切り出して実測し、学習しながら進める形に切り替えるのも十分に間に合います。あなたの組織が守りたいのはコストだけではなく、施策速度と選択肢のはずです。どの問いから検証を始めますか。

参考文献

1. McKinsey & Company — Delivering large-scale IT projects on time, on budget, and on value

2. Bent Flyvbjerg, Alexander Budzier — Why Your IT Project May Be Riskier Than You Think (arXiv:1304.0265)

3. 日経xTECH — スタンドッシュ・グループCHAOSレポートに基づく成功率31%の分析（記事ページ）

4. SAT株式会社 — TCO（総所有コスト）とは？定義と算出の考え方

5. Faster Safely — Accelerate findings（Deployment frequency / Lead time / MTTR）

6. Faster Safely — Accelerate findings（Change failure rate）