ニフクラのシステム開発の発注/外注/依頼/委託方法について

ニフクラのシステム発注は、現状と目的の整理、RFPによる提案比較、契約、開発・移行、運用引き継ぎの順に進めると、範囲と責任を明確にできます。

発注形態、要件と契約、費用相場、委託先の比較の順に見ていきます。全体像は、ニフクラのシステム開発の完全ガイドもあわせてご覧ください。

▼全体ガイドの記事
・ニフクラのシステム開発の完全ガイド

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

ニフクラのシステム発注・外注の意味

ニフクラのシステム発注・外注は、FJcloud-V上に業務アプリやデータベースを構築することです。必要に応じて既存環境からの移行も行い、運用まで専門会社に委託します。完成済みの業務アプリを契約する形とは異なり、クラウド基盤と業務要件を組み合わせて設計する点が特徴です。

ニフクラと現行名称FJcloud-Vの対応

富士通は2024年4月1日にニフクラをFJcloud-Vへ統合しました（出典：ニフクラ カスタマーサポート「サービス統合に基づくサービス名称の読み替えのお願い」、2024年）。公式サポートは、旧称と現行名の扱いを次のように案内しています。

• 読み替え：「ニフクラ」「NIFCLOUD」「nifcloud」をFJcloud-Vとする
• 発注書・RFP：「FJcloud-V（旧ニフクラ）」と併記する

なお、名称変更によって既存システムが自動的に再開発されるわけではありません。依頼する範囲は、現行環境の調査、アプリ改修、サーバーやDBの設計について、どこまでを依頼するかを工程ごとに明示します。移行、テスト、切り替え、運用引き継ぎも、同じ単位で依頼範囲を分けます。

発注範囲の基盤・アプリ・運用への分け方

ニフクラは、仮想サーバーやストレージ、データベースなどを組み合わせて使うIaaSに近い基盤で、ネットワークやバックアップも含まれます。販売管理や人材派遣管理などの業務アプリを標準搭載したSaaSとは違い、画面や帳票、権限、外部連携は別途設計する場合が多くあります。

発注時には、委託する範囲を次のように分けて考えます。

• クラウド基盤：構築と設定
• 業務アプリ：開発と改修
• データ：既存環境からの移行
• 運用：監視、障害対応、EOL対応

一社にまとめて委託する方法のほか、アプリに強いSIerと運用に強いMSPを組み合わせる方法もあります。分担する場合は、責任者と障害時の窓口を一つに定めます。

クラウド事業者と利用者の責任分界

基盤に第三者認証やSLAがあっても、業務システム全体の安全性や可用性までは自動で保証されません。そこで、設備やサービス提供の範囲と、利用者側で管理する項目を分けて確認します。

• 基盤側：認証・ネットワーク・監視、設備やサービスの提供
• 利用者側：OSパッチ、アプリの脆弱性、ID・権限、暗号化、ログ、バックアップ復旧テスト

RFPには、障害の検知時間、暫定復旧までの時間、データを戻す時点を記載します。サーバーの再起動担当だけでは、責任分界を決めきれません。

金融・決済、自治体、個人情報を扱う場合は、RTO・RPO、閉域網、WAF、操作履歴、復旧訓練の担当も定めておくと、契約後の追加費用を抑えやすくなります。

ニフクラの発注形態の選び方

発注形態は、業務を標準化できるか、独自機能が競争力になるか、社内にIT運用の人材がいるかで選びます。標準機能で足りるならパッケージやSaaS、既存資産を活かすならニフクラへの移行、独自業務を作るならスクラッチ開発が候補です。迷う場合は、標準化する領域と独自開発する領域を分けると、判断しやすくなります。

パッケージ・SaaSを中心にした不足分の開発

販売管理、会計、勤怠、顧客管理などを標準機能に合わせられる場合は、パッケージやSaaSで短期間の導入が見込めます。ニフクラは、製品を置く基盤や、既存の周辺システムとの連携先として利用できます。

発注前に、業務ごとにどの方法で対応するかを分けます。

• 標準機能：製品の機能に業務を合わせる
• 追加開発：標準機能で不足する部分を作る
• 手作業：システム化せず運用で対応する

