SNAMO Logo
SNAMO
システム開発の勝敗は「発注」で決まる。脱・丸投げの具体策

システム開発の勝敗は「発注」で決まる。脱・丸投げの具体策

11 min read

システム開発の勝敗は、現場の声と発注の設計次第です。丸投げが続くと要件はブラックボックス化し、予算超過と納期遅延が常態化します。この記事は、自社語での要件定義、RFPの有効活用、複数社競争による公正な提案、現場とベンダーを“翻訳者”として結ぶ具体策を、段階的にわかりやすく解説します。

01

第1章:丸投げの代償と現場の叫び

第1章:丸投げの代償と現場の叫び - 本文

第1章:丸投げの代償と現場の叫び

朝一の会議室。小規模IT部門のリーダー、高野翔は机の上に積まれた見積書とスケジュール表をじっと見つめていた。取引先ベンダーは「要件は後で詰めればよい」と楽観的だが、現場の声は薄く、数字だけが先走っている。過去のプロジェクトは丸投げの結果、コストが3倍に膨らみ、納期は2年遅延、設計は何度もブラックボックス化した──翔の頭には失敗のパターンが鮮明だった。

客観的なデータも背中を押す。AIプロジェクトの失敗率は約85%とされ、PoC(概念実証)疲れや、PoCから本番移行で約90%が課題に直面するという現実がある。日本企業のDX成果が20〜30%に留まる背景には、要求の曖昧さ、ベンダーロックイン、現場と開発の翻訳不在がある。現場の業務フローは明確でも、それをベンダー仕様へ翻訳する“橋渡し”が欠けているため、必要な機能が後づけになり、仕様はブラックボックス化する。

翔は嘆くだけで終わらせない。発注の設計で勝敗が決まるなら、まず「自社語での要件定義」と「RFP(提案依頼書)の整備」から始めるべきだと決めた。具体策の方向性は明確だ。目的とKPIを自社用語で書き、業務フローと優先度を現場視点で整理する。RFPでは比較可能な評価基準と受け入れ基準(PoVの合格条件)を明示し、複数社の競争を促して提案の質と公正性を担保する。非機能要件には「IaCやマルチクラウド対応」「ベンダー依存を減らす移行経路」を盛り込み、内製化やリスキリングの計画も要件の一部として提示する──これが翔の第一歩だった。

用語集

  • PoC(Proof of Concept): 技術的実現性を検証する試験的な実装。短期で行うが、実運用への移行が課題になりやすい。
  • PoV(Proof of Value): 価値を示す検証。成果や効果を評価する点でPoCと区別される。
  • RFP(Request for Proposal): 提案依頼書。要件や評価基準を明示して複数社から公平に提案を募る文書。
  • ベンダーロックイン: 特定ベンダーに依存しやすくなる状態。後の変更や移行が難しくなるリスク。
  • マルチクラウド: 複数のクラウドサービスを併用する設計。依存軽減と柔軟性を高める。
  • IaC(Infrastructure as Code): インフラ構成をコードで管理する手法。再現性と移行性を高める。
  • リスキリング: 社員の技能を新たに学び直すこと。内製化や運用継続のために重要。
02

第2章:PoC疲れと現場の壁

第2章:PoC疲れと現場の壁 - 本文

第2章:PoC疲れと現場の壁

数か月後、DX推進室が走らせたAIによる受発注自動化のPoCは、期待ほどの成果を出せなかった。関係者の間に「PoCは終わったが本番には至らない」という空気が漂い、現場リーダーの高橋の「98%の精度を求めても現場は使えない。残る“5%”を埋めるのは現場の運用と組織改革だ」という言葉が重く響く。業界統計も追い風にはならない。AIプロジェクトの失敗率は約85%とされ、日本企業のDX成果は20–30%程度に留まるという現実がある。

