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

FuelPHPのシステム開発を外部へ発注する流れは、現状の調査と要件整理から始め、同じ条件で委託先を比べて決めるのが基本です。

受入条件と保守の範囲まで合意しておくと、追加費用や運用上のリスクを抑えやすくなります。

▼全体ガイドの記事
・FuelPHPのシステム開発の完全ガイド

FuelPHPのシステムを発注する前の全体像

FuelPHPは業務システム製品ではなく、PHPでWebシステムを開発するフレームワークです。そのため、費用や委託先の適性は利用料ではなく、業務機能、データ、連携、品質要件、運用範囲で決まります。

新規開発と既存システムの保守の違い

既存システムの保守と新規開発では、確認すべき内容も選び方も異なります。

  • 既存システム:調査したうえで、保守継続、部分改修、段階移行から選ぶ
  • 新規開発:FuelPHPを採る目的と、既存の資産や人材を活用できるかを確認する
  • 長期運用:Laravelなどと比べたうえで、採用する環境で実機検証する

既存システムでは、PHPとFuelPHPの版、Composerの依存関係、DBを調べます。バッチや外部API、サーバー設定も、あわせて確認します。そのうえで、保守を続けるか、改修や移行に進むかを決めます。

既存の社内人材や資産を活用できる、特定の会社が保守を続けられるといった理由があれば、FuelPHPは候補になります。

既存システムでソースコードや設計書がなく、仕様がコードの中にしか残っていない場合は、改修の前に調査とテスト設計が必要です。

FuelPHPの公式GitHubには、PHP 8.0互換との説明があります。しかし、現行のPHPすべてに対応しているわけではないため、採用するPHPと周辺ライブラリで実機検証が必要です。

見積の中心となる業務範囲

見積条件を揃えるには、費用に影響する業務範囲と複雑さを具体的に示すことが欠かせません。

  • 機能:ログイン・権限、顧客・商品・社員などのマスタ、見積・受注・請求・在庫処理
  • 運用・連携:承認、CSV、帳票、定期バッチ、外部連携、操作ログ
  • 複雑さ:同じ10画面でも、部門別の権限や承認、締め処理、監査証跡によって工数が変わる

画面数だけで比べると、見積の差が条件の違いから来るのか、工数の違いから来るのかを見分けにくくなります。

問い合わせの際は、利用者や業務ルール、データ量を各社に同じ条件で示します。連携先、障害時の目標、納品物も書き添えておくと、見積の比較がしやすくなります。

FuelPHPのシステムに向く発注形態

一括請負と準委任・時間精算型を、向く工程と仕様の固まり具合で対比した図解。
仕様を固められるかどうかが契約選びの分かれ目です。

発注形態は、要件がどこまで固まっているかと、社内に必要な知識があるかで選びます。既存の仕様が不明なままなら、一括発注より先に調査と要件定義を進めたほうが、追加費用や納期の遅れを抑えやすくなります。

定型業務であれば、パッケージやSaaSを比較の候補に入れます。一方で、独自の業務や既存システムとの連携が重要な場合は、スクラッチ開発を検討します。

仕様と完成条件が決まる案件の一括請負

一括請負は、仕様と完成条件を合意できる案件で選びやすい契約形態です。

  • 委託範囲:要件定義から設計、開発、テスト、リリースまで
  • 利点:合意した成果物の完成を目指すため、納期と予算を管理しやすい
  • 注意点:要件が曖昧なままだと、範囲外の変更が追加費用になりやすい

契約書や仕様書には、画面一覧と業務フロー、受入条件を残します。さらに、除外範囲と変更手続きも書いておくと、範囲外の作業が出たときの扱いを事前に決めておけます。

準委任・時間精算が向く調査や段階改修

準委任や時間精算型では、作業時間と体制に応じて費用を支払います。既存コードの仕様把握やPHP更新の互換性確認、テスト追加のように、作業量を事前に確定しにくい工程に向いています。

予算を見通すには、月ごとの上限時間と担当者を決めておきます。作業報告と優先順位のほか、成果物と障害対応の扱いも、あらかじめ取り決めておきます。

調査・要件定義・開発を分けた段階発注

