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

Redmineのシステム開発を発注・外注するなら、インストール作業だけでなく、業務をチケットへ落とし込む設計、データ移行、権限、保守まで含めて委託範囲を決めることが成功の条件です。

Redmineはオープンソースで利用できるため、本体を無料で使える点が魅力です。一方で、サーバー構築、初期設定、既存データの移行、プラグイン開発、利用者教育、脆弱性対応には費用と専門知識が必要です。この記事では、発注形態の選び方からRFP・要件整理、契約形態、費用相場、委託先の選定、見積書の比較方法まで、発注担当者が社内で判断しやすい順番に解説します。

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

Redmineのシステム開発を発注する前に知っておきたい全体像

Redmineのシステム開発を発注する前に業務を整理している様子

Redmineの導入は、サーバーにソフトウェアを入れて終わるプロジェクトではありません。課題をどの単位でチケット化するか、誰が担当し、どのステータスを経て完了にするかを決めなければ、導入後に入力ルールがばらばらになり、Excelやメールへ戻ってしまいます。発注時は「何を作るか」だけでなく、「どの業務を、どのルールで、誰が使うか」を委託先へ伝えることが重要です。

標準機能で対応できる業務

Redmineの標準機能には、複数プロジェクト、サブプロジェクト、ロール別の権限、チケットのステータスとワークフロー、ガントチャート、カレンダー、作業時間、カスタムフィールド、Wiki、ファイル共有、GitやSubversionなどのリポジトリ連携が含まれます。公式の機能一覧でも、プロジェクトごとにモジュールを有効・無効にでき、ユーザーごとにプロジェクト内の役割を変えられると説明されています(出典: Redmine公式「Features」、2026年8月確認)。

たとえば受託開発なら、問い合わせ、要件確認、設計、実装、レビュー、受入確認をトラッカーとステータスで表現できます。社内問い合わせなら、申請、受付、調査中、回答待ち、完了の流れにできます。標準機能で十分な範囲を先に見極めると、不要な画面開発を避けられ、見積もりの精度も高まります。

無料の本体と有料の導入作業は分けて考える

オープンソースであるRedmine本体のライセンス費用が無料でも、発注費用がゼロになるわけではありません。クラウドを選べば月額利用料、自社構築ならインフラ費用と運用担当者の工数が発生します。さらに、初期設定、既存データの移行、SSOや通知の連携、プラグインの導入、研修、問い合わせ対応を加えると、実際の予算は本体価格だけでは判断できません。

発注書や稟議書では、少なくとも「Redmine本体・クラウドの利用料」「構築・設定費」「移行費」「追加開発費」「教育費」「月次保守費」を分けて記載します。無料という言葉だけで比較すると、必要な運用作業が見えなくなり、導入後に追加費用が発生しやすくなります。

Redmineのシステムは自社構築と外注のどちらがよいですか?

Redmineの自社構築と外注を比較している担当者

結論として、標準機能を小規模に試すだけなら自社構築も可能ですが、既存業務の整理、データ移行、認証連携、複数部門の権限、継続保守まで必要なら外注が向いています。自社のRubyやデータベースの運用担当者がいるか、障害時に誰が復旧するか、アップデートを継続できるかで判断してください。

自社構築が向いているケース

自社構築が向くのは、利用人数とプロジェクト数が少なく、標準機能中心で始められ、社内にLinux、Ruby、Rails、データベース、Webサーバー、バックアップを扱える担当者がいるケースです。まず検証環境を作り、1部署または1〜2プロジェクトでチケット運用を試すなら、初期の学習コストを抑えながら業務との相性を確認できます。

ただし、担当者が兼務の場合は注意が必要です。Redmine公式のインストール手順には、アプリケーションだけでなく、データベース接続、依存ライブラリ、添付ファイル領域、ログ、メール、バックアップなどの設定が含まれます。運用担当者が異動したときの引き継ぎ資料や、障害時の連絡先まで準備できないなら、クラウドまたは保守付きの外注を選ぶ方が安全です。

外注の代表的な発注形態

外注には、Redmineクラウドを契約して初期設定だけ依頼する形、オンプレミスや自社クラウドへ構築して保守を委託する形、既存Redmineからの移行を中心に依頼する形、プラグインやAPIを開発する形があります。すべてを一社に任せる必要はありませんが、障害の責任分界を曖昧にすると、クラウド事業者、開発会社、自社のどこへ問い合わせるか分からなくなります。

