LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

Redmineセルフホスト構築とは — オープンソース課題管理ツールの基本

Redmineセルフホスト構築とは、オープンソースのプロジェクト管理・課題管理ソフトウェアであるRedmineを、自社が管理するサーバーやクラウド環境上に導入し、自前で運用する取り組みを指します^*1。Ruby on Railsで開発され、GNU General Public License v2（GPL）のもとで公開されており、誰でも無償で入手・改変できます^*2。

Redmineの中核機能は「チケット」と呼ぶissue（課題・タスク）の登録・追跡です。実施すべき作業や修正すべきバグ、改善要望などをチケットとして記録し、担当者・期日・進捗率とともに管理します^*3。あわせてガントチャート・カレンダー・Wiki・フォーラム・リポジトリ連携といった機能を1つのWebアプリケーションで提供しています^*1。

2026年7月時点でRedmine 7.0.0が最新の安定版として公開されています^*4。セルフホストで導入する場合は、自社が選んだバージョンをそのまま使い続けられる一方、更新の適用判断や動作環境の維持は運用側の責務になります。まずは公式ドキュメントで動作要件を確認し、自社のIT基盤に合う構成を見極めることが最初の一歩です。

チケット・トラッカー・ワークフローの設計が運用の土台になる

Redmine運用の質は、チケット・トラッカー・ワークフローという3つの概念をどう設計するかで大きく変わります。導入前にこの構造を理解しておくことが、後の混乱を防ぎます。

チケットは「やるべきこと」を記録する最小単位

チケットとは、実施すべき作業・修正すべきバグ・検討すべき改善要望など、プロジェクトで発生する「やるべきこと」を1件ずつ登録する記録単位です^*3。担当者・優先度・期日・進捗率・ステータスといった属性を持ち、親子チケットや関連チケットへのリンクも設定できます^*1。

チケットは検索・フィルタ・並び替えができるため、担当者ごとの負荷状況や遅延しているタスクを一覧で把握できます。issue（英語表記）とチケット（日本語表記）は同じ概念を指す用語です。

トラッカーはチケットの種類を分類する仕組み

トラッカーは、チケットがどのような性質の作業かを分類する仕組みです。「バグ」「機能」「サポート」といった分類を設定でき、トラッカーごとに使用可能なフィールドやワークフローを個別に変えられます^*1。

たとえば「バグ」トラッカーには再現手順・環境情報の入力欄を必須にし、「機能」トラッカーには優先度と対象バージョンを重視する設計にするなど、業務特性に合わせた運用が可能です。トラッカーの設計を最初に固めておくと、後からチケットの分類基準がぶれるのを防げます。

ワークフローはステータス遷移のルールを定義する

ワークフローは、チケットのステータスがどのように移り変わっていくかを決めるルールです^*1。トラッカーとロール（権限グループ）の組み合わせごとに、「新規→対応中→レビュー中→完了」のような遷移経路を個別に設定できます。

ワークフローを厳密に設計すると、担当者が誤った手順でステータスを進めてしまう事態を防げます。反対に、必要以上に細かく分岐させると現場が使いこなせなくなるため、実際の業務フローに沿った粒度で設計することが大切です。この設計を怠ると、チケットが放置されたり、承認プロセスが機能しなくなったりする懸念があります。

ガントチャート・ロードマップで進捗を可視化する仕組み

Redmineには、チケットに登録した開始日・期日・進捗率のデータをもとに、ガントチャートを自動描画する機能があります^*1。手作業でスケジュール表を更新する必要がなく、チケットの更新がそのまま進捗表示に反映されます。

ガントチャートはチケットの日付データから自動生成される

ガントチャートの表示は、各チケットに設定された開始日・期日・進捗率の入力値に依存します。日付が未設定のチケットはガントチャート上に正しく表示されないため、運用ルールとして日付入力を徹底することが可視化の前提になります。

親子チケットの階層構造を使うと、大きなタスクを複数の子チケットに分割し、それぞれの進捗を積み上げて親チケットの進捗として表示する運用もできます。プロジェクト全体の遅延状況を経営層やプロジェクトマネージャーが一目で把握できる点が、ガントチャート機能の実務上の価値です。

ロードマップはバージョン単位でチケットを整理する表示

ロードマップは、チケットの表示オプションの1つで、プロジェクトのバージョン（マイルストーン）ごとに未完了・完了チケットを整理して表示します^*1。リリース計画や開発フェーズの区切りを可視化する用途に向いています。

