Redmineとは｜自分で建てて使う選択と、動かすのに要るもの

redmine とは何かを調べている人の多くは、いま使っている道具のどこかで詰まっています。表計算の工程表を毎週引き直している、チャットで決めたことが翌週には誰も思い出せない、進捗を聞いて回るだけで午前が終わる。そういう場面で「無料で使えるらしい」という言葉と一緒に名前が挙がるのがRedmineです。

この記事は、Redmineがどういう性格の道具なのかを、機能の羅列ではなく「使い始めるまでに何を用意することになるか」と「使い始めたあとに誰が何を担うことになるか」から説明します。結論を先に置くと、Redmineは自分でサーバーを用意して自分で動かすソフトウェアです。ライセンス料は要りません。その代わり、置き場所と、動かすための部品と、更新を続ける人が要ります。この構図を理解しているチームにとっては、他の道具では代えがたい選択肢になります。

もうひとつ先に書いておきます。この記事はRedmineから乗り換えることを勧めるものではありません。自分たちで管理できる体制があるチームにとって、Redmineは長く使える良い道具です。判断が分かれるのは、その体制を用意できるかどうかという一点だけです。

なお、この記事で挙げる仕様は、すべて公式サイト（redmine.org）に書かれている記載をもとにしています。確認日は2026年9月2日です。版の対応表や設定の既定値は更新されますので、実際に構築する前には必ず公式のインストール手順で最新の内容を確かめてください。

進行管理の道具が並ぶなかで、Redmineがどこに立っているか

チームの進行を管理する道具は、この10年で大きく増えました。付箋を並べる形のもの、表の形で持つもの、文書と台帳が一体になったもの、工程表を主役にしたもの。どれも「やることを並べて進み具合を見る」という点では同じことをしています。それでも使い比べると手触りがまったく違うのは、想定している仕事の形と、提供のされ方が違うからです。

提供のされ方には大きく2つあります。ひとつは、事業者が用意したサーバー上のサービスを、月額や年額を払って使う形です。いま名前をよく聞く道具のほとんどはこちらです。もうひとつが、ソフトウェアを受け取って自分たちのサーバーに置き、自分たちで動かす形です。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

self-hostedという語がすべてを表しています。自分のところで動かす、という意味です。あわせて、Ruby on Railsというフレームワークで書かれていること、プラットフォームを選ばないこと、データベースを選ばないことが書かれています。この3つは、あとで出てくる「動かすのに何が要るか」の話に直結します。

ライセンスについても公式サイトに明記があります。「Redmine is open source and released under the terms of the GNU General Public License v2 (GPL).」つまりGPL v2で公開されているオープンソースソフトウェアです。公式サイトには価格表というページが存在しません。利用料金やライセンス料の記載も見当たりません。ここが、月額のサービスと並べて比べたときの最大の違いになります。

この違いは、判断の軸そのものを変えます。月額のサービスを比べるときは、料金表の段組みと、プランごとの上限と、人数の掛け算を見ます。Redmineを検討するときに見るのは、料金表ではなく、サーバーの用意と、必要な部品の版と、更新を続ける手間です。同じ表に並べて比べようとすると、片方の列が空欄になって判断できなくなります。比べ方を変える必要があります。

道具の比べ方そのものに迷いがあるなら、何を軸に見ればよいかを整理したページも用意されています。機能の一覧表だけを見比べると、どれも似たように見えて決められなくなります。比較の一覧には、板の形で進行をまとめる道具と、他の主要な道具をどの観点で並べればよいかがまとめてあります。

先に書いておく、Redmineをそのまま使い続けていいチーム

道具の話を乗り換えの理由から始めると、判断を誤らせます。まず「そのままでいい場合」を具体的に挙げます。次に当てはまるチームは、別の道具を探す理由がありません。

社内にサーバーを見られる人がいるチーム

これが最も大きな分かれ目です。Linuxのサーバーに入って、Rubyの版を上げて、データベースのバックアップが取れているか確かめて、半年に一度の新しい版に追随できる人がチームの中にいる。あるいは、その作業を任せられる相手がいる。この条件が満たされているなら、Redmineは素直に効きます。