なぜPoC疲れは起きるのか。構造的要因は主に次の4点に集約される。

  1. データ品質と運用ギャップ
    PoCは「技術検証」に集中しがちで、現場データのノイズや欠損、運用ルールの揺らぎを見落とす。モデルが学習した環境と現場運用の乖離が、本番移行時の精度低下を招く。

  2. 組織的受容性の欠如
    現場の業務フローやKPIが設計に取り込まれていないと、ツールは現場に刺さらない。意思決定の責任分担や評価インセンティブが整っていないことも定着を妨げる。

  3. 技術的制約とベンダーロックイン
    インフラ設計が再現性・移行性を考えていないと、本番化でコスト跳ね上がりが発生する。IaCやAPIファースト、マルチクラウドを欠くとベンダー依存が深まる。

  4. 人材と学習環境の不足
    内製化とリスキリングの取り組み不足で、現場が運用・改善できる体制が育たない。LMS等で継続学習の仕組みを回していない企業が多い。

これらを踏まえた具体策(段階的)

  • PoC設計段階で「現場KPI」を明確化し、受容基準を定量化する(例:業務削減分、誤検知率、処理時間)。
  • 初期データの品質アセスメントを必須化し、データ整備(クレンジング、ラベリング)工程を計画に組み込む。
  • スモールスタートで現場担当を必須メンバーに据え、改善ループ(運用→フィードバック→モデル更新)を運用設計する。
  • IaCやAPIファースト設計、マルチクラウド対応で移行コストとロックインリスクを下げる。
  • 内製化ロードマップとリスキリング計画をLMSで回し、PoC後の運用担当を育てる。GPT-5-mini等の生成AI活用は補助と捉え、説明性とガバナンス設計を同時に行う。
  • 複数ベンダーによる競争的提案でRFPを精緻化し、ベンダー評価に「本番移行力」を明確基準に加える。

PoCは技術検証だけで終わらせず、組織の受容性と継続運用の「準備度」を測る試金石に変えることが、本章が示す本質である。

用語集

  • PoC:概念実証。技術やアイデアが実務で機能するかを小規模に検証する手法。
  • ベンダーロックイン:特定ベンダーの技術や契約に依存し、移行が困難になる状態。
  • 内製化:自社で開発・運用すること。外注に頼らずノウハウを蓄積する目的がある。
  • リスキリング:業務に必要な新しいスキルを社員に習得させること。
  • IaC(Infrastructure as Code):インフラ構成をコードで定義・管理する手法。再現性と自動化を高める。
  • APIファースト:サービスをAPI中心に設計し、連携性と拡張性を確保する開発方針。
  • マルチクラウド:複数のクラウド事業者を併用することで可用性と柔軟性を高める戦略。
  • LMS(Learning Management System):教育・研修を管理するシステム。継続的な学習に使う。
  • GPT-5-mini:次世代の生成AIモデルの一例(仮名)。導入時は説明性と運用ルールを検討すること。
03

第3章:RFPという攻めの道具

第3章:RFPという攻めの道具 - 本文

第3章:RFPという攻めの道具

ある日、翔の前に現れたのはRFP作成のコンサル、佐崎恵那。恵那は「RFPは最強の武器だ」と言い切り、翔に三つの実践ポイントを伝えた。第一は「自社語で作る」──目的と優先度を現場目線で明確化すること。第二は「複数社を競わせる」──公正な条件と評価軸で提案の質を引き上げること。第三は「現場とベンダーの対話を翻訳する」──現場の言葉をシステム要件に変換するリテラシーを養うこと。

実務的には恵那の示した四つのステップを実行する。

  • 業務フローの棚卸しと現場ヒアリングを徹底
  • 目的と優先度を定めた自社語の要件定義書作成
  • RFPテンプレートと評価基準を整え、複数社へ公開
  • ベンダーと対等に渡り合う(非機能要件重視・準委任/請負の使い分け・透明性確保)

ここで取り得るアプローチは主に三つだ。

  • 自社内製(メリット:ノウハウ蓄積・コントロール性。デメリット:人材・時間コスト大)
  • RFPで複数社競争(メリット:提案の質向上・価格競争。デメリット:作成負荷・評価設計の難易度)
  • ハイブリッド(要件自社/実装委託)(メリット:責任分担が明確。デメリット:境界定義があいまいだと齟齬が生じる)

翔は「ここまでは自社でやる、ここからはプロへ」と線引きし、現場とベンダーの会話を“翻訳可能な言葉”へと変える道を選んだ。