発注形態を選ぶときは、「初期費用を抑えるか」「運用負担を外部へ出すか」「独自要件を優先するか」の三つを軸にします。標準機能中心ならクラウド、閉域網や社内認証が必須ならオンプレミス対応、独自業務が多いならプラグイン・APIによる拡張という考え方が基本です。コアコードを直接改変する方式は、将来のアップデートで差分対応が必要になるため、採用理由と撤退条件を明記してください。

Redmineの発注を成功させるRFPと要件整理の進め方

RedmineのRFPと要件を整理しているプロジェクトメンバー

RFPは、開発会社に機能を一方的に指定する資料ではなく、自社の課題と期待する成果を同じ条件で比較してもらうための資料です。Redmineでは「ガントチャートが欲しい」と書くだけでは、標準機能で済むのか、プラグインが必要なのか、業務ルールの見直しが必要なのか判断できません。現状の業務と、導入後に変えたい行動を具体的に書き分けます。

現状業務とデータを棚卸しする

最初に、現在どの情報をExcel、メール、チャット、既存Redmine、顧客管理システムで管理しているかを一覧にします。案件、障害、問い合わせ、変更要求などの種類、登録者、担当者、期限、承認者、添付ファイル、個人情報の有無を確認してください。件数だけでなく、過去に未完了となった理由や、同じ内容を複数の場所へ転記している作業も記録します。

移行対象は、すべてを持ち込むとは限りません。完了から長期間経過したチケットや重複データを整理し、残すデータ、参照用に保管するデータ、廃棄するデータを分けます。添付ファイルの容量、文字コード、ユーザーの重複、プロジェクト名の変更も、見積もりへ影響する確認項目です。

RFPに書くべき要件

RFPには、目的、対象部門、想定ユーザー数、プロジェクト数、現行環境、希望する発注形態、対象業務、必須機能、できれば実現したい機能、非機能要件、移行範囲、教育、保守、納期、予算の考え方、提案依頼事項を入れます。必須機能と希望機能を分け、代替案を許容する項目には「提案を求める」と記載すると、各社の知見を比較しやすくなります。

非機能要件では、認証方式、IPアドレス制限、バックアップ頻度、復旧目標、ログの保持期間、データセンターの所在地、可用性、個人情報の取り扱い、脆弱性対応の期限を確認します。Redmine公式のインストール要件では、バージョンによって対応するRuby、Rails、データベースが異なります。例えばRedmine 7.0はRuby 3.2〜4.0とRails 8.1、Redmine 6.0はRuby 3.1〜3.3とRails 7.2が案内されています(出典: Redmine公式「Installing Redmine」、2026年8月確認)。利用するバージョンとアップデート方針をRFPに固定しておくことが大切です。

PoCから本番展開へ段階的に進める

最初から全社向けの完成形を作るのではなく、1部署または1〜2プロジェクトを対象にPoCを行います。PoCでは、チケットの分類、必須項目、担当者の割り当て、通知の頻度、権限、期限超過時の扱いを試し、現場が無理なく入力できるかを確認します。画面の見栄えよりも、会議でチケットを見ながら判断できるか、対応漏れを減らせるかを評価してください。

本番後は、チケット登録率、期限超過件数、受付から初回対応までの時間、完了までのリードタイム、作業時間の入力率などをKPIにします。数値が悪いときは、機能不足と決めつけず、入力項目が多すぎないか、責任者が明確か、通知が多すぎないかを見直します。PoCの結果を次の部門展開の要件へ反映すると、追加開発の優先順位も説明しやすくなります。

Redmineの契約形態と発注時に決める責任分界

Redmineの契約範囲と責任分界を確認する担当者

Redmineの発注では、開発部分と運用部分で契約を分ける方法が一般的です。初期の要件定義・設計・構築・移行・テストは請負契約、稼働後の監視・問い合わせ・アップデート・障害対応は準委任契約や保守契約で定めるなど、成果物と作業時間の性質に応じて整理します。契約名だけで判断せず、完成条件、検収方法、変更手続き、再委託、知的財産、秘密保持を確認してください。