自分たちで動かすということは、自分たちで決められるということでもあります。項目を好きなだけ増やせる、権限の区切りを細かく決められる、データが自分たちのサーバーの中にある。サービス提供者の都合で仕様が変わったり、プランが改定されたり、機能が終了したりすることがありません。この安心感を重く見るチームにとって、代えのきかない性質です。

人数が読めない、または増減が激しいチーム

Redmineは自分のサーバーに入れて使うソフトウェアであり、席数の契約という概念がありません。最低契約席数についての記載も、ユーザー数の上限についての記載も、公開資料では確認できませんでした。つまり、人を増やすたびに料金が積み上がる構造ではありません。

これは、外部の協力者を含めて出入りが多い進め方をしているチームにとって、計算しやすい作りです。人数で月額が動く道具では、「この人を招待していいか」を毎回考えることになり、結局その人だけメールで連絡が回るようになります。招待をためらわなくていいというのは、進行の記録がひとつの場所に集まるかどうかに直結します。

記録を長く残したいチーム

数年単位で案件が続く仕事、あとから経緯を辿る必要がある仕事では、履歴が残り続けることが効きます。Redmineには、履歴の保持期間について上限を定めた公式の記載が見当たりません。自分たちのデータベースの中にあるので、置いておく限り残ります。

保存期間に制限のあるプランを使っていて、去年の議論を辿れずに困った経験があるチームにとって、この点は判断の重みが違います。ただし、残るのは自分たちがバックアップを取り続けている限りにおいてです。ここも自分たちの責任範囲に入ります。

以上に当てはまるなら、この記事の残りは「いま使っている道具をより正しく理解するための情報」として読んでください。

「無料」が指しているのは、ライセンス料が要らないということ

Redmineの説明で最も誤解が生まれやすいのがここです。「Redmineは無料」という言い方は、正確には「ソフトウェアのライセンス料が要らない」という意味です。GPL v2で公開されているソフトウェアそのものが無償であり、機能を制限した無料版という区分も存在しません。有料版に上げないと使えない機能、という考え方自体がありません。

その一方で、動かすためにかかるものは、ライセンス料とは別に発生します。整理すると次のようになります。

・ソフトウェアを置くサーバー。自社の機械でも、借りるサーバーでも、置き場所は要ります ・そのサーバーの上に用意する部品。Rubyとデータベース、そして動かすためのWebサーバー ・構築する人の時間。手順に沿って入れて、動くところまで持っていく作業です ・動かし続ける人の時間。バックアップ、障害対応、半年に一度の版の更新 ・止まったときに困る度合い。進行の記録が全部そこに入っている以上、止まると全員の手が止まります

このうち、金額として見えるのはサーバーの費用だけです。残りは人の時間として消えます。見えないので計算から落ちやすく、あとで「思っていたのと違う」という話になりやすいのもここです。

判断の仕方としては、「ライセンス料がゼロになる代わりに、運用の担当が1人分の一部を継続的に使う」と置くのが実態に近くなります。その担当が社内にいて、他の業務と両立できるなら、費用としては十分に見合います。逆に、頼める人が1人しかおらず、その人が別の主業務で埋まっているなら、月額を払って事業者に運用を任せる形のほうが、結果として安く済むことがあります。

月額の側の相場を確かめたいなら、料金の考え方をまとめたページも見ておくと比較の軸が揃います。人数と使う板の数だけで区切る形が、自分たちの人の増え方に合うかどうかを確かめられます。料金には、どこで金額が変わるのかが書かれています。

動かすのに何が要るか、公式の手順に沿って確かめる

ここからが実務の話です。Redmineを検討していて最初に確かめるべきなのは、機能の一覧ではなく動作環境です。手元のサーバーに必要な版が入るかどうかで、そもそも成立するかが決まります。

OSは選ばない。ただしRubyが動くことが前提

公式のインストール手順には、こう書かれています。「Redmine should run on most Unix, Linux, macOS and Windows systems as long as Ruby is available on this platform.」Unix系、Linux、macOS、Windowsのほとんどで動く。ただし、そのプラットフォームでRubyが使えることが条件、という書き方です。

OSを選ばないという点は、既存の資産を使える可能性を広げます。社内にすでにLinuxのサーバーがあるなら、そこに追加で入れられます。ただし、条件として書かれているRubyの部分が実質的な壁になります。

RubyとRailsの版は、使うRedmineの版で決まる

