システム刷新の発注/外注/依頼/委託方法について

システム刷新の発注は、進め方次第で成果が大きく変わる重要な意思決定です。実際にスルガ銀行と日本IBMが争った総額95億円の白紙撤回訴訟、NHKと日本IBMの2025年2月の契約解除訴訟、みずほ銀行のATM障害など、失敗の多くは「発注の作法」を守れなかったことに起因しています。逆にキングジムは10億円規模の刷新で最高額の提案を選び「旧システムの構成を全部洗い出す」と明言した企業を選定し、成功への道筋をつけました。

この記事では、システム刷新を外部へ発注・外注・委託する際に、社内準備からRFP作成、ベンダー比較、契約締結、プロジェクト管理、現場定着までの一連の流れを実務レベルで解説します。請負契約と準委任契約の使い分け、SLA設定、瑕疵担保責任の交渉ポイント、デジタルデバイドへの対応など、他の解説記事ではあまり触れられない独自の切り口も盛り込みました。この記事を読めば、発注担当者として押さえるべきポイントを網羅的に理解でき、失敗確率を大幅に下げられます。

本テーマに関する全体ガイドは、以下の記事をご覧ください。

▼全体ガイドの記事
・システム刷新の完全ガイド

システム刷新を発注する前にやるべき社内準備

システム刷新は外部ベンダーへ発注する前の「社内準備」で8割が決まるといわれます。要件が曖昧なまま発注に進めば、後工程で仕様変更が連発し、コストもスケジュールも膨らみます。現行業務の棚卸し、キーパーソンの選出、予算の確保という三つの準備を確実に行うことが、発注成功の土台になります。

最初にやるべきは、現行システム(As-Is)の構成・機能・データ・外部連携・運用フローを網羅的に可視化する作業です。業務マニュアルに載らない「例外処理」や「Excelでの回避運用」ほど要件漏れの原因になります。現場のキーパーソンにヒアリングし、画面・帳票・データ項目・連携先まで一覧化することが重要です。

次に、刷新後のあるべき姿(To-Be)を業務プロセスから設計します。キングジムが10億円規模の刷新で最高額の提案を選んだ際、選定理由は「旧システムの構成を全部洗い出す」と明言した点にありました。つまり、As-Isを徹底的に可視化できる会社こそ、成功への道筋を描けるということです。

逆にスルガ銀行と日本IBMの裁判では、自社業務要件に合わないパッケージを前提として選定した結果、業務と合わずプロジェクトが頓挫し、IBM側に約42億円の賠償命令が下っています。As-Is/To-Be分析を怠ると、数十億円規模の損失につながる点を肝に銘じるべきです。

システム刷新は情報システム部門だけでは完結しません。営業・経理・製造・物流など、関連する全部門から「システムキーパーソン」を選出することが重要です。ある食品加工工場の事例では、各部署からキーパーソンを1名ずつ選出し、週次で会議体を持つことで、部門間の利害調整をスムーズに進めることに成功しました。

キーパーソンには「業務を最も理解している中堅クラス」を推薦する企業が多いですが、同時に意思決定できる「課長〜部長クラス」も巻き込むことが必須です。現場代表と決裁層の二層で構成すると、要件の深さと合意形成スピードを両立できます。

この体制づくりを怠ると、後工程で「聞いていない」「うちの部署の業務は違う」といった反発が必ず生じます。結果として仕様変更・追加要件が膨らみ、スケジュール遅延とコスト超過を招きます。社内合意形成は発注前に完了させることが鉄則です。

稟議書は「なぜ今刷新が必要か」「刷新しないとどれだけ損するか」を定量的に示す資料です。サポート切れによる障害リスク、保守コストの増加率、業務非効率による人件費ロスなどを金額換算して示すと、経営層の納得を得やすくなります。

予算には以下を必ず盛り込みます。①初期開発費(要件定義〜本番リリースまで)②移行費(データ移行・並行稼働)③教育費(研修・マニュアル整備)④運用保守費(年額、初期費の15〜20%が目安)⑤予備費(想定外対応、全体の10〜15%)です。⑤を削ると、ほぼ確実に赤字プロジェクトになります。

システム刷新の進め方全体の流れについては、システム刷新の進め方で詳しく解説しています。費用相場の詳細はシステム刷新の費用相場をご覧ください。

RFP(提案依頼書)の作り方【実務テンプレート】