標準機能に合わせられる業務まで個別開発すると、費用と保守負担が増えます。一方で、業務上の例外を無理に削ると現場で使われなくなります。そこで、候補製品のデモを業務シナリオと照らし合わせて判断します。

既存システムの移行とクラウド構築の外注

オンプレミスのWindows Server、Linux、DB、ファイルサーバーを活かす場合は、ニフクラへの移行を外注する方法が現実的です。Active Directoryも活用対象に含められます。

移行方式は、作業内容に応じて分けられます。

• リフト：現行サーバーを仮想マシンとして移す
• リプラットフォーム：OSやミドルウェアを更新する
• モダナイゼーション：アプリを再設計する

移行だけなら開発費を抑えられる場合があります。ただし、古いOSやSQL Server、複雑なバッチ、属人化した運用も、そのまま移行先に持ち込むおそれがあります。

現行調査と移行後の改善は別見積もりにし、安全に稼働させる計画と後から改善する計画を分けて比べます。

要件定義から運用までの一括委託

社内のクラウド・開発担当が少なく、業務部門の要望整理も必要なら、要件定義から運用までの一括委託が候補です。

窓口を一本化すると発注者の負担を抑えられます。一方で、提案が不透明だと、不要な機能や過剰な構成が入り込むおそれがあります。

一括委託でも、発注者が決める項目は明確にしておきます。

• 業務判断：優先順位、停止可能時間、承認者、データ保管年数、障害時の判断者
• 契約条件：納品物の利用権、運用費の上限

定例会議と承認手順は契約書や計画に組み込み、意思決定まで委託先に任せきりにしないことが大切です。

ニフクラのシステム発注の進め方

まず現状と目的を整え、そのうえで候補会社に同じ情報を渡すと、提案を比べやすくなります。発注から運用引き継ぎまでは、次の順に進めます。

1. 現状を洗い出し、目的を整理する
2. 発注形態を比較し、RFPを作成する
3. 提案と見積もりを比べ、契約する
4. 要件定義、設計、開発を進める
5. 移行・切り替えを行い、運用を引き継ぐ

現状の洗い出しと目的の整理

発注先に必要な情報を渡せるよう、現行環境、業務の流れ、目指す改善を洗い出します。

• 環境：サーバー台数、OS、DB、連携先、帳票、ユーザー数、ピーク時の処理量、データ量
• 運用条件：バックアップ方法、停止可能時間
• 業務の流れ：販売管理の受注から出荷・請求、人材派遣管理の求人・スタッフ・勤怠・請求、例外処理
• 目的：拠点からの安全な利用、月末処理の短縮、災害時の復旧、夜間対応の削減

例外処理も担当者に聞き取り、画面一覧だけでは見えない業務を記録します。目的が具体的であるほど、必要なサーバー性能や監視レベル、移行範囲を委託先と詰められます。

RFPで同じ条件を渡す提案比較

RFPには、候補会社が同じ前提で提案できるよう、次の情報を記載します。

• 背景と要件：目的、対象業務、現行環境、利用者数、必要機能
• 移行と品質：データ移行、外部連携、セキュリティ、性能、可用性
• 提案条件：納期、予算、納品物、保守条件、前提と除外事項

提案書は、構成、体制、工程表、初期・月額・保守費用を、同じ順番で提出してもらいます。

候補はFJcloud-Vの構築経験に加え、対象業界の業務知識と移行実績で選びます。

公式事例には、システナのニフクラを使ったIoTサービスのPoCがあります。ケンファーストの東西リージョンDRを含むFinTech基盤や、エイチ・シー・ネットワークスの遠隔講義システムも掲載されています。

候補を選ぶ際は、事例だけでなく、現行のFJcloud-Vに対応できる担当者や類似案件の成果物も確認します。

移行・切り替え・運用引き継ぎの工程分け

新システムが完成しても、データ移行や切り替えに失敗すれば業務は止まります。そのため、移行・切り替え・引き継ぎの作業を事前に決めておきます。

1. データの重複や欠損を確認し、移行対象と変換ルールを決める
2. テスト移行を複数回行い、結果を確認する
3. 切り替え手順、読み取り専用にする時間、旧環境を残す期間、切り戻し条件を事前承認する
4. 監視アラート、障害連絡網、復旧、アカウント追加、パッチ、費用、EOL確認の方法を文書化する
5. 本番前に復旧テストを行い、結果と残課題を納品物に含める

