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

ニフクラのシステム開発を発注・外注するなら、クラウド料金だけで判断せず、業務アプリケーション、データ移行、ネットワーク、セキュリティ、運用保守までを一つの計画として整理することが重要です。

ニフクラは2024年4月1日から「FUJITSU Hybrid IT Service FJcloud-V」へ統合・名称変更されていますが、旧称で検索する人や既存資料は少なくありません。この記事では、ニフクラ（現FJcloud-V）のシステムを発注・外注する際の形態、RFPと要件整理、契約、費用相場、委託先の選び方、見積書の比較方法を、発注者が社内で判断できる順番に解説します。

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

ニフクラのシステム発注・外注とは何ですか？

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

富士通の公式サポートでは、2024年4月1日をもってニフクラがFJcloud-Vへ統合され、各ページに記載された「ニフクラ」「NIFCLOUD」「nifcloud」はFJcloud-Vに読み替えるよう案内されています（出典: ニフクラ カスタマーサポート「サービス統合に基づくサービス名称の読み替えのお願い」、2024年）。そのため、発注書やRFPでは「FJcloud-V（旧ニフクラ）」と併記すると、検索語と現行の製品名を両方扱えます。

ただし、名称が変わっても、既存のニフクラ上で動いているシステムを自動的に再開発してくれるわけではありません。発注先には、現行環境の調査、業務アプリの改修、サーバーやDBの設計、移行、テスト、切り替え、運用引き継ぎをどこまで依頼するかを明示する必要があります。

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

発注時は、第一にクラウド基盤の構築と設定、第二に業務アプリの開発・改修、第三にデータ移行、第四に監視・障害対応・EOL対応などの運用を切り分けます。一社に一括委託する方法もありますが、アプリに強いSIerと運用に強いMSPを組み合わせる方法もあります。大切なのは、分担がある場合の責任者と障害時の窓口を一つに決めることです。

クラウド基盤に第三者認証やSLAがあっても、業務システム全体の安全性や可用性が自動的に保証されるわけではありません。クラウド基盤側の設備やサービス提供と、利用者側のOSパッチ、アプリの脆弱性、ID・権限、暗号化、ログ、バックアップ復旧テストは別の管理対象です。

RFPでは「誰がサーバーを再起動するか」だけでなく、障害を何分以内に検知するか、何時間以内に暫定復旧するか、データを何時点まで戻せればよいかを記載します。金融・決済、自治体、個人情報を扱うシステムでは、RTOとRPO、閉域網、WAF、操作履歴、復旧訓練の担当まで決めておくと、契約後の追加費用を抑えやすくなります。

ニフクラの発注形態はどれを選ぶべきですか？

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

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

この方式では、標準機能で対応する範囲、追加開発する範囲、手作業で運用する範囲を発注前に決めます。標準機能に合わせられる業務まで個別開発すると費用と保守負担が増えますが、業務上の例外を無理に削ると現場で使われません。候補製品のデモと業務シナリオを照らし合わせて判断します。

オンプレミスのWindows Server、Linux、DB、ファイルサーバー、Active Directoryを活かしたい場合は、ニフクラへの移行を外注する形態が現実的です。現行サーバーを仮想マシンとして移すリフト、OSやミドルウェアを更新するリプラットフォーム、アプリまで再設計するモダナイゼーションを区別すると、必要な作業が見えます。

移行だけなら開発費を抑えられる場合がありますが、古いOSやSQL Server、複雑なバッチ、属人化した運用をそのまま移すと、問題も移行先に持ち込むことになります。発注先には、現行調査と移行後の改善を別見積もりにしてもらい、まず安全に動かす計画と、後から改善する計画を分けて比較します。

社内にクラウドや開発の担当者が少なく、業務部門からの要望整理も含めて進めたい場合は、要件定義、設計、開発、移行、運用を一括委託する方法があります。窓口が一本化されるため、発注者の負担を抑えやすい一方、提案内容がブラックボックスになると、不要な機能や過剰な構成が入りやすくなります。