Redmine 6.0以降の公式インストール手順に、対応する版の表があります。内容は次のとおりです。

Redmineの版	対応するRuby	使っているRails
Redmine 7.0	3.2, 3.3, 3.4, 4.0	8.1
Redmine 6.1	3.2, 3.3, 3.4	7.2
Redmine 6.0	3.1, 3.2, 3.3	7.2

あわせて、「Redmine does not support JRuby.」という記載があります。JRubyは対象外です。

さらに、Redmine 7.0を入れる場合に注意すべき注記があります。「Ruby versions 4.0.0 to 4.0.3 have a significant wiki rendering slowdown caused by a regression in the Ruby runtime itself. This was fixed upstream in Ruby 4.0.4, so we recommend running Redmine 7.0 on Ruby 4.0.4 or later.」Rubyの4.0.0から4.0.3にはWikiの描画が大きく遅くなる問題があり、これはRuby側の後戻りが原因で、Ruby 4.0.4で直っている。だからRedmine 7.0はRuby 4.0.4以降で動かすことを勧める、という内容です。

この注記は、自分で建てて使うということの性格をよく表しています。ソフトウェアの側だけでなく、その下で動く言語の処理系の版まで自分たちの判断範囲に入ります。事業者が運用しているサービスなら、こうした話は利用者の目に触れません。触れないということは、決めなくていいということでもあります。どちらが良いかはチームの体制によります。

データベースは4種類。SQLiteだけ注意書きが付く

推奨として表に載っているデータベースは4種類です。

・PostgreSQL 14 ・MySQL 8.0 から 8.4（Redmine 6.0 は 8.0 から 8.1） ・Microsoft SQL Server は「2012 or higher」 ・SQLite 3。ただし「SQLite 3 (not for multi-user production use!)」という注記が付きます

最後の注記は、括弧のなかに感嘆符まで付いた強い書き方です。複数人で使う本番の用途には向かない、という意味になります。試しに動かしてみる用途と、チームで日々使う用途では、選ぶべきデータベースが違うということです。ここを取り違えると、人が増えたときに動きが重くなります。

MySQLを使う場合にはもうひとつ条件があります。「MySQL requires to change the transaction_isolation to READ COMMITTED in order to properly work」。正しく動かすには、トランザクション分離のレベルをREAD COMMITTEDに変える必要があります。既定のままでは想定どおりに動かないということなので、構築時に忘れずに設定します。

Webサーバーと、任意で入れるもの

インストール手順のなかで、動作確認の方法として挙げられているのはPumaです。「Test the installation by running Puma web server: bundle exec rails server -e production」という記載があります。あわせて、「If you need to load gems that are not required by Redmine core (eg. Puma, fcgi), create a file named Gemfile.local at the root of your redmine directory.」とあり、Redmine本体が必要としない部品を追加するときは、redmineのディレクトリの直下にGemfile.localというファイルを作る形になっています。

そして、公式が「Optional components」として挙げているものが5つあります。ここは実際の使い勝手に直結するので、それぞれ何のために要るのかを押さえておきます。

・SCM binaries（例: svn）。リポジトリを画面から見るために要ります。PATHから使える状態になっている必要があります ・ImageMagick。ガントチャートをPNG画像に書き出す機能と、添付ファイルの縮小画像の生成を有効にするために要ります ・Ghostscript。PDFの添付ファイルの縮小画像を生成するために要ります ・Pandoc。Redmine 7.0以降で、Microsoft Officeの文書（.docx、.xlsx、.pptx）とLibreOffice Writerの文書（.odt）を画面上で下見するために要ります。版は3.8.3以降が推奨されています ・Sidekiq。本番環境での待ち行列の仕組みとして推奨されています

「任意」と書かれてはいますが、実際にチームで使う場面を思い浮かべると、任意とは言いにくいものが混じっています。工程表を会議資料に貼りたいならImageMagickが要ります。取引先から届いた見積書のPDFを一覧で見分けたいならGhostscriptが要ります。入れ忘れたまま運用を始めると、「なぜかこの機能だけ使えない」という形で表面化します。構築の時点で、使う予定のある機能から逆算して入れておくのが安全です。

PHPは要件に出てこない