RFP:提案依頼書。期待する成果、要件、評価基準を明文化し、複数ベンダーから比較提案を得るための文書。
非機能要件:性能、可用性、セキュリティなど、機能以外の品質条件。
準委任/請負:業務委託の契約形態。準委任は時間・労力に対する報酬、請負は成果物に対する報酬。
IaC/API/マルチクラウド:運用の自動化(IaC)、サービス連携(API)、複数クラウド利用の方針(マルチクラ)を指す。

用語集(簡潔説明)

  • ベンダーロックイン:特定ベンダーに依存して抜けにくくなる状態。
  • 内製化:自社で開発運用を行うこと。
  • PoC:概念実証。実用化前の検証実験。
  • 生成AI:テキストなどを自動生成するAI技術。
  • DX推進:デジタルによる業務変革。
  • オープン戦略:標準や公開APIを活用し依存を減らす方針。
  • マルチクラウド:複数のクラウド事業者を組み合わせる運用。
  • IaC:Infrastructure as Code。構成をコードで管理する手法。
  • 85%AIプロジェクトの失敗率:AI導入が期待通りに行かない高失敗率を示す注意喚起。
  • リスキリング:従業員の技能を再教育すること。
04

第4章:自社語でのRFPと共創の実践

第4章:自社語でのRFPと共創の実践

第4章:自社語でのRFPと共創の実践 - 本文

第4章:自社語でのRFPと共創の実践

翔が取った実行手順をステップ化します。現場が最後まで主体的に活動できるよう、具体的な作業と成果物を明示します。

  1. キックオフ(1日)

    • 営業・現場・ITリーダーを集め目的と評価軸(機能、非機能、価格、TCO)を合意。
    • 成果物:評価軸一覧(重み付け含む)。
  2. 業務フロー棚卸し(2〜3日×ワークショップ)

    • 現場が「どう使うか」を場面ごとに付箋で可視化。現実の操作を撮影・記録。
    • 成果物:業務フロー図、主要画面の手描きモック(現場が使う順序を明示)。
  3. 自社語RFP作成(5〜7日)

    • 「使われ方」をユーザーストーリー化、受け入れ基準(受領テストケース)を明記。
    • 非機能要件(応答時間、可用性、運用負荷)を数値で定義。
    • 成果物:RFP本体、評価シート、PoC範囲(スコープ限定でPoC貧乏を回避)。
  4. 契約枠組み決定(社内ルール化)

    • 準委任⇔請負の境界(責任と成果物の明確化)、変更管理、納品検収プロセスを標準化。
    • ベンダーロックイン回避のため、ソース権利とデータポートビリティを条項化。
  5. 3社競合の実行(4〜6週間)

    • 同一テンプレートで提案要求、実ユーザーによるデモ評価、コストとROI評価。
    • 成果物:スコア化された比較表、上位2案への短期PoC提案。
  6. 選定・導入初期(0〜3ヶ月)

    • 選定ベンダーとSLA・KPI合意、IaCやマルチクラウド方針、運用責任分担を明確化。
    • 成果物:導入ロードマップ、教育計画(リスキリング含む)。
  7. 継続ガバナンス

    • 定期レビューで非機能項目と現場利用状況を評価。生成AIなど新技術導入は小規模PoCで検証。

用語集(簡潔に)

ベンダーロックイン:特定ベンダーに依存し移行が困難になる状態。
準委任/請負:業務委託形態。準委任は作業提供、請負は成果物責任。
PoC貧乏:検証ばかりで本番に進めない状態。範囲制限で防ぐ。
非機能要件:性能・可用性・運用性など定量化すべき要件。
RFP:提案依頼書。自社語で具体的に書くのが肝要。
IaC:Infrastructure as Code。運用をコード化し再現性を高める。
マルチクラウド:複数クラウドを併用する戦略。
デジタルガバナンス:IT利用の方針と管理体制。
リスキリング:現場の技能再教育。

05

第5章:対等な協働と実践の成果

第5章:対等な協働と実践の成果 - 本文

第5章:対等な協働と実践の成果