RFP(Request for Proposal=提案依頼書)は、ベンダーに「何を・いつまでに・いくらで・どう実現してほしいか」を明確に伝えるための設計図です。RFPの質が低いと、ベンダーごとに解釈がばらつき、比較評価そのものが成立しません。ここでは実務テンプレートとしてRFPに盛り込むべき項目を具体的に示します。

RFPに盛り込むべき主な項目は以下のとおりです。

①プロジェクト概要(背景・目的・経営課題)
②対象業務範囲とシステム範囲(スコープの明確化)
③現行システムの概要(As-Is:機能・構成・データ量・連携先)
④刷新後の要求(To-Be:機能要件・非機能要件・業務フロー)
⑤想定予算レンジ(上限と下限の目安)
⑥スケジュール(RFI提示日・提案書提出日・選定日・稼働予定日)
⑦評価基準(価格・技術・実績・体制・保守などの配点)
⑧提案書に含めてほしい内容(見積明細・体制図・類似実績・リスク分析)
⑨契約条件の前提(契約形態・著作権・再委託・秘密保持)
⑩問合せ窓口とQ&A期限

特に⑤の想定予算は「開示しないほうがよい」という意見もありますが、実務では上下限レンジを示したほうが各社の提案の現実性が高まり、比較しやすくなります。オープンにするか否かは、社内ポリシーと相場観に応じて判断しましょう。

RFPで最も重要なのは、現場の業務フローを具体的に記述することです。「経費精算システムを刷新したい」と書くだけでは足りません。「月間処理件数3000件、承認階層は課長→部長→経理の3階層、交通系ICカード連携必須、インボイス対応必須」といった具体の数値・要件を盛り込みます。

業務フロー図はBPMN(Business Process Model and Notation)形式で添付すると、ベンダー側の誤読が減ります。フロー図と併せて、画面遷移のラフスケッチやデータ項目一覧を提供すると、提案精度がさらに高まります。

ベンダー提案を比較しやすくするには、RFPで「記載フォーマット」を指定することが有効です。見積書のWBS粒度、工数単価の内訳、体制図のテンプレート、類似実績の記載項目(業種・規模・金額・期間)などを統一すれば、価格と品質を横並び比較できます。

また、質疑応答(Q&A)の期限と回答方法を明示し、全社共通で回答を開示する運用にすると、情報格差がなくなり公平性が保たれます。Q&Aのやり取りからベンダーの本気度や理解力も評価できるため、選定判断の材料にもなります。

ベンダー比較・選定プロセスの進め方

RFPを配布した後は、複数ベンダーの提案を公平に比較し、最適なパートナーを選定します。ここで判断を誤ると、プロジェクト全体が瓦解します。最低3社からの提案取得、評価マトリクスの作成、リファレンスチェックの3ステップを踏むことで、客観的な選定が可能になります。

提案は最低3社から取得するのが鉄則です。1社だけでは相場観が分からず、2社だと比較になりません。3社以上あってはじめて、価格の妥当性・提案内容の深さ・体制の強さを相対評価できます。

評価基準は提案依頼時に配点を決めておきます。例として①機能要件の充足度20点②非機能要件(性能・可用性)15点③技術力・アーキテクチャ15点④プロジェクト管理体制15点⑤類似実績10点⑥価格15点⑦サポート体制10点の計100点構成が一般的です。配点は経営課題に応じて調整します。

キングジムの事例では、最高額の提案を出したJQ社が選定されました。理由は価格より「旧システムの構成を全部洗い出す」という成功への道筋の明確さです。「最安値」で選ぶのではなく「成功確度が最も高い提案」で選ぶことが、長期的なコスト最適化につながります。

複数社の提案を比較するには、評価マトリクスをExcelで作成するのが有効です。縦軸にベンダー名、横軸に評価項目を置き、各項目の配点とスコアを記入します。スコアは「1〜5点」の5段階評価が現実的で、コメント欄に「強み・懸念点」を書き添えます。

複数の評価者(情報システム部門・現場・経営層)が独立してスコア付けし、後で擦り合わせる「デルファイ方式」も有効です。個人の主観が平均化され、より客観的な判断ができます。

評価マトリクスは選定後の稟議書添付資料としても使えるため、記録として残すことが重要です。「なぜこの会社を選んだか」を文書で説明できる状態にしておくことで、プロジェクト中の意思決定にも説得力が生まれます。

リファレンスチェックとは、候補ベンダーの「過去クライアント」に直接連絡を取り、実態を確認する独自の調査手法です。提案書には成功事例しか載らないため、失敗やトラブルの実態は元クライアントに聞くのが最短ルートになります。ある金融機関では、最終候補ベンダーの過去プロジェクトで大幅遅延があったことをリファレンスチェックで発見し、選定を覆しています。