検索でよく見かける誤解として、Redmineを動かすのにPHPが要ると思われていることがあります。RedmineはRuby on Railsで書かれており、PHPは要件に挙がっていません。PHPに関する要件の記載は、公開資料では確認できませんでした。

これが実務でどう効くかというと、既存のレンタルサーバーが使えるかどうかの判断に直結します。PHPが動くことを前提にした共用のレンタルサーバーは数多くありますが、そこにRubyとデータベースを自分の裁量で用意できるとは限りません。導入の可否を判断するときに確かめるのは、PHPの版ではなく、Rubyの版を選べるか、データベースを持てるか、常時動かし続けるプロセスを置けるか、という3点です。

半年ごとに新しい版が出る、という前提で計画する

公式サイトには、リリースの間隔についても記載があります。「Redmine currently releases a new version every 6 months」。現在は6か月ごとに新しい版が出ています。確認日時点で公式サイトに並んでいる版は、6.0.11（2026-08-26）、6.1.4（2026-08-26）、7.0.1（2026-08-26）の3系統です。

この「3系統が並んでいる」という状態には意味があります。新しい版がひとつあるだけでなく、少し前の系統も更新が続いているということです。運用の側から見ると、必ずしも最新の系統に飛びつく必要はなく、いま使っている系統の修正版に上げるという選択肢があります。安定を優先するなら、これは扱いやすい形です。

その一方で、更新の判断と作業が自分たちの仕事として毎回発生します。月額のサービスなら、機能の追加も不具合の修正も、気づかないうちに反映されています。自分で建てて使う場合は、いつ上げるか、上げる前に何を確かめるか、上げたあとに動かなくなった機能はないかを、誰かが見る必要があります。

進行を預かる立場の人が特に気にすべきなのは、この作業の担当が明示されているかどうかです。よく聞くのは、構築した人が異動や退職でいなくなり、そのあと誰も版を上げられなくなるという話です。動いてはいるが、誰も中身を触れない状態で年単位が過ぎる。そうなってから移行を考えると、選択肢が減ります。建てる時点で、担当と手順を文書に残しておくことが、実質的な費用の一部だと考えたほうが安全です。

ガントチャートは標準機能。PNGにするならImageMagickが要る

工程表を引く必要があるチームにとって、ここは重要な確認点です。Redmineのガントチャートは標準機能です。公式トップページの主な機能一覧に「Gantt chart and calendar」が入っており、機能ページには「Gantt chart and calendar. Automatic gantt and calendar based on issues start and due dates」と書かれています。課題の開始日と期日をもとに、自動でガントとカレンダーが作られる、という説明です。追加のプラグインを入れないとガントが使えない、という記載は見当たりません。

何が表示されるのかも、ガントの説明ページに明記があります。「The gantt chart displays issues that have a start date and a due date or are assigned to a version with a date.」開始日と期日が入っている課題、または日付を持つバージョンに紐づいた課題が並びます。

この仕様は、運用に直接効きます。ガントに出したい作業は、開始日と期日を入れておく必要があります。逆に言えば、日付が入っていない課題は工程表に現れません。表計算の工程表なら、日付が曖昧なまま「だいたいこのへん」で線を引いておくことができます。Redmineのガントは課題の日付から自動で作られるので、線を引き直す作業は消える代わりに、日付を入れる作業が全員の側に発生します。

工程表を1人が引き直している間、他の人はその表を見られません。この問題は自動で作られる形にすると解けます。ただし、入力する人が増えないと、工程表はすぐ嘘になります。道具を入れる話より、入れたあとにチームが日付を入れ続けてくれるかのほうが、実は難しい部分です。

書き出しについても押さえておきます。ガントはPNG画像に書き出せますが、そのためにImageMagickが必要です。公式の任意コンポーネントの説明に「ImageMagick (to enable Gantt export to PNG image and thumbnails generation).」とあります。会議資料や報告書に工程表の画像を貼る運用を想定しているなら、構築の時点でImageMagickを入れておきます。

表示件数にも設定があります。管理画面に「Maximum number of items displayed on the gantt chart」という項目があり、ガントに表示する項目の上限を決められます。案件が大きくなって課題が増えたときに、ここの値が効いてきます。

工程表そのものの引き方に迷いがあるなら、板の形で進行をまとめる道具が、どこまでを標準で持っているかを確かめておくと比較がしやすくなります。できることには、板と工程表をどう行き来する作りになっているかがまとめてあります。

