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

Yiiのシステム開発は、PHP向けのYiiを土台に独自の業務ルールをWebシステムへ落とし込み、要件整理から定着支援までを段階的に進める方法が基本です。

受発注、在庫、顧客、求人、予約、会員、社内ポータルなどをYiiで構築するときは、フレームワークの機能だけでなく、既存資産の状態、外部連携、セキュリティ、データ移行、運用担当者まで先に決めることが重要です。本記事では、Yiiのシステム開発を「要件整理→選定→設計開発→テスト→稼働→定着」の6フェーズに分け、各段階の判断基準、確認項目、費用相場、見積書の読み方を実務目線で解説します。

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

Yiiのシステムとは何ですか？全体像を把握する

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

Yiiは、画面を表示するView、入力を受け付けて処理をつなぐController、データと業務ルールを扱うModelに役割を分けるMVCを基本にしています。たとえば受注登録では、Controllerが入力を受け、Modelが在庫数や取引条件を検証し、Viewが担当者に結果を返す構成です。業務ロジックを整理して実装しやすい一方、どの業務を標準化し、どの例外を残すかは発注者と開発会社が決める必要があります。

Active RecordやQuery Builder、バリデーション、GridView、ページネーションなどは、マスタ管理や検索・一覧・登録・更新・削除の実装を助けます。GiiでデータベースからModelやCRUDのひな形を生成できるため、テーブル数が多い管理画面の初期構築を速めやすいです。ただし、生成コードをそのまま本番投入するのではなく、業務上の認可、入力制御、監査ログ、テストを追加して品質を確保します。

Yiiは、独自の業務ルールがあり、データベースを中心に継続的な拡張を行うWebシステムと相性が良いです。受発注・在庫・顧客管理、会員サイト、求人・物件検索、予約、EC、社内ポータル、スマートフォンアプリ向けAPIなどが候補になります。既存のPHP資産を活かしながら画面を追加したい場合も、現行コードを調査したうえで、段階的な改修を検討できます。

一方、会計、勤怠、給与、請求のように法改正への追随が頻繁で、標準機能で業務が完結する領域は、SaaSやパッケージを先に比較するのが合理的です。SaaSで足りる業務までYiiで作ると、初期開発だけでなく法改正対応や保守の負担も自社に残ります。独自性が高い部分だけをYiiで作り、標準化できる部分は既存サービスとAPIやCSVで連携する切り分けが、費用と将来性の両面で有効です。

新規開発でも既存改修でも、最初にYiiのメジャーバージョン、PHP、Composerの依存パッケージ、データベース、OS、Webサーバーを一覧化します。Yii公式のリリースサイクルでは、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の開発は、いきなり画面を作るのではなく、業務上の目的と制約を整理してから技術選定へ進めます。6フェーズを順番に進めながら、各フェーズの終了条件を文書で確認すると、認識違いによる手戻りを抑えやすくなります。特に既存Yiiの改修では、ソースコードを読める人がいるか、テストが残っているか、データの正しさを検証できるかが初期判断を左右します。

最初に「何をシステム化するか」ではなく、「誰のどの作業を、どの指標まで改善するか」を整理します。現行業務の開始条件、担当者、入力項目、承認、例外処理、出力帳票、保存期間、外部サービスとの受け渡しを業務フローに書き出します。受発注なら、見積、受注、在庫引当、出荷、請求、返品までを一続きで確認し、Excelやメールで行っている判断も対象にします。

実務で使える確認項目は、対象ユーザーと権限、画面と帳票の一覧、データ件数と増加量、同時利用者数、連携先、稼働時間、障害時の復旧目標、個人情報の有無です。各項目に「必須」「できれば」「今回は対象外」の優先度を付け、MVPで最初に出す範囲を決めます。このフェーズの終了条件は、業務フロー、機能一覧、非機能要件、移行対象データ、受入条件に発注者が合意していることです。

要件整理の結果をもとに、すべてをYiiで作るのか、標準SaaSを使うのか、既存Yiiを改修するのかを比較します。会計や勤怠など標準化しやすい業務はSaaS、独自の受注ルールや検索ロジックはYii、既存画面を維持したい領域は改修というように、業務単位で分けると過剰開発を避けられます。単一の製品に全業務を寄せるより、APIやCSVで連携したほうが将来の変更に強い場合もあります。

既存Yiiを使う場合は、Yii1かYii2かだけでなく、PHPの版、Composerのlockファイル、拡張パッケージ、テストの有無、Giiやデバッグ機能が本番に残っていないかを調査します。選定のチェックリストには、Yiiの実コードを担当できる人材、PHP・DB・クラウドの対応範囲、ソースコードと設計書の納品、保守窓口、引き継ぎ可能性を入れます。会社名や「Yii対応」の記載だけで決めず、現役案件のバージョンと担当体制を確認します。

