Yiiのシステム開発の進め方/やり方/流れや方法/手法/工程/手順

Yiiのシステム開発は、要件整理と方式選定から始め、設計・開発を経てテスト、移行、定着へと進みます。この順序で進めると、独自業務を安全に使い続けられます。全体像は、Yiiのシステム開発の完全ガイドでも確認できます。

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

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

Yiiのシステムの全体像

Yiiのシステムは、YiiというPHPのWebアプリケーションフレームワークを基盤に、企業ごとの業務アプリケーションを構築する仕組みです。完成済みの業務パッケージとは異なり、業務に合わせた画面と処理を作り込んでいきます。具体的には、MVCやデータベース連携、認証、権限のほか、フォームやREST API、キャッシュなどを組み合わせます。

Yiiが担う役割と、完成品ではない理由

Yiiの役割と生成機能を理解するには、MVCの分担と、実装を助ける部品の両方を押さえておく必要があります。

• MVC：Viewは画面、Controllerは入力処理、Modelはデータと業務ルールを扱う
• 開発部品：開発を助ける部品が、Yiiに備わっています
• Gii：DBからModelやCRUDのひな形を生成でき、多数のテーブルを扱う管理画面の初期構築を速めやすい

Active RecordやQuery Builder、バリデーションなどの部品に加え、GridViewやページネーションもあります。

これらは、マスタ管理や検索・一覧・登録・更新・削除の実装を助けます。

たとえば受注登録では、Controllerが入力を受け取り、Modelが在庫数や取引条件を検証したうえで、Viewが結果を返します。MVCに分けると、業務ロジックを整理できます。どの業務を標準化し、どの例外を残すかは、発注者と開発会社が一緒に決めます。また、生成されたコードは、そのまま本番に投入せず、認可や入力制御、監査ログ、テストを追加して品質を確保します。

向いているシステムと、比較検討が必要なケース

Yiiにするか既存サービスにするかは、業務の独自性や現行資産、標準機能で対応できる範囲で決まります。

• 独自業務：独自ルールがあり、DB中心で継続拡張するWebシステムなら、Yiiが候補になります
• 対象例：受発注・在庫・顧客管理、会員、求人・物件検索、予約、EC・社内ポータル、アプリ向けAPI
• 既存資産：PHP資産を活かす場合は、コードを調べて段階改修を検討する
• 標準業務：会計・勤怠・給与・請求などは、SaaSやパッケージとの比較を先に行う

SaaSで足りる業務までYiiで作ると、初期開発だけでなく、法改正対応や保守も自社に残ります。一方で、独自性が高い部分だけをYiiで作り、標準化できる部分は既存サービスとAPIやCSVで連携する方法もあります。この方法は、費用と将来性の両面で有効です。

2026年時点のバージョンと保守期限

採用する版や保守期限を判断するには、構成要素と公式のEOL情報を一覧にして確認します。

• 構成：Yii、PHP、Composer依存、データベース、OS、Webサーバー
• Yii 1.1：EOLは2026年12月31日
• Yii 2.0.50以降：EOLは2027年11月23日
• Yii3：PHP 8.2以上が前提で、EOLは2035年12月31日（出典：Yii公式「Release Cycle」、2026年8月確認）

期限は変わることがあるため、契約前に公式ページと実際の依存関係を再確認します。

2026年5月にYii 2.0.55が公開され、CVE-2026-39850の修正や新しいPHPとの互換性改善が含まれました（出典：Yii公式ニュース「Yii 2.0.55」、2026年5月）。

この情報から、Yii全体が使えないと判断する必要はありません。ただし、古いYii1を新規開発に使うのは避けます。

既存システムを延命するか、Yii2・Yii3を含めて刷新するかを比べます。

見積書では、バージョンアップ、脆弱性対応、移行後テストを別の項目にします。

Yiiのシステム開発の進め方と6フェーズ

Yiiの開発では、業務上の目的と制約を整理してから技術選定に進みます。

各フェーズの終了条件を文書で確認しておくと、認識違いによる手戻りを抑えやすくなります。

既存Yiiを改修する場合は、ソースコードを読める人がいるかを最初に確かめる必要があります。

テストの有無やデータの検証方法も、初期の判断を左右します。