権限とゲストの扱いは、役割の設計で決まる

社外の人を含めて進行を共有するなら、権限の作りは必ず確認する項目です。Redmineは、公式の機能一覧に「Flexible role based access control」と書かれているとおり、役割をもとにした権限管理の仕組みを持っています。

役割は組み合わさる

基本の考え方は2つの記載に集約されています。「Each member of a project has one or multiples Role(s)」つまり、プロジェクトの参加者はひとつ以上の役割を持ちます。そして「If a member has multiple roles in a project, the permissions applied to the member is the combination of all roles' permissions.」複数の役割を持っている場合、適用される権限はすべての役割の権限を合わせたものになります。

足し算になる、という点は運用上とても重要です。制限をかけたつもりで役割を追加すると、逆に権限が広がることがあります。「閲覧だけの役割」を追加しても、その人がすでに編集できる役割を持っていれば、編集できる状態は変わりません。権限を狭めたいときは、追加ではなく、持っている役割の側を見直す必要があります。

権限そのものは、役割の編集画面で決めます。プロジェクト管理、課題追跡、Wiki、フォーラム、リポジトリ、作業時間といった区分ごとに、個別の操作にチェックを入れていく形です。細かく決められる代わりに、決める項目が多いということでもあります。人数が少ないうちは、まず標準の役割のまま使って、困ったところだけ触るのが現実的です。

社外の人とログインしていない人の扱い

「ゲストアカウント」という名前の機能についての記載は、公開資料では確認できませんでした。代わりに、特別な役割が2つ用意されています。

ひとつが Non member です。「Non member: this role lets you define the permissions that a registered user has on projects which he is not a member of.」登録はしているが、そのプロジェクトの参加者ではない人に対する権限を決める役割です。

もうひとつが Anonymous です。「Anonymous: this role lets you define the permissions that anonymous users have on the projects.」ログインしていない人に対する権限を決める役割になります。

この2つには重要な適用範囲の条件が付きます。「Note that these two roles only apply to public projects since anonymous users and users who are not a member of a private project cannot even see it.」公開のプロジェクトにしか適用されません。非公開のプロジェクトは、ログインしていない人にも、参加者でない人にも、そもそも見えないためです。

さらに注意点が2つあります。ひとつは、これらの役割の権限がインストール単位で共通だということです。「the permissions of these roles are global for a given Redmine installation」「you cannot adapt Anonymous and Non member roles in a way, that non-members are allowed to create board-messages in one project, but are forbidden to do so in another project.」あるプロジェクトでは参加者以外の書き込みを許し、別のプロジェクトでは禁じる、という分け方はできません。案件ごとに社外の人の扱いを変えたい場合は、この制約が効いてきます。もうひとつは、与えられない権限があることです。「Some permissions cannot be given to these roles. For example, the 'Manage members' permission cannot be given to non member or anonymous users.」参加者の管理といった権限は、これらの役割には渡せません。

認証まわりでは、「Multiple LDAP authentication support」として複数のLDAP認証に対応していること、「User self-registration support」として利用者が自分で登録できることが機能一覧に挙がっています。自己登録には3つの有効化の方法があり、確認を要さない自動、管理者による手動、メールで送られる自動生成のURLを使う方法から選べます。社外の人を含める運用では、この設定を誤ると意図しない人が入れる状態になります。構築の直後に必ず確認する項目です。

社外の人にどこまで見せるかという話は、道具の選定でつまずきやすい点でもあります。考え方を整理したページもあるので、社内の情報の扱いを決めるときの下敷きにできます。安全性の考え方には、誰にどこまで見せるかをどう区切るかがまとめてあります。

日本語で使える。ただし翻訳の鮮度には断りがある

日本語で使えるかどうかは、チームに導入する際の実務的な条件です。公式の機能ページには「Multilanguage support. Thanks to many contributors, Redmine is available in the following forty-nine languages:」として49言語が列挙されており、そのなかに「Japanese (日本語)」が含まれています。列挙されている言語には、英語、フランス語、ドイツ語、韓国語、簡体字と繁体字の中国語、ロシア語などが並びます。