設計では、画面一覧だけでなく、データモデル、状態遷移、権限マトリクス、API仕様、エラー処理、ログ、バックアップ、環境構成を決めます。たとえば「営業は自分の顧客だけ閲覧」「管理者は全件変更」「経理は請求確定後の金額を変更不可」のように、役割と操作を具体的な組み合わせで記録します。YiiのRBACを採用する場合も、権限名だけを作るのではなく、業務上の承認責任と対応付けます。

開発は、共通レイアウト、ログイン、権限、主要マスタ、最重要業務の順に小さく動かすと、早い段階で認識を確認できます。Giiで骨格を作った場合も、入力バリデーション、重複登録の防止、トランザクション、監査ログ、例外処理を補います。外部APIは正常系だけでなく、タイムアウト、重複送信、認証期限切れ、先方仕様変更を想定します。設計書、ソースコード、DBマイグレーション、テストコードをリポジトリで管理すると、環境ごとの差分を減らせます。

テストは、画面が表示されるかだけで終わらせません。単体テストでModelやサービスの計算を確認し、結合テストでDB・外部API・権限の組み合わせを確認し、受入テストで実際の業務フローを確認します。受発注なら、在庫不足、返品、同一注文の二重送信、締め後の修正、通信切断など、現場で起きる例外をシナリオ化します。

品質判定には、重大な未解決不具合がないこと、必須シナリオの合格率、性能目標、バックアップからの復元、ログの確認、権限外アクセスの拒否を使います。個人情報を扱う場合は、SQLインジェクション、XSS、CSRF、認証、アクセス制御、セッション、ファイル公開をセキュリティテストへ含めます。Yii公式も認証、認可、パスワード、暗号、Viewの安全性などをセキュリティ領域として整理しています（出典：Yii公式「Security Overview」、2026年8月確認）。

稼働前には、旧システムから何を移すか、どの項目を変換するか、移行後に誰が件数と金額を照合するかを決めます。マスタの重複、担当者コードの欠落、日付形式の違い、削除済みデータ、過去取引の扱いを洗い出し、テスト移行を複数回行います。移行は開発会社だけでは完結しないため、現場責任者に確認期限と承認方法を割り当てます。

本番切り替えは、休日や締め処理の前後など業務影響が小さい時間帯を選び、凍結、最終バックアップ、移行、照合、利用開始、切り戻しの手順を分単位で記載します。RTO（復旧時間目標）とRPO（復旧時点目標）、障害時の連絡先、判断者、ベンダーの待機時間を決めておくと、トラブル時の迷いを減らせます。稼働直後は問い合わせ窓口と優先度を定め、現場の小さな違和感を拾える体制を置きます。

稼働しただけでは開発の成果になりません。利用率、入力漏れ、処理時間、差し戻し件数、問い合わせ件数などを導入前と比較し、業務が改善したかを確認します。操作マニュアルは機能説明だけでなく、受注登録、承認、取消、締め処理、障害時の連絡という業務シナリオで作ると現場で使われやすいです。管理者向けには、ユーザー追加、権限変更、バックアップ確認、ログ確認の手順も必要です。

保守契約では、障害対応、脆弱性調査、PHP・Yii・Composer依存の更新、クラウド監視、バックアップ、軽微改修、問い合わせの範囲と時間帯を区切ります。年間保守費は初期開発費の15〜20％程度を目安にする情報がありますが、24時間監視や法改正対応、追加開発を含めるかで変わります（出典：NotebookLM一次Q&A「業務システム全般_9」、2026年）。「保守一式」ではなく、対応時間、月間工数、SLA、追加料金の条件まで契約に記載します。

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

Yii自体はオープンソースのフレームワークであり、ライセンス費が基本的に無料でも、システム開発が無料になるわけではありません。費用の中心は、業務整理、設計、実装、テスト、データ移行、インフラ構築、保守に必要な人件費です。以下はYii専用の公的統計ではなく、2026年に公開された一般的なWeb・業務システム相場と、Yii案件の要件を組み合わせた概算です。

小規模は、ログイン、1〜3個のマスタ、一覧・登録・CSV出力、簡易権限を社内で使うケースで、150万〜400万円程度、2〜4か月が一つの目安です。単一業務のカスタムシステムについて100万〜500万円、スクラッチの小規模業務システムについて100万〜300万円という2026年の公開相場もあり、画面数とテスト範囲で上下します（出典：Cataly Design「業務システム開発の費用相場」、2026年；ノーコード総合研究所「業務システム開発の費用相場」、2026年）。

