業務システムリニューアルの発注/外注/依頼/委託方法について

業務システムリニューアルの発注は、業務の整理、RFI・RFPによる選定、契約、契約後の発注者主導の管理という順に進めます。

手戻りを抑え、現場に定着させるには、この流れに沿って進めることが大切です。全体像は業務システムリニューアルの完全ガイドもあわせてご覧ください。

▼全体ガイドの記事
・業務システムリニューアルの完全ガイド

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

業務システムリニューアルの発注前準備

発注前の準備が不足すると、後の工程で手戻りが増えます。そのため、業務フロー、社内体制、発注先の3点を整えてから発注するのが基本です。

現行業務フローの整理と問題点の洗い出し

現行業務が文書になっていないまま発注すると、ベンダーは不完全な情報をもとに設計することになり、完成後に想定とのずれが生じやすくなります。そこで、現場担当者の頭の中にある暗黙知も含めて、業務フローを描き出します。

業務フローは、次の順に整理すると要件へ結び付きます。

• 現場ヒアリング：各部門へ個別またはグループで話を聞き、現場の声を集めます。
• フロー図作成：SwimLaneダイアグラムやBPMN（Business Process Model and Notation）を使い、業務を図式化します。
• 問題点の洗い出し：時間のかかる工程、入力ミス、Excel管理、手動連携を書き出します。
• To-Be設計：導入後の業務の姿を描きます。

ヒアリングでは、どの手順で業務を進め、どのシステムを使っているかを聞きます。ベテラン社員が例外的に行っている処理も、見落とさないよう確認しておきます。

図にすると、誰が何をいつ行うか、どの順序で進むかが一目で分かり、関係者の共通認識をそろえられます。

例外処理や改善要望も記録しておくと、リニューアルで実現すべき要件の土台になります。また、現場担当者の意見を早い段階で取り入れておくことは、導入後の定着にもつながります。

社内体制の構築（IT担当者がいない中小企業も含む）

プロジェクトを成功させるには、発注側が主体となって社内の体制を整えることが欠かせません。ベンダーに全てを任せる姿勢では、うまくいきません。そのため、社内では意思決定と業務確認を担う人をあらかじめ決めておく必要があります。

役割ごとの責任を明確にしておくと、プロジェクトを円滑に進められます。一方で、オーナーが不明確なままだと、重要な判断が先送りされて停滞につながります。

• プロジェクトオーナー：予算や変更、関係者の調整について、経営層や部門長が判断します。
• プロジェクトマネージャー：ベンダーの窓口となり、進捗、課題、日程を管理します。
• 業務担当者：各部門のSME（Subject Matter Expert）として、要件定義、テスト、マニュアル作成に加わります。

専任のIT担当者がいない中小企業でも、発注はできます。たとえば、総務・情報システムの担当者や、業務に詳しい現場リーダーがPMを兼務するケースがあります。

社内に人手が足りない場合は、信頼できる外部コンサルタント（PMO）を頼る方法もあります。PMOは発注者の立場で、ベンダーとの交渉や進捗管理、品質確認を支援します。また、商工会議所やITコーディネータ協会などが、ITプロジェクトの支援を行う場合もあります。

発注先タイプの選択（SIer / パッケージ / SaaS）

発注先は大きく3タイプに分けられます。業務の独自性、費用、運用条件を照らし合わせて選びます。

• SIer：業務に合わせて一から開発します。複雑な独自業務を持つ場合に適します。
• パッケージ：既製品を導入し、必要に応じてカスタマイズする形です。
• SaaS：月額課金のクラウドサービスで、初期費用を抑えやすく、更新も自動で行われます。

SIerは柔軟性が高い一方で、費用と期間がかかります。費用は数百万円〜数千万円以上と幅があります。独自の業務プロセスそのものが競争優位の源泉となる場合に、検討の対象になります。

パッケージはスクラッチ開発より費用を抑えやすく、導入実績があるぶん品質リスクも低めです。ただし、業務とのずれが大きいと、カスタマイズ費用が膨らむおそれがあります。