言語の設定は管理画面で行います。既定の言語について、「Default language: The default language is selected when the application could not determine the user's browser language. The default language is also used when sending email to multiple users. Default: English」という記載があります。利用者のブラウザの言語が判別できなかったときに使われる言語で、複数人にメールを送るときにも使われます。既定値は英語です。日本語のチームで使うなら、ここは最初に変える設定になります。

強制する設定も2つあります。「Force default language for anonymous users: Disables automatic language detection based on browser setting and force default language for anonymous users.」ログインしていない人に対して、ブラウザ設定による自動判別をやめて既定の言語を強制する設定です。もうひとつが「Force default language for logged-in users: Disables "Language" setting on My account page and force default language for logged-in users.」で、ログインしている人の個人設定から言語の項目を外し、既定の言語を強制します。表示を全員で揃えたい場合に使う設定です。

ドキュメントについても押さえておきます。公式ドキュメント（Redmine guide）には日本語訳があります。ただし「Note that the following translations may not be up to date. Please refer to the original English documentation if needed.」という断り書きが付いています。翻訳が最新でない場合があるので、必要なら英語の原文を参照してほしい、という内容です。

これが運用にどう効くかというと、込み入った問題にぶつかったときの調べ物が英語になる可能性があるということです。画面が日本語で使えることと、困ったときの情報が日本語で手に入ることは別の話です。社内に英語の技術文書を読める人がいるかどうかは、構築の担当を決めるときに一緒に確かめておく項目になります。

データの出し入れとバックアップ

道具を選ぶときに最後まで見落とされやすいのが、入れたデータをどう出せるかです。ここが分からないまま数年使うと、移すときにも、報告書を作るときにも困ります。

書き出しはCSVとPDFとAtom、そしてガントのPNG

管理設定に「Issues export limit: Maximum number of issues contained in CSV and PDF exports. Default: 500」という項目があります。CSVとPDFの書き出しに含まれる課題の最大件数で、既定値は500件です。この記載から、課題のCSV書き出しとPDF書き出しが標準機能として備わっていることが分かります。

既定値が500件という点は、実務で意識しておく価値があります。案件が積み上がって課題が数千件になったとき、そのまま書き出そうとすると途中で切れます。全件を扱いたいなら設定を上げるか、絞り込んでから書き出す運用にします。

Atomフィードも出せます。「Maximum number of items in Atom feeds: Maximum number of records contained in Atom feeds.」という設定があり、フィードに含める件数の上限を決められます。ガントのPNG書き出しについては先に触れたとおりで、ImageMagickが要ります。

取り込みはCSVから。親子関係の書き方に癖がある

取り込みについては、「Since 3.2.0 Redmine can import issues from CSV files.」という記載があります。3.2.0以降、CSVファイルから課題を取り込めます。

手順も公式に書かれています。「In the issues tab there is a import link on the right. You can import any CSV-type file. The first line must contain the column names. You can freely assign them to the different fields of an issue.」課題のタブの右側に取り込みのリンクがあり、CSV形式のファイルを取り込めます。1行目に列の名前が必要で、その列を課題のどの項目に当てるかは自由に割り当てられます。

親子関係の指定には独特の書き方があります。「When importing issues, the content of a the parent colum can be: a number without # (eg: 10) => the parent will be the 10th imported issue / a number with # (eg: #10) => the parent will be the existing issue with id=10」。親の列に井桁なしの数字（例: 10）を書くと、取り込むファイルのなかで10番目の課題が親になります。井桁付きの数字（例: #10）を書くと、すでに存在するID 10の課題が親になります。

この違いは、移行の作業で事故が起きやすい箇所です。表計算で作った一覧をそのまま取り込むときに、この2つを取り違えると、まったく違う課題にぶら下がります。件数が多いほど、あとから直すのが大変になります。少数で試してから本番の取り込みに進むのが安全です。

移行そのものについては、公式ガイドに「Migrating from other systems」の章があります。他のシステムから移す場合は、まずここを確認します。

なお、道具を移すときに何が持っていけて何が持っていけないかは、移行の作業量をほぼ決めてしまいます。板の形でまとめる道具の側でも、自動で取り込める範囲は限られており、自動での取り込みに対応しているのはTrelloだけです。ほかの道具からはCSVを介して持っていく形になります。Trelloからの移行には、その手順と、何が引き継がれるのかが書かれています。