調査、要件定義、開発を分けておくと、各段階で確認した結果を次の発注判断に使えます。

  • 調査:2〜6週間程度の健康診断から始める
  • 次工程:診断結果を使い、要件定義を終えてから開発へ進む
  • 移行検証:代表画面やバッチで互換性とテスト方法を確かめる
  • 成果物:診断レポートや課題一覧を、次工程でそのまま使える形にしておく

既存のFuelPHPの調査・健康診断は、50万〜200万円程度が推定レンジです。調べる対象には、ソースや依存パッケージ、PHPとDBの版が含まれます。加えて、脆弱性や性能、運用手順も確認します。

調査結果があれば、複数社に同じ前提で開発の見積を依頼できます。

ポイント

要件と完成条件を決められるなら一括請負を、決めきれないなら準委任か段階発注を検討します。どれを選ぶかは、社内に必要な知識が足りているかでも変わります。

FuelPHPのシステム発注・外注の進め方

業務フローと非機能要件の整理からRFP、提案評価、受入条件へ進む発注工程の図解。
前工程で決めた条件が、提案と受入の共通基準になります。

発注の成否は、発注者と委託先が同じ完成イメージを持てるかで決まります。そのため、現場業務を担う人と管理者の判断を、初期の段階から要件に反映できるようにします。さらに、経営上必要な集計を使う人と運用責任者も、早い段階で巻き込んでおきます。

決まった内容は文書に残し、要件整理、提案依頼、開発受入の順に進めます。

要件定義で整理する業務フローと非機能要件

業務フローとシステム要件は分けて整理し、その内容をRFPに反映します。

  • 業務:誰がいつ何を使い、何を判断するかを整理する
  • 機能:利用者・権限、データ、承認、締め・例外処理、帳票・連携を確認する
  • 非機能:ピーク時の同時利用者数、応答時間、バックアップと復旧の目標
  • 環境:個人情報の扱い、クラウド、PHP・DBの版

既存システムでは、画面や帳票を見て、使われていない機能と止められない機能を区別しておきます。

ログの保存と監視、メンテナンス時間、データの保存期間も、要件に含めておきます。

個人情報を扱う場合は、アクセス制御と認証、不正アクセス防止、委託先の管理を確認します。さらに、漏えい時の連絡手順も、個人情報保護委員会のガイドラインに沿って整えます。

RFPに書く対象範囲と提案してほしい内容

RFPで依頼内容と提案への質問を揃えておくと、各社の回答を並べて比べられます。

  • 依頼内容:背景、目的、課題、対象業務、利用者、画面・帳票・バッチ・連携の概数
  • 計画条件:データ移行、希望日程、予算の考え方、納品物、保守体制、提案期限
  • 技術確認:PHP更新、静的解析、テスト、Docker、CI/CDの方法
  • 提案評価:体制や類似案件、リスク、前提条件を、具体的に示せるかで見る

既存のFuelPHPでは、ソースとComposer、DB定義を確認し、cron、環境変数、インフラ構成も押さえます。

ログイン情報の受け渡しやデータ移行リハーサル、障害時の一次対応についても、質問に含めます。

Composer auditやPHPUnit・E2Eテストの扱いに加え、設計書とテスト仕様書の作り方も確認します。

設計・開発・テストの前に決める受入条件

受入条件は、業務が完了したと言える状態から、品質、リリース後の対応までを含めて決めます。

  • 業務テスト:受注から在庫引当、承認、請求、会計連携までを通して確かめる
  • 例外テスト:権限不足、二重登録、締め後の変更、連携停止、CSVの不正を試す
  • 受入条件:機能、性能、セキュリティ、復元、マニュアル、教育、移行件数の基準
  • リリース:切り戻し、連絡網、監視、初期サポート期間

別フレームワークへ移行する場合は、旧システムと新システムの結果を照合する回帰テストが、特に重要です。

不具合を無償で直す期間と、有償の仕様変更になる条件を明確にしておくと、運用後の認識違いを抑えられます。

ポイント

発注者と委託先が同じ完成イメージを持てているかを、要件整理から受入まで各段階で確かめます。そろっていない項目は、次の工程に進む前に文書で埋めておきます。

FuelPHPのシステム開発・外注費用の相場

小規模、中規模、基幹システム、大規模移行の順に推定費用レンジを示す規模遷移図。
規模が大きくなるほど、費用レンジも広がります。