選定後の実装は「丸投げ」ではなく共創で進んだ。ベンダーとは要件をビジネス語へ翻訳したドキュメントを核に、定例で「動く画面」を確認。3社競争の短期PoC(6週間)を経て、現場が検証可能な成果物(動作画面、テストシナリオ、移行計画)を必須にしたことで意思決定は格段に速くなった。結果、導入後6ヶ月でROIは約40%向上、業務処理速度は30–50%改善、月間約100時間の工数削減を達成。PoC疲れを克服するために短期勝負にし、合意済みKPI(工数削減、応答時間、ROX=従業員体験)で評価する体制を整備した。

技術面では生成AIを検証しつつ、ベンダーロックイン回避のためオープン戦略とマルチクラウドを採用。内製化とリスキリングに投資して運用負荷をコントロールし、データ活用は段階的に本番へ移行した。翔は「技術導入」から「成長戦略の柱」への転換を実感し、投資対効果が明確になったことで継続的改善のサイクルが回り始めた。

用語集

  • PoC:概念実証。短期で技術や効果を検証する試験導入。
  • ROI:投資対効果(Return on Investment)。投資に対する利益率。
  • ROX:顧客・従業員など体験の価値(Return on Experience)。
  • ベンダーロックイン:特定ベンダーの技術に依存し離脱が難しくなる状態。
  • 内製化:自社で開発・運用を行うこと。
  • リスキリング:従業員の技能再教育。
  • データ活用:業務や意思決定にデータを用いること。
  • オープン戦略・マルチクラウド:ベンダー依存を減らすための柔軟なクラウド構成。
06

第6章:学びと今後へ続く道

第6章:学びと今後へ続く道 - 本文

第6章:学びと今後へ続く道

本取り組みで翔が得た本質は、「発注=戦略設計」であり、組織文化と人材育成を伴う再設計が不可欠だということです。技術検証に留まらず、PoCを組織適合性検証に転換し、要件定義を成長戦略に紐づける習慣を作る必要があります。

重要ポイント(要点整理)

  • 要件定義の目的を経営KPIと結び、優先度を明確化する
  • デジタル化DXの違いを理解し、現場とデータのリテラシーを上げる
  • PoCは技術+組織適合性の検証に設計する
  • KPIはアウトカム指標(ROI含む)で定量評価する
  • 内製化と外部パートナーを適切に組合せ、ベンダー依存を解く
  • RFPは自社語で作り、複数社に公正に提示して共創関係を築く

具体的アクション(30/60/90日プラン)

Day0-30: RFP骨子作成(担当: DX推進室)→成果: RFP_v1.md
Day31-60: PoC設計を「組織適合性」項目で拡張(現場1チーム参加)
          KPI設定: ROI目標・業務時間削減・定着率
Day61-90: 複数社RFP提示→短期入札&共創面談→契約条件に内製移行計画を明記

実行上のチェックリスト(例)

  • RFPに「現場オーナー」「移行計画」「KPI(数値)」を明記
  • PoC成果物に「動作画面」「テスト計画」「運用フロー」を必須化
  • リスキリング計画をHRと連携して四半期毎に実施

用語集

  • PoC:技術と運用の初期検証。組織適合性も含める。
  • PoV:ベンダー提案の概念実証。
  • 内製化:自社でソフト開発・運用を行うこと。
  • ベンダーロックイン:特定ベンダーへの依存状態。
  • 生成AI:自動で内容を生成するAI技術。
  • データ活用:業務改善や意思決定にデータを使うこと。
  • ROI:投資対効果(Return on Investment)。
  • HRガバナンス:人材管理と育成の仕組み。
  • リスキリング:既存社員の再教育による技能転換。
  • オープン戦略・マルチクラウド:ロックイン回避のための公開技術と複数クラウド利用。

関連キーワード

要件定義
RFP
PoC/PoV
ベンダーロックイン
内製化リスキリング
PoC疲れ
データ品質
組織的受容性
リスキリング
要件定義(自社語の明確化)

著者について

鈴木信弘(SNAMO)