APIはXMLとJSONの両方に対応する

外部の仕組みとつなぎたい場合はREST APIを使います。「The API supports both XML and JSON formats.」とあり、XMLとJSONの両方の形式に対応しています。

対象になる資源は幅広く、Issues、Projects、Users、Time Entries、News、Project Memberships、Issue Relations、Versions、Wiki Pages、Queries、Attachments、Issue Statuses、Trackers、Enumerations、Issue Categories、Roles、Groups、Custom Fields、Search、Files、My Account、Journalsなどが並びます。資源ごとに安定度が表で示されており、Stableと書かれているものは仕様が固まっています。

自分たちで建てて使う道具である以上、つなぎ込みも自分たちで書くことになります。書ける人がいるチームにとっては自由度が高く、いない場合は使わない機能になります。ここも、体制次第で価値がまったく変わる項目です。

バックアップは自分たちの仕事になる

公式のインストール手順には「Backups」の節があり、公式ガイドには「Backing up and restoring Redmine」の章があります。手順は用意されています。

用意されているということは、実行するのは自分たちだということでもあります。月額のサービスなら、バックアップは事業者の側で行われています。自分で建てて使う場合は、いつ取るか、どこに置くか、戻せる状態かを定期的に確かめるところまでが自分たちの担当です。

進行を預かる立場から見て、ここは最も確認しておくべき項目です。バックアップを取る設定をしただけで安心してしまい、実際に戻せるか試したことがない、という状態はよくあります。年に一度でよいので、別の場所に戻してみて開けることを確かめておくと、本当に必要になったときの結果が変わります。

建てる前に決めておきたい、5つのこと

Redmineを入れるかどうかの判断は、機能の比較ではなく、次の5つに答えられるかで決まります。答えが出ないまま構築を始めると、動き出したあとで詰まります。

1つ目は、置き場所です。自社の機械に置くのか、借りるサーバーに置くのか。社外からもアクセスするなら、その経路をどう守るのかまで含めて決めます。

2つ目は、部品の版です。Rubyの版とデータベースの種類を、使うRedmineの版の対応表に合わせて決めます。既存のサーバーに載せるなら、そこに必要な版を入れられるかを先に確かめます。

3つ目は、任意で入れるものの取捨です。ガントをPNGで書き出したいならImageMagick、PDFの縮小画像が要るならGhostscript、Officeの文書を画面で下見したいならPandoc。あとから足すこともできますが、使い始めてから「この機能だけ動かない」と気づくより、先に決めておくほうが手戻りがありません。

4つ目は、更新の担当です。6か月ごとに新しい版が出るという前提で、誰がいつ上げるのかを決めます。その人が抜けたときに引き継げるよう、手順を文書に残すところまでを含めます。

5つ目は、入力を続ける仕組みです。ここは道具の話ではなく運用の話ですが、実際に成否を分けるのはここです。ガントは課題の日付から自動で作られるので、日付が入らなければ工程表は空のままです。入力する人が増えないと、進捗の表はすぐ嘘になります。誰が、いつ、何を更新するのかを最初に決めておきます。

この5つのうち、1つ目から4つ目までは技術の話で、答えられる人がいれば解けます。5つ目だけは、どの道具を選んでも残ります。道具を替えても、入力の習慣は自動的には付きません。

板の形でまとめる道具と、自分で建てる道具は、どこで分かれるか

ここまで見てきた内容を、選択の軸として整理します。この記事を読んでいる人の多くは、Redmineだけを見ているのではなく、いくつかの道具を並べて迷っている状態にあります。

分かれ目は、機能の多さではありません。どこまでを自分たちの仕事にするか、という点です。Redmineは、置き場所も、部品の版も、更新も、バックアップも自分たちの担当になります。その代わり、料金表の枠に縛られず、席数の制約もなく、データは自分たちの手元にあります。事業者が用意したサービスは逆で、運用は任せられる代わりに、決められる範囲は事業者が用意した枠の中に収まります。

もうひとつの軸は、項目の多さです。Redmineの課題は、担当者、開始日、期日、優先度、種別、状態といった項目を持ち、役割ごとに細かく権限を決められます。記録の質を揃えるには効きますが、決めることも増えます。板に付箋を並べる形の道具は逆で、決めることが少ない代わりに、記録の形は自分たちで揃える必要があります。

