FuelPHPのシステム開発の完全ガイド

FuelPHPのシステム開発は、既存資産の保守・改善には合理的な選択肢ですが、新規の長期運用ではPHPの対応状況と将来の移行計画まで比較して判断することが重要です。

FuelPHPは業務システム製品ではなく、PHPでWebシステムを構築するためのフレームワークです。そのため、ログインや権限管理、顧客・商品マスタ、受発注、請求、在庫、帳票、外部連携などを、業務に合わせて設計・開発します。本記事では、FuelPHPの基本機能、向いているシステム、開発の進め方、費用相場、クラウドやセキュリティ、Laravelなどへの移行判断、開発会社・ベンダーの選び方、FAQまでを一つの判断ガイドとして解説します。

▼関連記事一覧
・FuelPHPのシステム開発の進め方/やり方/流れや方法/手法/工程/手順
・FuelPHPのシステム開発でおすすめの開発会社/ベンダー6選と選び方
・FuelPHPのシステム開発の見積相場や費用/コスト/値段について
・FuelPHPのシステム開発の発注/外注/依頼/委託方法について

FuelPHPのシステムとは何ですか？全体像を解説します

FuelPHPのシステムとは、FuelPHPを開発基盤として構築されたWeb業務システムを指すことが多いです。FuelPHP単体を導入すれば業務機能が完成するわけではなく、業務ルール、データ構造、権限、連携、運用を組み合わせて初めて企業向けの仕組みになります。

FuelPHPは、PHPでWebアプリケーションを作るためのオープンソースのフレームワークです。MVCを基本に、画面を担当するView、リクエストを受けて処理を制御するController、データや業務ロジックを扱うModelを分けて開発できます。さらに、機能を小さな単位で再利用するHMVC、ORMによるデータベース操作、入力値検証、認証、メール、ファイルアップロード、テンプレート、Oilコマンドラインツールなどを組み合わせられます。

公式リポジトリはFuelPHP 1.xについてPHP 8.0対応を掲げ、MITライセンスで公開しています。一方、Packagistで確認できるFuelPHP 1.x Coreの安定版1.9.0は2021年12月28日リリースです（出典: FuelPHP公式GitHubリポジトリ、Packagist、2026年確認）。これはすぐに使えないという意味ではありませんが、PHP 8.4やPHP 8.5、周辺パッケージまで自動的に適合することを意味しません。実際のシステムでは、対象バージョンでの検証が必要です。

典型的な構成は、利用者のブラウザや外部APIクライアント、WebサーバーとPHP-FPM、FuelPHPのController・Model・View、MySQLやPostgreSQLなどのデータベース、Oilやcronで動かすバッチ、クラウドまたはオンプレミスの実行基盤です。ログイン画面だけでなく、誰がどのデータを見られるか、どの承認を経て請求できるか、どのタイミングで在庫が減るかを、データと処理の関係として設計します。

既存システムの改修では、ソースコードだけを受け取っても不十分です。Composerの依存関係、PHP拡張、DBスキーマ、環境変数、cron、外部API、メール配信、ファイル保存先、デプロイ手順、監視、バックアップ、障害時の復旧方法まで棚卸しします。見えない運用を残したまま担当者だけを交代すると、軽微な改修でも業務停止につながるためです。

FuelPHPの標準機能は、認証や入力値検証などの土台を提供しますが、企業ごとの権限や承認を自動で決めるものではありません。たとえば、営業担当者は自分の顧客だけを参照し、部門長は部門全体を承認し、経理担当者は請求確定後の金額だけを修正できるようにする場合、組織階層・職務・データ範囲・操作ログを要件として定義します。

代表的な機能は、顧客・商品・社員のマスタ管理、見積・受注・請求・入金、在庫、承認ワークフロー、CSV入出力、帳票、定期バッチ、外部API、会計・EC・決済・SFTP連携、監査ログです。どの機能をFuelPHPで作れるかではなく、どのデータを正本にし、例外処理を誰が承認し、後から説明できる履歴をどこまで残すかが設計の中心になります。

FuelPHPで開発できるシステムの種類

FuelPHPは業種を限定するフレームワークではないため、定型的な管理画面から複雑な業務基幹まで幅広く使えます。ただし、機能を増やせることと、運用しやすいシステムを作れることは別です。利用者、データ量、業務の例外、外部連携、将来の保守体制を合わせて種類を選びます。