SaaSでは、データ出力、API連携、終了時のデータ保全方針を押さえておく必要があります。特定のサービスへの依存を避けるためです。

RFIとRFPの作成手順

RFI（情報提供依頼書）とRFP（提案依頼書）は、ベンダー選定に使う文書です。既存システムの制約や移行要件も、発注側から正確に伝えます。

RFI（情報提供依頼）による市場動向の把握

RFI（Request for Information）は、課題を共有したうえで、市場動向や解決策、概算費用をベンダー候補から得るための文書です。RFPの前段階で用いると、検討の精度を高められます。

RFIには、自社の状況と候補に確認したい内容を、次のとおり記載します。

• 自社情報：業種、規模、現在の課題をまとめます。
• 背景・目的・方向性：更新の背景と目的、スクラッチ・パッケージ・SaaS等の想定を示します。
• 現行システム：利用年数、主要機能、既存の問題点を記します。
• 質問事項：類似案件の実績と推奨アーキテクチャを尋ね、概算費用感と開発期間の目安も聞きます。
• 回答方法：回答期限と問い合わせ先を伝えます。

複数社の回答を比べると、市場相場や技術トレンドが見えてきて、有力候補を絞り込めます。また、回答の質や誠実さは、各社のコミュニケーション力を判断する材料になります。

RFP必須記載項目と業務要件の記述方法

RFP（Request for Proposal）は、正式な提案依頼書です。目標と制約を示すことで、ベンダーの提案条件をそろえられます。

RFPには、次の項目を盛り込みます。

• 背景・目標：更新理由に加え、業務効率化の数値目標やコスト削減目標、処理能力の向上を示します。
• 現行システム：構成、稼働年数、利用者数、機能、問題点、データ移行条件を記します。
• 機能要件：必須機能とNice to Haveを分け、利用者の操作の形で記述します。
• 非機能要件：性能、可用性、セキュリティ、保守性、移行条件を数値化します。
• 日程・予算・評価：稼働目標日、主要マイルストーン、概算予算、選定基準・配点を示します。繁忙期を避ける日程も検討します。

現行システムの構成は、言語・フレームワーク・データベース・インフラの4点を含めて書きます。データ移行がある場合は、その量と形式、難易度も記載します。

機能は「〇〇の登録・編集・削除ができる」「〇〇の一覧を検索・絞り込みできる」のように、操作の形で書くと認識の食い違いを防げます。

非機能要件には、レスポンスタイム、同時接続数、稼働率目標に加えて、認証方式、暗号化、ログ管理を含めます。見積もりの精度に関わるため、できるだけ数値で書くことが大切です。

また、評価基準には、技術力、実績、費用を含めます。サポート体制なども、あわせて評価の対象にします。

見積もり比較と最終選定の進め方

複数社の提案と見積もりを公正に評価し、最終的なベンダーを選びます。

比較では、金額と見積もりの内訳に加えて、提案内容や対応体制も確認します。

• 工数と追加費用：設計、開発、テスト、移行、運用保守の工数内訳から、過少見積もりや追加費用のリスクを見極めます。
• 移行・並行稼働：データ移行の工数と、並行稼働中のサポート費を見ておきます。
• 提案と体制：技術、類似実績、管理体制、セキュリティ、アフターサポートを総合的に評価します。

類似案件の参考先に問い合わせると、実績を確かめる材料になります。さらに、プレゼンでは担当PM本人に説明を求めて、実際に対応する人の力量を測ります。

契約締結の注意点

ベンダーを選んだ後、開発を始める前に契約を締結します。契約はリスク管理の土台になるため、慎重に検討する必要があります。

請負 vs 準委任の使い分け

主な契約形態は請負と準委任で、要件の確定度や工程に合わせて選びます。

• 請負：成果物の完成責任をベンダーが負い、不具合の修正義務も生じます。
• 準委任：業務の遂行を約束し、作業時間に応じて費用が発生します。
• 併用：要件定義を準委任、設計・開発を請負とする方法があります。