FuelPHPには公定価格も一律の料金表もありません。ここで示すのは、公開されている相場や人月単価、案件規模から整理した推定レンジです。

費用は、画面数やバッチ、外部連携の多さで変わります。さらに、移行量や性能要件、設計資料の有無にも左右されます。

予算計画の初期の目安として使えます。

規模別の費用の幅(300万〜1億2,000万円)

管理画面から基幹システムまで、規模ごとの推定レンジを並べて比べます。

  • 小規模:管理画面などは300万〜800万円程度
  • 中規模:受発注・在庫システムは800万〜2,000万円程度
  • 基幹システム:複数部門向けは2,000万〜8,000万円程度
  • 大規模移行:Laravelなどへの移行は3,000万〜1億2,000万円程度

小規模は5〜20画面の範囲で、ログイン・権限、CRUD、CSVを含む場合の目安です。簡易帳票とテストも含みます。

中規模は20〜60画面を想定した案件で、複数の権限や承認を含みます。帳票、外部連携、データ移行も含まれます。

基幹システムの推定は、複雑な業務ルールやバッチ、APIを前提にしています。監査や可用性、教育も含みます。

大規模移行の幅には、既存機能を洗い出す作業と互換実装が含まれます。さらに、段階リリースや回帰テスト、データ移行も含みます。

これらは規模から算出した推定で、特定の案件の価格を保証するものではありません。

要件定義・開発・移行・テストごとの費用内訳

見積の内訳と運用費を分けて見ておくと、総額と継続費用を比べられます。

  • 開発工程:要件定義、UI・業務・サーバー・DB設計、実装、各種テスト
  • 導入工程:データ移行、教育、リリース、保守準備
  • 運用費:初期開発費の年15〜20%が一つの目安

人月単価の公開相場は50万〜150万円程度で、専門性や難易度によって変わります。契約期間や管理工数によっても変動します。

テストやPMが別料金だと総額が増えるため、工数と成果物をあわせて比べます。

単体・結合・受入支援テストや保守準備が、内訳に含まれているかを確認します。

初期費用が1,000万円なら、運用費は年150万〜200万円、月12.5万〜16.7万円程度です。ただし、障害対応や監視、バックアップ確認をどこまで含むかや、セキュリティ更新や軽微な改修の範囲によっても変わります。

クラウド料金や、PHP・OSの更新は別料金かどうかを確認します。大きな追加機能や緊急の脆弱性対応も、別料金になるかを確かめておきます。

ポイント

費用は規模と範囲で変わるため、推定レンジは出発点の目安として使い、同じ条件の見積を複数社から取って比べます。運用費は初期費用と分けて見ます。

RFPと見積を比較する際のポイント

最安値の会社より、同じ前提でリスクを説明できる会社を選びます。見積のあとに、コード品質や資料不足、古いPHP拡張が見つかることがあります。さらに、手作業のバッチや属人運用が、後から分かることもあります。

安い理由と高い理由を各社に尋ね、見積の前提と除外範囲、追加条件を並べて確認します。

見積の前提条件と含まれない作業

各社の見積条件を揃えるため、対象と含まれない作業を並べて確かめます。

  • 画面・データ:画面数の定義、権限差、移行データの年数
  • 機能・検証:帳票、CSV形式、バッチ頻度、API数、テストデータ
  • 除外作業:クラウド、ネットワーク、ドメイン、SSL、外部契約、データ整備
  • 変更管理:追加や変更の単価と承認方法の決め方

画面数は、登録や検索を各1画面と数えるかどうかで変わります。詳細、承認、一覧出力についても、各1画面と数えるかを決めておきます。

マニュアルや教育、利用者側の受入作業は、見積に含まれるかを確認します。リリース後の問い合わせも、対応範囲に入るかを確かめます。

FuelPHP以外の保守力を含めた委託先への質問

FuelPHPの実績だけでなく、保守や移行をどこまで担えるかを、具体的に確認します。

  • 実績:業務領域、画面・バッチ数、連携、担当工程、保守期間、移行先
  • 技術力:既存PHP調査、PHP更新、Docker化、解析、テスト、移行の対応範囲
  • 移行事例:規模と実施内容を聞き、効果が自社の条件に当てはまるかを確認する