フェーズ1：要件整理（業務の目的と範囲）

要件整理では、改善対象と業務フロー、範囲と優先度を言葉にして、合意しておきます。

• 改善対象：誰のどの作業を、どの指標まで改善するか
• 業務フロー：開始条件、担当者、入力・承認、例外、帳票・保存期間、外部受け渡し
• 対象と規模：ユーザー・権限、画面・帳票、データ件数と増加量、同時利用者、連携先、稼働時間
• 品質と優先度：復旧目標、個人情報、「必須」「できれば」「対象外」、MVP（Minimum Viable Product）の範囲

受発注であれば、見積と受注、在庫引当の流れを確認します。

出荷や請求、返品まで含め、Excelやメール上の判断も対象です。

業務フローと機能一覧、非機能要件について発注者が合意し、移行対象データと受入条件も決まれば、このフェーズを終えます。

フェーズ2：SaaS・既存改修・Yii新規開発の選定

要件に合わせて、標準SaaS、Yiiの新規開発、既存Yiiの改修のどれを使うかを、業務単位で選びます。

• SaaS：会計や勤怠など、標準化しやすい業務
• Yii新規開発：独自の受注ルールや検索ロジック
• 既存改修：現在の画面を維持したい領域
• 既存環境：Yii版、PHP、Composer lock、拡張、テスト、Gii・デバッグ機能の本番残存
• 開発体制：Yii担当人材、PHP・DB・クラウド対応、成果物、保守窓口、引き継ぎ、現役案件の版と担当

業務単位で分けると、過剰な開発を避けられます。単一製品に全業務を寄せず、APIやCSVで連携したほうが、将来の変更に強い場合もあります。会社名や「Yii対応」の記載より、実装体制と成果物を確かめて選ぶことが大切です。

フェーズ3：設計と開発（データ・権限・連携）

設計と開発では、データ、権限、連携を決めてから、主要な機能を小さく実装していきます。

• 設計：データモデル・状態遷移、権限、API、エラー処理、ログ・バックアップ、環境
• 権限：営業は自分の顧客だけ閲覧、管理者は全件変更、経理は請求確定後の金額を変更不可。RBACは業務上の承認責任と対応させる
• 実装順：共通レイアウト、ログイン、権限、主要マスタ、最重要業務
• 品質と連携：入力検証、重複防止、トランザクション、監査ログ、例外、API異常系

小さく動かせば、早い段階で認識のずれを確かめられます。

Giiで生成した骨格にも、必要な制御を補います。

APIでは、タイムアウトや重複送信、認証期限切れ、先方の仕様変更を想定しておきます。

設計書やソース、DBマイグレーション、テストコードは、リポジトリで管理します。

フェーズ4：テストによる業務の安全性の確認

テストでは、画面の動きだけでなく、計算や外部連携、権限、実際の業務で起こる例外まで検証します。

• テスト段階：単体で計算、結合でDB・API・権限、受入で業務フローを確かめる
• 例外シナリオ：在庫不足、返品、二重送信、締め後の修正、通信切断
• 品質判定：重大な未解決不具合がないこと、必須シナリオの合格率、性能目標、復元、ログ、権限外アクセスを確かめる
• セキュリティ：個人情報を扱う場合は、SQLインジェクション・XSS・CSRF、認証・権限・セッション、ファイル公開を試験

Yii公式も、認証や認可、パスワード、暗号、Viewの安全性などをセキュリティの領域として整理しています（出典：Yii公式「Security Overview」、2026年8月確認）。

フェーズ5：データ移行と稼働

稼働前には、旧システムから移すデータと変換項目を決めるとともに、移行後の件数と金額を誰が照合するかも決めておきます。

マスタの重複や担当者コードの欠落、日付形式、削除済みデータ、過去取引の扱いを洗い出します。

そのうえで、テスト移行を複数回行います。

移行は、開発会社と現場が協力して完結させる作業です。そのため、現場責任者に確認期限と承認方法を割り当てておきます。

本番への切り替えは、休日や締め処理の前後など、業務への影響が小さい時間帯を選びます。また、次の順序と切り戻し手順を分単位で書き出します。

1. 業務データを凍結し、最終バックアップを取得する
2. データを移行し、件数と金額を照合する
3. 利用を開始し、必要な場合は切り戻す

