Redmineとは何か｜何を管理する道具で、どこまでできるか
Redmineとは何かを一言で言うと、自分のサーバに置いて動かす、プロジェクト管理のウェブアプリケーションです。無償で使えて、設定の自由度が高く、日本の開発現場では長く使われてきました。ただし「自分で置いて動かす」という性質が、良い面と面倒な面の両方を生みます。ここでは、何ができる道具なのか、動かすのに何が要るのか、どういう場面に向いていて、どこで詰まるのかを順に見ていきます。
どういう性質の道具なのか
公式サイトには、次のように書かれています。
Redmine is a flexible project management web application that can be self-hosted. It can be configured for different ways of working. Written using the Ruby on Rails framework, it is cross-platform and cross-database. 出典: redmine.org
ここに性質がほぼ書き切られています。順に見ます。
自分で置いて動かす、というのが第一の性質です。契約して使うサービスではなく、配布されているものを手元に落として、自分のサーバの上で動かします。データはすべて自分の管理下に置かれます。この点が、社外にデータを出せない仕事で選ばれてきた理由です。
働き方に合わせて設定できる、というのが第二の性質です。課題の種別も、状態の名前も、状態のつながり方も、追加する項目も、役割ごとの権限も、すべて画面から定義できます。既製品の型に業務を合わせるのではなく、業務に合わせて型を作る使い方ができます。
Ruby on Rails で書かれていて、複数の環境と複数のデータベースで動く、というのが第三の性質です。Unix系でもLinuxでもmacOSでもWindowsでも、Rubyが動く環境なら動きます。データベースは MySQL、PostgreSQL、SQLite が使えます。
そして、料金の面では GNU General Public License v2 という条件で公開されており、ソフトウェア本体の価格はゼロです。利用者を何人にしても本体の費用は変わりません。
この4つを合わせると、「無償で、手元に置けて、いくらでも形を変えられる」道具になります。裏返すと、「置き場所と動かす手間は自分で持つ」ことになります。
中心にあるのはチケット
Redmineの操作の中心にあるのは、チケットと呼ばれる単位です。1つの作業や1つの課題を1件として登録します。
チケットに入る主な項目は、題名、説明、種別、状態、優先度、担当者、開始日、期日、進捗率、予定工数、そして親チケットです。ここに、あとで説明する独自項目を足せます。
チケットには番号が自動で振られます。この番号は全体で通し番号になっていて、プロジェクトが違っても重複しません。会話の中で「1234番の件」と言えば1件が特定できるので、メールや議事録で参照するときに便利です。
チケットを開くと、下に更新の履歴が並びます。誰がいつ何を書いたか、どの項目をどの値からどの値へ変えたかが、時系列で残ります。この記録の細かさが、検収や監査で履歴の提出を求められる仕事で効いてきます。
一覧の画面では、絞り込みの条件を付けて、必要な列を並べられます。標準の項目も独自項目も、列にも絞り込みの条件にも使えます。作った条件は名前を付けて保存でき、1回の操作で呼び出せます。公開の設定にすれば全員から見えます。
一覧では、複数のチケットを選んでまとめて変更することもできます。チェックを入れて右クリックすると、状態、優先度、担当者などをまとめて変えたり、複製、移動、削除ができます。1件ずつ開いて直している人が多いので、この操作を知っているかどうかで作業時間がかなり変わります。
プロジェクトの入れ子と、公開の範囲
Redmineでは、1つの環境の中に複数のプロジェクトを作れます。そして、プロジェクトを入れ子にできます。
入れ子は、たとえば親を「顧客A社」、子を「A社の基幹刷新」「A社の保守」というように使います。あるいは、親を「2026年度」、子を案件ごとにする使い方もあります。子のチケットを親から横断して見られるので、まとめて眺めるのと個別に見るのを切り替えられます。
プロジェクトごとに、公開か非公開かを選べます。公開にすると誰からでも見え、非公開にするとそのプロジェクトの構成員からだけ見えます。社外の人を招くときは、見せてよい範囲を子のプロジェクトとして切り出して、そこにだけ招く形が使えます。
もう1つ、プロジェクトごとに使う機能を選べます。Wikiを使う、フォーラムは使わない、文書は使わない、といった具合に、画面に出るタブを絞れます。全部を有効にすると、タブが多くて何を見ればよいか分からなくなるので、使うものだけに絞るほうが定着します。
この「プロジェクトごとに機能を切る」設計は、社内のいろいろな部署が同じ環境を共有する使い方に向いています。開発の部署はリポジトリの閲覧を使い、営業の部署は使わない、という分け方ができます。
役割と権限の考え方
Redmineの権限は、利用者ではなく役割に対して設定します。役割を作り、その役割ができることを一覧から選び、利用者をプロジェクトごとに役割に割り当てます。
同じ人が、プロジェクトAでは管理者、プロジェクトBでは閲覧のみ、という設定ができます。ここは実務でかなり効きます。社内の人と社外の人が混ざる案件では、この粒度が無いと運用が組めません。
権限の項目は数十あります。チケットの追加、編集、削除、コメントの追加、他人のチケットの編集、期日の変更、時間の記録、Wikiの編集、ファイルの追加といった単位で、それぞれ与えるか与えないかを決めます。
細かく決められるのは良い面ですが、最初から全部を設計しようとすると進みません。実務的には、標準で用意されている役割を複製して、危ない権限だけを外していく形が早いです。作った後で、その役割の利用者を1人作り、その人でログインして実際にどう見えるかを確かめます。管理者の画面では見えないところに、設定の抜けが出ることがあります。
標準で付いてくるものの一覧
Redmineは、1つのアプリケーションの中にかなりの範囲が入っています。公式が挙げている主な機能は次のとおりです。
・複数プロジェクトの管理と、プロジェクトの入れ子 ・役割にひもづく権限の設定 ・課題の管理と、状態や種別の自由な定義 ・ガントチャートとカレンダー ・作業時間の記録と、利用者別や種別別の集計 ・独自項目の追加 ・ニュース、文書、ファイルの共有 ・プロジェクトごとのWikiとフォーラム ・リポジトリの閲覧と差分の表示 ・Atomフィードとメール通知 ・メールからのチケット作成 ・LDAPによる認証 ・利用者の自己登録 ・多言語の表示 ・複数のデータベースへの対応
対応しているバージョン管理システムは Subversion、CVS、Mercurial、Bazaar、Git です。表示言語は49言語で、日本語も入っています。
この範囲の広さが、Redmineの特徴でもあり、扱いにくさの原因でもあります。全部を有効にすると画面のタブが増え、新しく入った人がどこを見ればよいか分かりません。導入するときは、まず使う機能を3つか4つに絞り、慣れてから増やすほうが定着します。
独自項目とワークフローで、業務に合わせる
「働き方に合わせて設定できる」の中身が、この2つです。
独自項目は、課題、作業時間、プロジェクト、利用者に対して追加できます。形式はテキスト、日付、真偽値、整数、選択肢、チェックボックスなどが選べます。追加した項目は、一覧の列にも、絞り込みの条件にも使えます。
実務では、受注番号、原価コード、担当部署、検収予定日といった値がここに入ります。既製のツールでは項目が足りない、という場面で効きます。ただし増やしすぎると、チケットを1件作るのに入力する欄が多くなり、作るのが億劫になります。作った項目のうち、実際に値が入っているものの割合を、たまに数えてみるとよいです。
ワークフローは、種別と役割の組み合わせごとに、どの状態からどの状態へ移れるかを定義する仕組みです。画面から表の形で設定します。たとえば「テスト中」から「完了」へは、テスト担当の役割だけが移せる、という制約を仕組みで作れます。
この仕組みを持っている道具はそれほど多くありません。承認の流れを運用の約束ではなく仕組みで守りたい場合、ここがRedmineを選ぶ理由になります。逆に、こうした制約が要らない仕事では、設定の手間だけが残ります。
板の上でカードを動かして状態を表す形の道具では、この制約は持てないのが普通です。代わりに更新の手数が少なくなります。考え方の違いはTrelloとの比較やNotionとの比較で、機能ごとに並べてあります。
動かすために必要なもの
自分で立てる場合、要件は公開されています。7.0系の場合、Ruby は 3.2 から 4.0、Rails は 8.1、PostgreSQL は 14 以上、MySQL は 8.0 から 8.4、SQL Server は 2012 以上、SQLite は 3 という記載です。
注意点も明記されています。SQLite は複数人での実運用には向かないと書かれています。試しに動かすには使えますが、チームで使う本番の置き場所にはなりません。また、JRuby には対応していないと書かれています。
任意で入れるものもあります。ガントチャートをPNG画像として書き出す機能とサムネイルの生成には ImageMagick が要ります。PDFの添付ファイルのサムネイル生成には Ghostscript が要ります。7.0以降でMicrosoft Officeの文書の下見表示を使うには Pandoc が要ります。リポジトリの閲覧には、対象のバージョン管理システムの実行ファイルが必要です。
つまり、ソフトウェアを落として置くだけでは、機能の一部が動きません。ガントの書き出しボタンを押しても何も起きない、という状態の原因はここにあることが多いです。
この構成を用意して動かし続ける作業が、Redmineを使う実質の費用になります。仮想マシンやコンテナの形で配布している第三者の組み合わせもあり、公式のダウンロード案内にも紹介されています。最初に動かすまでの手間は、これを使うと短くなります。
版の寿命と、更新の頻度
Redmineは定期的に版が更新されます。公式の配布ページには、マイナーの版が3か月ごと、メジャーの版が年に1回を目安に出されると記載されています。安全上の重大な修正は、可能な限り早く出されます。
支えられる範囲も決まっています。最新のマイナー版は新機能と不具合修正と安全上の修正をすべて受け取れます。1つ前は不具合修正と安全上の修正のみ、2つ前は重要な安全上の修正のみです。それより古い版は対象外です。
2026年9月時点で公開されている版は次のとおりです。7.0系が最新の安定版、6.1系が不具合修正と安全上の修正を受け取る版、6.0系が重要な安全上の修正のみを受け取る版、5.1系より前は対象外と記載されています。2026年8月26日には 7.0.1、6.1.4、6.0.11 が公開され、この更新で4件の脆弱性が修正されたことが公表されています。深刻度は High が2件、Moderate が2件です。
導入を検討する段階で知っておくべきなのは、この更新が自分の仕事になるということです。契約して使うサービスなら提供元が版を上げますが、自分で立てているなら自分が上げます。上げないと、公表されている脆弱性が残ったまま動き続けます。情報を守るための基本的な考え方は情報処理推進機構が公開している資料にまとまっています。
なお、Redmineをクラウドで提供している事業者もあり、その場合は更新が提供元の仕事になります。国内では、月額10,000円（税込11,000円）で1,000ユーザーまでという形のものがあります（2026年9月時点の掲載内容）。費用の考え方の整理は料金のページで条件ごとに比べられます。
外の仕組みとつなぐ
Redmineは、自分のデータの一部をREST APIで公開しています。XMLとJSONの両方の形式に対応しています。
公開されている資源には、それぞれ完成度の区分が付いています。Issues、Projects、Users、Time Entries、News が Stable、Attachments が Beta、Wiki Pages、Journals、Issue Relations、Versions、Custom Fields などが Alpha と記載されています。Stable は仕様が固まっているもの、Alpha は主要な機能はあるが利用者からの反応を待っている段階のものです。
APIを使うには、管理画面でREST APIの利用を有効にします。認証には利用者ごとのAPIキーを使います。キーは個人設定の画面から確認できます。
もう1つ、メールからチケットを作る仕組みもあります。決められたアドレスにメールを送ると、その内容がチケットとして登録されます。社内からの依頼をメールで受けている職場では、この入口を使うと登録の手間が減ります。
自動化や外部のサービスとの連携という点では、あらかじめ用意された接続先が並んでいる製品と比べると、自分で作る部分が多くなります。プログラムを書ける人がチームにいるかどうかで、この差の重さが変わります。
導入の形は3つある
Redmineを使い始める形は、大きく3つに分かれます。どれを選ぶかで、必要な技能も費用の出方も変わります。
1つ目は、配布物を落として自分で組み立てる形です。公式サイトから tar.gz か zip を落とし、データベースを作り、依存する部品を入れ、初期データを読み込み、動作を確かめる。公式の導入手順には、この工程が段階ごとに書かれています。Rubyの環境を自分で用意できる人なら、半日から1日で動きます。慣れていない場合は、依存する部品の入れ方でつまずくことが多く、そこで数日かかることがあります。
2つ目は、あらかじめ組み上がったものを使う形です。公式のダウンロード案内には、第三者が用意している組み合わせが紹介されています。仮想マシンの形式や、クラウド向けの起動用の形式で配られているものがあり、これを使うと組み立ての工程を飛ばせます。試しに触ってみる段階では、この形がいちばん早く到達できます。ただし、中身の構成が自分で組んだ場合と違うため、版を上げるときの手順もそちらの案内に従うことになります。
3つ目は、クラウドで提供されているものを契約する形です。この場合、組み立ても版の更新も提供元がやります。自分で用意するのは利用者の登録と、プロジェクトの設計だけです。画面と用語は同じなので、Redmineを知っている人ならそのまま使えます。国内で提供されているものは、日本語のサポート窓口が付き、データの保管場所も国内と明記されているものがあります。
どれを選ぶかは、社内に環境を用意して動かし続けられる人がいるかどうかで、ほぼ決まります。いるなら1つ目、いないなら3つ目。2つ目は、試す段階の選択肢として位置づけるのが現実的です。
使い始めの最初の1週間で決めること
導入して最初につまずくのは、機能ではなく設計です。何を決めておくかを挙げます。
まず、プロジェクトの切り方です。案件ごとに作るのか、顧客ごとに作るのか、部署ごとに作るのか。ここを決めずに作り始めると、数か月後にプロジェクトが50件を超えて、どこに何があるか分からなくなります。入れ子にできるので、親を大きな単位、子を実際の作業の単位にする形が扱いやすいです。
次に、種別の数です。標準では「バグ」「機能」「サポート」といった種別が入っていますが、名前は自由に変えられます。ここを増やしすぎると、チケットを作るときに選ぶのに迷います。3種類から5種類に収めるのが目安です。
3つ目に、状態の名前と数です。標準では新規、進行中、解決、フィードバック、終了、却下といった状態が入っています。実際の仕事の流れに合わない名前があるなら、最初に変えます。後から変えると、過去のチケットの状態も一緒に変わるので、混乱が起きます。
4つ目に、必須にする項目です。作成のときに担当者を必須にするか、期日を必須にするか。必須が多いほど記録は揃いますが、チケットを作るのが億劫になります。まずは期日だけを必須にして、運用が回り始めてから増やすのが安全です。
5つ目に、通知の範囲です。既定のままだと、関わっているプロジェクトの全部の更新が届きます。1日に数十通が届く状態になると、数日で誰も読まなくなります。作業する人は自分に関係するものだけ、進行を見る人は全部、という2段階に分けておきます。
この5つを最初の1週間で決めておくと、後から作り直す作業がほとんど発生しません。逆に、決めずに走り出すと、半年後に全部を作り直すことになります。
よく起きるつまずきと、その原因
導入した後で出てくる詰まりは、だいたい決まっています。原因が分かっていれば対処できます。
ガントチャートに一部のチケットが出てこない。原因は、開始日と期日の両方が入っていないことです。片方でも空欄だと線が引かれません。ガントを使うなら、この2つの入力を必須にします。もう1つ、管理画面にガントチャートの表示件数の上限があり、これを超えた分も出ません。
チケットの一覧をCSVで落としたら途中で切れていた。原因は、書き出しの件数に上限があることです。初期値は500件です。管理者ならこの値を上げられます。上げられない場合は、絞り込みを分けて複数回に分けます。
新しく入った人が使ってくれない。原因は、たいてい画面のタブが多すぎることです。プロジェクトごとに使う機能を選べるので、使っていないタブは切ります。タブが3つに減るだけで、迷いがかなり減ります。
チケットが更新されなくなる。原因は、更新1件あたりの手数です。開いて、状態を選んで、進捗率を選んで、コメントを書いて、保存する。この手数が多いほど、忙しい日から順に飛ばされます。進捗率を状態と連動させる設定にすると、選ぶ手間が1つ減ります。一覧で右クリックしてその場で状態を変えられることを伝えるだけでも、負担が下がります。
版を上げたらプラグインが動かなくなった。原因は、プラグインが新しい版に対応していないことです。上げる前に、入れているプラグインの対応状況を1つずつ確かめます。使われていないプラグインが混ざっていることが多いので、この機会に外すと次回が楽になります。
日本語で使えるか、情報はどこにあるか
導入を検討するときに気になるのが、日本語で使えるかどうかと、困ったときに調べられるかどうかです。
表示言語は49言語に対応していて、日本語が含まれています。管理画面で全体の既定の言語を決められるほか、利用者ごとに表示言語を変えられます。日本語の担当者と海外の協力会社が同じ環境を使う場合、それぞれの言語で表示できます。この点は、多言語の現場では効いてきます。
公式の資料は英語です。導入手順、設定の説明、APIの仕様は、いずれも英語で書かれています。翻訳された案内も一部にありますが、最新の内容は英語のほうが早く反映されます。設定の細かい挙動を調べるときは、英語のページを読むことになります。
日本語での情報は、公式とは別に、国内の事業者や利用者が公開しているものが多くあります。国内でRedmineをクラウドで提供している事業者は、日本語のサポート窓口を持ち、使い方の案内やセミナーの記録を公開しています。自分で立てて使う場合でも、こうした資料は設定の参考になります。
もう1点、日本語で使ううえで確かめておきたいのが、書き出したCSVの文字コードです。書き出しの画面で選べますが、環境によっては日本語環境向けの形式が既定になっていることがあります。この形式で出すと、丸囲みの数字や一部の漢字が別の環境で化けます。他の道具へ渡す前提なら、UTF-8を選んで出します。
向く場面と、合いにくい場面
最後に、どういう場面に向いているのかを整理します。
向いているのは、次のような場合です。
・データを社外に置けない決まりがあり、自社のサーバで動かす必要がある ・承認や検収の流れを、運用の約束ではなく仕組みで守りたい ・業務に固有の項目が多く、既製の項目では足りない ・利用者が多く、1人あたりいくらの体系では費用が跳ね上がる ・社内に、環境を作って動かし続けられる人がいる
合いにくいのは、次のような場合です。
・環境を用意して動かし続ける人がいない。ここが最大の分かれ目です ・チームが数人で、細かい権限や状態の分岐が要らない。設定の手間だけが残ります ・更新の手数を減らして、入力してくれる人を増やしたい。1件ずつ開いて項目を選ぶ形は、忙しい人から順に飛ばされます ・外部のサービスとの連携を、設定だけで済ませたい
最後の点は正直に書いておきます。板の形でカードを動かす道具には、リポジトリの閲覧のような開発向けの機能は入っていないのが普通です。ソースを見る場所は別に持つ前提になります。機能で絞らず、区切るのは人数とボードの数だけという区切り方の道具もあり、必要な機能が上位プランにしか無いという事態は起きませんが、その代わり機能の範囲そのものはRedmineより狭くなります。
検討の順番としては、機能の一覧を見比べる前に、上の「合いにくい場面」の1つ目、つまり環境を用意して動かし続ける人がいるかどうかを先に確かめます。ここが埋まらないまま導入すると、最初の数か月は動いていても、版が2つ3つ古くなったあたりで手が付けられなくなります。人がいないなら、クラウドで提供されているものを契約するか、別の設計の道具を検討するかの二択になります。
どちらを選ぶかは、上に挙げた条件のうちいくつが当てはまるかで決まります。判断の材料として、機能の対応関係はできることに、他の道具との違いは比較の一覧に整理されています。移すときに何が運べるのかはTrelloからの移行の説明が参考になり、運用に乗った後で出る疑問はよくある質問にまとめてあります。
Q1. Redmineは何をする道具ですか？
プロジェクトの作業や課題を1件ずつチケットとして登録し、担当者と期日と状態を追う道具です。ガントチャート、カレンダー、Wiki、作業時間の記録、リポジトリの閲覧までが1つのアプリケーションに入っています。契約して使うサービスではなく、自分のサーバに置いて動かします。
Q2. Redmineを使うのに費用はかかりますか？
ソフトウェア本体は GNU General Public License v2 で公開されており無償です。利用者を何人にしても本体の価格は変わりません。ただしサーバの費用と、版を上げ続ける作業の時間は別に発生します。
Q3. Redmineを動かすには何が必要ですか？
Ruby と Rails とデータベースが要ります。7.0系では Ruby 3.2 から 4.0、Rails 8.1、PostgreSQL 14 以上または MySQL 8.0 から 8.4 という記載です。ガントチャートのPNG書き出しには ImageMagick が別途必要です。SQLite は複数人での実運用には向かないと明記されています。
Q4. Redmineはどういうチームに向いていますか？
データを自社のサーバに置く必要がある場合、承認の流れを仕組みで守りたい場合、業務固有の項目が多い場合、利用者が多い場合に向いています。逆に、環境を用意して動かし続ける人がいない場合は、運用の負担が先に重くなります。