板の形でまとめる道具の側で言うと、区切り方の考え方が違います。機能で絞らず、区切るのは人数とボードの数だけという作りにすると、料金のプランを上げないと使えない機能を気にせずに済みます。その代わり、正直に書いておくと、できないこともはっきりしています。ソースコードのリポジトリを持つ機能はありません。自動化や外部サービスとの連携で勝負する作りにもしていません。画面は日本語のみです。自動で取り込めるのはTrelloだけで、ほかの道具からはCSVを介することになります。

こうした違いは、いま使っている道具からどう見えるかで確かめるのが早くなります。付箋を並べる形の道具から工程表が要る段階に来ているなら、Trelloとの比較に、板の形を保ったまま工程表を持つとどうなるかがまとめてあります。作業の割り当てと期限の管理を軸に見ているなら、Asanaとの比較で、機能の幅と使い続けやすさのどちらを取るかを整理できます。

文書と台帳を一体で持つ道具を使っていて、進行の把握だけが弱いと感じているなら、Notionとの比較に、自由度の高さと運用の負担の関係が書かれています。表の形で持つ道具から移ることを考えているなら、monday.comとの比較で、項目の多さが日々の入力にどう効くかを確かめられます。

国内の道具と並べているなら、Backlogとの比較に、開発の現場に寄せた作りと、進行のとりまとめに寄せた作りの違いがまとめてあります。板の形で日本語の道具を探しているなら、Jootoとの比較で、無料の範囲と有料に移る境目の考え方を比べられます。

判断を急ぐ必要はありません。確かめておくべきなのは、いま詰まっているのが道具の機能不足なのか、それとも入力が続かないことなのか、という切り分けです。機能不足なら道具を替えると解けます。入力が続かないのであれば、どの道具に替えても同じ結果になります。その場合に効くのは、決めることを減らすことと、更新の手間を軽くすることです。

導入前によく出る疑問については、まとめてあるページも用意されています。人数の数え方、社外の人の扱い、データの持ち出しなど、契約の前に確かめておきたい項目が並んでいます。よくある質問を先に読んでおくと、社内で説明するときの材料になります。

自分で建てて使うという選択は、体制がある人にとっては強い選択肢です。ライセンス料が要らないことは事実で、席数の制約がないことも事実です。同時に、その分の仕事が自分たちの側に移ることも事実です。両方を並べたうえで、どちらの手間なら続けられるかで決めるのが、最も外れにくい判断になります。

Q1. Redmineは本当に無料で使えますか？

ソフトウェアはGPL v2で公開されており、ライセンス料は要りません。公式サイトに価格表も存在しません。ただし無料なのはライセンス料だけで、サーバーの費用、構築する人の時間、半年ごとの版の更新やバックアップを続ける手間は別に発生します。運用を担う人が社内にいるかどうかで、実質的な費用は大きく変わります。

Q2. 動かすのに何を用意すればよいですか？

サーバーと、Rubyと、データベースです。Unix系、Linux、macOS、WindowsのほとんどでRubyが使えれば動きます。Rubyの版は使うRedmineの版で決まり、7.0はRuby 3.2から4.0、6.1は3.2から3.4、6.0は3.1から3.3が対応です。データベースはPostgreSQL 14、MySQL 8.0から8.4、Microsoft SQL Server 2012以上、SQLite 3から選びます。PHPは要件に挙がっていません。

Q3. ガントチャートは標準で使えますか？

標準機能です。公式の機能一覧に「Gantt chart and calendar」が入っており、開始日と期日が入っている課題、または日付を持つバージョンに紐づいた課題が自動で並びます。プラグインが要るという記載は見当たりません。ただしPNG画像として書き出すにはImageMagickを別途入れる必要があり、管理画面にはガントの表示件数の上限を決める設定もあります。

Q4. 社外の人にはどこまで見せられますか？

登録済みで参加者ではない人向けのNon memberと、ログインしていない人向けのAnonymousという2つの特別な役割で決めます。ただし適用されるのは公開プロジェクトだけで、非公開のプロジェクトは見えません。またこの2つの権限はインストール単位で共通なので、案件ごとに扱いを変えることはできません。参加者の管理など、渡せない権限もあります。