RTO（復旧時間目標）とRPO（復旧時点目標）を決めます。

障害時の連絡先や判断者、ベンダーの待機時間も、あらかじめ整えておきます。

稼働直後は、問い合わせ窓口と優先度を設定しておきます。

現場の小さな違和感を拾える体制を置きます。

フェーズ6：定着と保守

稼働後は、改善の確認、業務に沿った教育、対応範囲の合意が欠かせません。

• 改善確認：利用率、入力漏れ、処理時間、差し戻し、問い合わせを導入前と比較
• マニュアル：受注登録、承認、取消、締め処理、障害連絡などの業務シナリオで作成
• 管理手順：ユーザー追加、権限変更、バックアップ確認、ログ確認を用意
• 保守範囲：障害と脆弱性、PHP・Yii・Composer更新、監視、バックアップ、軽微改修の範囲と、問い合わせの時間帯を決める

年間保守費は、初期開発費の15〜20％程度が目安とされています。ただし、24時間監視や法改正対応、追加開発を含むかどうかで変わります（出典：NotebookLM一次Q&A「業務システム全般_9」、2026年）。

対応時間や月間工数、SLA、追加料金の条件まで、契約に記載しておきます。特に「保守一式」とだけ書かれていると、範囲が分かりにくくなります。

Yiiのシステム開発の費用相場と内訳

Yiiはオープンソースで、ライセンス費は基本的に無料です。ただし、システム開発そのものが無料になるわけではありません。

費用の中心は、業務整理から保守までに必要な人件費です。対象は設計や実装、テスト、データ移行、インフラ構築などです。

次の目安は、2026年公開の一般的なWeb・業務システム相場とYii案件の要件を組み合わせた概算です。Yii専用の公的統計ではありません。

規模別の費用レンジと開発期間

費用と期間は、開発規模や含める機能・移行範囲によって変わります。

• 小規模：150万〜400万円程度、2〜4か月
• 中規模：500万〜1,200万円程度、4〜9か月
• 大規模：1,200万〜5,000万円超、9か月〜2年程度となる可能性
• 既存Yiiの保守・改修：案件単位で50万〜500万円程度

小規模は、社内で使うシステムで、ログインや1〜3個のマスタ、一覧・登録・CSV出力、簡易権限を備えるケースです。

2026年公開の相場では、単一業務のカスタムが100万〜500万円、スクラッチの小規模業務システムが100万〜300万円とされています。金額は、画面数とテスト範囲で上下します（出典：Cataly Design「業務システム開発の費用相場」、2026年；ノーコード総合研究所「業務システム開発の費用相場」、2026年）。

中規模には、受発注・在庫・顧客管理が含まれます。帳票と部署別権限も入ります。外部APIとデータ移行も加わります。

2026年の相場では、部門横断の業務システムや会員制Webシステムが500万〜1,000万円です。

大規模は1,000万円〜数千万円以上とされます（出典：SIA株式会社「システム開発の費用・相場 2026年版」、2026年）。Yii案件も、一般的な相場を起点に、外部連携の数や権限の複雑さ、既存データの品質を加味して考えます。

大規模には、複数拠点・多権限、基幹連携が含まれます。数十万規模の会員、冗長化も入ります。監査ログや段階移行も加わります。

既存Yiiの保守・改修では、PHPや依存の更新、脆弱性対応、画面追加、API連携、Yii1からの段階移行などを扱います。ただし、現行コードの解析やテスト不足が大きい場合は、先に調査費が必要です。

見積もりに含まれる主な費用項目

見積もりでは、人月単価、工程別工数、費用配分、外部費用を分けて確認します。

• 人月単価：2026年公開相場は60万〜200万円程度（出典：SIA株式会社「システム開発の費用・相場 2026年版」、2026年）
• 工程別工数：要件整理、UI・DB設計、実装、テスト、移行、プロジェクト管理
• 費用配分：要件定義10〜25％、設計20〜30％、開発30〜40％、テスト15〜20％。移行・導入は別途
• 外部費用：クラウド、監視、バックアップ、メール・決済・電子契約、脆弱性診断。初期費用と月額に分けて扱う