社内向けの管理画面は、FuelPHPの構成を活かしやすい代表例です。顧客、商品、社員、取引先、拠点などのマスタを登録し、検索、一覧、詳細、CSV入出力、権限管理、履歴表示を実装します。業務の最初の対象を小さく定めれば、既存のExcelや紙の運用を置き換えながら、入力漏れや集計作業を減らせます。

ただし、単純なCRUD画面だけで終わらせないことが重要です。重複登録、無効化、過去データの訂正、締め処理後の変更、CSVの文字コード、個人情報のマスキング、操作ログの保存など、現場で発生する例外を最初から決めます。管理画面の便利さだけを優先すると、後からデータの正しさを確認できなくなります。

受発注や請求、在庫のシステムでは、画面数よりも処理の整合性が重要です。受注を確定すると在庫引当が発生し、出荷すると在庫が減り、請求条件に応じて請求書が発行されるように、状態の変化を設計します。返品、分納、部分キャンセル、値引き、税区分、締め日変更などを想定し、どの状態からどの状態へ遷移できるかを定義します。

複数部門で使う場合は、部門別の権限と全社集計の境界も決めます。月末に処理が集中するなら、同時アクセス数、バッチ実行時間、帳票生成、データベースのロックを測定します。業務システムの費用は画面数だけで決まらず、こうした整合性と性能の要件が工数を左右します。

見積や経費、申請、契約、購買などは、申請・差し戻し・承認・確定の状態を持つワークフロー型のシステムにできます。外部APIやSFTPで会計、決済、EC、物流、勤怠などと連携する場合は、連携先の障害、再送、重複取込、タイムアウト、仕様変更を要件に含めます。

定期バッチは、売上集計、請求書生成、在庫同期、メール配信、データ連携に使われます。バッチが失敗した場合に、どこまで処理済みか、再実行しても二重計上しないか、担当者へどう通知するかを設計します。画面上は正常に見えても夜間処理が止まれば業務が翌朝に持ち越されるため、監視とリカバリ手順までがシステムの一部です。

新規開発・既存保守・Laravel移行はどのように選びますか？

判断の起点は、FuelPHPを採用したいかではなく、業務を止めずに必要な機能と保守性を実現できるかです。既存資産がある場合は継続利用・改善・移行を比較し、新規の場合は現行のPHPフレームワークやSaaS、パッケージと同じ要件で比較します。

既存のFuelPHPシステムが業務を支えており、大きな障害がなく、利用者も運用に慣れているなら、すぐに全面刷新する必要はありません。まずはソースコード、PHP、FuelPHP、Composer、データベース、サーバー、外部連携、脆弱性、性能、ログ、テスト、設計書を調査し、継続利用できる部分と危険な部分を分けます。調査だけでも50万〜200万円、2〜6週間程度が本記事の推定目安です。

調査の成果物は、技術者の感想ではなく、依存関係一覧、PHP更新の可否、障害リスク、改修優先順位、保守手順、移行候補、概算工数を含む診断書にします。これにより、担当者が変わっても判断を引き継ぎやすくなります。

新規開発でFuelPHPを選ぶなら、既存の社内人材や共通部品を活用できる、特定の業務要件を柔軟に実装できる、既存システムとの連携が容易であるなど、具体的な理由を言語化します。単に知名度のある技術だから、開発者が一人見つかったからという理由では、数年後に保守担当者を確保できない可能性があります。

比較対象には、現行のPHPフレームワーク、SaaS、業務パッケージ、別のスクラッチ開発を含めます。初期開発費だけでなく、採用しやすい人材の数、アップデートの頻度、テスト資産、ライブラリ、セキュリティ対応、教育、将来の移行費用を5年程度の総保有コストで比べます。

PHPの更新やFuelPHPの保守が難しくなった場合でも、すべてを一度に作り直す必要はありません。認証、マスタ、参照画面、主要APIなどから新しい構成へ切り出し、旧システムと新システムを段階的に並行稼働させるストラングラー型の移行が候補になります。代表画面と代表バッチでPoCを行い、互換性、性能、データ整合性、テスト工数を確認してから範囲を広げます。

2026年6月に公開された大規模移行の一事例では、数十万行規模のFuelPHPシステムを最新PHPとLaravel 12へ移行し、画面約200、バッチ約60を含む案件で、従来手法と比べて金額と工期を約3分の1にしたと報告されています。ただし、これは個別案件の成果であり、一般的な相場や再現可能な保証ではありません（出典: FuelPHPからLaravel 12への移行事例公開資料、2026年6月）。自社ではコード量だけでなく、仕様不明箇所、外部連携、データ移行、回帰テスト、並行稼働期間を見積もります。