バックアップは取得するだけでは足りず、実際に復元できるかを確かめておく必要があります。

RFPと要件整理で決めること

RFPは、発注者と委託先が同じ前提に立つための資料であり、開発会社に丸投げするための資料ではありません。画面仕様が未確定でも、業務目的・優先順位・制約条件・判断基準を明確にすると、提案を比べやすくなります。

業務シナリオで書く機能要件

「顧客管理機能が必要」とだけ書くと、会社ごとに解釈が変わってしまいます。そこで、業務シナリオに機能の流れと優先順位を含めます。

• シナリオ要素：利用者、入力、処理、承認、出力、例外
• 例：営業担当が顧客を登録し、重複を検知。承認後に受注へ連携し、月次で一覧を出力
• 関連機能：画面、帳票、バッチ、API、通知、権限
• 優先順位：初日必須、手作業で代替、将来追加

業務シナリオを機能に結び付けると、見積もりの抜けに気づけます。第一段階の費用と納期も抑えられます。一方で、すべてを必須にすると、予算超過や納期遅延を招きかねません。

数値と責任者で定める非機能要件

非機能要件は、次の項目を数値と担当範囲で定義します。

• 対象：性能、可用性、セキュリティ、バックアップ、監視、拡張性、運用時間
• 数値：平常時・ピーク時の同時利用者数、画面応答時間の目標、月間稼働時間、障害検知の目標時間
• 復旧・保管：RTO、RPO、バックアップ世代、ログ保管期間
• 責任分界：FJcloud-V側の認証・ネットワーク・監視と、利用者側のID管理、OS・ミドルウェアのパッチ、アプリの脆弱性診断、データ持ち出し制御を分ける
• 監査：ISMAPやISO/IEC 27017などの認証と、自社要件に必要な追加設定・運用手順

「高速」「安全」「止まらない」など曖昧な表現は、提案段階で委託先に質問して具体化します。

データ移行の対象と品質基準

移行の対象と、品質の確認項目は次のように決めます。

• 対象データ：マスタ、取引履歴、添付ファイル、ユーザー、権限、ログ、バックアップ
• 移行範囲：全件、一定期間の履歴、参照用に保存する古いデータ
• データ品質：文字コード、日付形式、コード体系、重複、欠損、個人情報
• 検証基準：件数と金額合計の一致、主要顧客の検索、帳票出力と現行結果の照合

業務担当者には、サンプルデータの確認と受入判定に参加してもらいます。業務上の意味を開発会社だけに判断させると、誤認のリスクが高まります。

契約形態と責任分界の選び方

基盤設定、アプリ開発、移行、保守では、作業の性質が異なります。そのため、要件の確定度と成果物の明確さに合わせて契約を分けると、費用と責任を管理しやすくなります。

要件と成果物が固まった部分の請負契約

画面仕様、機能一覧、テスト条件、納期、検収基準が固まった開発工程では、請負契約が候補です。

請負契約では、成果物と検収条件を書き込みやすく、予算も固定できます。一方で、要件が曖昧だと変更のたびに追加見積もりとなり、認識が食い違う場面が生じます。

契約書や仕様書では、次の条件を確認します。

• 検収：納品形式、検収期間、瑕疵対応
• 変更：仕様変更の手続き
• 権利：第三者ソフトのライセンス、ソースコード・設計書の利用権

クラウド設定、Infrastructure as Code、監視設定、バックアップ手順が納品対象かどうかは、運用引き継ぎに直結します。そこで、見積書ではなく、契約書や仕様書に記載しておきます。

調査・要件定義・アジャイル開発の準委任契約

現行調査、技術検証、要件定義、アジャイル開発など、進めながら方法を決める工程では準委任契約が候補です。こうした工程では、作業条件と確定後の契約移行を先に取り決めます。

• 進め方：月額の人月や稼働時間を基準にし、未知の課題を洗い出す
• 作業範囲：調査内容、参加会議、作成資料を明確にする
• 契約条件：担当者の役割、稼働上限、成果物、課題管理、報告頻度、追加作業の承認方法
• 段階契約：要件定義後、確定した開発を請負へ移す

段階契約は、不確かな仕様を最初から固定価格にするリスクを抑えられます。