バージョンにはリリース予定日を設定できるため、ロードマップとガントチャートを併用することで、マイルストーン単位の計画と日次の進捗管理の両方を1つのツール内で完結できます。

プラグインによる拡張とカスタマイズの範囲

Redmine本体の標準機能はチケット管理・ガントチャート・Wiki・フォーラム・リポジトリ連携などに限られますが、プラグインによって機能を追加できる拡張性を備えています^*5。

プラグインディレクトリには多数の拡張機能が公開されている

redmine.orgが公開するプラグインディレクトリには、目的別に検索できる形で100件を超えるプラグインが登録されています^*5。UI拡張・チャット通知連携・カスタムフィールドの拡張・レポート機能の追加など、標準機能を補う拡張が幅広く存在します。

プラグインの導入は、Redmineのpluginsディレクトリに配置し、必要に応じてデータベースのマイグレーションを実行する手順で行います^*5。プラグインごとに対応するRedmineバージョンが異なるため、導入前に互換性の確認が必要です。

プラグインの互換性維持は運用側の継続対応が前提

プラグインはRedmine本体のバージョンアップに追随して更新されるとは限りません。本体をアップグレードした際に、導入済みプラグインが動作しなくなるケースが起こり得ます。プラグインを多用する場合は、アップグレード計画にプラグインの動作確認工程を含める必要があります。

また、プラグイン開発には固有のAPIとフレームワークの理解が求められるため^*5、自社に合わせた独自プラグインを内製で開発するには専門知識を持つ担当者の確保が前提になります。

セルフホストRedmineとSaaS型PMツールの違い

プロジェクト管理・課題管理の分野では、Jira・BacklogといったSaaS型ツールも広く使われています。セルフホストのRedmineとSaaS型ツールは、どちらが優れているという単純な比較ではなく、運用モデルの違いとして捉える必要があります。

データ保持とカスタマイズの裁量が自社側にある

セルフホストを選ぶ企業の主な動機は、データの保管場所を自社の管理下に置けることと、トラッカー・ワークフロー・プラグインによる細かなカスタマイズができることです。社内規定やセキュリティポリシー上、外部クラウドへの情報保管に制約がある組織にとっては、この点が導入判断の軸になります。

一方でSaaS型ツールは、契約すればすぐに使い始められる導入の速さと、インフラ運用を自社で担わなくて済む点が利点です。どちらを選ぶかは、自社のセキュリティ要件・IT運用体制・カスタマイズ要求の強さによって変わります。

ライセンスコストと運用負荷はトレードオフの関係にある

Redmineのソフトウェア自体はGPLv2のライセンスのもとで無償公開されています^*2。ただし無償であることは「運用コストがゼロになる」ことを意味しません。サーバー費用・保守対応・アップグレード作業・障害対応といった工数は自社側の負担として発生します。

SaaS型ツールのサブスクリプション費用には、こうした運用工数が提供事業者側のサービス料金に含まれていると捉えられます。セルフホストを選ぶ場合は、ライセンス費用の有無だけでなく、運用工数を誰がどの体制で担うかを合わせて検討する必要があります。

認証連携・バックアップ・アップグレードという運用設計の論点

Redmineをセルフホストで安定運用するには、構築時点だけでなく、その後の継続運用を見据えた設計が欠かせません。特に認証連携・バックアップ・アップグレードの3点は、構築段階で方針を決めておくべき論点です。

LDAP認証連携でアカウント管理を一元化できる

Redmineは複数のLDAPサーバーとの認証連携に対応しています^*1。社内で既にActive Directory等のディレクトリサービスを運用している場合、Redmine側で個別にアカウントを管理するのではなく、既存の認証基盤と連携させることで、入退社時のアカウント管理を一元化できます。

ユーザー自己登録機能も備えているため^*1、社外パートナーとの協業案件など、社内ディレクトリに含まれない利用者を扱うプロジェクトでは、自己登録の運用ルールを別途定める必要があります。

バックアップはファイルディレクトリとデータベースの両方が対象

Redmineのバックアップ対象は2つに分かれます。1つはインストールディレクトリ直下のfilesディレクトリで、チケットやWikiに添付されたファイルが保存されています。もう1つはデータベースで、チケット・プロジェクト・ユーザー情報などのデータ本体が格納されています^*7。

データベースの種類がMySQLであればmysqldump、PostgreSQLであればpg_dumpといった標準的なバックアップコマンドを使用します^*7。復元時は、バックアップ取得時と同一バージョンのRedmineを用意し、filesディレクトリとデータベースの両方を戻す手順になります^*7。バックアップの取得頻度と保管場所を運用ルールとして定めておくことが、障害時の復旧時間を左右します。