FuelPHPに対応している会社でも、新規開発は受けず、既存の保守や移行だけを受ける場合があります。

株式会社イーグリッドは、FuelPHPとMySQLによる製品管理や分析、CRMなどを紹介しています。

BPS株式会社は、既存PHPの調査とPHP 8対応を案内しています。Docker化や静的解析、テスト、Laravelなどへの移行も案内しています。

2026年6月、株式会社DEN-NO Solutionsは、FuelPHPから最新PHPとLaravel 12への大規模移行事例を公開しました。

対象は数十万行の基幹システムで、従来の手法と比べて金額と工期が約3分の1になったと、個別に発表されています。

効果は対象や要件によって異なります。そのため、削減率をそのまま自社の見積に当てはめず、コード解析やテスト、知識移管を比べます。

契約前に確定する納品物と引き継ぎ体制

契約前に、納品物と権利、引き継ぎ、発注者側の役割を明確にしておきます。

  • 成果物:設計・テスト資料、DB・Composer定義、環境設定、運用資料
  • 権利:リポジトリ、著作権、第三者ライセンス、再委託成果物の扱い
  • 引き継ぎ:期間、窓口、障害対応、報告、PHP・OS更新の責任者
  • 発注者の役割:業務、移行データ、受入テストのそれぞれに担当者を置く

成果物には、要件定義書や画面・API・DB設計書、テスト仕様と結果を含めます。さらに、DBマイグレーションやDocker・CI/CDも、納品の対象に入れます。インフラ構成やバックアップ・復元手順も対象です。

運用マニュアルとアカウント・ライセンス一覧は、契約書に記載します。

リポジトリの所有権や著作権、第三者ライセンスは、契約前に確認しておきます。退職者や再委託先が作った成果物については、扱いを決めておきます。

データ移行とマスタ整備は、業務の正しさを判断できる発注者と開発会社とで分けて担います。

担当会社が変わる可能性がある場合は、引き継ぎ期間や窓口、障害の優先度と応答時間を決めておきます。

月次の報告と、定期的なPHP・OS更新の責任者も、あらかじめ定めておきます。

ポイント

見積は安さだけで決めず、前提条件と除外範囲をそろえたうえで、リスクを説明できる会社を選びます。後から見つかりやすい問題も、事前に委託先へ尋ねておきます。

契約、セキュリティ、将来の移行を含む発注条件

FuelPHPでは、技術の選定に加えて、安全に運用できる契約条件も欠かせません。

既存システムは、担当会社が変わっても保守できる状態にしておくことと、PHPや依存パッケージの更新計画を持つことが、将来の費用を抑えることにつながります。

請負と準委任の責任範囲の区別

機能や文書を納品する部分は請負とし、調査や継続的な改善など、作業の遂行を委託する部分は準委任とする方法があります。

1つの契約にまとめると、仕様変更や追加作業、受入の責任が曖昧になりやすくなります。そのため、工程ごとに契約形態を整理します。

検収や不具合、再委託の扱いは、専門家にも確認します。秘密保持や個人情報、損害賠償の上限も、契約の前に専門家へ相談しておきます。

PHPのサポート期限と依存パッケージの管理

採用環境の互換性と各バージョンのサポート期限を把握したうえで、更新と検証の作業を発注範囲に含めます。

  • 互換性:PHP、拡張、Composer、DB、Webサーバーの組み合わせを検証する
  • 依存関係:FuelPHP 1.9.0は2021年12月28日付でPackagistに掲載
  • サポート期限:PHP 8.2は2026年12月31日、8.3は2027年12月31日まで
  • サポート期限:PHP 8.4は2028年12月31日、8.5は2029年12月31日まで

安定版の掲載日が古くても、すぐに使えなくなるとは限りません。そのため、周辺パッケージの更新頻度や脆弱性を確認します。

更新できない理由も記録しておきます。サポート期限は、PHP Supported Versions(2026年確認)の内容によります。

PHP 8.1以下の場合は、コード修正や非推奨APIの検出を含めます。さらに、ステージングでの負荷・回帰テストやロールバックも含めておきます。

保守継続とLaravelなどへの段階移行の比較