中規模は、受発注・在庫・顧客管理、帳票、部署別権限、外部API、データ移行を含むケースで、500万〜1,200万円程度、4〜9か月が目安です。SIAの2026年相場では、部門横断の業務システムや会員制Webシステムが500万〜1,000万円、大規模は1,000万円〜数千万円以上とされています（出典：SIA株式会社「システム開発の費用・相場 2026年版」、2026年）。Yiiで作る場合もこの一般相場を起点にし、外部連携数、権限の複雑さ、既存データの品質を加味します。

大規模は、複数拠点・多権限、基幹連携、数十万規模の会員、冗長化、監査ログ、段階移行を含み、1,200万〜5,000万円超、9か月〜2年程度になる可能性があります。既存Yiiの保守・改修は、PHPや依存パッケージの更新、脆弱性対応、画面追加、API連携、Yii1からの段階移行などの範囲で、50万〜500万円程度の案件単位を想定します。ただし、現行コードの解析とテスト不足が大きい場合は、先に調査費が必要です。

開発費は、人月単価に工数を掛けて算出することが多く、2026年の公開相場では人月60万〜200万円程度という幅があります（出典：SIA株式会社「システム開発の費用・相場 2026年版」、2026年）。たとえば要件整理、UI・DB設計、実装、テスト、移行、プロジェクト管理を分け、各項目の人月と単価を示してもらいます。単に「開発一式」とだけ書かれた見積もりは、後から追加費用が発生する範囲を把握しにくいです。

費用配分の目安は、要件定義10〜25％、設計20〜30％、開発30〜40％、テスト15〜20％に、移行・導入を別途加える考え方です。業務システムでは、要件整理を削るより、初期リリースの機能を絞るほうが安全にコストを調整できます。クラウド利用料、監視、バックアップ、メール配信、決済、電子契約、脆弱性診断などの外部費用も、初期費用と月額費用を分けて確認します。

ランニングコストには、クラウドのサーバー・DB・ストレージ、監視、バックアップ、ログ保管、SSLやメールなどのサービス費が含まれます。利用者数やデータ量が増えると、性能改善、キュー処理、キャッシュ、冗長化が必要になり、開発後にインフラ費と改修費が増える場合があります。非機能要件として月間アクセス数、ピーク時の同時利用者、保存年数、RTO・RPOを決めておくことが大切です。

保守費には、障害修正だけでなく、PHP・Yii・Composer依存の更新、OSやミドルウェアの更新、脆弱性対応、問い合わせ、軽微な画面変更が含まれることがあります。初期費用の15〜20％程度という目安はありますが、最低対応時間、月間作業量、緊急対応、休日対応、追加開発の単価で実額は変わります。3年間の総保有コストで比較すると、初期見積もりだけでは見えない差を把握できます。

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

Yiiの見積もりは、同じ画面数でもデータの関係、権限、例外処理、外部連携、性能、移行の難易度で金額が変わります。発注者が準備する資料をそろえ、同じ前提条件で2〜3社へ依頼すると、価格差の理由を比較しやすくなります。安さだけでなく、未確定要件をどう扱うか、担当者がどこまで伴走するか、稼働後の責任範囲まで確認します。

最低限、開発目的、対象部署、利用者数、業務フロー、機能一覧、画面イメージ、帳票、マスタ、データ件数、外部連携、希望時期、予算の考え方を一枚にまとめます。既存改修なら、URLや画面だけでなく、ソースコード、DB定義、環境構築手順、Composerの依存一覧、障害履歴、テスト仕様、運用手順の有無を伝えます。資料がない項目は「未調査」と明示し、調査・解析の見積もりを別立てにします。

受入条件もRFPに入れます。たとえば、主要シナリオの処理時間、権限外操作の拒否、バックアップからの復元、移行後の件数照合、帳票の金額一致、障害時の連絡時間を合格基準にします。「使いやすく」「高速に」といった曖昧な表現は、対象画面、利用者数、秒数、測定方法に置き換えます。要件が明確になるほど、会社ごとの見積もりを同じ土俵で比較できます。

見積書では、要件定義、基本設計、詳細設計、フロントエンド、バックエンド、API、インフラ、テスト、移行、マニュアル、教育、プロジェクト管理を工程ごとに確認します。各工程の成果物が、要件定義書、画面仕様、ER図、API仕様、ソースコード、DBマイグレーション、テスト仕様、移行結果、運用手順のどれに対応するかを確認します。成果物が納品されないと、担当会社を変えるときに引き継げません。

特に差が出やすいのは、データ移行、権限設計、外部APIの異常系、性能試験、脆弱性診断、リリース立会い、教育です。見積もりに含まれない項目は、未対応なのか、別途契約なのか、発注者の作業なのかを明確にします。追加要件の単価、仕様変更の承認方法、納期を延長できる条件も、契約前に確認しておくと予算超過を防ぎやすくなります。