FuelPHPのシステム開発の進め方

FuelPHPの開発では、技術の選定より先に業務とデータを整理します。新規でも既存改修でも、企画、現状診断、要件定義、設計、開発、テスト、データ移行、リリース、保守の順に責任範囲を明確にします。特に既存システムでは、仕様書に書かれていない業務ルールを現場から取り出すことが重要です。

最初に、誰が、いつ、何を入力し、どの条件で承認し、どのデータを次の処理へ渡すのかを業務フローにします。利用者・部門・権限、マスタ、トランザクション、帳票、CSV、API、バッチ、データ量、ピーク時間、保存期間を一覧化します。既存システムでは、PHP・FuelPHP・Composer・DB・OSのバージョン、ソースと設計書の所在、テストの有無、手作業の運用も確認します。

要件定義の段階で、正常系だけでなく、返品、取消、差し戻し、担当者変更、組織変更、連携先停止、重複取込、データ訂正を確認します。要件定義を軽視すると、開発後の追加要望が仕様変更として積み上がり、費用と納期が膨らみます。発注者側が業務ルールと正しいマスタを提供する責任も、最初に合意します。

設計では、画面遷移、データベース、権限、API、バッチ、エラー処理、ログ、バックアップ、監視を決めます。画面一覧やワイヤーフレームだけでなく、受注が確定する条件、在庫を引き当てるタイミング、請求を発行できる状態、再送しても二重登録しない仕組みまで仕様にします。

開発環境と本番環境の差を小さくするため、Composerで依存関係を固定し、Dockerなどで環境を再現できるようにします。静的解析、PHPUnitなどの自動テスト、コードレビュー、CI/CDを導入し、属人的な手順を減らします。FuelPHPの古いコードを扱う場合は、最初から全面的な書き換えを目指すのではなく、改修箇所の周辺からテストを追加して安全な変更範囲を広げます。

テストは、単体テスト、結合テスト、システムテスト、受入テスト、性能テスト、セキュリティテストに分けます。受入テストでは、実際の業務担当者が代表的な一日や月末処理を再現し、画面の使いやすさだけでなく、帳票、集計、権限、エラー、連携結果を確認します。

データ移行では、移行対象、除外対象、変換ルール、名寄せ、欠損、件数照合、旧システムの参照期間を決めます。移行後のマスタ整備を発注者と開発側のどちらが担うかも曖昧にしません。リリース当日は切り戻し条件、緊急連絡先、旧システムの参照方法を準備し、稼働後は障害対応、監視、バックアップ確認、軽微改修、PHPや依存パッケージの更新を保守契約に含めます。

FuelPHPのシステム開発費用と期間の相場

FuelPHP単体の料金表はほとんどなく、費用は画面数、権限、帳票、バッチ、外部連携、データ移行、性能、テスト、インフラ、保守で決まります。以下は2025〜2026年に公開された一般的なWeb・業務システム相場、人月単価、FuelPHP案件の規模から整理した推定目安です。実際の見積では、機能数ではなく作業範囲を同じ条件で比較します。

既存FuelPHPの調査・健康診断は50万〜200万円、期間は2〜6週間程度が目安です。小規模な管理画面や社内業務システムは300万〜800万円、3〜6か月程度です。ログイン・権限、5〜20画面、CRUD、CSV、簡易帳票、テストを含む想定です。

中規模の受発注・顧客・在庫システムは800万〜2,000万円、6〜12か月程度です。20〜60画面、複数権限、承認、帳票、外部連携、データ移行が増えるためです。複数部門で使う基幹・業務システムは2,000万〜8,000万円、12〜24か月程度となり、複雑な業務ルール、バッチ、API、監査、性能、教育、移行を含むとさらに上がります。これは2026年時点の公開相場をもとにした推定です（出典: システム開発外注費用の公開相場情報、2026年）。

FuelPHPからLaravelなどへ大規模に移行する場合は、3,000万〜1億2,000万円、12〜24か月程度を一つの検討レンジとします。画面数だけでなく、バッチ、外部連携、仕様不明箇所、回帰テスト、データ移行、並行稼働が含まれるためです。安価な移行をうたう事例があっても、業務停止リスクを抑えるテストと切り戻しを削らないことが重要です。

