会社情報
採用情報
お問い合わせ
Article

開発会社の得意分野を見極めよう：分野別の選び方

高田晃太郎
開発会社の得意分野を見極めよう：分野別の選び方

McKinseyの分析では、大規模ITプロジェクトは平均で45％の予算超過、7％の納期遅延、想定価値を56％下回る価値しか実現できないことがあると報告されています¹。失敗の背景には技術力不足だけではなく、分野特有の規制や非機能要件（性能・可用性・セキュリティ・運用性など）を読み違える構造的問題が横たわります⁴。過去の調達案件を俯瞰すると、同じ“フルスタック”を名乗る企業でも、金融の勘定合わせやECのピークトラフィック、SaaSのマルチテナンシーなど、暗黙知の深さが成果に直結していました。つまり“得意分野”は単なる作った回数ではなく、分野の物理法則を身体化しているかどうかです。CTOやエンジニアリングリーダーにとって、ここを見誤らないことが、中長期のROIに最も効きます。ベンダー選定や開発会社の選び方を迷うときほど、分野適合と非機能要件の扱いを軸に、SLA/SLOや見積もりの前提まで一気通貫で確認しましょう。

なぜ「得意分野」の見極めがROIを左右するのか

プロジェクトの損益は、要件定義の精度と再学習コストに強く依存します。分野適合した開発会社は、非機能要件を先回りして設計に織り込むため、後戻りの規模が小さくなります⁴。例えば決済を扱うシステムでは、冪等性キー（同じ要求を繰り返しても結果が変わらないための識別子）、対帳プロセス（トランザクションの突合・整合確認）、障害時の二重引き落とし防止といった制御が仕様書に落ち切らないまま残りがちです。ここでの経験差は、運用初期の障害密度や変更失敗率に現れます。デリバリーの生産性を測る枠組みとしてDORA指標（デプロイ頻度・変更リードタイム・変更失敗率・平均復旧時間）が知られています²が、デプロイ頻度や変更失敗率、MTTR（平均復旧時間）を対外案件でも管理し、案件後に定量共有できる会社は、分野特有の落とし穴をプロセスとして吸収していることが多い³。つまり**「得意」は成果物の見栄えより、データで語れる運用安定性に表れます**。

もうひとつの要因はドメインモデルの探索速度です。業務概念の粒度を適切に切り出す力は、フィーチャーの実装速度以上にバグの再発防止率と直結します。医療なら監査証跡やアクセス制御の粒度、ECなら在庫確定のタイミング、SaaSならテナント境界のライフサイクルが代表例です。暗黙知がある会社は、最初の一週間で作るドメイン用語集とシーケンス図の密度が違います。結果として、同じ見積り工数でも実効ベロシティが上がり、価値実現の先行指標であるリードタイムが短くなります。ここまでを踏まえると、開発会社の選び方は「技術スタック」より「分野の物理法則をどれだけ先読みして設計に折り込めるか」を主軸に据えるのが合理的です。

分野別に見る要件のクセと、面談での見抜き方

FinTech/決済：整合性と監査可能性が最優先

金融・決済では、最終整合性（時間をかけて整合する）を許容する箇所と強整合性（常に矛盾がない）を求める箇所の切り分けが成否を分けます。強整合性が必要な勘定系はトランザクション境界が明確で、冪等処理や補償トランザクション（失敗時の打ち消し処理）の設計が丁寧であるべきです⁵⁷。監査の観点では、操作ログの改ざん耐性、データ保持期間、ロールの権限委譲履歴など、設計段階で示せるはずのアーキテクチャが鍵になります。面談では、過去の障害事例を具体的に尋ね、二重計上や整合性崩壊時にどのようなロールバック戦略を採ったか、対帳の自動化率やリコンシリエーション（突合）に用いたジョブ設計⁶、PCI DSSやSOC 2の監査対応で提出したエビデンスの種類まで語れるかを確認すると、経験値の深さが露わになります。SLO（運用目標）としては、承認系APIのp95レイテンシ（95%のリクエストが収まる遅延値）、フェイルオーバー時のRTO/RPO（復旧目標時間/目標復旧時点）を数値で即答できるかが一つの判断材料です。なお、SLA（対顧客の合意水準）とSLOの違いも説明できると信頼度は上がります。

EC/D2C：ピークトラフィックと検索体験の両立