運用保守の対応範囲と時間帯

運用保守の契約では、作業範囲と担当を分けて定めます。

• 監視・初動：監視、アラート通知、一次切り分け、再起動
• 保守作業：障害復旧、バックアップ確認、パッチ適用、問い合わせ、軽微な改修
• 対応責任：検知、連絡、判断、復旧、報告の担当者

24時間365日の監視でも、アプリ障害の原因調査やデータ修正まで含むとは限りません。さらに、FJcloud-Vの有人監視は、2026年4月1日以降の利用分から価格改定が案内されています（出典：FUJITSU Hybrid IT Service「FJcloud-V 有人監視の価格改定について」、2026年）。

発注側は、月額だけでなく、将来の価格改定、夜間・休日対応、EOL対応、障害時の追加作業も含めて確認します。

ニフクラのシステム発注費用の相場

開発費は、クラウド利用料と設計・開発・移行・保守費を合算して考えます。なお、公式に一律の開発費はありません。

ここで示す目安は、業務システムの類似案件とリサーチノートに基づきます。機能数、データ量、連携数、可用性、移行難易度、契約形態によって変わります。

サーバー以外を含むクラウド基盤の利用料

2026年3月16日時点で、Type-c2「c2-small」は1vCPU・1GB、月3,157円（税込）／台です（出典：FJcloud-V「クラウド 料金一覧（税込）」、2026年）。

サーバー本体以外に必要な費用と、台数別の試算も合わせて確認します。

• 追加費用：DB、増設ディスク、IPアドレス、ロードバランサー、バックアップ、WAF、転送量、監視、OSライセンス
• 検証環境：3台ならサーバー本体は単純計算で月額9,471円
• 冗長化した本番環境：Web・AP・DBを6台にすると、サーバー本体だけで月額18,942円

実際の請求額は構成で変わり、試算に含まれない費用もあります。停止時の料金、長期利用割引、OSやオプションの適用条件も確認します。

案件規模ごとの開発・移行費のレンジ

開発・移行費の推定レンジは、案件規模によって異なります。

• 100万〜500万円：IoT・WebのPoC、簡易業務アプリ
• 500万〜1,500万円：部門業務システム、既存パッケージのクラウド化
• 1,500万〜5,000万円：基幹移行、複数拠点・複数DB
• 5,000万円〜数億円：大規模ERP、スクラッチ開発、DR付き

これらは、類似案件から整理した推定値で、ニフクラの公式価格ではありません。実際の費用は個別見積もりで確認します。

期間の目安は、PoCが2週間〜3か月、部門システムが3〜6か月、基幹移行が6〜12か月、大規模案件が1〜3年です。

公開されたニフクラIoTのPoCは、インフラ構築、データ設計、アプリ開発を含めて2週間で完了し、費用は未公開です。ただし、本番では移行、受入テスト、教育、切り替えの期間が加わります。

工程別と運用費に分けた見積もり

初期費用の工程別配分は、次の割合が目安です。

• 要件定義：10〜15%
• 基本設計・詳細設計：各15〜20%、10〜15%
• 開発・テスト：各30〜40%、15〜20%
• 移行・導入：5〜10%程度

これは一般的な配分で、案件の特性によって変わります。移行が難しい場合は開発より移行・テストの割合が増え、PoCでは設計と開発の割合が高くなることがあります。

保守・改修費は、初期開発費の年10〜20%程度を目安に置くことがありますが、契約内容で大きく変わります。そのため、監視、アプリ改修、問い合わせの範囲、月間時間、障害時の追加料金を確認します。

2026年にはSQL Server 2016のサポート終了に伴い、FJcloud-Vの対象OSイメージ提供終了が案内されています。そこで、EOLによる将来の更新費も予算に含めます。

ニフクラの委託先選定と見積比較のポイント

委託先は、FJcloud-V上で自社に似た業務を設計・移行・運用した実績で選びます。最安値だけで決めず、同じRFPに対する前提条件、除外事項、工程、体制、成果物、保守範囲を比べます。

構築経験に加えた業務・移行・運用実績

構築以外の実績と、契約後の進め方も確認します。