開発費の中心は人件費ですが、要件定義、UI設計、データベース設計、実装、テスト、移行、教育、プロジェクト管理をどこまで含むかで変わります。画面が少なくても、権限が細かい、履歴を長期間残す、帳票が多い、外部連携が複雑、ピーク時の性能が厳しい場合は工数が増えます。人月単価だけでなく、工程別の人月数と成果物を確認します。

クラウドを使う場合は、サーバー、データベース、ストレージ、監視、バックアップ、ログ、通信、検証環境の費用が発生します。オンプレミスの場合は、機器、設置、保守、更新、障害対応の負担が自社側に残ります。データ移行では、抽出、変換、名寄せ、検証、リハーサルを分けて見積もり、移行後のデータ確認を省かないことが重要です。

業務システムの保守は、初期開発費の年15〜20％を一つの目安にします。初期費用が1,000万円なら、年150万〜200万円、月12.5万〜16.7万円程度です。これは障害対応、監視、バックアップ確認、セキュリティ更新、軽微改修をどこまで含むかで変わります（出典: 業務システム全般の保守費用に関する公開整理、2026年）。

PHPやOS、ミドルウェアの更新、クラウド料金、脆弱性対応、追加機能、データ修正、休日対応は別費用になりやすいです。月額保守に含む時間、対応時間帯、一次応答、復旧目標、軽微改修の定義、契約外作業の単価、更新計画を契約書に明記します。月額が安くても、障害時に別見積が続けばTCOが高くなるためです。

クラウド・PHP更新・セキュリティをどう設計しますか？

FuelPHPのシステムでも、クラウドに載せれば自動的に安全になるわけではありません。実行基盤、通信、認証、権限、ログ、バックアップ、更新、脆弱性対応を運用として設計します。特に個人情報や取引情報を扱う場合は、技術要件と法令・社内規程を一緒に確認します。

クラウドは、複数拠点、テレワーク、環境の増減、バックアップの自動化を進めやすい選択肢です。仮想マシンやコンテナにPHP-FPM、Webサーバー、データベース、オブジェクトストレージ、監視、バックアップを構成し、開発・検証・本番を分離します。コンテナ化やCI/CDを組み合わせると、担当者の手元だけで動く環境を減らせます。

オンプレミスは、社内ネットワークとの連携、データ保管方針、設備との接続、通信停止時の業務継続などに理由がある場合の選択肢です。一方で、サーバー更新、バックアップ、監視、脆弱性対応、障害対応が自社に残ります。どちらを選ぶ場合も、復旧時間の目標、許容できるデータ損失、バックアップの保管先、定期的な復元テストを決めます。

PHPは各ブランチについて、原則として2年間の通常サポートと、その後2年間の重要なセキュリティ修正を経て、サポート終了となります。2026年時点でPHP 8.2のセキュリティサポートは2026年12月31日まで、8.3は2027年12月31日まで、8.4は2028年12月31日まで、8.5は2029年12月31日までです（出典: PHP公式 Supported Versions、2026年8月確認）。

FuelPHP公式のPHP 8.0対応という記載だけを根拠に、PHP 8.4や8.5でも動作すると判断してはいけません。対象PHP、FuelPHP、Composerパッケージ、拡張、DBドライバを固定した検証環境を作り、非推奨API、型の変更、文字コード、日付処理、認証、ファイルアップロード、決済や外部APIを実機テストします。更新時は段階リリースとロールバック手順を用意します。

個人情報を扱う場合は、担当者とデータ範囲を限定するアクセス制御、利用者の識別と認証、外部からの不正アクセス対策、通信や保存データの保護、操作ログ、委託先管理、漏えい時の対応を要件化します。個人情報保護委員会のガイドラインは、技術的安全管理措置としてアクセス制御、アクセス者の識別・認証、不正アクセス等の防止、漏えい等の防止を示しています（出典: 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」、2026年6月改正）。

Web通信はHTTPSを基本とし、TLSの設定、証明書更新、Cookie、セッション、CSRF、XSS、SQLインジェクション、認可漏れ、ファイルアップロード、依存パッケージの脆弱性を検査します。IPAのTLS暗号設定ガイドラインは2025年4月25日に第3.1.1版が公開され、設定基準とチェックリストを示しています（出典: IPA「TLS暗号設定ガイドライン」、2025年）。FuelPHPの標準機能だけに任せず、インフラとアプリケーションを合わせて確認します。

FuelPHPのシステム開発で起こりやすい失敗と対策

失敗の多くは、FuelPHPという技術そのものよりも、要件、運用、データ、契約、保守の準備不足から起こります。技術選定の議論だけでなく、業務が止まる条件と、止めないための代替手段を具体化します。