請負契約で固定しやすい範囲

請負契約に向くのは、納品物と受入条件を事前に定義できる作業です。例えば、指定したバージョンのRedmine環境構築、合意した項目のデータ移行、設定一覧の納品、テスト仕様書に基づく動作確認、操作マニュアルの作成などです。納品物の形式、検収期間、瑕疵や不具合の修正範囲、追加要望の扱いを契約書または仕様書へ書きます。

要件が固まっていないまま、画面数や機能数だけで請負金額を固定すると、後から変更が集中します。契約前に要件定義を別工程にするか、変更管理のルールを設けて、当初の範囲と追加費用を区別してください。仕様変更を口頭で依頼せず、チケットや変更依頼書に残す運用も必要です。

準委任・保守契約で明確にする範囲

準委任や保守契約では、月間の対応時間、受付時間、連絡方法、一次回答の目標、障害の優先度、復旧目標、定例会の回数、バージョンアップの対象、プラグインの互換性確認、バックアップ復元テストを定義します。24時間365日の監視が含まれるのか、平日日中の問い合わせだけなのかで、費用も責任も大きく変わります。

2026年時点のRedmine公式セキュリティアドバイザリには、脆弱性と修正版が継続的に掲載されています。例えば、PostScript実行、OAuthの権限回避、保存型XSS、非公開プロジェクト情報の漏えい、API経由のカスタムフィールド漏えいなどが掲載されています(出典: Redmine公式「Security Advisories」、2026年8月確認)。保守契約では「最新版対応」とだけ書かず、脆弱性情報の確認担当、修正版の評価期限、緊急アップデート時の連絡手順まで決めることが重要です。

データ返却とセキュリティを契約に入れる

クラウドを委託する場合は、契約終了時に何が返却されるかを確認します。データベースのダンプだけでなく、チケットやWikiの添付ファイル、ユーザー情報、設定ファイル、リポジトリ、移行手順が必要になることがあります。返却費用、返却形式、返却期限、返却後の消去証明、移行先で復元できるかまで、契約前に質問してください。

チケットや添付ファイルに顧客情報、担当者の連絡先、障害画面、契約書などを保存する場合は、委託先だけでなく再委託先の管理も必要です。個人情報保護委員会のガイドラインでは、委託先の選定、契約、取扱状況の把握など、委託先に対する必要かつ適切な監督が示されています(出典: 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン(通則編)」、2026年8月確認)。アクセス権限、ログ、暗号化、インシデント時の連絡期限をRFPと契約の両方へ反映します。

Redmineのシステム開発・外注費用相場とコストの内訳

Redmineの開発費用と運用費用を確認している担当者

Redmine固有の受託開発費について全国統計は確認できないため、以下はリサーチノートに基づく推定レンジです。実際の金額は、ユーザー数、データ量、移行元の数、認証方式、プラグイン、外部連携、要求される保守水準で変わります。相場は予算を置くための目安とし、RFPを渡した提案見積もりで確定してください。

導入パターン別の費用レンジ

OSSのRedmineを自社構築する場合は、環境構築・初期設定・バックアップ・監視を含めて初期50万〜200万円程度、インフラと保守は月5万〜30万円程度が一つの推定目安です。情シスの既存人員で作業できる場合は外注費を抑えられますが、その分だけ社内工数が発生します。標準機能中心のRedmineクラウドは、初期0万〜20万円程度、月額1万〜18万円程度のサービスが比較対象になります。

実際の公開価格として、My Redmine Gen.2はスタンダード月額10,000円、ミディアム14,000円、エンタープライズ28,000円、1.5TBプラン40,000円です。最大2か月の無料試用も案内されています(出典: ファーエンドテクノロジー「My Redmine サービス内容・料金」、2026年8月確認)。また、Lychee Redmineの2026年価格表では、クラウドの掲載価格が月額5,000円から180,000円まであり、ユーザー数やプラン、カスタマイズ可否で変わります(出典: アジャイルウェア「Lychee Redmine 価格表 2026年版」、2026年8月確認)。

移行・連携・追加開発の費用目安