要件が明確な詳細設計以降は、請負で進める形が合います。費用を確定しやすい一方で、仕様変更があると追加費用の交渉が必要になります。

要件定義やアジャイル開発のように要件が流動的な工程では、準委任が向いています。スコープを変えやすい反面、費用が膨らむ可能性があります。

業務要件を詳細に固めてから請負で見積もれば、品質と費用、範囲の管理に役立ちます。

SaaSの利用規約・データ利用条件の確認ポイント

SaaSは、契約後に条件を変えにくい場合があります。そのため、利用規約とデータの扱いは契約前に確かめておきます。

乗り換えや終了時の影響を見極めるため、次の条件を確認します。

• 所有権・二次利用：登録データの所有権が自社にあるか、二次利用の条件は明確かを見ます。
• データ出力：解約時に、CSVやJSONなどの標準形式で出力できるかを確かめます。
• 終了時対応：データ保全と通知期間、移行支援、事前通知なしで終了するリスクを押さえます。
• 安全管理：ISO27001・SOC2等の認証、保管場所、サブプロセッサーの扱い。

個人情報や機密情報を扱う場合は、認証やデータセンターの所在地も、契約判断の材料に含めます。また、解約時の出力が限られていると、将来の移行費用が増えるおそれがあります。

追加開発・スコープ変更の取り決め

要件変更や機能追加はスコープクリープにつながるため、変更の手順を契約に定めておきます。

• 申請と承認：誰が、どのような形式で申請し、誰に承認を求めるかを決めます。
• 書面での記録：口頭の指示を避け、変更内容と承認を文書に残すことで、認識違いを防ぎます。
• 変更規模の区分：画面調整などの軽微な変更と、新機能追加などの大規模な変更を分けて扱います。
• 費用と権限：変更規模ごとに、承認レベルと費用負担を決めます。

変更指示は口頭で済ませず書面に残し、双方の署名がそろった後に正式な変更として扱います。変更管理票には、影響の見積もりと承認内容を記録し、申請から承認まで追跡します。

【独自】発注者が主導権を握るプロジェクト管理

「ベンダーに任せていたら、気づいたら炎上していた」。これは、最も多く聞かれる失敗談のひとつです。こうした事態を防ぐには、発注者が進捗と成果物を把握し、早めに対応することが欠かせません。

ベンダー任せにしない進捗管理

「順調です」という報告だけで実態を知るのは難しいため、定期報告と成果物の確認方法をあらかじめ決めておきます。

• 週次レポート：完了タスク、今週の予定、遅延タスク、課題の内容・対応状況・期限、潜在的な問題・影響度・対策を記します。
• WBS共有：ベンダーが開始前に作成し、毎週更新・共有する詳細日程で、遅延を把握します。
• 成果物レビュー：設計書、画面モックアップ、開発機能を、工程ごとに確かめます。

レポートはベンダーから提出してもらい、書式は発注者側で指定します。WBSの共有には、NotionやGoogleスプレッドシートなどを使います。

特に、成果物は完成後にまとめて確認するより、中間の段階で定期的にレビューするほうが、方向性のずれを早く修正できます。

「言った言わない」を防ぐドキュメント管理

口頭での合意や曖昧な指示は、後のトラブルにつながります。そのため、議事録や変更履歴を双方で確認できる形で残しておきます。

• 議事録：24時間以内に作成し、双方で即日確認します。決定事項、宿題の担当・期限、次回の議題を記します。
• 要件変更：変更内容と理由、日程・費用への影響、承認者と承認日を記録します。
• 設計書のバージョン管理：要件定義書・基本設計書・詳細設計書の版番号、変更日、変更内容を記録し、合意済みの最新版が分かるようにします。

議事録は、署名か返信で双方の確認を取り、確認が済むまで作業を進めないルールにします。

変更管理票は、双方の署名がそろった時点で正式な変更になります。さらに、メールで届いた変更指示は、台帳に転記して番号で管理します。