アップグレードは動作環境確認からデータベース更新まで段階的に行う

Redmineの公式アップグレード手順は、動作環境の確認、データベースおよびアップロードファイルのバックアップ、新バージョンの配置と設定ファイルの移行、データベースのマイグレーション、キャッシュクリアとアプリケーションサーバーの再起動という段階を踏みます^*8。

プラグインを導入している場合は、プラグイン側のマイグレーションも別途実行する必要があります^*8。バージョンアップを長期間見送ると、セキュリティ修正の適用が遅れるリスクや、対応環境の差が大きくなり移行作業が難しくなるリスクが生じます。年次または半年ごとにアップグレード計画を組み込むことが、運用の安定に寄与します。

構築を外注する場合と内製する場合の判断軸

Redmineのセルフホスト構築は、必要スキルの見極めができれば内製も可能な一方、体制によっては外注が現実的な選択肢になります。判断軸を整理します。

内製に必要なスキルと工数の見立て

内製で構築する場合、サーバー構築・Ruby on Railsの動作環境整備・データベース設計・セキュリティ設定（アクセス制御・SSL証明書等）・LDAP連携設定といった複数領域の知識が必要になります。加えて、構築後はトラッカー・ワークフローの設計、プラグインの選定と互換性検証、継続的なバックアップ・アップグレード対応という運用フェーズの工数も発生します。

社内にRuby on Railsアプリケーションの運用経験を持つ担当者がいない場合、初期構築だけでなく、その後の障害対応やアップグレード時に都度調査が必要となり、対応が長期化する可能性があります。

外部委託した場合と内製した場合の違い

専門の開発・運用パートナーに委託する場合、構築時の環境設計・セキュリティ設定・LDAP連携・プラグイン選定を経験に基づいて進められる点と、アップグレード・バックアップといった継続運用を体制として提供してもらえる点が内製との違いになります。内製では、これらすべてを社内の限られた人員で継続的に担う必要があります。

ただし外部委託であっても、トラッカー・ワークフローの設計といった「自社の業務プロセスをどう反映するか」という部分は、発注側が要件を明確に伝える必要があります。委託先に丸投げすると、実際の業務フローに合わない運用ルールになるリスクがあるため、要件定義の段階から発注側が関与することが欠かせません。

継続運用まで見据えた体制構築が長期コストを左右する

Redmineは無償で導入できるソフトウェアですが、構築直後で運用を終える前提のツールではありません。ワークフローの見直し・プラグインの追加要望・アップグレード対応・障害時の復旧といった業務が継続的に発生します。

外注先を選定する際は、初期構築の費用だけでなく、継続的な運用保守まで対応できる体制を持っているかを確認することが、長期的なコスト管理につながります。構築時点で運用フェーズの体制まで含めて検討しておくことが、セルフホスト運用を成功させる実務上のポイントです。

まとめ：Redmineセルフホスト構築を成功させる3つの視点

本稿では、Redmineセルフホスト構築の基本概念（チケット・トラッカー・ワークフロー）、ガントチャート・ロードマップによる可視化、プラグイン拡張、SaaS型ツールとの違い、認証連携・バックアップ・アップグレードという運用設計、外注と内製の判断軸を整理しました。要点は次の3つに集約されます。

第一に、チケット・トラッカー・ワークフローの設計を業務プロセスに合わせて最初に固めることが、運用の混乱を防ぎます。第二に、セルフホストとSaaS型はデータ保持・カスタマイズ性・運用負荷のトレードオフであり、自社のセキュリティ要件と運用体制に応じて選ぶべき論点です。第三に、認証連携・バックアップ・アップグレードという継続運用の工程まで見据えて、内製と外注のどちらで担うかを構築段階から検討することが、長期的な安定運用につながります。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：Redmine.JP「Redmineの概要」（2026年確認）
2. *2　出典：Wikipedia「Redmine」（2026年確認）
3. *3　出典：Redmine.JP「5分でわかるRedmineの「チケット」機能」（2026年確認）
4. *4　出典：Redmine.JP「Redmine.JPトップページ（バージョン情報）」（2026年7月確認）
5. *5　出典：Redmine.org「Redmine Features」（2026年確認）
6. *6　出典：Redmine.JP「Redmineインストールガイド」（2026年確認）
7. *7　出典：Redmine.JP「データのバックアップ方法」（2026年確認）
8. *8　出典：Redmine.JP「アップグレード – Redmineガイド」（2026年確認）

Tweet