既存Redmine、Excel、メール運用からの移行、初期設定、操作研修は、データ量や利用者数によって15万〜100万円程度の推定レンジです。Git、CI、会計、顧客管理、SSO、通知などのプラグイン・API連携は100万〜500万円程度、複数拠点や顧客ポータル、監査要件、大規模移行を含む部門横断の追加開発は500万〜1,500万円程度が推定の比較レンジになります。

開発費の見積書では、要件定義、環境構築、設定、移行、プラグイン開発、テスト、教育、リリース、保守を分けてください。業務システムの人月単価の目安として、リサーチノートではプログラマー50万〜90万円、システムエンジニア65万〜110万円、プロジェクトマネージャー90万〜150万円が示されています。ただし、これはRedmine専用の統計ではなく、業務システムの人件費から推定する際の参考値です。要件定義を省くと手戻りで当初見積もりの1.3〜1.5倍に膨らむ可能性があるため、安い初期見積もりだけで決めないことが重要です。

見落としやすいランニングコスト

ランニングコストには、クラウド利用料やサーバー費だけでなく、監視、バックアップ保管、メール送信、ログ保存、SSL証明書、プラグインのライセンス、脆弱性対応、問い合わせ、教育、データ抽出が含まれます。保守費は初期開発費の年15〜25%程度を一つの検討目安にできますが、対応時間や対象範囲で変わるため、率だけでなく作業内容を確認してください。

例えば、月額が安いサービスでも、IP制限、監査ログ、既存環境からのデータ移行、解約時のバックアップ取得、個別のセキュリティ回答が有料オプションの場合があります。月額だけでなく、3年分または5年分の総保有コストで比較し、初期費用と追加作業の条件を同じ表へ並べると、価格差の理由を説明できます。

Redmineの委託先選定と見積比較のポイント

Redmineの委託先候補と見積書を比較している場面

委託先は、Redmineを扱えるというだけでなく、自社の業務を理解し、標準機能と追加開発の境界を説明できる会社を選びます。導入事例の社名や利用ユーザー数だけでなく、移行元の環境、利用目的、導入後の保守体制、どの課題をどう解決したかを確認してください。提案時の質問に対して、すぐに開発を勧める会社より、まず業務と制約を確認する会社の方が、長期運用では相性を判断しやすいです。

実績と技術体制を確認する

候補会社には、対応できるRedmineのバージョン、Ruby・Rails・データベースの知識、利用中プラグインの互換性、REST APIやWebhookの実績、移行できるデータ形式を質問します。担当者が一人だけの属人的な体制か、複数名でレビューと障害対応ができるかも重要です。可能であれば、実際に設計・構築・保守を担当するメンバーとの打ち合わせを設定します。

クラウド事業者を選ぶ場合は、データの保管場所、SAMLやIP制限の有無、ログダウンロード、バックアップの方式、サービス障害時の通知、解約時のデータ返却を確認します。My Redmine Gen.2の公式仕様では、国内データセンター、API、SAML認証、IPアドレス制限、ログダウンロード、AIチケット要約などの項目がプランごとに案内されています。自社に必要な機能がどのプランに含まれるかを、提案書と契約書で一致させてください。

導入事例は課題と成果の再現性を見る

公開事例では、住友重機械工業がオンプレミスのRedmineからクラウドへ移行し、運用コスト削減と効率化を実現したと紹介されています。また、アルコニックスはメールとExcelによる管理から移行して開発ベンダーとのやり取りを円滑にし、アーティサンは離れた拠点間のシステム開発で進捗を把握しやすくしたとされています(出典: My Redmine公式「導入事例」、2026年8月確認)。事例を見るときは社名の知名度ではなく、自社と同じ移行課題、利用者構成、社外共有の有無、導入後の運用体制があるかを確認してください。

見積書は作業項目と前提条件をそろえて比較する

見積比較では、総額の安さよりも、同じ範囲を見積もっているかを確認します。要件定義の回数、打ち合わせ時間、環境数、本番と検証の区別、移行対象件数、添付ファイル、ユーザー登録、権限設定、テストケース、研修回数、リリース支援、保守開始日を各社の見積書でそろえます。作業一式とだけ書かれた項目は、内容と成果物を質問してください。