設計書は、SharePointやConfluence、Notionなどで最新版をまとめて管理します。

炎上兆候の早期発見と対処

炎上には、事前に兆候が見られます。報告や成果物の変化を見落とさないよう、注意して確認します。

• 遅延：「少し遅れています」という報告が2週間以上続きます。
• 課題滞留：課題数が増え、クローズが追いつきません。
• 成果物遅れ：設計書の提出が予定より大幅に遅れます。
• 体制変化：担当者が頻繁に変わるか、PMが不在になります。
• 回答・レビューの停滞：「確認します」「調整中です」という曖昧な回答が増え、デモや成果物の確認を避ける反応が見られます。

兆候が見えたら、まず緊急レビュー会を開き、遅延の根本原因と具体的な回復計画を確かめます。必要に応じて、PMOや第三者の専門家に客観的なヘルスチェックを依頼します。さらに深刻な場合は、契約に基づいてエスカレーションや是正措置を求めます。

チェンジマネジメント：現場を巻き込む発注者の役割

技術的に優れたシステムでも、現場に定着しなければ失敗といえます。そのため発注者は、開発管理と並行して、使ってもらえる環境を整えます。

キーマン特定と早期巻き込み

「このシステムは使えない」「前の方が良かった」と現場のキーマンが反発すると、利用が妨げられることがあります。そのため、キーマンを早く特定し、参加を促します。

キーマンの候補は、次の特性をもとに選びます。

• 業務知識：各部門で業務に最も詳しいベテラン担当者。
• 周囲への影響力：同僚から信頼され、発言が周囲に影響する人物。
• 変化への姿勢：変化に比較的オープンで、新しい挑戦に前向きな人物。

要件定義の段階からワーキンググループに加わってもらいます。プロトタイプ（試作品）の意見を集めれば、現場の実態をシステムに反映できます。また、「作る側」として関わることで、当事者意識も生まれます。

さらに、導入後は社内サポーターとして育て、周囲への普及を担ってもらう方法もあります。

運用定着までのフォローアップ

リリースは運用の始まりです。支援が不足すると、現場がExcelや紙の方法に戻ってしまうおそれがあります。

定着までの支援は、次の流れで続けます。

• 事前研修：リリース前に、一般ユーザー、管理者、上長別の操作研修を行います。
• 操作資料：マニュアルと操作早見表を作り、誰でも参照できる場所に共有します。
• 集中支援：本番開始後1〜2週間、ヘルプデスク、現場巡回、迅速な回答を行います。
• 利用状況確認：ログイン率、機能別利用頻度、エラー発生率から、未利用機能や問題箇所を探します。
• 継続改善：利用者へ定期的に意見を聞き、要望を次期更新に反映します。

集中支援の期間中に寄せられた問い合わせやトラブルを記録してFAQにまとめると、二次的なサポートコストを抑えられます。

まとめ

業務システムリニューアルの発注は、準備から定着までを一連の流れとして捉えることが大切です。

• 発注前準備：業務フローと問題を整理し、社内体制を整えます。
• ベンダー選定：RFIで情報を集め、RFPで要件、日程、予算を伝えます。
• 契約：工程に応じた契約形態と変更管理を定めます。
• 発注者主導：進捗報告やWBS、レビューに加え、議事録の即日確認・変更管理票・設計書の版管理を続けます。
• 現場定着：キーマンの参加、研修、運用後の支援を続けます。

RFI・RFPで条件をそろえておくと、提案を公平に比べやすくなります。そのうえで、見積もりの内訳やリスク費用も確かめます。SaaSを選ぶ場合は、データ出力とAPI連携の柔軟性も事前に見ておく必要があります。

現場のキーマンを早い段階で巻き込み、利用状況を見ながら改善を重ねると、運用への定着と投資対効果の向上につながります。

発注先の選定やRFPの作成について具体的に知りたい場合は、riplaへご相談いただけます。

▼全体ガイドの記事
・業務システムリニューアルの完全ガイド

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

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

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

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

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

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。