「受発注を管理する」「Excelをなくす」といった目的だけでは、見積もりも完成条件も決まりません。対象部門、利用者数、権限、処理件数、締め処理、帳票、連携、保存年数、例外、性能、移行範囲を定義します。特に、現場だけが知っている口頭の判断や、担当者ごとのExcel加工を業務フローに書き出します。

要件を一度に完璧にする必要はありませんが、最初のリリース範囲と後回しにする機能を明示します。MVPとして重要な業務を小さくつなぎ、実データと利用者の反応を見て拡張する方が、全機能を想像だけで作るよりリスクを抑えやすいです。

FuelPHPの経験があるという説明だけでなく、既存コードを読んで、依存関係、認証、DB、バッチ、外部API、ログ、デプロイ、テストを説明できるかを確認します。ソースコードと設計書が一致していない場合は、実際の挙動をテスト環境で確認し、仕様として再整理します。

担当者が退職した場合や契約を終了した場合に備え、ソースコード、設計書、DB定義、テストコード、インフラ設定、Composerファイル、環境変数の一覧、運用手順、アカウントの名義と引き継ぎ条件を決めます。納品物を「ソースコード一式」だけにすると、別の担当者が運用を再現できない可能性があります。

データ移行をリリース直前に始めると、名寄せ、重複、欠損、文字化け、旧コード、税区分、日付、履歴の扱いが一度に問題になります。早い段階でサンプルデータを抽出し、移行後の件数、金額、在庫、残高、参照関係を照合します。発注者がマスタを整備し、開発側が変換と検証を支援するように役割を分けます。

自動テストが少ない既存システムでは、業務上重要な画面やバッチから回帰テストを作ります。代表的な取引、月末締め、異常系、権限違い、連携先停止を実データに近い条件で再現し、旧システムと新しい処理結果を比較します。テストを費用削減の対象にすると、障害発生時の損失が開発費を上回ることがあります。

FuelPHPの開発会社・ベンダーの選び方

開発会社・ベンダーは「FuelPHP対応」と書いてあるかだけで決めません。既存コードを読める力、業務システムの設計力、PHP更新、Docker化、静的解析、自動テスト、クラウド、障害対応、データ移行、段階的なLaravel移行まで、今回の課題に必要な工程を実行できるかで評価します。

実績を見るときは、FuelPHPを使ったという一文だけでなく、どの業務を、どの規模で、どの工程まで担当したかを質問します。業務システムの新規開発、既存保守、PHP更新、クラウド移行、Laravelなどへのモダナイズは必要な技術が異なります。画面数、利用者数、バッチ数、外部連携、データ量、障害対応、保守期間を確認し、自社の条件に近い経験を比較します。

公開実績をそのまま自社の成功保証と考えず、現在も同じ体制で対応できるか、担当者が誰か、契約後にどのメンバーが関わるかを確認します。可能であれば、匿名化した課題や成果物のサンプル、テスト計画、移行リハーサルの進め方を説明してもらいます。

「PHP 8系へ更新できますか」「FuelPHP 1.xの依存パッケージをどう調査しますか」「テストがないコードをどう安全に改修しますか」「障害時に何分以内に一次回答しますか」「夜間バッチが失敗したらどう再実行しますか」といった具体的な質問をします。回答が技術用語だけでなく、調査、検証、承認、リリース、監視、切り戻しの手順まで含んでいるかを確認します。

保守契約では、通常受付の時間、緊急時の連絡先、一次応答と復旧の目標、軽微改修の範囲、セキュリティ更新、脆弱性の報告、バックアップ確認、定例会、担当者交代、再委託の有無を確認します。特定の担当者一人に依存せず、複数人でコードと運用を共有できる体制が望ましいです。

見積書には、要件定義書、画面一覧、画面仕様、DB定義、API仕様、ソースコード、テスト計画・結果、テストコード、移行計画、インフラ設定、監視設定、操作マニュアル、運用手順を含めるかを記載します。成果物の形式、リポジトリの所有権、第三者ライブラリのライセンス、納品時期、検収条件、修正回数も確認します。

相見積もりでは、同じ要件書を渡し、開発費だけでなく調査費、移行費、クラウド費、保守費、追加変更の単価を比較します。極端に安い提案は、要件定義、テスト、ドキュメント、運用引き継ぎが含まれていない可能性があります。初期価格ではなく、5年程度の総保有コストと業務停止リスクで判断します。