一括委託でも、発注者が決めるべき事項は残ります。業務上の優先順位、停止できる時間、承認者、データの保管年数、障害時の判断者、納品物の利用権、運用費の上限などです。委託先に任せることと、意思決定を丸投げすることは違うため、定例会議と承認プロセスを契約書やプロジェクト計画に組み込みます。

ニフクラのシステム発注はどのように進めますか？

発注は、会社を探してすぐ見積もりを依頼するより、現状と目的を整えてから候補会社へ同じ情報を渡す方が成功しやすくなります。おすすめは、現状棚卸し、方式の比較、RFP作成、提案・見積もり、契約、要件定義、設計・開発、移行・運用引き継ぎという順番です。

まず、現行サーバーの台数、OS、DB、連携先、帳票、ユーザー数、ピーク時の処理量、データ量、バックアップ方法、停止可能時間を一覧化します。販売管理なら受注から出荷・請求まで、人材派遣管理なら求人・スタッフ・勤怠・請求まで、業務の流れを担当者に確認して、画面一覧だけでは見えない例外処理も記録します。

目的も「クラウド化する」だけでは不十分です。たとえば、拠点から安全に利用したい、月末の処理時間を短くしたい、災害時に復旧したい、運用担当者の夜間対応を減らしたいなど、測定可能な目的に置き換えます。目的が具体的になるほど、必要なサーバー性能、監視レベル、移行範囲を発注先と話しやすくなります。

RFPには、背景と目的、対象業務、現行環境、利用者数、必要な機能、データ移行、外部連携、セキュリティ、性能、可用性、納期、予算、納品物、保守条件を入れます。候補会社には、提案書の構成、前提条件、除外事項、体制、工程表、初期費用、月額費用、保守費用を同じ順番で提出してもらいます。

候補は、FJcloud-Vの構築経験だけでなく、対象業界の業務知識と移行実績を合わせて選びます。公式事例には、システナによるニフクラを使ったIoTサービスのPoC、ケンファーストによる東西リージョンのDRを含むFinTech基盤、エイチ・シー・ネットワークスによる遠隔講義システムなどがあります。事例の掲載だけで決めず、現在もFJcloud-Vに対応できる担当者がいるか、類似案件の成果物を確認します。

新システムが完成しても、データ移行と切り替えに失敗すれば業務は止まります。移行対象のデータを洗い出し、重複や欠損を確認し、変換ルールを決め、テスト移行を複数回行います。切り替え当日の作業手順、読み取り専用にする時間、旧環境を残す期間、切り戻しの条件を事前に承認します。

運用引き継ぎでは、監視アラートの見方、障害時の連絡網、バックアップからの復旧手順、アカウント追加、パッチ適用、費用確認、EOL情報の確認方法を文書化します。バックアップが取得できるだけでなく、実際に復元できることが重要です。少なくとも本番稼働前に復旧テストを実施し、結果と残課題を納品物に含めてもらいます。

RFPと要件整理では何を決めますか？

RFPは、開発会社に丸投げするための資料ではなく、発注者と委託先が同じ前提に立つための資料です。細かな画面仕様を最初から確定できなくても、業務上の目的、優先順位、制約条件、判断基準を明確にすると、提案の比較精度が上がります。

機能要件は「顧客管理機能が必要です」と書くだけでは、会社ごとの解釈が変わります。「営業担当が顧客を登録し、重複を検知し、承認後に受注へ連携し、月次で一覧を出力する」のように、利用者、入力、処理、承認、出力、例外を業務シナリオで記載します。画面、帳票、バッチ、API、通知、権限をシナリオに紐づけると、見積もりの抜けが見つかります。

優先順位も必ず付けます。稼働初日に必要な機能、手作業で代替できる機能、将来追加する機能を分ければ、第一段階の費用と納期を抑えられます。すべてを必須機能として見積もると、予算超過や納期遅延につながりやすくなります。

非機能要件には、性能、可用性、セキュリティ、バックアップ、監視、拡張性、運用時間を含めます。たとえば、平常時とピーク時の同時利用者数、画面応答時間の目標、月間の稼働時間、障害検知の目標時間、RTO、RPO、バックアップ世代、ログ保管期間を記載します。曖昧な「高速」「安全」「止まらない」という表現は、提案段階で質問して具体化します。