ECはプロモーションやセール時の急激な負荷変動と、商品探索の体験品質が同居します。得意な会社は、カートや在庫引き当ての一貫性、クーポンの適用順序、レコメンドのフィード更新遅延といった“細い配管”に強い。検索は同義語辞書やベクトル検索（意味ベース検索）の導入範囲、インデックス再構築のダウンタイム戦略と関係します。面談では、ブラックフライデー級トラフィックでのp99レイテンシ、オートスケールの指標設定（CPU/キュー長/カスタムメトリクス）、在庫を確定させるイベントの順序制御の経験を尋ねると良いでしょう。A/Bテストの実験プラットフォームを内製・外部いずれで構築したか、実験の最小検出力やサンプルサイズ計算まで語れるなら、成長ドライバーに理解があるサインです⁸。カゴ落ち対策を単発のUI改善で語らず、サーバーサイド計測とアトリビューション（貢献度測定）の精度から説明できるかも重要です。ECサイト開発に長けたベンダーは、CDN・キャッシュ戦略とパーソナライズの両立にも現実解を持っています。

SaaS/Enterprise：テナント境界と拡張性の設計体力

SaaSはマルチテナントの隔離方式、拡張性、課金・権限の複雑さが本質です。強い会社は、スキーマ分離かアプリ分離か、Noisy Neighbor対策（同居テナントの負荷干渉防止）、機能フラグによる段階的リリース、ゼロダウンタイムマイグレーションの定石を持っています。面談では、スキーマ変更の手順とバックアウト戦略、テナント跨ぎのレポート要件、RBAC/ABAC（ロール/属性ベース権限）の適用境界、監査ログの相互参照に関する具体策を聞きます。さらに、アドオンマーケットプレイスを想定した拡張ポイント設計や、Webhookの順序保証と再配信ポリシー、プラン変更に伴うデータ移行の手順が語れるかを見ると、運用年数に裏打ちされた“得意”かどうかが見えてきます。SLAは可用性の数字だけでなく、変更失敗率と平均復旧時間を四半期ごとに顧客へ開示しているかまで踏み込みましょう。SaaS開発の選び方としては、運用ファイアウォール（オンコール・Runbook・合議制）も確認対象です。

データ/AI：データ契約とモデル運用の現実主義

データ/AIは、ETL（抽出・変換・ロード）の整備やフィーチャーストアの運用、学習・推論の再現性管理が実力差になります。モデルの精度指標だけでなく、ドリフト検知、シャドー運用（本番並走テスト）、ロールバックの設計まで運用に踏み込めているかが肝心です。面談では、データリネージ（来歴）の可視化方法、P99の推論レイテンシを保ちながらバッチとストリーミングを両立させた事例、個人情報の擬似化やアクセス制御の粒度、生成AIであればプロンプトガードレールや監査ログの扱いを問うと、机上の空論か実務経験かが分かれます。さらに、モデル更新に伴うA/Bやチャンピオン・チャレンジャー戦略、ビジネスKPIへの寄与を計測する実験設計まで自社の方法論として持っているかが、長期の価値創出能力を測る指標になります。データ基盤・AI開発のベンダー選定では、データ契約（スキーマ・品質・SLO）をどう運用に落としているかが決定打です。

「本当の得意」はプロセスとデータで裏取りする

分野の話だけでなく、プロセスの成熟度をデータで確認することが不可欠です。DORA指標の推移を案件別に提示できるか、ポストモーテム（再発防止を目的とした原因分析）のテンプレート化と是正計画の追跡があるか、アーキテクチャ・ディシジョン・レコード（ADR：設計判断の記録）を残して意思決定の履歴を共有しているか。この三点は、抽象的な「品質へのこだわり」を測る実用的な物差しです。ソースコードやTerraformなどの変更管理において、レビューのリードタイムとスループットのトレードオフをどう解いているか、レビュー基準の定量化があるかも見てください。強い会社は、変更の粒度、リリーストレインのリズム、フラグ駆動のデリバリーと回帰テストの自動化に一貫した設計思想を持っており、説明が短く整っています。

人の面でも、アーキテクトとEM、SRE、セキュリティのロール定義が曖昧でないことが重要です。面談に出てくるメンバーが、実際のデリバリーチームの中核と一致しているか、プリセールス専任のスターだけが出ていないかを見極めます。過去案件のオンコール体制、深夜のインシデント時の指揮系統、ベンダー側のナレッジ共有の仕組みなど、運用時の汗のかき方を具体的に聞くと、外面の良さと中身の差が浮かび上がります。さらに、第三者レビューやセキュリティ監査への態度も指標になります。SOC 2やISO 27001の実施有無だけでなく、顧客指定の脆弱性診断を歓迎するか、開示ポリシーが明文化されているかも評価しましょう。

コストと見積もりの読み方、そして発注前の準備

