Redmineのガントチャートは標準機能｜運用に要る手間まで見る
「redmine ガントチャート」で検索する人の多くは、まず「別途プラグインを入れないと工程表は出せないのか」を確かめようとしています。結論から書くと、Redmineのガントチャートは追加のプラグインを入れなくても使える標準の機能です。公式サイトの機能一覧に最初から並んでおり、課題に入れた開始日と期日から線が自動で引かれます。ここで詰まる必要はありません。
ただし、工程表が出せるかどうかと、その工程表をチームで使い続けられるかどうかは、まったく別の話です。Redmineは自分でサーバーを用意して動かすソフトウェアなので、線を引く前に「どこに建てるか」を決める必要があり、線が引けたあとには「誰が動かし続けるか」という仕事が残ります。この記事では、公式サイトに書かれている内容だけを使って、ガントチャートの仕様と、それを支えるために要る手間の両方を順番に整理します。
なお、この記事に書いた版数・対応環境・設定項目は、すべて2026年9月2日時点で公式サイト（redmine.org）に掲載されていた記載を写したものです。ソフトウェアは更新されます。導入や更新の判断をするときは、必ずその時点の公式ドキュメントで確かめてください。
工程表の道具は「借りる」か「建てる」かで、かかる手間の種類が変わる
チームの人数が5人を超えたあたりから、進行のとりまとめをしている人のところに「全体の工程が見えない」という声が集まりはじめます。個々の作業は担当者が把握しているのに、全体としていつ何が終わるのかを言える人がいない。この状態を解消するために、多くのチームが工程表を引きます。
このとき選べる道具は、大きく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
この違いは、単に「月額がかかるかどうか」の違いではありません。かかる手間の種類が変わります。借りる形なら、動かし続ける仕事は事業者が持ちます。版の更新も、サーバーの面倒も、バックアップの基本的な部分も、こちらの仕事にはなりません。そのかわり、使える機能の範囲や上限は事業者が決めた枠の中に収まります。
建てる形なら、機能の範囲を自分たちで広げられます。RedmineはGPL v2で公開されており、公式サイトに価格表はありません。ソフトウェア自体の利用料という考え方がないので、席数に応じて月額が積み上がることもありません。そのかわり、動かし続ける仕事はすべて自分たちの側に来ます。サーバー、データベース、バックアップ、版の更新。これらは工程表を1本引くこととは無関係に、毎月発生し続けます。
進行を預かる立場からすると、判断すべきなのは「どちらが安いか」ではありません。3年なり5年なりの単位で見たときに、その手間を持てる人がチームの中にいるかどうかです。ここを見ないまま入れると、建てた本人が異動した時点で、誰も触れないサーバーの上に工程表が取り残されます。
Redmineのガントチャートは標準機能で、追加のプラグインは要らない
まず、検索する人が一番知りたいところから片付けます。Redmineの公式トップページに並んでいる主な機能の一覧には「Gantt chart and calendar」が入っています。機能ページにも同じ記載があり、ガントチャート専用の説明ページも用意されています。追加のプラグインを入れないとガントが使えない、という記載は公式資料には見当たりません。
つまり、Redmineを普通に導入すれば工程表は最初から使えます。ここで別売りの何かを探す必要はありません。
並ぶのは「開始日と期日が入っている課題」
Redmineのガントチャートは、白紙の画面に線を引いていく道具ではありません。すでに登録されている課題のうち、条件を満たすものが自動的に並びます。
The gantt chart displays issues that have a start date and a due date or are assigned to a version with a date. 出典: redmine.org
機能ページ側では「Automatic gantt and calendar based on issues start and due dates」と説明されています。開始日と期日が入っている課題、または日付を持つバージョンに紐づけられた課題が、自動的に線になるという作りです。
この仕様は、工程表の運用にとって決定的に重要です。表計算ソフトで引いた工程表が続かない最大の理由は、線と実際の作業がつながっていないことにあります。担当者が作業の締切を延ばしても、別ファイルにある工程表は勝手には動きません。誰かが手で引き直すまで、表は古いままです。
Redmineの作りでは、担当者が課題の期日を直せば、その課題の線が動きます。とりまとめる人が線を引き直す作業そのものが発生しません。これは、進行を預かっている立場から見て、非常に大きな利点です。
裏返すと、注意すべき点もはっきりします。開始日と期日が入っていない課題は、ガントチャートに出てきません。工程表に穴が空いているように見えるとき、多くの場合それはガントの不具合ではなく、課題に日付が入っていないだけです。工程表を運用に乗せたいなら、「課題を登録するときは開始日と期日を必ず入れる」という約束をチームで決めておく必要があります。ここが曖昧なままだと、工程表は自動で作られるのに、その工程表が全体を表していないという、いちばん厄介な状態になります。
PNGに書き出すにはImageMagickが要る
ガントチャートを画像として書き出す機能には、条件があります。公式のインストール手順で「任意で入れるもの」として挙げられている項目に、次の記載があります。
ImageMagick (to enable Gantt export to PNG image and thumbnails generation). 出典: redmine.org
ImageMagickは画像を扱うためのソフトウェアで、Redmine本体とは別に、サーバー側へ入れておくものです。これが入っていないと、ガントチャートをPNG画像として書き出す機能は有効になりません。あわせて、添付ファイルのサムネイル生成も同じImageMagickに依存します。
この点は、導入の段取りを組むときに見落とされがちです。工程表そのものは画面上でちゃんと表示されているので、動作確認の段階では問題なく見えます。ところが実際の運用に入って、進捗の報告資料に工程表を貼りたいとなった段階で、書き出しが使えないことに気づく。現場でしばしば起きるのがこのパターンです。
サーバーを用意する担当と、工程表を使う担当が別の人になっているチームでは、とくに注意が必要です。サーバー側の作業が終わったあとにImageMagickを追加するのは難しい作業ではありませんが、そのためにまた別の人へ依頼を出して、順番を待つことになります。導入を計画する段階で「ガントをPNGで書き出したい」という要望を先に拾っておき、最初のセットアップに含めておくほうが確実です。
なお、PDFで添付ファイルのサムネイルを出したい場合はGhostscriptが、Redmine 7.0以降でMicrosoft Officeの文書やLibreOffice Writerの文書のプレビューを出したい場合はPandocが、それぞれ任意で入れるものとして公式に挙げられています。Pandocについては「Version 3.8.3 or later is recommended」と版の目安まで書かれています。工程表そのものには関係しませんが、同じ「任意で入れるもの」の並びにあるため、導入時にまとめて検討しておくと二度手間になりません。
ガントに出す件数には上限の設定がある
管理画面の設定項目に「Maximum number of items displayed on the gantt chart」というものがあります。ガントチャートに表示する項目の最大数を決める設定です。公式の設定一覧では、この項目の説明本文が作成中の表記になっており、既定値についての具体的な記載は確認できませんでした。
同じ設定一覧には、書き出しの件数に関する項目もあります。
Issues export limit: Maximum number of issues contained in CSV and PDF exports. Default: 500 出典: redmine.org
課題をCSVやPDFに書き出すときの上限が、既定で500件という指定です。Atomフィードの件数にも同様の上限設定があります。
これらはいずれも管理画面から変更できる設定なので、「上限がある」ことそのものより、「上限があることを誰が知っているか」のほうが運用上は重要になります。課題が増えてきたチームで、工程表に出るはずのものが出ない、書き出したCSVの行数が足りない、といった相談が出たとき、まず疑うべきはこの設定です。管理画面を触れる人が1人もいない状態でRedmineを使い続けていると、こうした調整のたびに手が止まります。
建てる前に決めたことが、あとの手間をほぼ決める
Redmineを動かすには、サーバーの上に一式を組み上げる必要があります。ここで選んだ組み合わせが、そのあと何年も続く手間の量を決めます。
OSとRubyとRailsの組み合わせ
OSについては、公式インストール手順に幅のある書き方がされています。
Redmine should run on most Unix, Linux, macOS and Windows systems as long as Ruby is available on this platform. 出典: redmine.org
Rubyが動く環境であれば、たいていのOSで動くという説明です。実務では、社内で他のサーバーと同じOSに揃えておくほうが、あとの管理が楽になります。
Rubyの版については、Redmineの版ごとに対応が決まっています。公式の対応表では、Redmine 7.0が対応するRubyは3.2、3.3、3.4、4.0で、使用しているRailsは8.1。Redmine 6.1が対応するRubyは3.2、3.3、3.4で、Railsは7.2。Redmine 6.0が対応するRubyは3.1、3.2、3.3で、Railsは7.2とされています。あわせて「Redmine does not support JRuby.」と明記されています。
さらに、Rubyの版については注意書きが付いています。Ruby 4.0.0から4.0.3にはWikiの描画が大きく遅くなる問題があり、これはRuby側の不具合として4.0.4で修正されたため、Redmine 7.0はRuby 4.0.4以降で動かすことが推奨されています。
この対応表が意味するのは、Redmineを更新するときにRubyの版も一緒に見る必要がある、ということです。工程表の機能だけを見ていると忘れがちですが、実際の更新作業は「Redmineを上げる」だけでは終わりません。土台のRubyがその版に対応しているかを先に確かめ、必要なら土台側から手を入れることになります。
データベースはどれを選ぶか
Redmineはデータベースを選べます。公式の推奨として表に載っているのは、PostgreSQL 14、MySQL 8.0から8.4（Redmine 6.0の場合は8.0から8.1）、Microsoft SQL Serverの「2012 or higher」、そしてSQLite 3です。
ただしSQLite 3には、はっきりした但し書きが付いています。
SQLite 3 (not for multi-user production use!) 出典: redmine.org
複数人が使う本番環境には向かない、という警告です。試しに動かしてみるところまではSQLiteで足りますが、チームで実際に使う工程表を載せるなら、PostgreSQLかMySQLを選ぶことになります。
MySQLを選ぶ場合は、設定にひとつ条件があります。公式手順には「MySQL requires to change the transaction_isolation to READ COMMITTED in order to properly work」と書かれています。正しく動かすためにトランザクション分離レベルを変更する必要がある、という指定です。この一行を見落としたまま本番に入ると、原因のわかりにくい不具合として後から出てきます。
どのデータベースを選ぶかは、工程表の見た目にはまったく影響しません。影響するのは、バックアップの取り方、復旧の手順、そして何かあったときに相談できる人がチーム内にいるかどうかです。すでに社内で使い慣れているデータベースがあるなら、それに揃えるのが最も手間の少ない選び方になります。
Webサーバーと、あとから効いてくる任意の部品
インストール手順では、動作確認の方法としてPumaを使う例が示されています。「Test the installation by running Puma web server: bundle exec rails server -e production」という記載です。あわせて、Redmine本体が必要としないgemを読み込みたい場合は、Redmineのディレクトリ直下にGemfile.localというファイルを作る、という案内も書かれています。Pumaやfcgiがその例として挙がっています。
任意で入れるものの一覧には、ここまでに触れたImageMagick、Ghostscript、Pandocのほかに、次の2つが並んでいます。ひとつは「SCM binaries (eg. svn), for repository browsing (must be available in your PATH).」で、リポジトリを画面から閲覧したい場合に必要になるものです。もうひとつは「Sidekiq, recommended queue backend system for production environment.」で、本番環境で推奨される処理待ち行列の仕組みです。
これらは「任意」と書かれていますが、実際にチームで運用する段になると、入っているかどうかで使い勝手が変わります。工程表をPNGで出したいならImageMagick、本番で安定して動かしたいならSidekiq、という具合です。導入を計画するときは、必要な機能を先に洗い出してから、この一覧を上から順に確認していくのが確実です。
建てたあとに続く手間を、担当者ごと決めておく
ここからが、工程表の機能一覧には出てこない部分です。自分で建てる形の道具は、建てた日から動かし続ける仕事が始まります。
半年ごとに新しい版が出る
Redmineは定期的に新しい版が出ます。公式サイトには「Redmine currently releases a new version every 6 months」と書かれており、およそ6か月ごとに新しい版が出る前提で運用することになります。
実際、2026年8月26日付で6.0.11、6.1.4、7.0.1という3つの版が同じ日に公開されています。系統が複数並行して保守されている形です。
この更新のリズムをどう受けるかは、チームごとに決めることになります。毎回すぐに追いかけるのか、年に1回まとめて上げるのか、あるいは動いている限り触らないのか。どれを選んでも構いませんが、決めないまま放置するのが一番よくありません。放置された状態は「今の版で安定している」ではなく「誰も上げ方を知らない」に変わっていきます。
更新の作業には、Redmine本体だけでなく、対応するRubyの版、データベースの版、そして入れているプラグインの対応状況が絡みます。前の節で見たとおり、Redmineの版によって対応するRubyが違うため、本体を上げるときには土台も一緒に見る必要があります。この作業を年に1回か2回、確実にこなせる体制があるかどうかが、自分で建てる形を選べるかどうかの分かれ目です。
バックアップは自分で設計して、戻せることまで確かめる
公式のインストール手順には「Backups」という節があり、公式ガイドにも「Backing up and restoring Redmine」という章があります。手順そのものは公式に用意されているので、ゼロから考える必要はありません。
ただし、その手順を「いつ、誰が、どこへ」実行するかは、こちらで決めることになります。借りる形の道具なら、事業者側でデータの保全が行われます。建てる形の場合は、バックアップを取るのも、その保管先を用意するのも、自分たちの仕事です。
現場でよく聞くのは、バックアップを取る仕組みは組んだものの、戻す手順を一度も試していないという話です。これは工程表に限らず、自分で建てたシステム全般で起きます。取っているファイルが本当に復旧に使えるかどうかは、実際に別の環境へ戻してみるまで分かりません。年に1回でよいので、戻す訓練の日を工程表に載せておくくらいがちょうどよい扱いです。
工程表は、進行の記録そのものです。課題の履歴、日付の変更、誰がいつ何を決めたか。これらが消えると、進行の判断ができなくなります。線が引けることより、そのデータが確実に残ることのほうが、長い目で見れば重要です。
担当者を1人に寄せない
自分で建てる形の道具で最も起きやすい事故は、技術的な障害ではありません。担当者がいなくなることです。
導入するとき、たいていのチームでは技術に強い人が1人で立ち上げます。サーバーを用意し、Rubyを入れ、データベースを選び、Redmineを動かし、権限を設定する。この一連の作業を1人でやり切ると、そのあとの保守も自然にその人へ集まります。
問題は、その人が異動したり退職したりしたときです。工程表は動き続けているので、すぐには困りません。困りはじめるのは、更新が必要になったとき、設定を変えたくなったとき、そして何かが壊れたときです。
これを避ける方法は単純で、最初から2人以上で触れるようにしておくことです。加えて、次の3点を文書に残しておくと、引き継ぎのときに効きます。どのサーバーの、どこに、何の版が入っているか。バックアップはどこへ、どういう頻度で取っているか。管理画面に入れる人は誰か。
進行を預かる立場の人が、技術の担当者ではないケースも多くあります。その場合でも、この3点だけは把握しておいたほうがよいものです。工程表が止まったときに、誰に何を頼めばよいかが分かるからです。
工程表を社外に見せる段で効いてくる権限の話
工程表は、チームの中だけで完結しないことがよくあります。委託先に見せたい、発注元に共有したい、社内の別部署に進捗を出したい。こうした場面で効いてくるのが権限の設計です。
Redmineの機能一覧には「Flexible role based access control」が挙げられており、役割にもとづいて権限を決める仕組みになっています。公式の説明では「Each member of a project has one or multiples Role(s)」とされ、1人が複数の役割を持てます。複数の役割を持つ場合の扱いも明示されています。
If a member has multiple roles in a project, the permissions applied to the member is the combination of all roles' permissions. 出典: redmine.org
権限は役割の編集画面で決めます。プロジェクト管理、課題追跡、Wiki、フォーラム、リポジトリ、作業時間といった区分ごとに、個別の操作へチェックを入れていく形です。細かく決められるぶん、最初に方針を決めておかないと、役割が増えるたびに設定がばらついていきます。
ログインしていない人や、そのプロジェクトの参加者ではない人の扱いには、特別な役割が2つ用意されています。「Non member」は登録済みのユーザーが参加していないプロジェクトに対して持つ権限を、「Anonymous」は匿名のユーザーが持つ権限を、それぞれ決めるものです。
ただし、この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.」と書かれており、公開プロジェクトにのみ適用されます。非公開のプロジェクトは、そもそも見えません。
さらに重要な注意があります。「the permissions of these roles are global for a given Redmine installation」とされており、この2つの役割の権限は、そのRedmine全体で共通です。公式には「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.」ともあり、メンバー管理の権限のように、これらの役割には与えられない権限もあります。
「ゲストアカウント」という名前の機能についての記載は、公開資料では確認できませんでした。社外の人に工程表を見せたい場合は、この2つの特別な役割と、プロジェクトを公開にするかどうかの組み合わせで設計することになります。ここは導入前に方針を決めておくべき部分です。あとから「この委託先にだけ見せたい」という要望が出てきたとき、設計が全体共通の作りになっていると、対応の幅が限られます。
認証まわりでは、機能一覧に「Multiple LDAP authentication support」が挙げられており、社内の認証基盤と繋ぐ道が用意されています。利用者の自己登録にも対応しており、アカウントを有効にする方法として、確認なしの自動、管理者による手動、メールで送られる自動生成URLの3つが用意されています。社外の人を招く運用をするなら、どの方法にするかは先に決めておくところです。
日本語で使えるが、訳と原文の関係は知っておく
画面の日本語対応は問題ありません。公式の機能ページには多言語対応の説明があり、対応する49言語が列挙されています。その中に「Japanese (日本語)」が含まれています。
言語の設定は管理画面から行います。既定の言語を決める「Default language」という項目があり、利用者のブラウザの言語が判定できなかったときや、複数の利用者へまとめてメールを送るときに使われます。既定値は英語です。ここを日本語にしておかないと、通知メールが英語で届くことになります。
このほか、匿名ユーザーに対してブラウザ言語の自動判定を無効にして既定の言語を強制する設定と、ログイン済みの利用者に対して個人設定の言語欄そのものを無効にして既定の言語を強制する設定があります。社内で表記を統一したい場合に使う項目です。
ドキュメントについては、公式のガイドに日本語訳があります。ただし断り書きが付いています。
Note that the following translations may not be up to date. Please refer to the original English documentation if needed. 出典: redmine.org
訳が最新とは限らないので、必要なら英語の原文を参照してほしい、という案内です。日常の操作を調べるぶんには日本語のガイドで足りますが、更新の手順や設定の細かい部分を確認するときは、英語の原文にあたる場面が出てきます。運用の担当者を決めるとき、この点は考慮に入れておくとよいところです。
書き出し・取り込み・APIで、工程表の外に出す
工程表のデータを、Redmineの外で使いたい場面は必ず出てきます。報告資料に貼る、別のシステムに渡す、集計する。この経路が用意されているかどうかは、運用のしやすさに直結します。
書き出しについては、課題のCSV書き出しとPDF書き出しが標準にあります。前述のとおり、その件数の上限が管理設定の「Issues export limit」で既定500件と定められています。Atomフィードも出せます。そしてガントチャートはPNGに書き出せますが、これにはImageMagickが必要です。
取り込みについては、CSVからの取り込みが用意されています。公式には「Since 3.2.0 Redmine can import issues from CSV files.」とあり、課題の一覧画面の右側に取り込みのリンクがあると説明されています。CSVの1行目に列名を入れておき、それをRedmine側の項目へ自由に割り当てる形です。
親子関係の指定にも決まりがあります。親の列に「10」のように番号だけを書いた場合は、その取り込みの中で10番目にあたる課題が親になります。「#10」のように番号の前に記号を付けた場合は、すでに存在するID 10の課題が親になります。この違いを知らずに取り込むと、意図しない親子関係ができあがるため、最初の一度は少数の行で試したほうが安全です。
APIも用意されています。「The API supports both XML and JSON formats.」とされ、XMLとJSONの両方に対応します。対象となる資源は幅広く、課題、プロジェクト、ユーザー、作業時間、ニュース、プロジェクトの参加、課題の関連、バージョン、Wikiページ、クエリ、添付、課題のステータス、トラッカー、列挙値、課題のカテゴリ、ロール、グループ、カスタムフィールド、検索、ファイル、マイアカウント、ジャーナルなどが並びます。資源ごとに安定度が表で示されており、安定していると明示されているものとそうでないものが分かるようになっています。
他システムからの移行についても、公式ガイドに「Migrating from other systems」の章があります。すでに別の道具で課題を管理しているチームが移ってくる場合の入口です。
進行を預かる立場から見て押さえておきたいのは、この経路が「あるかどうか」よりも「使える人がいるかどうか」です。APIは強力ですが、使うには書ける人が必要です。CSVの書き出しなら、管理画面を触れる人であれば誰でも扱えます。チームの実情に合わせて、どの経路を常用するかを決めておくと、月末の集計のたびに特定の人へ依頼が集中する状況を避けられます。
工程表が嘘になるのは、たいてい道具のせいではない
ここまで見てきたとおり、Redmineのガントチャートは標準機能で、課題の日付から自動で線が引かれます。手で引き直す作業が要らないという点で、表計算ソフトで工程表を管理している状態から見れば、はっきりした改善です。
それでも、工程表が実態とずれていく現象は起きます。ずれる原因は、ほとんどの場合、道具の側にはありません。
第一の原因は、課題に日付が入らないことです。ガントに並ぶのは開始日と期日を持つ課題だけなので、日付を入れる習慣がないチームでは、工程表に半分しか出てきません。半分しか出ていない表は、見た人に「全体が見えている」という誤解を与えるぶん、何も無いより危険です。
第二の原因は、課題を作る人が限られていることです。とりまとめる人が全員分の課題を代わりに登録している状態では、その人の手が空いていない期間、工程表の更新が止まります。入力する人が増えないと、進捗の表はすぐ嘘になります。
第三の原因は、更新の負担が担当者にとって重すぎることです。1つの課題を進めるのに、必須の入力項目が多く、画面の行き来が必要で、どこを触ればよいか分かりにくいと、更新は後回しになります。後回しにされた更新は、まとめて週末に入力されるか、そのまま忘れられます。
この3つは、どの道具に替えても付いてきます。工程表の道具を選び直すとき、機能の一覧を比べるより先に確かめるべきなのは、担当者が毎日そこを触るかどうかです。触られない場所に置かれた工程表は、どれだけ高機能でも実態を映しません。
Redmineは、課題管理として細かく作り込める道具です。トラッカー、ステータス、カスタムフィールド、ワークフローを設計すれば、自分たちの仕事の流れにかなり近い形にできます。この作り込みができることは強みですが、同時に、作り込みすぎたときに入力の負担が増えるという側面も持ちます。どこまで細かくするかは、実際に入力する人の数と、その人たちが1日に触る回数から逆算して決めるのが現実的です。
Redmineのままがいい場合と、板型の道具を試す価値がある場合
比較の記事ではありますが、まず「Redmineのままがいい場合」を先に書きます。
ソースコードのリポジトリと課題を同じ場所で見たいチームは、Redmineのままがよいはずです。公式の任意コンポーネントにSCMのバイナリが挙げられているとおり、リポジトリの閲覧が本体に組み込まれています。これは開発チームにとって大きな価値です。
社内の認証基盤と繋いで、全社の利用者を一元管理したいチームも同様です。LDAP認証への対応が機能一覧に明示されており、この経路が要る組織では代えがききません。
課題の種類や進行の流れを、自分たちの業務に合わせて細かく設計したいチームも、Redmineの作り込みやすさが効きます。そして、サーバーを持っていて、Ruby環境の面倒を見られる人がチームの中に複数いるなら、動かし続ける手間は実質的に既存の運用に吸収されます。この条件が揃っているなら、乗り換える理由はほとんどありません。
一方で、検討する価値があるのは次のような場合です。工程表を見たいだけなのに、サーバーの用意から始めなければならない。建てたあとの版の更新やバックアップを持てる人が1人しかいない、あるいはいない。開発チームではないので、リポジトリの機能を使う予定がまったくない。そして何より、細かい設定より先に、まずチーム全員が毎日開いてくれる場所がほしい。
こういう場合は、ボード型の道具を一度並べて見比べる価値があります。板の上にカードを並べて、全員がそこを触る形にすると、更新の心理的な負担が下がります。工程表は、その板の上のデータから見る形になります。
比較の材料として、それぞれの道具の特徴を整理したページがあります。カードを並べる形の代表的な道具についてはTrelloとの比較に、大きな組織向けに作られた道具についてはAsanaとの比較とmonday.comとの比較にまとめています。文書と表を自由に組み合わせる形の道具についてはNotionとの比較、国産で課題管理と工程表を1つにまとめている道具についてはBacklogとの比較とJootoとの比較が近い話です。どれを見ればよいか決めかねる場合は、比較の一覧から入るのが早道です。
道具を選び直すときに、実際に見るべき情報の集め方
最後に、比較の進め方そのものについて整理します。工程表の道具を選び直すとき、判断材料の大半は「機能があるかどうか」ではなく、「その機能を使い続けるのに何が要るか」に集まります。
確かめる順番は、次のようにすると漏れが出にくくなります。まず、工程表を毎日見る人と、毎日更新する人が、それぞれ何人いるかを数えます。次に、その人たちが工程表以外に何を使っているかを書き出します。チャット、表計算ソフト、ファイル共有。ここに散らばっているものが多いほど、道具を1つ増やしたときに更新が止まりやすくなります。そして最後に、動かし続ける手間を持てる人が何人いるかを数えます。ここが1人以下なら、建てる形は選ばないほうが無難です。
料金の考え方も、先に決めておくと迷いが減ります。機能ごとにプランが分かれている料金体系では、「工程表を見るために上のプランへ上がる」という判断が定期的に発生します。これに対して、機能で絞らず、区切るのは人数とボードの数だけという組み立てなら、その判断そのものが起きません。区切り方を人数と板の数だけにしている料金の考え方は料金に、板の上でできることの範囲はできることにまとめてあります。
同時に、こちらの弱いところも先に書いておきます。リポジトリの機能はありません。Redmineが標準で持っているリポジトリ閲覧にあたるものは用意していないので、ソースコードと課題を同じ場所で管理したいチームには向きません。自動化と外部サービス連携の広さで勝負するつくりでもありません。画面は日本語のみです。データを自動で取り込めるのは今のところTrelloだけで、その手順はTrelloからの移行に書いてあります。Redmineから移す場合は、標準のCSV書き出しを使って手作業で移すことになります。合わないと分かっているものを勧めても、誰の得にもなりません。
預かっているデータをどう扱うかの考え方は安全性の考え方に、細かい疑問への回答はよくある質問にまとめています。自分で建てる形から借りる形へ移るとき、いちばん気になるのはこの部分のはずなので、先に目を通しておくことをおすすめします。
もうひとつ、比較を進めるときの実務的なコツがあります。候補の道具を、進行のとりまとめをしている人だけで評価しないことです。工程表がずれる原因の大半は、更新する側の負担にあります。実際に毎日課題を触る担当者を2人か3人選んで、1週間だけ実際の仕事を載せてみると、機能の一覧を眺めているだけでは分からないことが出てきます。入力の項目が多すぎる、画面の移動が多い、通知が届かない。こうした点は、使ってみないと見えません。
そして、この記事に書いたRedmineの仕様は、いずれも2026年9月2日時点で公式サイトに掲載されていた記載にもとづくものです。およそ6か月ごとに新しい版が出るソフトウェアなので、対応するRubyの版も、任意で入れるものの一覧も、これから変わります。導入や更新を実際に決めるときは、その時点のRedmine公式のドキュメントを必ず確認してください。工程表を1本引くことより、その工程表を3年後も同じ場所で見られるようにしておくことのほうが、進行を預かる立場にとっては価値があります。
Q1. Redmineでガントチャートを使うにはプラグインが必要ですか？
必要ありません。公式サイトの機能一覧に「Gantt chart and calendar」が標準機能として掲載されており、専用の説明ページも用意されています。プラグインを入れないとガントが使えないという記載は、公開資料では確認できませんでした。課題に開始日と期日を入れれば自動で線が引かれます。
Q2. ガントチャートに課題が表示されないのはなぜですか？
ガントに並ぶのは、開始日と期日が入っている課題、または日付を持つバージョンに紐づいた課題だけです。日付が入っていない課題は表示されません。あわせて、管理画面に「Maximum number of items displayed on the gantt chart」という表示件数の設定項目があるため、件数が多い場合はこの設定も確認してください。
Q3. ガントチャートを画像で書き出すのに必要なものは何ですか？
ImageMagickが必要です。公式のインストール手順では任意で入れるものとして「ImageMagick (to enable Gantt export to PNG image and thumbnails generation).」と記載されています。サーバー側に入っていないとPNG書き出しは有効になりません。導入時のセットアップに含めておくと後の手戻りを防げます。
Q4. Redmineを導入したあと、継続的にかかる手間は何ですか？
公式サイトにはおよそ6か月ごとに新しい版が出ると記載されており、版の更新が定期的に発生します。Redmineの版ごとに対応するRubyが異なるため、更新時は土台側も確認が必要です。あわせてバックアップの実行と復旧の確認、管理画面を触れる担当者の確保が続く作業になります。