セキュリティでは、FJcloud-V側の認証・ネットワーク・監視と、利用者側のID管理、OS・ミドルウェアのパッチ、アプリの脆弱性診断、データの持ち出し制御を分けます。ISMAPやISO/IEC 27017などの認証を確認するだけでなく、自社の監査要件を満たすために追加設定や運用手順が必要かを委託先へ質問します。

移行では、マスタ、取引履歴、添付ファイル、ユーザー、権限、ログ、バックアップをそれぞれ対象にします。すべてを移すのか、一定期間の履歴だけにするのか、古いデータを参照用に保存するのかを決めます。データ量だけでなく、文字コード、日付形式、コード体系、重複、欠損、個人情報の扱いも確認します。

品質基準は「移行後の件数が一致する」「金額合計が一致する」「主要な顧客を検索できる」「帳票の出力結果を現行と照合する」など、検証できる形にします。発注者側の業務担当者には、サンプルデータの確認と受入判定に参加してもらいます。移行データの正しさを開発会社だけに負わせると、業務上の意味を誤認するリスクが高くなります。

契約形態と責任分界はどう選びますか？

ニフクラのシステムでは、基盤の設定、アプリ開発、移行、保守で作業の性質が異なります。すべてを一つの契約形態に押し込めるより、要件の確定度と成果物の明確さに合わせて契約を分ける方が、費用と責任を管理しやすくなります。

画面仕様、機能一覧、テスト条件、納期、検収基準が固まっている開発工程では、請負契約が候補になります。完成させる成果物と検収条件を契約に書きやすく、予算を固定しやすい点が特徴です。一方、要件が曖昧なまま請負にすると、変更のたびに追加見積もりとなり、発注者と受注者の認識が対立しやすくなります。

請負契約では、納品物の形式、検収期間、瑕疵対応、仕様変更の手続き、第三者ソフトウェアのライセンス、ソースコードや設計書の利用権を確認します。特にクラウドの設定情報、Infrastructure as Code、監視設定、バックアップ手順が納品対象かは、運用引き継ぎに直結するため、見積書ではなく契約書や仕様書に記載します。

現行調査、技術検証、要件定義、アジャイル開発のように、作業を進めながら最適な方法を決める工程では、準委任契約が候補になります。稼働する人員や作業時間を基準に進めやすく、未知の課題を洗い出す工程に向いています。ただし、作業を依頼する契約であっても、何を調査し、どの会議に参加し、どの資料を作るかは明確にします。

準委任では、月額の人月や稼働時間だけを見ず、担当者の役割、稼働上限、成果物、課題管理、報告頻度、追加作業の承認方法を確認します。要件定義を準委任で行い、確定した開発部分を請負に移す段階契約にすると、最初から不確かな仕様を固定価格にするリスクを抑えられます。

運用保守では、監視、アラート通知、一次切り分け、再起動、障害復旧、バックアップ確認、パッチ適用、問い合わせ、軽微な改修を分けて契約します。24時間365日監視と書かれていても、アプリ障害の原因調査やデータ修正まで含むとは限りません。検知、連絡、判断、復旧、報告の各担当を明記します。

2026年にはFJcloud-Vの有人監視について、4月1日以降の利用分を対象とした価格改定が案内されています（出典: FUJITSU Hybrid IT Service「FJcloud-V 有人監視の価格改定について」、2026年）。運用費は契約時の月額だけでなく、将来の価格改定、夜間対応、休日対応、EOL対応、障害時の追加作業まで含めて確認します。

ニフクラのシステム発注費用の相場はいくらですか？

ニフクラのシステム開発費は、クラウド基盤の利用料と、開発会社へ支払う設計・開発・移行・保守費を合算して考えます。公式に一律の開発費が定められているわけではないため、以下は業務システムの類似案件とリサーチノートに基づく目安です。実際の金額は、機能数、データ量、連携数、可用性、移行難易度、契約形態で変わります。