見積もりは、単価の比較だけでは適切に読めません⁹。分野に明るい会社ほど、探索に対する投資比率が高く、要件の不確実性を減らすためのディスカバリー（短期の検証フェーズ）を設けます。スプリントの先頭にドメイン探索を固定費で置き、その後の実装はタイム＆マテリアル（準委任）で流す、あるいは成果ベースのマイルストーンでリスクを分担する、といった契約構造を提案できるかが腕の見せどころです。固定価格一括の美しさだけでなく、変更の弾力性を担保したうえでのコスト曲線を比較してください。コスト・オブ・ディレイの観点から、出荷時期の前倒しがどれだけの収益インパクトを生むか、逆に品質劣化による将来負債がいくらかを、ベンダーと同じ数直線で議論できると、健全な意思決定に近づきます。RFPの作り方や相見積もりの比較軸は、ベンダー選定の初期で精度を決めます。

選定の場では、短期間の有償ディスカバリーを二社並走で設け、同一の問題に対するアプローチの違いを比較する方法が有効です。成果物は、業務語彙の定義、主要ユースケースのシーケンス、非機能要件とSLO、リスク登録簿、最初のアーキテクチャ案とバックアウト戦略、そして初期のメトリクス設計です。文字にすると大仰ですが、優れたチームは一、二週間で要点を外さずまとめてきます。比較の観点は、図の密度と矛盾の少なさ、仮説の明確さ、そして「何をやらないか」の宣言に表れます。オフショアやニアショアを組み合わせる場合は、コミュニケーション構造と責任分界の設計がコスト効果を左右します。

発注側の準備としては、ビジネスの北極星指標（North Star Metric）、制約条件、既存システムのインターフェース、データの所在と品質、セキュリティ・コンプライアンス境界、そして非目標の明示を短くまとめておくことが効果的です。これにより、見積もりの前提が揃い、比較可能性が高まります。SLOは“可用性99.9%”といった抽象度ではなく、エンドユーザーの旅路に沿ったp95レイテンシやジョブの締切時間、リカバリーの上限時間など、ユーザー体験と運用の現実を結ぶ数値で表現しましょう。最後に、ベンダーと共有するロードマップには、バッファと意思決定ポイントをあらかじめ埋め込み、学習からの方向転換を前提化します。これができると、契約は衝突の装置ではなく、共同で不確実性を燃やすための燃焼室に変わります。

まとめ：得意の見極めは、技術と契約と運用の三点測量

開発会社の“得意”は、ロゴの並びや営業資料の華やかさより、分野特有の非機能要件を平時から設計に織り込めるか、プロセスの成熟度をデータで示せるか、そして契約で不確実性を適切に分担できるかの三点で立体的に見えてきます。面談では障害の語り口と復旧データ、ADRやポストモーテムの扱い、SLOの粒度を丁寧に追いかけてください。分野別のクセを理解し、あなたのビジネスの物理法則と照らし合わせることで、選定の精度は着実に上がります。

次に取る一歩として、社内で北極星指標と非機能の最小セットを短く整え、二週間の有償ディスカバリーを前提に候補企業と話し始めてはどうでしょうか。あなたの組織のスピードと安全係数に合う相手は必ずいます。準備の質を一段引き上げていきましょう。

参考文献

  1. McKinsey & Company. Delivering large-scale IT projects on time, on budget, and on value. https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/delivering-large-scale-it-projects-on-time-on-budget-and-on-value
  2. Open Practice Library JA. Accelerate/DORA メトリクスでソフトウェアデリバリーパフォーマンスを測る. https://openpracticelibrary-ja.netlify.app/blog/accelerate-metrics-software-delivery-performance/
  3. Open Practice Library JA. Accelerate/DORA メトリクス（定義と指標の詳細）. https://openpracticelibrary-ja.netlify.app/blog/accelerate-metrics-software-delivery-performance/#:~:text=The%20DORA%2FAccelerate%20metrics%20were%20devised,book%20%E2%80%9CAccelerate%E2%80%9D%2C%20published%20in%202018
  4. ResearchGate. Role of Non-functional Requirements in projects’ success. https://www.researchgate.net/publication/361184121_Role_of_Non-functional_Requirements_in_projects’_success
  5. Cockroach Labs. Why idempotency matters for finance. https://www.cockroachlabs.com/blog/idempotency-in-finance/
  6. ResearchGate. Idempotency and Reconciliation in Payment Software. https://www.researchgate.net/publication/380285760_Idempotency_and_Reconciliation_in_Payment_Software
  7. PingCAP. Idempotency in finance payment systems. https://www.pingcap.com/article/idempotency-in-finance-payment-systems/
  8. Shopify. A/Bテスト完全ガイド（サンプルサイズと検出力の基礎）. https://www.shopify.com/jp/blog/the-complete-guide-to-ab-testing
  9. ＠IT（アットマーク・アイティ）. 見積もりの基本と読み解き方. https://atmarkit.itmedia.co.jp/ait/articles/2108/11/news006.html