• 類似案件：同じ業界・業務、同程度のデータ量
• 技術範囲：既存DB・Active Directory連携、閉域網、WAF、バックアップ、DR、24時間監視
• 現在の対応力：古い事例の場合、現担当者、対応範囲、現行名称での支援実績
• 担当者と成果物：責任者・技術者との面談、成果物、課題管理表、テスト計画、障害報告のサンプル

営業担当だけでは、移行の難所や運用上の制約を見抜きにくい点にも注意します。

一式見積もりを避けた同じ単位での比較

見積書は工程別に分け、同じ単位で比べます。

• 工程：要件定義、基本設計、詳細設計、開発、テスト、移行、教育、運用設計、保守
• 工数と体制：人日・人月、単価、担当ロール
• 作業条件：作業内容、成果物、前提条件

「システム開発一式」だけでは作業範囲を比べられません。クラウド費用は、サーバー、DB、ディスク、バックアップ、ロードバランサーに分けて見積もります。WAF、監視、OSライセンス、通信、サポートも同じ単位で分けます。

初期費用と月額費用を分け、通常月、繁忙期、障害時、将来のサーバー増設の4パターンを試算します。

価格改定やEOLに伴う更新作業の負担者も、見積もりの注記で確認します。

安さの理由と追加費用の条件

安価な見積もりでは、次の範囲や条件に違いがないか確認します。

• 見積もり範囲：機能、移行・テスト、担当者の経験
• 漏れやすい作業：データクレンジング、連携先改修、性能試験、脆弱性診断、利用者教育、切り替え後の立ち会い
• 追加費用：仕様変更、データ量・連携先の変更、休日作業、障害対応
• 将来費用：OS・ミドルウェアのEOL、クラウド料金改定

発注前に変更をすべて予測できなくても、追加が発生する条件と承認者を決めておくと、予算を管理しやすくなります。

よくある質問（FAQ）

発注担当者からよく寄せられる質問に答えます。料金や契約の判断は、現行環境、必要な可用性、業務範囲によって変わります。

ニフクラとFJcloud-Vは同じサービスですか？

公式名はFJcloud-V、ニフクラは旧称です。2024年4月1日以降も旧ドメイン・資料が残るため、RFP等には「FJcloud-V（旧ニフクラ）」と併記すると認識を合わせやすくなります。

ニフクラ上のシステム開発は何円から発注できますか？

簡易PoCや業務アプリは100万〜500万円、部門システムは500万〜1,500万円、基幹移行は1,500万〜5,000万円が目安です。

要件定義、データ移行、連携、テスト、DR、保守の範囲で変わるため、同じRFPを複数社に渡し、工程別の見積もりを取ります。ニフクラ固有の定額の開発費はありません。

ニフクラを使えば開発費や運用費は安くなりますか？

ニフクラを使えば、サーバー調達期間や設備管理の負担を抑えられる可能性があります。ただし、開発費が必ず安くなるとは限りません。

アプリ開発、移行、DBは別途かかります。また、バックアップ、WAF、監視、OSライセンス、保守も別途かかります。そのため、初期費用と月額費用を分け、3年程度の利用を想定した総保有コストで比べます。

委託先を選ぶときに最も重視すべき点は何ですか？

FJcloud-Vの構築経験に加え、自社に似た業務、データ移行、非機能要件、運用保守の実績を重視します。

提案書では、対応範囲、除外事項、成果物を確認します。担当者、障害時の窓口、EOL対応、追加費用の条件も押さえます。さらに、稼働後の責任者も比べます。

まとめ

発注時は、現行環境と業務目的を整理し、パッケージ・SaaS・移行・スクラッチ開発の範囲を決めます。

RFPには機能要件に加えて、データ移行、性能、セキュリティを含めます。また、バックアップ、RTO・RPO、運用保守、EOL対応も入れます。

発注前の目的と責任分界

見積もりは、サーバー料金だけでなく、DB、ストレージ、WAF、監視も含めた総額で比べます。OSライセンス、開発、移行も同じ総額に入れます。さらに、テスト、教育、保守も含めて確認します。

2026年時点のFJcloud-Vという名称、有人監視の価格改定、SQL Server 2016などのライフサイクルを確認します。

短期の初期費用だけでなく、運用開始後の責任分界にも納得してから契約します。

工程別の見積もりと運用体制の比較

候補会社には同じ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を創業。