システム刷新の発注は、社内準備から契約締結、段階的な移行と現場定着まで、次の5段階で進みます。
- 社内準備で、現行システム、業務要件、体制、予算を整理する。
- RFPに、刷新の範囲、要求、予算、選定条件をまとめる。
- 複数社の提案を比べ、実績を確かめたうえで依頼先を選ぶ。
- 契約形態、SLA、責任範囲を確認し、契約を締結する。
- 段階的に移行し、進捗を管理しながら現場への定着を進める。
スルガ銀行と日本IBMが争った総額95億円の白紙撤回訴訟など、失敗の多くは発注の作法を守れなかったことに起因しています。各段階の全体像は、次の完全ガイドでも解説しています。
▼全体ガイドの記事
・システム刷新の完全ガイド
レガシーシステム刷新を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「レガシーシステム刷新の完全ガイドブック」で詳しく解説しています。
発注前にやるべき社内準備
システム刷新は、外部ベンダーへ発注する前の社内準備で8割が決まるといわれます。要件が曖昧なまま発注に進むと、後工程で仕様変更が続けて起こり、コストもスケジュールも膨らみます。
そのため、現行業務の棚卸し、キーパーソンの選出、予算の確保という三つの準備を、発注前に確実に行うことが大切です。この三つが、発注成功の土台になります。
現行システムの棚卸しとAs-Is/To-Be分析
最初に行うのは、現行システム(As-Is)の構成や機能、データ、外部連携を網羅的に可視化する作業です。業務マニュアルに載らない例外処理やExcelでの回避運用は、要件漏れの原因になりやすい部分です。そのため、現場のキーパーソンにヒアリングし、画面や帳票から連携先までを一覧にしておくことが重要です。
次に、刷新後のあるべき姿(To-Be)を業務プロセスから設計します。キングジムは10億円規模の刷新で最高額の提案を選びました。その選定理由は、「旧システムの構成を全部洗い出す」と明言した点にありました。したがって、As-Isを徹底的に可視化できる会社こそ、成功への道筋を描けます。
逆に、スルガ銀行と日本IBMの裁判では、自社の業務要件に合わないパッケージを前提に選定した結果、業務と合わずプロジェクトが頓挫しました。IBM側には約42億円の賠償命令が下っています。さらに、As-Is/To-Be分析を怠ると、数十億円規模の損失につながります。
社内の「システムキーパーソン」の選出と部門間調整
システム刷新は、営業や経理、製造、物流など関連する全部門が関わって進みます。そのため、各部門から「システムキーパーソン」を選ぶことが大切です。たとえば、ある食品加工工場では、各部署から1名ずつキーパーソンを選び、週次で会議を開くことで、部門間の利害調整をスムーズに進めることに成功しました。
キーパーソンには、業務を最も理解している中堅クラスを推薦する企業が多いです。ただし、同時に意思決定できる課長から部長クラスも巻き込むことが必須です。そのうえで、現場代表と決裁層の二層で構成すると、要件の深さと合意形成のスピードを両立できます。
この体制づくりを怠ると、後工程で「聞いていない」「うちの部署の業務は違う」といった反発が必ず生じます。その結果、仕様変更や追加要件が膨らみ、スケジュール遅延とコスト超過を招きます。そのため、社内合意形成は発注前に完了させることが鉄則です。
予算確保のための稟議書に盛り込むべき情報
稟議書は、「なぜ今刷新が必要か」と「刷新しないとどれだけ損をするか」を定量的に示す資料です。サポート切れによる障害リスクや保守コストの増加率、業務非効率による人件費ロスを金額に換算して示すと、経営層の納得を得やすくなります。
予算には、次の5つを必ず盛り込みます。①初期開発費(要件定義〜本番リリースまで)、②移行費(データ移行・並行稼働)、③教育費(研修・マニュアル整備)、④運用保守費(年額、初期費の15〜20%が目安)、⑤予備費(想定外対応、全体の10〜15%)です。⑤を削ると、ほぼ確実に赤字プロジェクトになります。
システム刷新の進め方全体の流れについては、システム刷新の進め方で詳しく解説しています。費用相場の詳細はシステム刷新の費用相場をご覧ください。
RFP(提案依頼書)の作り方【実務テンプレート】
RFP(Request for Proposal=提案依頼書)は、ベンダーに「何を・いつまでに・いくらで・どう実現してほしいか」を明確に伝えるための設計図です。RFPの質が低いと、ベンダーごとに解釈がばらつき、比較評価そのものが成り立ちません。そこで、実務で使えるテンプレートとして、RFPに盛り込むべき項目を具体的に挙げます。
RFPに記載すべき項目と書き方のポイント
RFPに盛り込むべき主な項目は、次のとおりです。①プロジェクト概要(背景・目的・経営課題)を書きます。
②対象業務範囲とシステム範囲(スコープの明確化)を定めます。
③現行システムの概要(As-Is:機能・構成・データ量・連携先)を載せます。
④刷新後の要求(To-Be:機能要件・非機能要件・業務フロー)を書きます。
⑤想定予算レンジ(上限と下限の目安)を示します。
残りの項目は次のとおりです。⑥スケジュール(RFI提示日・提案書提出日・選定日・稼働予定日)。
⑦評価基準(価格・技術・実績・体制・保守などの配点)。
⑧提案書に含めてほしい内容(見積明細・体制図・類似実績・リスク分析)。
⑨契約条件の前提(契約形態・著作権・再委託・秘密保持)。
⑩問合せ窓口とQ&A期限を明記します。
特に⑤の想定予算は、「開示しないほうがよい」という意見もあります。一方で、実務では上下限のレンジを示したほうが、各社の提案の現実性が高まり、比較しやすくなります。オープンにするかどうかは、社内ポリシーと相場観に応じて判断するとよいでしょう。
現場ニーズと業務フローの反映方法
RFPで最も重要なのは、現場の業務フローを具体的に記述することです。「経費精算システムを刷新したい」という一文では、ベンダーに必要な情報は伝わりません。たとえば、「月間処理件数3000件、承認階層は課長→部長→経理の3階層、交通系ICカード連携必須、インボイス対応必須」のように、具体的な数値や要件を示します。
業務フロー図はBPMN(Business Process Model and Notation)形式で添付すると、ベンダー側の誤読が減ります。加えて、フロー図と併せて画面遷移のラフスケッチやデータ項目一覧を提供すると、提案の精度が高まります。
比較しやすい提案を引き出すためのRFP設計
ベンダー提案を比較しやすくするには、RFPで記載フォーマットを指定することが有効です。見積書のWBS粒度や工数単価の内訳、体制図のテンプレート、類似実績の記載項目(業種・規模・金額・期間)などを統一すれば、価格と品質を横並びで比べられます。
さらに、質疑応答(Q&A)の期限と回答方法を明示し、回答を全社共通で開示する運用にすると、情報格差をなくして公平性を保てます。Q&Aのやり取りからは、ベンダーの本気度や理解力も評価できるため、選定判断の材料にもなります。
ベンダー比較・選定プロセスの進め方
RFPを配布したら、複数ベンダーの提案を公平に比較し、最適なパートナーを選定します。ここで判断を誤ると、プロジェクト全体が瓦解します。
そこで、最低3社からの提案取得、評価マトリクスの作成、リファレンスチェックの3ステップを踏みます。これにより、客観的な選定が可能になります。
最低3社からの提案取得と評価基準の設定
提案は最低3社から取得するのが鉄則です。1社だけでは相場観が分からず、2社だと比較になりません。3社以上あってはじめて、価格の妥当性や提案内容の深さ、体制の強さを相対評価できます。
評価基準の配点は、提案依頼時に決めておき、経営課題に応じて調整します。例として、次の計100点の構成が一般的です。
①機能要件の充足度20点。
②非機能要件(性能・可用性)15点。
③技術力・アーキテクチャ15点。
④プロジェクト管理体制15点。
⑤類似実績10点。
⑥価格15点。
⑦サポート体制10点です。
キングジムの事例では、最高額の提案を出したJQ社が選定されました。理由は、価格よりも「旧システムの構成を全部洗い出す」という、成功への道筋の明確さでした。「最安値」より「成功確度が最も高い提案」を基準に選ぶことが、長期的なコスト最適化につながります。
提案内容の比較評価マトリクス
複数社の提案を比べるには、評価マトリクスをExcelで作成するのが有効です。縦軸にベンダー名、横軸に評価項目を置き、各項目の配点とスコアを記入します。スコアは1〜5点の5段階評価が現実的で、コメント欄には強みと懸念点を書き添えます。
複数の評価者(情報システム部門・現場・経営層)が独立してスコアを付け、後で擦り合わせる「デルファイ方式」も有効です。個人の主観が平均化され、より客観的な判断ができます。
評価マトリクスは選定後の稟議書にも添付でき、記録として残しておくと役立ちます。さらに、「なぜこの会社を選んだか」を文書で説明できる状態にしておけば、プロジェクト中の意思決定にも説得力が生まれます。
リファレンスチェックの実施手順【独自テクニック】
リファレンスチェックとは、候補ベンダーの過去クライアントに直接連絡を取り、実態を確かめる独自の調査手法です。提案書には成功事例しか載らないため、失敗やトラブルは元クライアントに聞くのが最短ルートです。たとえば、ある金融機関では、最終候補ベンダーの過去プロジェクトで大幅な遅延があったことを、リファレンスチェックで発見し、選定を覆しています。
具体的な手順は次のとおりです。①ベンダーに過去クライアント2〜3社の連絡先提供を依頼する。
②電話または対面で情報システム責任者にヒアリングする。
③確認項目:スケジュール遵守率・追加見積の発生有無・PM品質・現場の満足度・保守対応の質。
④ベンダー経由ではない独自ルート(同業界の人脈・業界団体・SNS)でも情報収集する。
⑤入手情報を評価マトリクスに反映する。
ヒアリング時は、「良かった点」だけでなく「もう一度頼みますか?」「何か懸念はありましたか?」と具体的に聞くのがコツです。抽象的な褒め言葉より、実際の出来事を聞き出すことで、候補ベンダーの素の実力が見えてきます。なお、具体的な会社比較はシステム刷新おすすめ会社で詳しく紹介しています。
契約締結のチェックリスト
契約書は、プロジェクトが順調なうちは開く機会がなく、トラブル時に命綱になります。スルガ銀行や2025年のNHK訴訟でも、契約上の権利義務が裁判の焦点になりました。
契約形態の選択、SLA、瑕疵担保・損害賠償の3点は、発注前に法務を含めて徹底的に確認する必要があります。
請負契約と準委任契約の選択基準
システム開発の契約形態には、大きく請負契約と準委任契約があります。請負契約は成果物の完成を約束し、ベンダー側が納期や品質の責任を負います。準委任契約は役務の提供を約束する契約で、成果物の完成義務はなく、善管注意義務を負う形です。
要件定義やPoC、アジャイル開発など、要件が流動的なフェーズには準委任が向いています。一方で、仕様が確定した後の開発フェーズには請負が適切です。また、プロジェクト全体を一括請負にすると、要件変更のたびに追加見積が発生し、関係悪化の原因になります。
解除の作法も異なり、請負は完成前ならいつでも解除できますが、発注者が損害を賠償する必要があります(民法641条)。準委任は相互にいつでも解除できますが(民法651条)、相手方に不利な時期の解除は損害賠償の対象です。そのため、この点を契約条件として確かめつつ、炎上時の撤退も見据えて、どの段階でどの契約を結ぶかを設計することが大切です。
SLA(サービスレベル合意)の具体的な設定項目
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の大型訴訟は、いずれも契約や要件の詰めが甘かったことが根本原因であり、発注の作法を守れば回避できる失敗です。
特に重要なのは、次の5点です。最低3社からの提案取得とリファレンスチェック、請負と準委任の使い分け、SLAと契約不適合責任の数値化、チェンジマネジメントとデジタルデバイド対応です。「最安値」より「成功への道筋を明確に示せるパートナー」を選ぶ視点が、長期的な投資対効果を最大化します。
システム刷新全体を体系的に理解したい方はシステム刷新完全ガイドをご覧ください。進め方の詳細は進め方ガイド、会社選定はおすすめ会社、費用感は費用相場を参考にしてください。
株式会社riplaは、コンサルティングから開発・運用定着まで一気通貫で支援できる体制を整えています。IT事業会社として社内DXを推進してきた経験を活かし、ビジネス成果の創出とシステム定着に強みがあります。基幹システムの刷新発注でお悩みの方は、ぜひ一度ご相談ください。
▼全体ガイドの記事
・システム刷新の完全ガイド
RFP作成前に読みたい無料ホワイトペーパーをご覧ください。
レガシーシステム刷新の完全ガイドブックをご覧いただけます。
【2026年最新版】AI駆動開発の完全ガイドブックもご覧いただけます。
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。