会社選びでは、Yiiの実績件数だけでなく、どのバージョンで、どの業務を、どの規模で、どこまで担当したかを聞きます。受発注・在庫・求人・検索・会員など自社に近い事例があるか、PHP・MySQLやPostgreSQL・AWSなど周辺技術も扱えるか、担当エンジニアと直接話せるかを確認します。公開実績が古い場合は、現在もその技術者と保守体制が残っているかを質問します。

提案時には、Yii1をそのまま延命する案、Yii2へ更新する案、Yii3や別フレームワークへ段階移行する案、SaaSと連携する案を並べてもらうと、技術の押し付けを防げます。最終的には、初期費用の安さより、担当者依存を減らせる設計書・テスト・CI/CD・監視・引き継ぎの有無を重視します。契約書にはソースコードの権利、リポジトリの管理者、第三者ライブラリの扱い、終了時のデータ返却と引き継ぎを記載します。

個人情報を扱うなら、アクセス制御、認証、操作ログ、暗号化、バックアップ、退職者アカウントの停止、委託先管理を要件にします。請求や受発注を扱う場合は、インボイス制度の登録番号・税率・税額・保存、電子取引データの保存要件を確認し、制度変更時の担当者を決めます。フレームワークにセキュリティ機能があることと、業務システムが安全に運用できることは同じではありません。

移行リスクは、現行DBの調査、データクレンジング、テスト移行、照合、本番移行、切り戻しを別工程で見積もります。Yii1からの刷新では、画面を新しくするだけでなく、暗黙の業務ルールをソースコードから抽出する作業が発生します。調査を省いた低価格見積もりは、開発途中で追加費用と納期延長につながる可能性があるため、最初に調査フェーズを置く提案を評価します。

よくある質問（FAQ）

Yiiの採用や既存システムの改修では、技術の将来性、費用、担当会社、移行の進め方について質問が多く寄せられます。ここでは、発注前に確認しておきたい代表的な疑問へ、結論から回答します。

要件と保守体制が合っていれば、2026年でも選択肢になります。Yii 2.0.55が2026年5月に公開され、Yii3のリリースサイクルも公式に案内されているため、既存資産やPHP人材を活かせる案件では検討価値があります。ただし、新規開発でYii1.1を選ぶ理由は限定的であり、採用する版、PHPの版、更新責任、将来の移行方針を契約前に決めます。

ライセンス費を抑えられる可能性はありますが、開発費や保守費が自動的に安くなるわけではありません。要件整理、画面設計、業務ロジック、テスト、移行、クラウド、セキュリティ、運用教育が費用の中心だからです。小規模なら150万〜400万円程度、中規模なら500万〜1,200万円程度という目安がありますが、機能数、連携、データ量、非機能要件によって大きく変わります。

すぐに全面刷新する必要はありませんが、期限とリスクを把握して段階的な計画を作るべきです。まず、PHP・Yii・Composer・OS・DBの棚卸し、脆弱性診断、テスト整備、ソースコードの可読性、担当者依存、データ移行の難易度を調査します。その結果をもとに、延命、Yii2やYii3への段階移行、API分離、別サービスへの切り出し、全面刷新を比較し、業務影響と予算に合う順序を決めます。

Yiiの実績の有無だけでなく、バージョン、業務領域、対応工程、周辺技術、保守体制、担当者の継続性を確認します。現行コードを見たうえで見積もりを出すか、既存システムの調査を別工程で提案するかも重要です。ソースコード、設計書、テスト、インフラ情報を納品し、契約終了時に引き継げる会社であるかを、提案書と契約書の両方で確認します。

まとめ：Yiiのシステム開発は6フェーズの終了条件を決めて進めます

Yiiのシステム開発は、フレームワークを選ぶことがゴールではなく、独自業務を安全に、継続的に使える状態へ変えるプロジェクトです。要件整理で目的と範囲を決め、選定でSaaS・既存改修・新規開発を比較し、設計開発でデータ・権限・連携を固め、テスト、移行、稼働、定着までを一つの計画にします。

最後に、目的とKPI、対象業務、必須機能、利用者と権限、Yii・PHP・DBの版、外部連携、データ移行、セキュリティ、法令、性能、バックアップ、受入条件、納品物、保守範囲、追加費用の条件を確認します。特に既存Yiiでは、現行資産の調査結果と、延命・刷新・段階移行の判断理由を残します。ここまで合意できていれば、見積もりの金額差を「要件の違い」と「会社の工数・体制の違い」に分けて評価できます。

これからYiiのシステムを検討する企業は、現行業務の流れ、困っている作業、残したいデータ、必要な連携先を整理して、開発会社へ相談します。既存システムがある企業は、画面の一覧だけでなく、PHP・Yii・Composer・DB・インフラ・テスト・運用担当者を調査し、最初の調査見積もりを依頼します。技術の採用判断を費用だけで終わらせず、稼働後の保守と定着まで含めて比較することが、長く使えるシステムにつながります。

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

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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