鈴木信弘(SNAMO)- 静岡県焼津市を拠点に活動する総経験19年のフルスタックエンジニア。AI時代の次世代検索最適化技術「レリバンスエンジニアリング」の先駆的実装者として、GEO(Generative Engine Optimization)最適化システムを開発。2024年12月からSNAMO Portfolioの開発を開始し、特に2025年6月〜9月にGEO技術を集中実装。12,000文字級AI記事自動生成システム、ベクトル検索、Fragment ID最適化を実現。製造業での7年間の社内SE経験を通じて、業務効率75%改善、検品作業完全デジタル化など、現場の課題を最新技術で解決する実装力を発揮。富山大学工学部卒、基本情報技術者保有。

プロフィールを見る

よくある質問

Q1「自社語で要件を定義する」とはどういう意味ですか?どうやって作ればよいですか?
自社語とは業務の現場が普段使うKPIや業務フローを基準に要件を表現することです。抽象的なIT要件やベンダー言葉ではなく、現場の数値目標・成功条件(例:処理時間○分、月間○時間削減、データ品質基準)や具体的な業務シナリオでRFPを作ります。関係者からのヒアリングで業務可視化→KPI化→RFP化の順に整備すると、ベンダーの提案が現場適合性で比較しやすくなります。
Q2丸投げを防ぐ具体的な手順は何ですか?
(1) 現場KPIを明確化、(2) 業務可視化して要件を自社語化、(3) RFPに非機能要件(IaC、API、マルチクラウドなど)を盛る、(4) 複数社の競争と短期PoCで提案の現場適合性を検証、(5) 移行経路と内製化計画をRFPに含める、(6) 導入後のガバナンス・リスキリング計画を作る、という流れを推進します。
Q3PoCはよく失敗するが、原因と対策は何か?
典型的原因はデータ品質・現場運用とPoC条件の乖離、組織受容不足、技術制約やベンダーロック、人材不足です。対策は現場KPIと実データでPoCを設計、小規模で現場運用に近い運用を回す、IaC/API/マルチクラウドなどを非機能要件に入れて本番移行を見据える、組織側の受容性(オーナーシップ)を事前に担保することです。
Q4どうやってベンダーロックインを避けるべきか?
RFP段階でオープン戦略とマルチクラウド対応、Infrastructure as Code(IaC)と標準APIの採用を明確に要件化します。移行経路(データ・コードのエクスポート手順)、契約枠組みの標準化、成果物(画面定義・移行計画・テスト計画)を納品させることで将来の内製化や別ベンダーへの切替えを容易にします。
Q5複数社競争(3社程度)と短期PoCをどう回せば効果的ですか?
まず評価軸(現場KPI、技術要件、コスト、移行可能性)を決め、同じRFP基準で3社に提案させます。短期PoC(記事では6週程度)で現場データ・運用を使って検証し、成果物(動作画面、テスト計画、移行計画)を出させる。審査は現場と技術の双方で行い、透明な比較で選定します。
Q6内製化と外注(プロへ委ねる)をどう最適化すればいいですか?
ハイブリッド戦略で重要なのは「境界を明確にする」こと。コア業務や継続的改善は内製で、基盤構築や専門技術は外注に任せる。RFPに移行経路・ドキュメント・IaCを必須化し、リスキリング計画を並行して立てて現場の運用能力を高めます。これにより運用最適化と将来的な自律化が両立します。
Q7共創PoCの成功指標や得られる成果物は何ですか?
成功指標は現場KPI達成度、本番移行の準備度(データ品質、テスト計画、移行計画の完成度)、組織受容性、技術的移行可能性などです。典型的成果物は動作画面のプロトタイプ、テスト計画、移行計画、ROI試算書。記事の事例ではROI40%、処理改善30–50%、月100時間削減といった定量成果が得られています。
Q8発注を「戦略設計」として扱うには何を変えるべきか?
発注を単なる調達から戦略的行為に変えるには、要件定義を成長戦略やビジネスKPIに紐づけ、PoCを組織適合性検証に転換、発注プロセスに人材育成・組織文化の再設計を組み込むことが必要です。KPIで評価し、ガバナンスと継続的な共創体制(評価→改善のループ)を整えることで発注自体が競争優位の源泉になります。