Redmineで足りない部分をどう補うか｜プラグインと併用と乗り換えの境目
プロジェクト管理 ツール redmine で検索する人には、大きく2つの層があります。1つはこれから導入を検討している層、もう1つはすでに何年も使っていて、あと少し足りないと感じている層です。後者のほうが圧倒的に多く、そして悩みが具体的です。
足りないと感じる部分は人によって違います。画面が固くて新しく入った人が使ってくれない、工程表は出るが編集ができない、外部の協力会社を招くたびにアカウントの発行が要る、サーバーの更新作業が誰か1人の頭の中にある、といった話が並びます。どれも道具そのものの欠陥ではなく、Redmineの設計思想と、いまのチームの使い方がずれてきたことの表れです。
この記事では、Redmineが標準で何を持っているかを公式の情報で数え直したうえで、足りない部分を補う手段を3つに分けて扱います。プラグインで埋める、運用で埋める、別の道具と併用する、の3つです。そして最後に、補うのをやめて移すべき境目がどこにあるかを整理します。
Redmineが標準で持っているものを、先に数え直す
補う話に入る前に、いま何を持っているかを正確に把握しておかないと、すでにある機能をプラグインで買い直すことになります。公式のFeaturesのページに挙げられている主な機能は次のとおりです。
・複数プロジェクトとサブプロジェクトの管理 ・役割ベースのアクセス制御。役割を自分で定義して権限を設定できる ・柔軟なチケット管理。ステータスとトラッカーを自分で定義でき、トラッカーと役割ごとにワークフローの遷移を設定できる ・ガントチャートとカレンダー ・作業時間の記録。プロジェクト単位でもチケット単位でも入力できる ・カスタムフィールド。テキスト、日付、真偽値、整数、ドロップダウン、チェックボックスの形式が使える ・ニュース、文書、ファイルの管理 ・プロジェクトごとのWikiとフォーラム ・リポジトリのブラウザと差分の表示 ・Atomフィードとメール通知 ・複数のLDAP認証 ・ユーザーの自己登録
ガントチャートについては、公式に次のように書かれています。
Automatic gantt and calendar based on issues start and due dates 出典: redmine.org
つまり工程表は、チケットに入っている開始日と期日から自動で描かれます。この設計が、後で触れる「線を直接ドラッグして動かせない」という感覚の元になっています。工程表そのものが編集の対象ではなく、チケットの日付の写し絵だからです。
リポジトリの連携は、Subversion、CVS、Mercurial、Bazaar、Gitに対応しています。ソースコードの変更をチケットに紐づけて追える点は、開発を抱えるチームにとって代えの利かない機能です。ここを使っているなら、他の道具への移行はそれだけで難しくなります。
多言語の対応は49言語です。データベースはMySQL、PostgreSQL、SQLiteが使えます。そしてRedmineはGNU General Public License v2のもとで公開されている、自分のサーバーに置いて使う道具です。ライセンス費用が発生しないことが最大の特徴で、同時に運用の責任を自分たちで持つという条件が付いてきます。
足りないと言われる部分は、だいたい4つに分かれる
現場で挙がる不満を並べると、性質の違う4つに分類できます。混ぜて考えると打ち手がぼやけるので、自分がどれに当たっているかを先に決めてください。
1つめは画面の見た目と操作感です。新しく入った人がチケットの作り方を覚えられない、必須の項目が多くて入力が止まる、といった話がここに入ります。RedmineのUIは長く堅実に作られてきた反面、最近の道具に慣れた人には情報の密度が高く見えます。ちなみに2026年7月に公開されたRedmine 7.0.0では、ヘッダーとナビゲーションの再設計が行われており、6.0と6.1から続くUIの刷新が継続していると公式に説明されています。バージョンが古いままなら、まず上げることが最初の打ち手になります。
2つめはビューの少なさです。チケットの一覧とガントチャートとカレンダーはありますが、付箋を横に並べて動かすカンバンの形は標準の機能としては用意されていません。作業の状態を視覚的に動かしたいという要求は、この形を指していることが多くなります。
3つめは工程表の扱いです。前述のとおりガントチャートはチケットの日付から自動で描かれるため、線を直接ドラッグして日程を組み替えるという操作は想定されていません。工程を引き直す作業が主業務になっている人にとっては、ここが不便に感じられます。
4つめは運用の重さです。自分のサーバーに置く道具なので、更新も、バックアップも、セキュリティの対応も自分たちの仕事になります。ここは機能ではなく体制の話で、プラグインでは埋まりません。
この4つのうち、1つめと2つめと3つめはプラグインや設定で補える余地があります。4つめだけは性質が違い、人の時間で払うか、外に出すかの二択になります。
プラグインで補う場合に、先に確かめること
Redmineには公式のプラグインの一覧が用意されていて、redmine.org のプラグイン一覧から探せます。評価の高いものにはカンバンの形を追加するもの、チェックリストを追加するもの、通知や集計を強化するものが並びます。無料で公開されているものも多く、目的の機能がすでに誰かの手で作られている確率は高いといえます。
ただし、入れる前に確かめる点が3つあります。
1つめは本体のバージョンへの追従です。プラグインは本体の内部の作りに依存するため、本体を上げた瞬間に動かなくなることがあります。Redmine 7.0.0ではRails 8への移行が行われました。フレームワークの大きな移行があると、追従できないプラグインが出ます。導入の前に、そのプラグインが直近1年以内に更新されているかを確認してください。更新が止まっているものを本番に入れると、本体のセキュリティ更新を当てられない状態に自分を追い込みます。
2つめは、そのプラグインが本当に問題を解いているかです。カンバンの表示を足しても、チケットを作る人が増えなければ板の上は空のままです。表示の形が足りないのか、入力する人が足りないのかを分けて考えてください。入力する人が増えないと、進捗の表はすぐ嘘になります。
3つめは、誰が面倒を見るかです。プラグインを入れた瞬間に、本体の更新のたびに動作確認をする仕事が生まれます。この仕事を引き受ける人を決めずに入れると、数年後に「怖くて上げられないサーバー」ができあがります。プラグインを3つ入れたら、更新のたびに3つ分の確認が必要になると考えてください。
補い方として現実的なのは、まず設定で何とかならないかを試すことです。トラッカーの数を減らす、必須の項目を減らす、既定のクエリを保存して各自の入口を作る、といった調整だけで、入力が止まる問題はかなり改善します。Redmineは既定でbug、feature、supportの3つのトラッカーを持ちますが、これをそのまま全社で使う必要はありません。自分たちの仕事の分け方に合わせて作り直すほうが、プラグインを増やすより効果が出ます。
自分たちで運用する重さを、時間で見積もる
Redmineの費用は、ライセンスの金額ではなく人の時間で発生します。この時間を見積もっておかないと、無料だと思っていた道具がいちばん高くつくことになります。
具体的な作業は、サーバーの用意、Rubyとデータベースの環境の維持、本体の更新、バックアップの取得と復旧の訓練、そしてセキュリティ対応です。このうち予定を立てにくいのがセキュリティ対応です。2026年8月26日には、7.0.1、6.1.4、6.0.11の3系統が同時に公開され、複数の脆弱性の修正が含まれていました。修正の内容には、APIのリクエストがユーザーのセッションに影響してセキュリティの方針を回避できる不具合や、Textileの整形機能を経由した保存型のスクリプト混入などが挙げられています。
こうした更新は、公開されたことを知った時点で当てる必要があります。つまり、月に1度の定例作業では足りず、公式のお知らせを追う担当が要るということです。この担当が1人しかいない状態は、その人が休んだ日にリスクが上がることを意味します。
見積もりの目安として、次の項目にかかる時間を年間で足してみてください。
・本体のマイナー更新の適用と動作確認。年に3回から5回程度 ・メジャーバージョンの移行。数年に1度、プラグインの入れ替えを含めて数日規模 ・バックアップの確認と復旧の訓練。年に1回は実際に戻してみる ・脆弱性の情報を追う時間。毎月の定期的な確認 ・利用者からの問い合わせ対応
これらを社内の人件費に換算すると、有料のサービスの年額を上回ることは珍しくありません。逆に、すでにサーバーを運用している部門があり、その体制の中に組み込めるなら、Redmineの費用対効果は非常に高くなります。判断は「無料かどうか」ではなく「その時間を出せるかどうか」で決まります。
工程表を補いたいときに、まず試すべき順番
足りないと感じる部分が工程表なら、打ち手には順番があります。いきなりプラグインを探すと、遠回りになります。
最初に確かめるのは、チケットに開始日と期日が入っているかです。ガントチャートは開始日と期日、またはバージョンに設定された日付をもとに描かれます。つまり日付が空のチケットは、そもそも図に出ません。工程表が薄く見える原因の大半は、機能ではなく入力です。期日だけ入れて開始日を空にしている運用も多く、この場合は線が細く見えます。
次に、バージョンを使っているかを確かめます。バージョンに日付を設定しておくと、そのバージョンに割り当てたチケットが工程表に並びます。開発の反復の単位でも、案件の区切りでも構いません。マイルストーンに相当する使い方ができるので、大きな区切りを図の上に置きたい場合はここを使います。
3つめが親子のチケットです。親のチケットの下に子を並べると、親の期間は子の期間から算出されます。作業を分解して積み上げる形の工程表は、この仕組みで作れます。分解の粒度は、1つの作業が2日から5日で終わる大きさが目安です。半日で終わるものまで子にすると、更新の手間が増えて誰も入れなくなります。
4つめが関連の設定です。先行するの関係を使うと、前の作業の終了日を動かしたときに、後ろの作業の日付も一緒に動きます。すべての作業をつなぐ必要はありません。遅れが本当に波及する箇所だけをつなぐと、図が読みやすいまま残ります。
ここまでやって、それでも図の上で直接組み替えたい、あるいは横に並べた板の形で見たい、という要求が残るなら、そこで初めてプラグインか別の道具の検討に入ります。順番を守ると、追加の道具を入れずに済む場合がかなりあります。
新しく入った人が使ってくれないときは、設定を疑う
導入から数年たったRedmineでいちばん多い相談が、これです。とりまとめる人は毎日開いているのに、他の人が開かない。開いてもチケットを作らない。結果として進捗はチャットと口頭に戻り、Redmineは過去の記録の置き場所になります。
この状態は、道具の問題として語られがちですが、設定の問題であることがほとんどです。順に確かめてください。
まず、チケットを作る画面に必須の項目がいくつあるかを数えます。トラッカー、件名、説明、担当者、優先度、開始日、期日、予定工数、対象バージョン、カテゴリ、そして独自に足したカスタムフィールド。これが全部必須になっていると、1件作るのに数分かかります。数分かかる作業は、忙しいときに飛ばされます。必須は件名と担当者と期日の3つに絞り、あとは任意にするだけで、作られる件数が変わります。
次に、トラッカーの数を数えます。既定ではbug、feature、supportの3つですが、運用の中で増やしていくと10を超えることがあります。作る側は毎回どれを選ぶか迷い、迷ったところで手が止まります。実際に使われているトラッカーを集計して、1年間で1件も作られていないものは無効にしてください。
3つめは、各自の入口です。Redmineは既定でプロジェクトの一覧から入る作りですが、担当者にとっての入口は「自分に割り当てられていて、まだ終わっていないもの」です。この条件でクエリを保存し、共有のクエリとして全員に見えるようにしておくと、開いた瞬間にやることが見えます。ここまでやってから使われないなら、それは設定ではなく運用の合意の問題です。
4つめは本体のバージョンです。2026年7月に公開されたRedmine 7.0.0では、ヘッダーとナビゲーションの再設計、右から左に読む言語への対応の改善などが行われ、122件の課題が取り込まれています。数年前のバージョンのまま使っている場合、いま見えている画面は最新の姿ではありません。
社外の協力会社を招くときに詰まる場所
もう1つ、補い方の相談が多いのが社外の人の扱いです。Redmineは役割ベースのアクセス制御を持ち、役割を自分で定義して権限を設定できます。仕組みとしては、社外の人だけに見せるプロジェクトを作り、閲覧と自分のチケットの更新だけを許す役割を割り当てれば実現できます。
詰まるのは仕組みではなく手順です。自分のサーバーに置いた道具なので、相手にアカウントを発行するのは自社の作業になります。案件ごとに数人ずつ招く運用だと、この発行と削除が積み上がります。退職や契約終了のあとにアカウントが残っているかどうかを定期的に見る仕事も付いてきます。
さらに、社外の人から見た障壁もあります。社内のネットワークからしか見えない場所に置いてある場合、相手は接続の手続きから始めることになります。そこまでして進捗を書いてくれる協力会社は多くありません。結局、社外とのやり取りだけメールとスプレッドシートに戻り、進行が2か所に分かれます。
打ち手は2つあります。1つは、社外の人が入るプロジェクトだけを外から見える場所に置き、認証を分ける構成にすること。もう1つは、社外が関わる進行の共有だけを別の板に出すことです。前者は運用の設計が要り、後者は道具が1つ増えます。どちらが軽いかは、社外の人が関わる案件の本数で決まります。年に数本なら前者、常時何本も走っているなら後者のほうが結果として楽になります。
判断のときに一緒に見ておきたいのが、招いた人の分だけ費用が増えるかどうかです。人数で課金する道具だと、閲覧しかしない相手にも単価が乗ります。ここは道具ごとに扱いがはっきり違うので、契約の前に必ず確かめてください。
移すと決めたときの、データの持ち出し方
補うのをやめて移すと決めた場合、最初に確かめるのはデータを外に出せるかどうかです。ここはRedmineの強い部分で、チケットの一覧はCSVで書き出せます。さらにデータベースを直接持っているため、必要なら任意の形で取り出せます。
ただし、出せることと、移せることは別です。移行で落ちやすいのは次の情報です。
・チケットに付いた添付ファイル。一覧のCSVには含まれないため、別に取り出す必要があります ・コメントの履歴。誰がいつ何を書いたかの記録は、移行先の形式に合わないと失われます ・チケット同士の関連。関連する、ブロックする、先行するといった関係は、移行先に同じ概念が無ければ再現できません ・作業時間の記録。集計の粒度が違うと数字が合わなくなります ・カスタムフィールドの値。移行先に同じ項目を作ってから移す必要があります
現実的な進め方は、全部を移さないことです。過去の記録はRedmineを読み取り専用で残し、新しい案件から新しい道具で始める形が、いちばん摩擦が少なくなります。全件の移行に何週間もかけたあげく、結局誰も過去のチケットを見なかった、という話は珍しくありません。
残す場合も、置きっぱなしにはできません。読み取り専用であっても、公開されている場所に置くならセキュリティの更新は当て続ける必要があります。社内からのみ見える場所に移す、あるいは一定期間後に静的な形で書き出して閉じる、といった出口を先に決めておいてください。
Redmineのままがよい場合を、先に置いておく
補う話をしてきましたが、次の条件に当てはまるなら、道具を変える理由はほとんどありません。
・ソースコードのリポジトリとチケットを紐づけて使っている。コミットからチケットを追える運用が回っている ・役割ごとの権限を細かく設計していて、その設計が業務のルールと結びついている ・チケットの数が数万件を超え、過去の記録が資産になっている ・サーバーを運用する体制が社内にあり、更新の作業が仕組みとして回っている ・ワークフローの遷移をトラッカーと役割ごとに設計しており、その通りに現場が動いている
とくに1つめは重い条件です。開発の記録とプロジェクトの記録が1か所にある状態は、他の道具では作りにくく、無理に分けると両方が中途半端になります。
チケットの関連の表現力も、他の道具ではあまり見ない部分です。関連する、重複する、ブロックする、先行する、複製元である、といった関係を選べて、先行するの関係では「Aが終わってからx日後にBを開始する」という形で日程が連動します。この連動を実際に使って工程を管理しているなら、移行は現実的ではありません。
一方で、これらのどれにも当てはまらず、実際にはチケットの一覧と期限の管理にしか使っていない、という状態も現場ではよくあります。導入したときの目的と、いまの使い方がずれているケースです。この場合は、いったん使い方を棚卸ししてから道具を考えるほうが順番として正しくなります。
補うのをやめて、別の道具と併用する境目
補うか移すかの判断は、次の1点で決まります。足りないと感じている部分が、開発の記録に関わるかどうかです。
リポジトリの連携、コミットとチケットの紐づけ、差分の表示に価値を感じているなら、そこはRedmineに残します。そのうえで、進行の共有だけを別の板に出すという併用の形が取れます。開発チームはRedmineでチケットを回し、営業や制作や外部の協力会社が関わる進行は板で共有する、という分け方です。
分けるときの原則は1つです。同じ作業を2か所に書かないことです。書いた瞬間に、どちらが正しいのか分からなくなります。境界の引き方としては、社外の人が見る必要があるものは板に、社内の開発の詳細はRedmineに、という分け方が運用しやすくなります。
板の側で必要になるのは、たいてい次の機能です。工程表が見られること、担当と期限が付けられること、外の人を招けること、そして画面が説明なしで分かることです。何ができて何ができないかはできることに一覧があります。工程表を見たいという理由だけで上位プランに移らずに済むかどうかは、料金の設計を見れば分かります。機能で段階を分けず、区切るのは人数とボードの数だけという形なら、この移動が起きません。実際の条件は料金で確かめてください。
他の道具と並べたときに、どこが違って見えるか
Redmineから見て、他の道具との差がいちばん出るのは、リポジトリの連携とライセンスの費用の2点です。この2つを手放してよいかどうかが、比較の前提になります。
板を横に並べる形の道具は、進行の共有を軽くすることに寄っています。Trelloの無料プランはワークスペースあたり10ボード、10コラボレーターまでで、カレンダーやタイムラインやテーブルのビューはPremium以上です。無料でどこまでできて、どこから有料になるかはTrelloとの比較に整理があります。
自動化と外部連携の幅を売りにしている道具もあります。ワークフローの自動化に時間を割ける体制があるなら、その方向に投資する判断も成り立ちます。それぞれの立ち位置はAsanaとの比較とmonday.comとの比較にまとめてあります。文書とデータベースを同じ場所に置きたい場合はNotionとの比較が判断材料になります。
国内のサービスは、いま前提が動いている時期です。Backlogは2026年12月31日で現行プランの新規契約が終了し、2027年1月1日から新しい3つのプランに移ります。フリープランのユーザー上限は10名から5名に変わります。詳細はBacklogとの比較にあります。Jootoは2027年7月31日で一般提供の終了が公式に告知されています。こちらはJootoとの比較を参照してください。各サービスの料金と上限を横並びで見たい場合は比較の一覧にまとめてあります。
併用や移行を決める前に、確かめておく3点
最後に、板の側を検討する場合に見ておく点を3つ挙げます。これはRedmineから見た「相手のできないこと」でもあります。
1つめは、リポジトリの機能を持たない道具が多いという点です。板をまとめる型の道具は、進行の共有に振り切っている代わりに、ソースコードの閲覧や差分の表示は持ちません。Redmineでこの機能を使っているなら、そこは残す前提で考えてください。
2つめは、自動化と外部連携の幅です。ここで勝負していない道具は、他のサービスとつなぐ仕組みが限られます。すでにRedmineをスクリプトで叩いて集計している場合、その仕組みは作り直しになります。
3つめは、取り込みの経路です。他のサービスから自動で移せる範囲は道具ごとに違い、Trelloからだけ自動で取り込める、という設計のものもあります。Redmineから移す場合は、CSVの書き出しと手作業の組み合わせになる前提で見積もってください。実際の手順はTrelloからの移行に書かれている形が参考になります。データの置き場所や権限の設計といった、社内の審査で必ず聞かれる論点は安全性の考え方に整理があります。契約や運用の細かい疑問はよくある質問にも並んでいます。
この3つを確かめる順番も決めておくと迷いません。まず自分たちが実際に使っている機能を洗い出し、次にそれが移行先にあるかを見て、最後に無い機能をどう代替するかを決めます。機能の一覧から入ると、どの道具にも足りない部分が見つかっていつまでも決まりません。
3つとも、優劣の話ではなく、何を残して何を出すかという設計の話です。Redmineは20年にわたって使われてきた道具で、2026年に7.0が公開されて開発も続いています。足りないと感じた部分だけを外に出して、残りはそのまま使い続けるという判断は、十分に現実的な選択肢です。
Q1. Redmineにカンバンボードの機能はありますか？
公式のFeaturesのページに挙げられている標準の機能は、チケットの一覧、ガントチャート、カレンダー、Wiki、フォーラム、リポジトリの閲覧などで、カンバンの形の記載は見当たりません。公式のプラグインの一覧には、カンバンの表示を追加するものが評価の高い順に並んでいます。導入する場合は、本体のバージョンに追従して更新されているかを先に確かめてください。
Q2. Redmineのガントチャートで、線をドラッグして日程を変えられますか？
公式には、ガントチャートはチケットの開始日と期日、またはバージョンに設定された日付をもとに自動で描かれると説明されています。つまり工程表はチケットの日付の写し絵で、図の側が入力欄ではありません。日程を変えるにはチケットの日付を直します。図の上で直接組み替える操作を主業務にしているなら、その用途に向いた道具を併用するほうが早くなります。
Q3. Redmineは無料と聞きましたが、本当に費用はかかりませんか？
Redmineは GNU General Public License v2 のもとで公開されており、ライセンスの費用はかかりません。ただし自分のサーバーに置いて使う道具なので、サーバーの費用と、更新やバックアップやセキュリティ対応にかかる人の時間が発生します。2026年8月26日にも複数の脆弱性を修正した更新が公開されており、公式のお知らせを追う担当が必要です。
Q4. Redmineと別の道具を併用する場合、どこで分ければよいですか？
同じ作業を2か所に書かないことが唯一の原則です。分け方としては、社外の人が見る必要がある進行は板に、社内の開発の詳細とリポジトリに紐づく記録はRedmineに、という形が運用しやすくなります。境界を決めたら、どちらを正とするかを1文にして全員に配ってください。この1文が無いまま併用を始めると、両方が信用されなくなります。