具体的な手順は以下のとおりです。

①ベンダーに過去クライアント2〜3社の連絡先提供を依頼する
②電話または対面で情報システム責任者にヒアリング
③確認項目:スケジュール遵守率・追加見積の発生有無・PM品質・現場の満足度・保守対応の質
④ベンダー経由ではない独自ルート(同業界の人脈・業界団体・SNS)でも情報収集
⑤入手情報を評価マトリクスに反映

ヒアリング時は「良かった点」だけでなく「もう一度頼みますか?」「何か懸念はありましたか?」と具体的に聞くのがコツです。抽象的な褒め言葉より、実際の出来事を聞き出すことで、候補ベンダーの素の実力が見えてきます。

具体的な会社比較はシステム刷新おすすめ会社で詳しく紹介しています。

契約締結のチェックリスト

契約書はプロジェクトが順調な時には見ることがなく、トラブル時に命綱になります。スルガ銀行や2025年のNHK訴訟でも、契約上の権利義務が裁判の焦点になりました。契約形態の選択、SLA、瑕疵担保・損害賠償の3点は、発注前に法務を含めて徹底的に確認すべきです。

システム開発の契約形態には大きく「請負契約」と「準委任契約」があります。請負契約は「成果物の完成」を約束する契約で、ベンダー側が納期・品質責任を負います。準委任契約は「役務の提供」を約束する契約で、成果物の完成義務はなく善管注意義務を負う形です。

要件定義・PoC・アジャイル開発など、要件が流動的なフェーズは準委任が向いています。一方で、仕様が確定した後の開発フェーズは請負が適切です。プロジェクト全体を一括請負にすると、要件変更のたびに追加見積が発生し、関係悪化の原因になります。

解除の作法も異なります。請負は完成前ならいつでも解除できますが、発注者が損害を賠償する必要があります(民法641条)。準委任は相互にいつでも解除可能(民法651条)ですが、相手方に不利な時期の解除は損害賠償対象です。プロジェクト炎上時の撤退戦略として、どの段階でどの契約を結ぶかの設計が重要になります。

SLA(Service Level Agreement)は、運用保守フェーズでベンダーが提供するサービス水準を数値で定義するものです。曖昧な契約だと、障害時にどこまでベンダーが責任を負うかで揉めるため、発注前に具体的な数値で合意しておくことが必要です。

SLAに盛り込む主な項目は以下です。

①稼働率(例:月間99.9%以上)
②障害検知から一次対応までの時間(例:重大障害は30分以内)
③復旧目標時間(RTO:例:4時間以内)
④データ損失許容量(RPO:例:1時間以内)
⑤問合せ対応時間(平日9〜18時/24時間365日)
⑥未達時のペナルティ(返金率・契約解除条件)

SLA違反時のペナルティは、月額保守費の10〜30%の返金が一般的です。金額だけでなく「3カ月連続違反時は契約解除可能」などのエスカレーション条項も盛り込むと、ベンダーへの牽制になります。

2020年の民法改正で「瑕疵担保責任」は「契約不適合責任」に改称されました。請負契約では、成果物に不具合があった場合、ベンダーに追完請求・代金減額・損害賠償・契約解除を求められます。発注者が不具合を知った時から1年以内に通知すれば権利が保全されます。

契約交渉の重要ポイントは以下です。

①契約不適合責任の期間は「検収後1年以上」を明記する(ベンダー提示テンプレートは3〜6カ月が多く、交渉で延長)
②追加費用の発生条件を具体的に定義する(要件追加、スコープ変更、外部要因など)
③損害賠償の上限は「契約金額の100%」が標準だが、重過失の場合は無制限とする条項を入れる
④ベンダーの免責事項(発注者の指示ミス、第三者の侵害など)を明確にする

スルガ銀行訴訟でIBMが約42億円の賠償命令を受けたケースは、契約不適合責任だけでなく「プロジェクトマネジメント義務違反」が問われた事例です。ベンダーには要件定義段階から適切なリスク通知義務があるとされ、これを契約にも盛り込むとベンダー責任を明確化できます。

発注後のプロジェクト管理と現場定着

発注は「ゴール」ではなく「スタート」にすぎません。発注後のプロジェクト管理と現場定着の巧拙で、投資対効果が大きく変わります。チェンジマネジメント・デジタルデバイド対応・段階的移行の3つは、競合記事でもあまり触れられない実務上の重要テーマです。