また、「開発一式」とだけ書かれていると、後から追加費用が発生する範囲を把握しにくくなります。業務システムでは、要件整理を削るより、初期リリースの機能を絞るほうが安全に調整できます。

開発後のランニングコスト

運用費は、インフラの規模やサービス利用、保守契約の範囲から見積もります。

• サービス費：クラウドのサーバー・DB・ストレージ、監視、バックアップ、ログ、SSL、メール
• 増加時の対応：性能改善、キュー処理、キャッシュ、冗長化が必要になり、費用が増える場合
• 非機能要件：月間アクセス、ピーク同時利用者、保存年数、RTO・RPO
• 保守範囲：障害修正、依存更新、OS・ミドルウェア、脆弱性、問い合わせ、軽微な画面変更

初期費用の15〜20％程度という目安はあります。ただし、実額は最低対応時間や月間作業量、緊急・休日対応、追加開発の単価によって変わります。

3年間の総保有コストで比べると、初期見積もりでは見えない差も把握できます。

Yiiのシステム開発で見積もりを取る際のポイント

同じ画面数でも、データの関係や権限、例外処理によって、見積もりは変わります。外部連携や性能、移行の難しさも、差を生む要因です。

発注側の資料をそろえ、同じ前提条件で2〜3社に依頼すると、価格差を比べやすくなります。

未確定要件の扱い、担当者の伴走範囲、稼働後の責任も確かめます。価格の安さだけで判断しないことが大切です。

要件定義書とRFPに入れる確認項目

見積もりの前提をそろえるため、次の項目を要件定義書やRFPにまとめます。

• 業務と利用者：開発目的、対象部署、利用者数、業務フロー
• 機能とデータ：機能一覧、画面、帳票、マスタ、データ件数
• 連携と計画：外部連携、希望時期、予算の考え方
• 既存改修の資産：ソース・DB定義、環境手順、Composer依存、障害履歴、テスト・運用手順

資料がない項目には「未調査」と記したうえで、調査・解析の見積もりを別に示します。

受入条件には、主要シナリオの処理時間や権限外操作の拒否、バックアップ復元を含めます。加えて、移行後の件数照合や帳票の金額一致、障害時の連絡時間も書いておきます。

「使いやすく」や「高速に」は、対象画面、利用者数、秒数、測定方法に置き換えます。要件が明確になるほど、各社の見積もりを同じ物差しで比べられます。

見積書の工程・成果物・前提条件による比較

見積書は、工程や成果物、費用差が出る作業、契約条件をそろえて比べます。

• 工程：要件定義、基本・詳細設計、画面・API・インフラ、テストと移行、教育と管理
• 成果物：要件書・画面仕様・ER図、API仕様、ソース、DB移行、テスト、運用手順
• 差が出る作業：移行、権限、API異常系、性能、脆弱性診断、立会いと教育
• 契約条件：対象外作業、追加単価、変更承認、納期延長の条件

成果物が納品されない場合、担当会社を変えるときに引き継ぎにくくなります。

見積もりに含まれない作業は、未対応か、別途契約か、発注者の作業かを明確にしておきます。契約前にこれを確かめておけば、予算超過を防げます。

Yii対応会社を選ぶときの判断基準

Yii対応会社は、実績の適合性や周辺技術、提案の幅、保守と引き継ぎの体制で選びます。

• 経験：Yiiの版、業務、規模、担当範囲。近い受発注・在庫・求人・検索・会員事例
• 体制：PHP・MySQL・PostgreSQL・AWS、担当者との対話。公開実績が古い場合は、現在も技術者と保守体制が残るかを確かめる
• 提案：Yii1延命、Yii2更新、Yii3等への段階移行、別FW、SaaS連携の比較
• 継続性：設計書、テスト、CI/CD、監視、引き継ぎで担当者依存を減らせるか
• 契約：ソース権利、リポジトリ管理者、第三者ライブラリ、終了時のデータ返却と引き継ぎ

見積もりに含めるセキュリティ・法令・移行リスク

セキュリティ・法令対応と移行調査は、開発費とは別に範囲を明確にして見積もります。