FJcloud-Vの公式料金一覧では、2026年3月16日時点のType-c2「c2-small」が1vCPU・1GBで3,157円（税込）／台／月と案内されています（出典: FJcloud-V「クラウド 料金一覧（税込）」、2026年）。ただし、これはサーバー本体の目安です。DB、増設ディスク、IPアドレス、ロードバランサー、バックアップ、WAF、転送量、監視、OSライセンスなどは構成に応じて別途確認します。

たとえば、検証用にc2-smallを3台使うだけなら、サーバー本体は単純計算で月額9,471円です。本番環境でWeb・AP・DBを冗長化し、6台に増やすと月額18,942円がサーバー本体だけの計算になります。これは実際の請求額を示すものではなく、ディスクやバックアップなどを含まない試算です。見積書では、サーバー台数だけでなく、停止時の料金、長期利用割引、OSやオプションの適用条件を確認します。

費用の目安は、IoT・WebのPoCや簡易業務アプリで100万〜500万円、部門業務システムや既存パッケージのクラウド化で500万〜1,500万円、基幹システム移行や複数拠点・複数DBで1,500万〜5,000万円、大規模ERP・スクラッチ開発・DR付きで5,000万円〜数億円です。いずれもニフクラの公式価格ではなく、業務システムの類似案件から整理した推定レンジであり、個別見積もりが必要です。

期間の目安は、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に対して、前提条件、除外事項、工程、体制、成果物、保守範囲を並べて比較します。

確認する実績は、FJcloud-Vのサーバー構築経験だけでは足りません。自社と同じ業界・業務、同程度のデータ量、既存DBやActive Directoryとの連携、閉域網、WAF、バックアップ、DR、24時間監視の経験を確認します。公式導入事例が古い場合は、現在の担当エンジニア、対応可能なサービス範囲、現行名称での支援実績を質問します。

提案時には、実際にプロジェクトを担当する責任者と技術者に会います。営業担当だけでは、移行の難所や運用の制約を見抜きにくいためです。過去の成果物のサンプル、課題管理表、テスト計画、障害報告の形式を確認すると、契約後の進め方をイメージしやすくなります。

見積書は、要件定義、基本設計、詳細設計、開発、テスト、移行、教育、運用設計、保守に分けてもらいます。各工程で、人日または人月、単価、担当ロール、作業内容、成果物、前提条件を確認します。「システム開発一式」とだけ書かれている見積もりは、安く見えても作業範囲が比較できません。

クラウド費用も、サーバー、DB、ディスク、バックアップ、ロードバランサー、WAF、監視、OSライセンス、通信、サポートに分けます。初期費用と月額費用を分け、通常月、繁忙期、障害時、将来のサーバー増設の4パターンを試算すると、稼働後の予算を見通せます。価格改定やEOLに伴う更新作業が誰の負担かも、見積もりの注記で確認します。

他社より大幅に安い見積もりが出た場合は、機能が少ないのか、移行やテストが含まれていないのか、担当者の経験が異なるのかを確認します。特に、データクレンジング、連携先の改修、性能試験、脆弱性診断、利用者教育、切り替え後の立ち会いは、見積もりから漏れやすい作業です。

追加費用の条件は、仕様変更、データ量の増加、連携先の仕様変更、休日作業、障害対応、OSやミドルウェアのEOL、クラウド料金の改定に分けて確認します。発注前にすべての変更を予測することはできませんが、追加が発生する条件と承認者を決めておけば、予算管理がしやすくなります。

よくある質問（FAQ）

最後に、ニフクラのシステムを発注・外注するときに、担当者からよく寄せられる質問へ回答します。料金や契約の判断は、現行環境、求める可用性、業務範囲によって変わるため、ここでは判断の軸を整理します。

現在の公式上の名称は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を渡し、工程別の費用、前提条件、除外事項、成果物、担当体制、障害対応を確認してください。ニフクラ上のシステムは、基盤、アプリ、移行、運用を分けて考えるほど、発注後の追加費用や責任のあいまいさを減らしやすくなります。

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

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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