FutureStage導入の発注/外注/依頼/委託方法について

FutureStage導入の発注は、情報収集、RFI・RFPの作成と提案依頼、提案評価・契約の順に進みます。この順に進めると、自社に合うパートナーを適切な費用で選定できます。

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

FutureStage導入発注の全体プロセス

情報収集から契約交渉・締結まで、RFPによる提案依頼と提案評価を挟みながら段階を順に進めます。

情報収集・市場調査
RFI（情報提供依頼）
RFP（提案依頼）作成
複数社への提案依頼
提案評価・選定
契約交渉・締結
プロジェクト開始

大型のシステム導入では、この発注プロセス自体に2〜4ヶ月を要することも珍しくありません。だからこそ、十分な準備期間を確保して、自社に合うパートナーを適切な費用で選ぶことが大切です。

RFI（情報提供依頼）の活用

RFI（Request for Information：情報提供依頼）は、RFPを作る前に候補企業から情報を提供してもらう文書です。回答を比べると市場の概況がつかめるため、RFPを送る候補を絞り込めます。

会社情報：会社概要やサービス内容
実績・資格：導入実績やFutureStage認定資格
費用・規模：料金体系の概要や対応可能な規模感

候補は、OBC公式サイトの認定パートナー一覧から選び、5〜10社程度に送るのが一般的です。

回答を比べるときは、認定ランク、同業種の導入実績数、対応可能な規模感を見ると、候補の違いがはっきりします。

RFP（提案依頼書）の作成方法

RFP（Request for Proposal：提案依頼書）は、導入プロジェクトの発注で重要な文書です。各社の提案を同じ条件で並べて比べられるよう、RFPには背景から提出方法までの項目を書き込みます。

背景・目的：企業概要と導入の背景、目的
導入範囲：モジュール、機能、連携システム
スケジュール・品質：希望稼働時期、重要マイルストーン、テスト方針、性能要件、セキュリティ要件
費用・評価：費用の上限・予算感、評価基準と重み付け
提出方法：提案フォーマット、提出期限、質問受付・回答方式

詳細なRFPほど提案の比較精度が高まります。作成に不慣れな場合は、ITコンサルタントやDX支援会社に支援を頼む方法もあります。

ポイント

発注の途中で迷ったら、候補を絞る段階と、同じ条件のRFPを各社に渡す段階が済んでいるかを見直すとよいでしょう。前の段階を飛ばすと、提案を比べにくくなります。

提案評価と最終ベンダー選定

配点の差から、評価で重視する軸が見えてきます。

提案書が届いたら、複数の候補を評価・比較して、最終的なベンダーを選びます。評価は感覚で決めず、RFPの基準に沿った定量的な採点が推奨されます。評価を多面的に行うには、評価委員会に経営層、情報システム担当、業務部門の代表者が加わると役立ちます。

提案評価のスコアリング基準

評価は感覚に頼らず、RFPの基準に沿って項目ごとに重み付けして定量的に採点します。下に挙げた例では、技術・業務要件への対応度に最も大きな重みを置いています。

技術・業務要件への対応度：30%
プロジェクト管理計画の妥当性：20%
費用対効果：20%
FutureStage実績・専門性：15%
稼働後サポート体制：15%

配分が最も大きい要件への対応度では、自社の業務課題をどこまで理解しているか、解決策が具体的かを重視します。

安い見積もりでも、スコープ外が多ければ総費用が高くなる場合があります。そのため、概算総額と、追加費用が発生しやすい箇所の説明を確認します。

プレゼンテーション・デモによる最終確認

書面での評価のあと、上位2〜3社には提案プレゼンテーションとFutureStageのデモを依頼します。最終確認では、説明する人の顔ぶれと、自社業務への理解、標準機能での対応範囲を見ます。

担当チーム：予定PMと業務コンサルタントが直接説明することを必須にする
業務理解：チームの雰囲気や意思疎通、自社業務への理解を見る
機能適合：主要業務フローを実演し、標準機能での対応範囲を見る

実際に業務が回るかを確かめるため、業務キーユーザーもデモに同席させることが勧められます。

ポイント

選定で迷ったときは、点数の高さだけでなく、見積もりに含まれるスコープや、予定PMが直接説明したかを合わせて見比べると判断しやすくなります。

契約形態の選択と要点

契約形態は、報酬の対象を軸に整理できます。

FutureStage導入では、主に請負契約と準委任契約が使われます。両者の特徴と使い分けを押さえておくことが、発注リスクを管理する助けになります。

請負契約と準委任契約の違い

契約形態は、成果物の完成に対して報酬を払うか、作業の提供に対して払うかで異なります。

請負契約：完成したシステムなど成果物の納品に対して報酬を払う
準委任契約：作業の提供に対して報酬を払い、作業時間（人月）に応じて費用が発生する

請負では、要件定義から設計・開発・テストまでを固定金額で発注できます。また、成果物が仕様を満たさない場合には、ベンダーが修正義務（瑕疵担保責任）を負います。

FutureStage導入では、要件定義を準委任で進め、設計・開発以降を請負にする組み合わせが一般的です。要件が曖昧な段階から固定費用の請負を提案するベンダーには、注意が必要です。

契約書で必ず確認すべき重要事項

契約後に認識の違いが生まれないよう、契約書では、作業範囲から権利・機密の扱いまで、あいまいさを残さずに書いておきます。