現行環境の状態と今後の運用条件を比べ、保守を続けるか移行するかを判断します。

  • 保守継続:業務知識があり、PHP更新とテスト整備で安全に運用できる場合
  • 移行検討:担当者不在、依存ライブラリの更新不能、改修時の障害、仕様がコードに埋もれている場合
  • 判断軸:停止リスク、改修量、保守人材、総保有コスト
  • 段階移行:影響を抑えやすい機能から切り離し、並行稼働も検討する

段階移行では、認証やマスタを、APIやデータ連携を介して切り分けて置き換えます。参照画面と代表バッチは、同じ仕組みで分けていきます。

全面移行の前には、代表画面とバッチでPoCを行い、データ差分の検証と受入テストの基準を作ります。

ポイント

契約と将来の移行は、担当会社が変わっても保守を続けられるかを基準に考えます。工程ごとの契約形態と、PHPの更新計画も、あらかじめ決めておきます。

よくある質問

技術が古いというだけで結論を出さず、システムの状態と将来の運用条件を確認します。

問い合わせ前によくある疑問に答えます。

FuelPHPのシステムはPHP 8系で動きますか?

公式の説明はPHP 8.0互換ですが、8.4や8.5で動くとは限りません。そのため、本体と拡張、Composerパッケージを対象の版で検証し、アプリも同じ条件で確かめます。非推奨API、テスト結果、障害時の切り戻しも確認します。

FuelPHPのシステム発注はいくらかかりますか?

FuelPHPの発注費用は、既存調査・健康診断から大規模移行まで、対象の規模と範囲が広がるほど高くなります。

  • 既存調査:50万〜200万円
  • 小規模管理画面:300万〜800万円程度
  • 中規模受発注・在庫:800万〜2,000万円
  • 大規模移行:3,000万〜1億2,000万円程度

公開相場と案件規模から見た目安で、金額は画面数のほか、バッチや連携、移行の範囲で変わります。テストや保守の範囲によっても差が出ます。そのため、同じ条件をRFPで示し、複数社から見積を取ります。

2026年に新規開発でFuelPHPを選んでもよいですか?

既存の資産や人材、連携を活用でき、PHPなどを長期にわたって検証できるなら、候補になります。

Packagistの安定版1.9.0は、2021年12月28日に公開されています。そのため、Laravelなどとの比較や保守体制、移行のしやすさも比べます。

ソースコードや設計書がない場合も外注できますか?

外注は可能ですが、いきなり改修を頼まず、まずは調査を発注して現状を一覧にしてもらいます。

  • 調査:ソース、DB、サーバー、cron、外部サービス、環境変数を確認する
  • 運用情報:ログとバックアップを確認し、現場へのヒアリングで業務仕様を補う
  • 方針比較:保守、部分改修、段階移行、全面刷新を比較表にする

比較表に優先順位を付けておくと、対応方針を選びやすくなります。

まとめ

発注では、新規開発、既存保守、移行のそれぞれの目的を分けて考えます。そのうえで、業務フローと画面・帳票・バッチ・連携を、RFPに整理します。データと非機能要件も、あわせて盛り込みます。

調査、要件定義、開発は、必要に応じて段階的に発注します。

調査から始める段階的な発注

調査は50万〜200万円、小規模開発は300万〜800万円程度です。中規模開発は800万〜2,000万円、大規模移行は3,000万〜1億2,000万円と見込まれます。これらは、いずれも推定レンジです。

金額だけでなく、どこまでを含むかも見ておく必要があります。要件定義から移行、テストまでの範囲に加え、設計書と保守、PHP更新と障害対応も比べます。

コードの状態を一覧にして、品質や将来の移行まで説明できる委託先は、発注後のリスクを抑える助けになります。

価格と納品物、将来の保守体制の比較

同じ条件で複数社を比べ、見積の範囲、成果物、将来の運用方針を確認します。

  • 作業範囲:調査、要件定義、開発、テスト、移行、保守
  • 納品物:ソース、設計書、テスト結果、インフラ設定、バックアップ手順
  • 将来方針:保守継続かLaravelなどへの段階移行かを比較する

引き継ぎの条件を確認しておき、移行の判断では、業務停止のリスクと総保有コストを材料にします。

▼全体ガイドの記事
・FuelPHPのシステム開発の完全ガイド

会社紹介

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

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

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

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

執筆者プロフィール
張田谷凌央
張田谷凌央

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