見積もりの前提条件も比較対象です。「ユーザー数は100人まで」「移行元は1環境のみ」「プラグインは指定済みのものだけ」「休日作業は別料金」「仕様変更は別見積もり」などが隠れていると、契約後に金額が変わります。安い見積もりを採用するなら、除外項目を社内で引き受ける担当者と費用を明確にしてください。

価格以外の評価軸を点数化する

候補を比較するときは、価格だけでなく、業務理解、Redmineの技術力、移行実績、提案の具体性、保守体制、セキュリティ、データ返却、担当者との相性を評価軸にします。例えば、費用30%、要件への適合25%、技術・移行実績20%、保守・セキュリティ15%、提案と体制10%のように社内で重みを決めると、単純な最安値競争を避けられます。重みの割合は自社のリスクに合わせて変更してください。

最終候補には、短時間のデモやPoCを依頼します。チケット登録から担当者への通知、権限の違うユーザーの見え方、期限変更、作業時間の集計、データ出力までを実際の業務シナリオで確認します。提案書の文章だけでなく、打ち合わせ中に不明点をどう扱うか、制約をどのように説明するかも、委託後のコミュニケーションを予測する材料になります。

よくある質問(FAQ)

Redmineの発注に関するよくある質問を確認している場面

Redmineの発注では、無料で使える範囲、カスタマイズの必要性、クラウドとオンプレミスの違い、導入後の保守がよく質問されます。ここでは、発注前に社内で答えをそろえておきたい質問に、結論から回答します。

Redmineは無料なのに、なぜ外注費がかかるのですか?

Redmine本体のライセンス費用が無料でも、環境構築、業務設計、データ移行、認証連携、プラグイン、教育、バックアップ、脆弱性対応には作業が必要です。外注費はソフトウェアの購入代金ではなく、導入して使い続けるための専門作業と責任を委託する費用と考えると、予算の内訳を理解しやすくなります。

Redmineはクラウドとオンプレミスのどちらを選ぶべきですか?

サーバーやRuby、データベース、バックアップの保守負担を減らしたいならクラウド、閉域網や社内認証、独自の保存方針を優先するならオンプレミスが候補です。クラウドでもデータ所在地、SAML、IP制限、ログ、障害時の復旧、解約時の返却条件を確認し、オンプレミスでもアップデート担当者と保守費を確保してください。

Redmineは自社の業務に合わせてカスタマイズできますか?

カスタムフィールド、ステータス、ワークフロー、権限、プラグイン、REST APIなどで多くの業務に合わせられます。ただし、最初から独自画面を作るのではなく、標準機能で対応できる範囲を確認し、足りない部分だけを拡張してください。コアコードを直接変更するとアップデートの負担が増えるため、プラグインや外部連携で実現できるかを委託先へ確認します。

導入後の保守は誰に依頼すればよいですか?

クラウドを利用する場合でも、サービス側が担う範囲と、自社または別の開発会社が担う範囲を確認します。Redmine本体の更新、プラグインの互換性確認、設定変更、ユーザー管理、業務ルールの改善、障害時の一次切り分けを誰が担当するかを保守契約へ記載してください。契約終了後に自社で運用できるよう、設定一覧と手順書を納品してもらうことも大切です。

まとめ

Redmineのシステム発注方針をまとめているプロジェクトチーム

発注前に確認する項目

Redmineのシステム開発を発注するときは、無料の本体と、構築・移行・追加開発・保守の費用を分けて考えます。標準機能中心ならクラウドや小規模な自社構築、認証・権限・データ移行・連携が必要なら導入支援付きの外注、独自業務が多いならプラグインやAPIによる拡張が候補です。

導入後の運用まで見据える

発注前に現状業務とデータを棚卸しし、RFPで必須要件、非機能要件、移行範囲、教育、保守、データ返却を明記します。見積書は総額だけでなく、作業項目、前提条件、除外項目、追加費用、契約後の責任分界まで比較してください。PoCで現場の定着を確認し、KPIを見ながら段階的に展開すると、過剰なカスタマイズと導入後の手戻りを抑えられます。

Redmineのシステム開発は、機能を購入するだけの取り組みではなく、情報の流れと責任の持ち方を設計する取り組みです。自社に不足する技術や運用体制を把握したうえで、発注先と役割を分担し、アップデートやセキュリティまで継続できる計画を作ってください。

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

会社紹介

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

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

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

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

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

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