スコープ：含む内容と含まない内容
変更管理：追加要件の見積もりと承認手続き
成果物・検収：各フェーズの納品物と受け入れ基準
瑕疵担保責任：稼働後の修正義務期間と対応範囲
権利・機密保持：カスタマイズ開発ソフトウェアの著作権の帰属先と、NDAで定める業務情報・データの取り扱い

瑕疵担保責任の期間は一般的に1年間です。曖昧な契約はトラブルの原因になるため、法務担当者が内容を確認し、必要に応じて弁護士の確認を経て締結します。

ポイント

契約形態で迷ったら、要件定義は準委任で進め、設計・開発以降を請負にする組み合わせを検討します。契約書では、範囲・検収・瑕疵担保責任の期間を確かめておくと、認識違いを減らせます。

フェーズ分割発注によるリスク管理

各段階を区切ることで、次の発注を成果に応じて検討できます。

フェーズ分割発注は、発注リスクを抑えるのに有効な方法です。プロジェクトを段階に分け、フェーズごとに契約・発注します。区切りの位置は、要件定義から稼働後保守までの流れに合わせて決めます。

フェーズ1：要件定義
フェーズ2：設計・開発・テスト
フェーズ3：本番稼働・移行支援
フェーズ4：稼働後保守

フェーズ分割発注のメリットと注意点

フェーズ分割発注は、見積もりの精度や発注先の見直しに効く反面、フェーズ間の引き継ぎに手間がかかります。

開発費の精度：要件定義後に開発フェーズを見積もれ、要件の不確かさを抑えられる
発注先の見直し：要件定義の成果が期待を下回れば、次の段階で変更を検討できる
引き継ぎへの配慮：フェーズ間の引き継ぎコストを見込む

一方で、要件定義の前に開発まで一括で発注すると、不確かな要件が見積もりに反映されず、追加費用のリスクが高まります。また、契約を切り替える際に空白期間が生じないよう、次のフェーズの発注は前のフェーズの終盤に始めておきます。

ポイント

要件が固まりきっていない案件では、要件定義だけを先に発注し、成果を見て次のフェーズを決める進め方が目安になります。次の発注は前のフェーズの終盤に始め、空白期間を避けます。

発注後のプロジェクト管理と検収

発注後は丸投げにせず、自社もプロジェクトに積極的に関わる必要があります。ベンダー任せにすると、自社の業務要件がシステムに適切に反映されないリスクが高まります。実際に、ERP導入の失敗要因では、発注者のコミットメント不足が上位に挙げられています。

ステアリングコミッティとプロジェクト会議体の設置

定期的な会議体を設けておくと、進捗や課題を確認して、問題を早い段階で見つけ、解決につなげられます。会議は、経営層の方針決定、PMとベンダーの進捗共有、現場の業務設計という役割ごとに分けて設けます。

ステアリングコミッティ（月次）：経営層が全体方針や重要事項を決める
プロジェクト推進会議（週次）：PMとベンダーが進捗・課題・リスクを共有する
モジュール別ワーキング（週次）：業務キーユーザーとベンダーが業務設計を検討する

会議のあとは議事録を作成して共有し、決定事項と宿題事項をはっきりさせます。

成果物の検収手順と注意点

各フェーズの成果物は、契約上の仕様を満たしているかを発注者側で確認したうえで、正式に検収します。

対象：要件定義書、設計書、テスト結果、操作マニュアル、本番稼働環境
不具合・不足：修正依頼書（パンチリスト）を作成して対応を求める
確認方法：業務キーユーザーが業務シナリオに沿って動作を確認する

検収が終わってから、フェーズの費用を払うマイルストーン払いが一般的です。ただし、形式的な確認にとどめると、後から問題が見つかるリスクがあります。

ポイント

発注後は、会議体で進捗と課題を共有しつつ、各フェーズの成果物が契約上の仕様を満たすかで判断するのが目安になります。形式的な確認に終わらせないことが大切です。

FutureStage外注・委託でよくある失敗と対策

外注・委託で起きやすい失敗は、対策を先に決めておくことで避けやすくなります。

よくある失敗パターンと対策

追加費用や進行の停滞を防ぐには、発注前に起きやすい失敗を想定して、選定時の確認点を押さえておくことが大切です。価格や担当者、契約の範囲にまつわる失敗は、選定や契約の段階で対策を決めておくと、つまずきを抑えられます。

価格だけで選ぶ：実績・体制・提案の質も評価する
曖昧なスコープで契約する：RFPに範囲を明記する
担当者が頻繁に交代する：主要担当者の変更に事前承諾を求める
進捗報告が形式的になる：完了タスク数・バグ件数・残工数を定期確認する
稼働後サポートが曖昧：保守契約・SLA・対応時間帯を事前合意する

なかでも価格だけで選ぶのは、最も多い失敗パターンです。安価な見積もりには、スコープの絞り込みや品質水準の低下が含まれる場合があります。

「お任せします」という曖昧な発注は、追加費用の原因になります。また、スライドを共有するだけの週次報告では、課題が隠れやすくなります。

PMやSEが頻繁に替わると、プロジェクトの品質と進捗に悪影響が出ます。さらに、稼働後のサポートを事前に合意しないと、稼働直後のトラブル対応が遅れるリスクがあります。

まとめ

FutureStage導入の発注では、RFPで範囲を定めたうえで複数社に提案を依頼し、定量評価をもとに選定します。

契約後は、フェーズ分割でリスクを管理しながら、自社もプロジェクトに関わって検収まで進めます。

特に大切なのは、スコープを明確にして発注することと、ベンダー任せにせず自社も参加することです。費用相場や推奨パートナーについては、関連記事もあわせて参照してください。

▼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を創業。