チェンジマネジメントとは、組織変革を成功に導くための体系的な手法です。システム刷新は「IT更新」ではなく「業務改革」であり、現場の行動変容が伴わなければ成果は出ません。みずほ銀行のATM障害も「失点を恐れて積極的行動を取らない」組織風土が根本原因と指摘されています。

実務では「スポンサーロードマップ」を作成します。経営層(Executive Sponsor)→部門長→中間管理職→現場リーダーの順に変革メッセージを伝達し、各層が責任を持って下位層に浸透させる仕組みです。経営層が1回メッセージを出しただけでは現場は動きません。スポンサー層が継続的にコミットする体制づくりが鍵になります。

ADKARモデル(Awareness→Desire→Knowledge→Ability→Reinforcement)を活用し、現場の認識・欲求・知識・能力・定着を段階的に引き上げるのも有効です。研修・マニュアル・サポート窓口・成功事例の共有をフェーズごとに設計することで、現場の抵抗を最小化できます。

デジタルデバイドとは、従業員間のITリテラシー格差のことです。高齢従業員や現場作業者にITアレルギーがあると、せっかくの新システムが使われずに終わります。中堅製造業の現場では、ベテラン従業員が「新システムは使いにくい」と紙運用に戻り、データが二重管理になった事例もあります。

対応策は以下のとおりです。

①UI/UX設計で大きなボタン・少ない画面遷移・日本語ラベルを徹底する
②初期3カ月は「紙との一時的併用」を認め、強制移行しない
③現場ごとに「デジタルメンター」を配置し、日常的にサポートを受けられる体制を作る
④段階研修(座学→ハンズオン→実務OJT)で3段階で習熟度を上げる
⑤マニュアルは動画化(2〜3分の短尺)し、スマホでもすぐ参照できるようにする

「全員に一度に完璧を求めない」ことが重要です。60点で使える状態から、80点、90点と段階的に引き上げるアプローチが、結果的に最も定着率を高めます。完璧主義は現場の反発を招き、プロジェクトそのものを頓挫させるリスクがある点を認識すべきです。

システム刷新の移行方式には「一括切替」「段階的移行」「並行稼働」の3つがあります。NHK・日本IBM訴訟(2025年2月)では、100%完全移行を前提にしたことがプロジェクト頓挫の一因とされ、契約解除に至っています。100%移行の非現実性を前提に、段階的移行と並行稼働を組み合わせるのが実務的な解です。

段階的移行では「部門別」「機能別」「地域別」のいずれかの軸で、小さく切り出して順次リリースします。PoC(概念実証)で1部門先行導入し、課題を洗い出してから全社展開するアプローチが、最もリスクが低い方式です。

並行稼働は旧システムと新システムを一定期間同時運用し、新システムの安定性を確認する手法です。並行稼働期間中は運用コストが増えますが、障害時の切り戻しが可能なため、基幹システム刷新では2〜3カ月の並行稼働が標準的です。

内製化の流れも広がっていますが、IT人材枯渇と単価高騰は深刻です。2026年の国内フリーランス単価はRust 93.7万円、Go 87.0万円、TypeScript 85.5万円と上昇しており、優秀なエンジニアの確保は容易ではありません。ローコード・ノーコードにも限界があるため、外部パートナーとの協業体制を前提に設計することが現実的です。

まとめ

システム刷新の発注を成功させる鍵は、社内準備・RFP・ベンダー選定・契約・現場定着の5ステップを丁寧に設計することです。スルガ銀行やNHKのような大型訴訟は、いずれも契約や要件の詰めが甘かったことが根本原因であり、発注の作法を守れば回避できる失敗です。

特に重要なのは、最低3社からの提案取得とリファレンスチェック、請負と準委任の使い分け、SLAと契約不適合責任の数値化、チェンジマネジメントとデジタルデバイド対応の5点です。「最安値」ではなく「成功への道筋を明確に示せるパートナー」を選ぶ視点が、長期的な投資対効果を最大化します。

システム刷新全体を体系的に理解したい方はシステム刷新完全ガイドをご覧ください。進め方の詳細は進め方ガイド、会社選定はおすすめ会社、費用感は費用相場を参考にしてください。

株式会社riplaは、コンサルティングから開発・運用定着まで一気通貫で支援できる体制を整えています。IT事業会社として社内DXを推進してきた経験を活かし、ビジネス成果の創出とシステム定着に強みがあります。基幹システムの刷新発注でお悩みの方は、ぜひ一度ご相談ください。

▼全体ガイドの記事
・システム刷新の完全ガイド

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。