▶ 詳細はこちら：FuelPHPのシステム開発でおすすめの開発会社/ベンダー6選と選び方

▶ 詳細はこちら：FuelPHPのシステム開発の発注/外注/依頼/委託方法について

よくある質問

FuelPHPのシステムを検討する際は、技術の古さだけで結論を出さず、既存資産、PHPの対応状況、業務停止リスク、保守体制、移行可能性を合わせて判断します。ここでは、検索者が特に気にする点をまとめます。

FuelPHP公式リポジトリにはPHP 8.0対応の記載がありますが、PHP 8.4や8.5で動くことまで保証する記載ではありません。FuelPHP本体だけでなく、Composerパッケージ、PHP拡張、DBドライバ、アプリケーション独自コードを対象バージョンで検証し、非推奨APIやエラーを修正してください。

既存資産や社内標準を活かせる明確な理由があり、保守担当者、PHP更新、テスト、将来の移行計画を用意できるなら候補になります。ただし、新規の長期運用では現行フレームワーク、SaaS、パッケージも同じ要件で比較し、5年程度の総保有コストと人材確保を確認してから決めます。

規模によって大きく異なりますが、本記事では大規模移行の検討レンジを3,000万〜1億2,000万円、期間を12〜24か月程度としています。画面、バッチ、外部連携、仕様不明箇所、テスト、データ移行、並行稼働を含むためです。まずは健康診断と代表機能のPoCを行い、全面移行と段階移行の差を見積もります。

保守できる可能性はありますが、最初から改修を始めず、現状調査を行います。稼働環境、ソースの所在、依存パッケージ、DB、外部連携、ログ、バッチ、バックアップ、実際の操作を確認し、重要機能の挙動をテストで記録します。調査成果物として構成図、リスク一覧、改修優先度、復旧手順を作ると、引き継ぎの土台になります。

初期開発費の年15〜20％を一つの目安にできます。初期費用1,000万円なら、年150万〜200万円、月12.5万〜16.7万円程度です。ただし、障害対応、PHP更新、脆弱性対応、監視、バックアップ、軽微改修、休日対応のどこまで含むかで変わるため、月額だけでなく契約範囲を確認してください。

アクセス制御、利用者の識別・認証、権限分離、通信と保存データの保護、操作ログ、脆弱性対策、バックアップ、委託先管理、漏えい時の連絡と復旧を要件に含めます。FuelPHPの機能だけでなく、Webサーバー、PHP、DB、クラウド、端末、運用担当者を含めた多層の対策が必要です。個人情報保護委員会のガイドラインと社内規程をもとに、必要な安全管理措置を確認してください。

まとめ

FuelPHPのシステムは、既存の業務資産を活かしながら改修・保守する場合には合理的な選択肢です。一方、新規開発では、PHPのサポート期限、人材、ライブラリ、テスト、保守会社、将来の移行費用まで含めて現行フレームワークやSaaS、パッケージと比較します。

第一に、FuelPHPは製品ではなく、業務要件を実装する開発基盤だと理解します。第二に、既存保守、新規開発、段階移行の3つを分けて考えます。第三に、費用は画面数ではなく、要件定義、権限、連携、バッチ、移行、テスト、保守で変わると捉えます。第四に、PHPの対応状況と脆弱性、個人情報、TLS、バックアップ、復旧を運用まで含めて確認します。

まず、業務フロー、利用者・権限、マスタ、画面、バッチ、外部連携、データ量、PHP・FuelPHP・Composerのバージョン、ソースコードと設計書の所在を棚卸しします。そのうえで、継続利用・改善・段階移行・全面刷新の選択肢を同じ条件で比較し、要件定義、診断、PoC、見積、契約、保守の順に判断します。

開発会社・ベンダーを選ぶ際は、FuelPHPの経験だけでなく、業務理解、既存コードの読解、PHP更新、テスト、データ移行、クラウド、障害対応、成果物の引き継ぎまで確認してください。FuelPHPを使い続けることや新しい技術へ移行することを目的にせず、業務停止リスクと総保有コストを抑えながら、利用者が使い続けられるシステムを作ることが最終的な目的です。

▼関連記事一覧
・FuelPHPのシステム開発の進め方/やり方/流れや方法/手法/工程/手順
・FuelPHPのシステム開発でおすすめの開発会社/ベンダー6選と選び方
・FuelPHPのシステム開発の見積相場や費用/コスト/値段について
・FuelPHPのシステム開発の発注/外注/依頼/委託方法について