Redmineのシステム開発は、業務整理、環境と拡張方法の選定、設計・テスト・段階導入の順に進めると、現場で続けられる運用につながります。
導入は、業務の整理から定着までを段階に分けて進めます。
▼全体ガイドの記事
・Redmineのシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
Redmineのシステムの全体像
Redmineは、案件や障害、問い合わせ、変更依頼をチケットで管理する、オープンソースのプロジェクト管理システムです。
チケットに担当者、期限、優先度、ステータス、作業時間を記録すると、情報を一か所にまとめられます。特に大切なのは、Excel・メール・チャットに分かれた情報を、誰がいつ何を更新するかまで決めて運用に変えることです。
Redmineのシステムの構成
Redmineのシステムは、Redmine本体にRuby on Rails環境やデータベースを組み合わせた業務基盤です。
データベースにはPostgreSQLやMySQLなどを使い、構成にはWebサーバーや添付ファイルの保存領域も含まれます。
構成には、メール通知や認証のほか、バックアップと監視も含まれます。公式機能は次のとおりです（出典: Redmine公式「Features」）。
- 複数プロジェクト、サブプロジェクト、ロール別権限、ワークフロー
- ガントチャート、カレンダー、工数管理、カスタムフィールド
- Wiki、リポジトリ連携、REST API
受託開発では、トラッカーやステータスを業務に合わせて設計します。
- トラッカー：「要望」「不具合」「作業」「確認待ち」の区分
- ステータス：「新規→対応中→レビュー→顧客確認→完了」の流れ
社内問い合わせでは、依頼部門、影響範囲、回答期限に加えて、個人情報の有無も必須項目にします。
設計があいまいだと、チケットが単なるメモになってしまい、ガントチャートや工数集計を意思決定に使えなくなります。
クラウド・オンプレミス・OSS自社構築の選び方
環境を選ぶときは、導入の速さや運用の負担、社内の要件を比べます。
- クラウド：標準機能で早く始められ、サーバー、監視、バックアップ、更新の負担を減らせる
- オンプレミス等：閉域網や社内認証、特殊なプラグイン、保管場所に対応しやすい
- 選定条件：契約条件と将来の更新体制の確認
契約前には、データの保管場所とSAML認証、IP制限を確かめておく必要があります。プラグインの扱いやログの保持も、同じ段階で見ておきます。さらに、障害時の復旧目標と解約時のデータ返却も確かめます。
My Redmine Gen.2の公式掲載価格は、スタンダードが月額10,000円、ミディアムが14,000円、エンタープライズが28,000円です。
また、1.5TBプランは月額40,000円です。いずれも税別です（出典: ファーエンドテクノロジー「サービス内容・料金」、2026年確認）。
オンプレミスや専用環境では、OSやRuby、Railsなどの実行環境の更新責任が自社に残ります。
データベース、NginxやApache、Redmine本体、プラグインの更新も、自社の担当になります。
Redmine 6.1の要件は、Ruby 3.2〜3.4、Rails 7.2、PostgreSQL 14などです。なお、Redmine 7.0はRuby 3.2〜4.0、Rails 8.1です（出典: Redmine公式「RedmineInstall」、2026年確認）。
導入時は、今の稼働に合うかだけでなく、3年後も更新できるかを基準に選びます。
Redmineのシステム開発の進め方
Redmineの導入では、要件整理から全社展開までを6つのフェーズに分けて段階的に進めます。まず、標準機能で解決できる範囲を見極め、カスタマイズを最小限にとどめます。
各フェーズで成果物を残しておくと、開発会社との認識違いや、導入後の手戻りを抑えられます。
1. 要件整理フェーズでの業務・データの洗い出し
まずは、誰が何を管理するのかを業務単位で整理します。「プロジェクト管理」とまとめるだけでは、後の設計に必要な情報が足りなくなります。洗い出しの観点は、下の一覧のとおりです。
- 業務：案件、障害、問い合わせ、変更要求、社内申請を一覧にする
- 移行データ：残すもの、変換するもの、破棄するものの区分
- 成果物：業務フロー、項目、権限、移行対象、非機能要件
- 確認：登録例を5〜10件作り、現場と認識をそろえる
各業務について、起票者、担当者、承認者を決めておくと、誰が次に動くかがはっきりします。そのうえで、完了条件と期限を定めます。公開範囲と通知先も、同じ段階で決めておきます。
移行の対象は、Excel、メール、チャット、旧Redmineのデータです。
どこに何が残っているかを先に把握しておくと、分類の作業が進めやすくなります。
非機能要件には、利用者数や同時アクセス、添付容量を含めます。
保存期間、バックアップ頻度、復旧目標時間も、同じ要件として書き出します。
IP制限やSSO、監査ログの扱いを、要件の段階で定めます。個人情報をどう扱うかも、あわせて決めておきます。さらに、担当者が替わっても同じ判断で登録できるかを確かめます。
2. 選定フェーズでの標準機能と拡張方法の決定
要件に合わせて、候補を比べます。クラウドやオンプレミス、OSS自社構築のほか、Redmine互換製品も対象にします。
- 拡張性：プラグインの互換性、API、Webhook、Git連携
- 運用：認証、バックアップ、監視、サポート、責任分界（どこまでを誰が受け持つか）
- 適合性：標準設定、プラグイン、外部連携、新規開発、他製品
比較表には、費用とRedmine本体のバージョン追従を書き込みます。
サポート時間やデータのエクスポート方法も、同じ表で比べます。ただし、価格が安くても、自社で更新や復旧を担えない場合は、総コストが高くなります。
Fit and Gap分析では、要件ごとに対応方法を分類します。特に、本体コードの直接改変は、更新時の差分吸収と脆弱性対応を難しくします。そのため、最後の選択肢として扱います。
候補を絞り切れない場合は、1部署・1〜2プロジェクトで、期間2〜4週間程度のPoCを行います。
PoCでは、実際のチケットを使い、操作性と管理指標を確かめます。
3. 設計・開発フェーズでの運用ルールの実装
設計・開発では、運用ルールと拡張の範囲を具体的に決めていきます。
- 運用設定：トラッカーや状態、ワークフローの設計、ロールと権限の割り当て、項目と通知の設定
- アクセス：閲覧、作成、編集、状態変更、工数、ファイルの権限
- 連携：プラグインやAPI、Webhookの連携、認証、Git、CI、外部システムとの接続
- AI利用：外部送信や誤要約、権限、結果の確定者を定める
カテゴリとバージョンの扱いも決めます。
通知やメールテンプレート、命名規則も、あわせて決めておきます。
権限は、管理者とプロジェクト管理者、担当者に分けます。
閲覧者や顧客・協力会社なども、同様に区分します。
顧客や協力会社を招く場合は、非公開プロジェクトの見え方と添付ファイルの共有範囲をテストします。
会計や顧客管理のシステムとの連携も検討します。2026年6月のMy Redmine公式サービス仕様には、AIチケット要約やGitHub連携も掲載されています。ただし、My Redmineはプランごとに機能差があるため、必要な機能が契約プランに含まれるかを確かめます。
4. テストフェーズでの業務シナリオと移行の検証
テストでは、画面が表示されるかだけでなく、業務が最後までつながるかを確かめます。
- 単体テストでは、設定やプラグインを一つずつ検証します。
- 結合テストでは、認証や通知、API、Git連携の動きを確かめます。
- 受入テストは、現場代表者が実際のシナリオを操作して行います。
- 移行データの照合と、受入条件および復元の確認。
受入テストでは、「問い合わせ起票→担当割り当て→期限変更→承認→完了→月次集計」の流れを一通り実施します。
権限の異なる利用者ごとに、見える情報と操作できる範囲を記録します。
移行時は件数だけでなく、担当者やステータス、日時、コメントを照合します。
添付やリンク、文字コードも、あわせて照合します。
事前にバックアップを取り、テスト環境でリハーサルします。
差分件数をゼロにする基準も、あらかじめ決めておきます。
移行に失敗したときに旧環境へ戻す判断時刻を決めておきます。また、利用者へ告知する停止時間も定めます。
受入条件は、重大な未解決の不具合がないこと、主要シナリオを完走できること、復元テストが完了していることです。
5. 稼働フェーズでの段階的なリリース
本番稼働は、業務量と影響範囲を見ながら段階的に進めます。全社一斉の切り替えは避けます。
- 運用責任者やプロジェクト管理者、現場代表を含むパイロット部門から始めます。
- 起票率や期限超過件数、未割当チケット、対応リードタイム、工数入力率を測定します。
- 初週の問い合わせ窓口を用意します。
- 切り替え後に寄せられた声は、独自開発より先に設定変更で改善できないかを検討します。
利用者が困ったときに、メールや個人チャットへ戻らず相談できる導線を用意します。切り替え当日は、バックアップやDNS、URL、メール通知、バッチを確認します。監視や管理者の連絡先、障害時の連絡手段も、あわせて確かめます。
6. 定着フェーズでのKPIと改善サイクル
業務側のオーナーを決め、KPIや教育、更新を継続して管理します。
- 定期確認：滞留、期限超過、再オープン、未入力、未検索項目、通知エラーの有無
- 指標：業務成果につながるKPIの選定
- 教育：良いチケット例、登録禁止情報、状態変更、完了条件の共有
- 更新：半年から1年単位で計画を立てる
月次または四半期ごとに状況を確認し、運用ルールを見直します。
登録率だけを目標にすると、意味の薄いチケットが増えることがあります。
業務成果を測る指標には、期限超過の早期把握や、問い合わせの初回回答時間、障害の再発防止件数などがあります。
操作マニュアルも、教育と同じ内容でそろえておくと、現場が迷いにくくなります。
困ったときの相談先も決めておきます。教育は管理者向けと一般利用者向けに分け、新入社員や異動者にも備えます。
更新の対象は、Redmine本体やRuby、Rails、データベース、プラグインです。これらは、検証環境での更新とバックアップ復元を定期的に試します。
Redmineのシステム開発にかかる費用相場
Redmine本体はオープンソースですが、導入費用がゼロになるわけではありません。費用は、環境と要件整理、設定や移行に分けて考えます。さらに、プラグインやテスト、研修、保守も、それぞれ別に見積もります。
以下の金額の幅は、Redmine固有の全国統計ではありません。リサーチノートの業務システム人月単価と、一般的な構築・移行工数から推定した目安です。
正式な金額は、利用者数や連携数によって変わります。データ量やセキュリティ要件も、金額を左右します。
標準クラウドと自社構築の費用の目安
費用は、公開価格と、自社運用に必要な作業とを分けて見積もります。
- クラウド：初期0万〜20万円程度、月額1万〜18万円程度の例
- 自社構築：初期50万〜200万円程度が推定目安
- 運用：インフラ・保守は月5万〜30万円程度の推定レンジ
My Redmine Gen.2の公式掲載価格は、税別で月額1万〜4万円です。一方、Lychee Redmineの2026年価格表では、クラウドの月額が5,000円〜18万円として掲載されています。
ユーザー数やストレージ、SAMLに機能差があり、ログや優先サポート、ガントや工数にも違いがあります。そのため、月額だけで横並びに比べないよう注意します。
価格は改定されるため、契約時に提供会社の最新料金表を確認します。
自社構築の初期費用には、環境設計、サーバー構築、認証が含まれます。さらに、バックアップ、監視、初期設定、手順書も含まれます。
これらは、要件と体制から算出した推定の目安です。公開されたRedmineの定価ではありません。
Ruby・Railsやデータベースを運用できる人材がいれば、内製の比率を高められます。ただし、担当者が不在になったときの引き継ぎ費用も含めて判断します。
移行・初期設定・研修の費用
移行・初期設定・研修は、作業範囲とデータの状態によって見積もりが変わります。
- 移行作業：抽出、項目変換、ユーザー統合、添付確認、重複除去、リハーサル
- 費用目安：初期設定、移行、研修の合計15万〜100万円程度
プロジェクト数や添付ファイルが増えるほど、検証に要する時間は延びます。そのため、発注側は件数だけでなく、データの状態と変換ルールも示します。
説明会を1回にまとめると、利用者がつまずいたまま運用が始まることがあります。そこで、管理者研修と現場向けの操作研修を分ける方法もあります。
利用開始後の相談会を設けるか、録画やFAQ、チケット登録例を納品物に含めるかを決めます。
定着支援を頼む場合は、研修回数に加えて、KPIレビューやルール改定、問い合わせ対応期間を契約に記載します。
プラグイン・API連携と保守開発の費用
追加開発と保守の金額は、対象範囲や想定工数によって変わります。
- 個別連携・独自プラグイン：100万〜500万円程度
- 部門横断開発：500万〜1,500万円程度になる場合がある
- 人件費目安：PG月50万〜90万円、SE月65万〜110万円、PM月90万〜150万円
- 保守費：初期開発費の年15〜25％が目安
連携の対象は、Git、CI、会計、顧客管理などです。また、SSOやチャットも連携の対象です。
部門横断開発は、複数拠点や顧客ポータル、監査、大規模移行を含む場合があります。
これらは、人月単価と想定工数からの目安です。機能の数だけで、一律に決まる金額ではありません。
要件定義やPMを見積もりから外すと、仕様変更や意思決定の遅れを管理しきれない場合があります。
脆弱性対応や問い合わせ、障害対応が、保守に含まれるかを確認します。また、アップデート検証やバックアップ復元テストも、保守の範囲に入るかを確かめます。
Redmine公式Changelogには、2026年6月30日の7.0.0が掲載されています。同じ月の15日には、6.1.3、6.0.10、5.1.13が掲載されています（出典: Redmine公式「Changelog」、2026年確認）。
本番へすぐに適用せず、検証環境や互換性、移行手順、停止時間を保守契約に含めておくと、更新費用を予測しやすくなります。
Redmineのシステム開発で見積もりを取る際のポイント
見積もりを依頼するときは、機能名に加えて、開始と完了の条件、データ量、利用者の種類、運用責任者を伝えます。
各社には同じ資料を渡します。そのうえで、初期費用と月額、追加開発の費用を分けて比べ、移行や教育、保守、契約終了時の作業も項目ごとに見ます。
総額の安さよりも、前提条件と除外条件が明確な会社を選ぶ方が、契約後の追加請求を見極めやすくなります。
要件と前提条件を1枚にまとめた資料
要件資料には、利用範囲や移行情報、業務成果、セキュリティ要件をまとめます。
- 利用範囲：目的、部門、利用者数、プロジェクト数、同時利用、チケット種別
- 運用：状態、権限、通知、外部連携、希望時期
- 移行：サンプル、件数、文字コード、重複、削除対象、保持期限
- 安全管理：個人情報、委託先、ログ、IP制限、認証、事故時の連絡時間
「問い合わせの初回回答時間を短くしたい」のように、達成したい業務成果を先に書いておきます。
標準機能で対応する項目とカスタマイズが必要な項目、将来検討する項目に分けておきます。
移行の見積もりには、旧システムの画面よりも、CSVやデータベースのサンプルを渡します。さらに、文字コードや利用者の重複、削除対象、保持期限も示しておくと、移行工数の見積もる材料になります。
チケットに個人情報が書き込まれる可能性があるため、この項目は要件の中で具体的に書いておきます。SAMLや二要素認証の扱いも、あわせて明記します。
複数社の提案を同じ評価軸で比較
複数社の提案は、実績と契約条件を同じ軸で比べます。比べるときは、導入工程や運用支援、納品物も確認します。
- 実績：Redmine本体のコミットと、規模・業種・目的の近い事例
- 導入：要件整理、標準機能と開発の切り分け、移行リハーサル、テスト、教育
- 運用：保守窓口、障害時SLA、プラグイン更新保証
- 引き渡し：設定・ソース、解約時のデータ返却、作業と成果物
- 契約：担当者、期間、前提・除外、検収、変更管理の方法
導入事例を見るときは、社名より、何をどこまで変えた事例かを質問します。なお、固定価格であっても、要件の追加やデータの増加、プラグインの互換性、追加教育の扱いが曖昧だと、費用は膨らみます。
準委任では、月ごとの成果や稼働上限、レビュー方法、意思決定者を決めておきます。
未決事項とリスクは、毎週確認します。
更新・権限・復旧の担当範囲と契約での取り決め
Redmineがオープンソースであっても、脆弱性対応が自動で代行されるわけではありません。
公式Security Advisoriesには、2026年時点でも、ディレクトリトラバーサルやLDAPインジェクション、保存型XSSが掲載されています。影響バージョンと修正版も確認できます（出典: Redmine公式「Security Advisories」、2026年確認）。
誰が情報を監視し、何営業日以内に影響を判定するかを決めておきます。検証環境での確認と本番適用時の停止時間は、契約に記載します。
バックアップは、取得するだけでなく、保存先や世代数、暗号化、アクセス権、保存期間まで確認します。そのうえで、復元責任者とテスト頻度、目標復旧時間・時点を決めます。
クラウドでも、提供会社が復旧する範囲や、利用者が取得できるデータは、契約ごとに異なります。
個人情報を扱う場合は、委託先の選定と契約条項を自社ルールに合わせます。
再委託や監査、漏えい時の報告連絡も、同じ基準で確認します。
見積もりの確認は、費用区分、作業項目、契約条件の順に進めます。
- 初期費用と月額費用が分かれているかを確かめます。
- 要件定義と設定、開発、移行、テスト、教育と保守が、別項目になっているかを見ます。
- 対象外の作業や追加費用、検収、更新と障害、解約とデータ返却の条件を押さえます。
この順で確かめると、安く見えても移行や保守が含まれていない提案を見分けられます。
Redmineのシステム開発でよくある質問
「無料なのに費用がかかるのか」「どこまでカスタマイズするか」「現場が使わなくならないか」という疑問に答えます。
Redmineは無料なのに、なぜ導入費用がかかるのですか？
Redmine本体は無償でも、サーバーやデータベース、バックアップ、認証、監視の用意が要ります。さらに、初期設定や移行、教育、保守の作業も必要です。一方で、標準クラウドはインフラ運用を減らせますが、月額や導入支援費がかかります。
本体価格だけでなく、業務で安全に使い続けるための総保有コストで比較します。
Redmineは自社の業務に合わせてどこまでカスタマイズできますか？
Redmineは、トラッカーや状態、ワークフロー、権限の設定に加え、カスタム項目、通知、Wikiで多くの業務に対応します。プラグインやREST API、Webhookも使えるので、まずは標準設定と既存プラグインから試せます。
標準で埋まらない差は、独自プラグインや外部連携で補います。一方で、本体の直接改変は更新や脆弱性修正に影響しやすいため、引き継げる構成を優先します。
Redmineはクラウドとオンプレミスのどちらがよいですか？
環境は、運用体制や接続・認証要件に合わせて選びます。
- クラウド：標準機能で早く始めたい場合や、インフラ担当を置きにくい場合
- クラウド：バックアップや更新を外部へ任せたい場合
- 自社環境：閉域網、保管場所、特殊認証が必要な場合
- 専用環境等：独自プラグインや社内基盤との密な連携が必要な場合
どちらを選ぶ場合も、SLAや障害時の復旧を比べます。さらに、ログやデータ返却、更新時の互換性も確認します。
Redmineを導入しても現場が使わない場合はどうしますか？
利用が進まない場合は、対象を絞って始め、現場の利用状況を定期的に見直します。
- 利用目的がはっきりした1部署や1〜2プロジェクトから始めます。
- 入力項目を絞ったうえで、良いチケットの例や完了条件、相談窓口を用意します。
- 起票率に加えて、期限超過や問い合わせ対応時間、障害の再発防止をKPIとして見ます。
- KPIの結果をもとに、月次で運用ルールを改善します。
まとめ
Redmine開発は、要件整理から始め、稼働を経て定着まで、6つのフェーズを順に進めます。チケットの種類と状態、権限、通知を業務に合わせ、完了条件も同じように定めると、現場が続けられる運用になります。
費用は、本体の無償性だけで判断せず、環境や移行、教育まで含めて比べます。追加開発、保守や更新、復旧も、次の確認項目で見ていきます。
発注前に確認する最終チェックリスト
発注前には、確認する範囲を整理しておきます。責任者が決まっていない場合は、開発に入る前に決めます。
- 要件：目的と範囲、利用者と権限、チケット項目、ワークフロー
- 導入：標準機能と改修、移行データ、テスト、検収、教育、定着支援
- 保守：バックアップと復元、脆弱性対応、更新、SLA、障害連絡
- 終了・責任者：データ返却と更新・復旧・運用変更の担当者
まずは1業務でのPoCの実施
本番展開の前にPoCを行い、要件と構成を確かめます。
- 効果を測りやすい1業務を選び、代表的なチケットで試します。
- 2〜4週間使い、入力率や期限超過、対応時間、通知、権限を確かめます。
- 結果は要件と見積もりに反映し、標準設定と開発を分けて、費用や定着のリスクを抑えます。
- 業務整理から運用改善まで伴走する会社を、課題や利用者、データ、更新計画の観点で比べます。
▼全体ガイドの記事
・Redmineのシステム開発の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。