• 個人情報：扱う場合に、アクセス制御・認証、操作ログ、暗号化、バックアップ、退職者のアカウント停止、委託先管理を要件に含める
• 法令：請求や受発注を扱う場合、登録番号・税率・税額・保存、電子取引データの保存要件、制度変更時の担当者を確かめる
• データ移行：現行DB調査、クレンジング、テスト移行、照合、本番移行、切り戻しを別工程化
• Yii1刷新：画面改修だけでなく、ソースから暗黙の業務ルールを抽出

業務システムを安全に運用するには、フレームワークのセキュリティ機能に加え、業務に合わせた設計と確認が必要です。

調査を省いた低価格の見積もりは、開発中の追加費用や納期延長につながる可能性があります。そのため、先に調査フェーズを置く提案を評価します。

よくある質問（FAQ）

Yiiの採用や既存システムの改修では、技術の将来性、費用、開発会社、移行の進め方について、次のような質問があります。発注前に確かめたい疑問に、順に答えます。

2026年にYiiで新規システムを開発しても大丈夫ですか？

要件と保守体制が合っていれば、2026年でも選択肢になります。また、Yii 2.0.55は2026年5月に公開され、Yii3のリリースサイクルも公式に案内されています。

既存資産やPHP人材を活かせる案件では、検討する価値があります。一方で、新規開発でYii1.1を選ぶ理由は限られます。

採用する版やPHPの版、更新の責任、将来の移行方針は、契約前に決めておきます。

Yiiのライセンス費が無料なら、開発費も安くなりますか？

ライセンス費を抑えられる可能性はありますが、開発費や保守費が自動的に安くなるわけではありません。

費用の中心は、要件整理や画面設計、業務ロジック、テストです。加えて、移行やクラウド、セキュリティ、運用教育にも費用がかかります。

小規模は150万〜400万円程度、中規模は500万〜1,200万円程度が目安です。ただし、機能数や連携、データ量、非機能要件によって大きく変わります。

既存のYii1システムは、すぐに作り直すべきですか？

期限とリスクを把握し、段階的な計画を立てることが先になります。全面刷新を急ぐ必要はありません。

まず、PHP・Yii・Composer・OS・DBを洗い出します。あわせて、脆弱性診断やテスト整備、コードの可読性、担当者依存、データ移行の難しさも調べます。

その結果をもとに、延命、Yii2やYii3への段階移行、API分離、別サービスへの切り出し、全面刷新を比べます。そのうえで、業務への影響と予算に合う順序を決めます。

Yiiに詳しい開発会社は、何を確認して選べばよいですか？

実績の有無に加えて、バージョンや業務領域、対応工程、周辺技術、保守体制、担当者の継続性を確かめます。

現行コードを見て見積もるか、既存システムの調査を別工程として提案するかも、重要な判断材料です。

ソースコードや設計書、テスト、インフラ情報を納品してもらい、契約終了時に引き継げる会社かを、提案書と契約書で確かめます。

まとめ：Yiiのシステム開発の6フェーズと終了条件

Yiiの開発では、独自業務を安全に、継続して使える状態に整えることが目標です。フレームワークの選定は、その手段の一つにあたります。

要件整理で目的と範囲を決め、SaaS・既存改修・新規開発を比べます。続いて、設計と開発でデータ・権限・連携を固め、テスト、移行、稼働、定着までを計画します。

発注前に確認したい最終チェックリスト

発注前には、要件・技術・運用の範囲と受入条件を一通り確かめます。

• 目的と範囲：KPI、対象業務、必須機能、利用者と権限
• 技術と品質：Yii・PHP・DBの版、連携・移行、セキュリティ・法令、性能・バックアップ、受入条件
• 契約と運用：納品物、保守範囲、追加費用の条件

既存Yiiの場合は、現行資産の調査結果と、延命・刷新・段階移行のどれを選んだかの理由を残しておきます。

合意がそろえば、見積もりの差を、要件の違いと会社の工数・体制の違いに分けて評価できます。

現行業務と資産の洗い出し

開発会社に相談する前に、業務と既存資産を洗い出し、稼働後の体制まで含めて比べます。

• 新規検討：業務の流れ、困っている作業、残すデータ、必要な連携先を整理
• 既存システム：PHP・Yii・Composer・DB・インフラ・テスト・運用担当を調べ、初回調査を見積もる
• 会社の比較：費用だけでなく、稼働後の保守と定着も含めて評価

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

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