Redmineの使い方｜最初のプロジェクトをどう組み立てるか
Redmineの使い方を調べる人の多くは、画面の操作方法ではなく「最初にどう組み立てればチームが使い続けてくれるか」で迷っています。チケットを1件作る手順は5分で覚えられますが、トラッカーをいくつ用意するか、誰にどこまで見せるか、チケットをどの大きさで切るかは、後から変えると全員の手が止まります。この記事では、機能の一覧をなぞる代わりに、最初の1週間で決めておくべきことを順番に並べます。決める順番を間違えなければ、あとから足すのは難しくありません。
自分たちで持つ道具だという前提から始める
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 is open source and released under the terms of the GNU General Public License v2 (GPL). 出典: redmine.org
ここから読み取るべきことは3つあります。1つ目は、置き場所を自分たちで用意する必要があること。2つ目は、働き方に合わせて設定を変えられること。3つ目は、費用のかかり方が月額の利用料ではなく、サーバー代と手を動かす人の時間になることです。
必要なものは公式の導入手順に表として載っています。7.0系であればRuby 3.2から4.0、Rails 8.1、データベースはPostgreSQL 14、MySQLは8.0から8.4、Microsoft SQL Serverは2012より新しいもの、という組み合わせです。SQLiteも動きますが、公式の表には多人数での本番利用には向かないと明記されています。試しに一人で触るときと、チーム全員が同時に開くときで、選ぶべきものが変わります。
任意で入れるものも決まっています。ガントチャートをPNG画像で書き出したい場合はImageMagickが要ります。PDFの添付ファイルのサムネイルを出すならGhostscript、本番で動かすならSidekiqが推奨のキュー処理として案内されています。これらは後から足せますが、「ガント表を画像で共有したい」と言われてから慌てないよう、入れるかどうかを最初に決めておくと手戻りがありません。
とりまとめる立場で押さえるべきなのは、この初期構築を誰がやるかです。社内に情報システムの担当がいるなら相談先は明確ですが、いない場合は、動かし始めた人がそのまま保守の担当になります。導入を決める前に、その役目を引き受ける人がいるかどうかを確かめてください。ここが曖昧なまま始めた仕組みは、最初の更新作業で止まります。
最初に決める4つと、その順番
設定画面は項目が多く、上から順に埋めていくと迷います。決める順番は次の4つで固定してしまうのが早いです。
・プロジェクトをどの単位で切るか ・チケットの種類（トラッカー）をいくつ用意するか ・状態（ステータス）をいくつ並べるか ・誰にどの操作を許すか（ロール）
この順番には理由があります。プロジェクトの単位が決まらないと、そこに置くチケットの種類が決まりません。種類が決まらないと状態の並びが決まらず、状態が決まらないと「誰がどの状態に動かせるか」を定義できないからです。逆向きに進めると必ず作り直しになります。
プロジェクトの単位でよくある分け方は3つです。顧客ごと、案件ごと、社内の部署ごと。制作や受託の仕事なら案件ごとが素直で、社内の定常業務が中心なら部署や機能ごとが向きます。判断の基準は、「この単位で権限を分けたいか」です。Redmineの権限はプロジェクトに紐づくので、見せたくない相手がいる境目がそのままプロジェクトの境目になります。
親子の関係を作ることもできます。公式の説明では、プロジェクトは制限なく入れ子にできるとされています。ただし深くすると一覧が読みにくくなるので、実務では親1階層と子1階層、多くても2階層までにとどめている例が多いです。
プロジェクトの識別子だけは後から変えられない
作成画面で見落としやすいのが識別子です。公式の説明では、識別子はURLなどで使われ、一意である必要があり、数字だけでは作れず、そして1度作成すると変更できないと書かれています。
この項目だけは、あとから直せません。命名の決め方を先に置いてください。よく使われるのは、顧客の略称と年度と連番を組み合わせる形です。日本語の案件名をそのままローマ字にすると長くなり、URLを共有したときに折り返されて読みにくくなります。短く、他と重ならず、意味が分かる範囲で最小の文字数にするのが実用的です。
あわせて決めておきたいのが公開の設定です。公開にすると、そのプロジェクトはメンバーでない利用者からも見えます。社内向けの情報共有として全社に開くのか、案件ごとに閉じるのか。ここも後から変えられますが、変えた瞬間に見えていたものが見えなくなるので、混乱を避けるなら最初に決めておくほうが穏やかです。
もう1つ、プロジェクトごとにモジュールの有効と無効を切り替えられます。使わない機能の画面を最初から消しておくと、初めて開いた人の迷いが減ります。チケットと文書だけで足りるチームに、フォーラムやリポジトリの入口まで出す必要はありません。画面を減らすのは、教える手間を減らすことと同じです。
トラッカーとワークフローは最小で始める
トラッカーはチケットの種類です。既定では不具合や機能といった名前のものが用意されていて、種類ごとに次のことを決められます。名前、新規作成したときの既定の状態、ロードマップに表示するかどうか、使うワークフロー、そしてその種類で使える標準の項目と追加の項目です。
ここで起きがちなのが、種類を増やしすぎることです。「調査」「問い合わせ」「改善」「相談」と細かく分けると、登録する人が最初の選択で止まります。最初は2種類か3種類にとどめ、運用しながら「この種類だけ流れが明らかに違う」と分かった時点で足すほうが定着します。
種類を増やすと、そのぶんワークフローの定義も増えます。ワークフローは、種類と役割の組み合わせごとに「どの状態からどの状態へ動かしてよいか」を決めるものです。種類が4つ、役割が4つあれば、定義する組み合わせは16通りになります。新しい種類を作るときには既存の種類からワークフローを複製できる仕組みが用意されているので、ゼロから組む前にそちらを使ってください。
状態の数も同じ考え方です。状態は自由に追加と削除ができ、それぞれに「終了扱いにするかどうか」の設定があります。終了扱いの状態は複数持てるので、完了と却下を分けて集計したい場合はここで表現します。加えて、進捗率を状態から自動で計算する設定もあります。これを使うと、担当者が進捗の数字を手で入れる必要がなくなります。毎回の入力を1つ減らせる設定なので、最初に有効にするかどうかを検討する価値があります。
ロールは操作の許可より先に「見える範囲」を決める
ロールの設定で見落とされやすいのが、操作の可否ではなく可視性の設定です。公式の説明では、チケットの見え方に3つの選択肢があります。すべてのチケットが見える、非公開でないチケットと自分が作成または担当のものが見える、自分が作成または担当のものだけが見える、の3つです。既定は真ん中です。
同じように、作業時間の記録の見え方（すべて、または自分が記録したものだけ）と、利用者の見え方（すべての有効な利用者、または見えるプロジェクトのメンバーだけ）も選べます。外部の協力会社にアカウントを渡す場合、この3つの設定を先に確認しておかないと、渡すつもりのなかった情報まで見える状態になります。
権限は足し算で効きます。公式の説明では、1人が複数のロールを持つとき、適用される権限はすべてのロールの権限を合わせたものになります。さらに、同じ人でもプロジェクトごとに違うロールを持てます。「Aの案件では進行の担当、Bの案件では見るだけ」という割り当てが自然にできる設計です。
実務での落とし穴は、管理者権限を持つ人が少なすぎることです。トラッカーの追加、追加項目の定義、ワークフローの変更は、プロジェクトの担当者ではなく全体の管理者しか触れません。管理者が1人だけだと、その人が休んだ日に設定変更が止まります。かといって全員を管理者にすると、誰かが状態を1つ消しただけで全プロジェクトの流れが変わります。2人から3人を管理者にして、変更したら記録を残す。この程度の運用が現実的です。
チケットの粒度を先に決めておく
道具の設定より、実は定着を左右するのがチケットの大きさです。粒度が揃っていない板は、見た瞬間に何が起きているのか読めません。
決め方の目安として使いやすいのは、「1件が1人の担当で、3日以内に終わる大きさ」です。担当が複数人になる粒度だと、誰が動かすのか決まらず放置されます。2週間かかる粒度だと、状態が何日も変わらないので、進んでいるのか止まっているのかが外から見えません。
大きな仕事は親のチケットにして、実際に手を動かす単位を子で切ります。親には期日と目的を書き、子には作業を書く。この分け方だと、報告のときに親だけを並べれば全体像になり、日々の作業は子で追えます。
書き方の型も最初に決めてください。表題に何を書くか、本文に何を書くか、この2つだけで揃います。表題は「何をどうする」の形にして、名詞だけで終わらせない。本文には、決まっていること、決まっていないこと、次に動く人が誰かを書く。この3点が書かれていれば、他の人が引き取れます。型を1度示すと、以降は真似で揃っていきます。
ロードマップとガントを動かすにはバージョンが要る
Redmineの機能の一覧にはガントチャートとカレンダーが含まれています。ただし、入れただけで工程表ができるわけではありません。ロードマップの画面に何かを出すには、プロジェクトにバージョン（マイルストーン）を作り、そこにチケットを紐づける必要があります。加えて、そのトラッカーが「ロードマップに表示する」設定になっていることが条件です。
導入して1週間で「ロードマップに何も出ない」という声が出るのは、たいていこの3つのどれかが抜けています。バージョンを作っていない、チケットを紐づけていない、トラッカーの設定が外れている、のいずれかです。
バージョンの切り方は、案件の性質で変わります。納品日が決まっている受託の仕事なら、フェーズや納品の単位で切るのが素直です。継続的に手を入れる社内の仕組みなら、月単位や隔週単位で区切って、その期間に入れる分だけを紐づける形が回ります。どちらにしても、期日のないバージョンを作ると、ロードマップは並び順の意味を失います。
ガント画面は、チケットの開始日と期日をそのまま横棒にして表示します。つまり、日付が入っていないチケットはガントに現れません。工程表として使うつもりなら、日付の入力を必須にするかどうかを最初に決めてください。必須にすると入力の手間が増え、必須にしないと表が虫食いになります。どちらを取るかは、その表を誰が何のために見るかで決まります。社外に出す工程表なら必須にする価値がありますが、社内の把握だけなら期日だけでも足ります。
チケットどうしの関係で日程をつなぐ
Redmineには、チケットどうしを関連づける仕組みがあります。公式の説明で挙げられている関係は、単にリンクを張る「関連する」、片方を閉じるともう片方も閉じる「重複」、片方が開いている間はもう片方を閉じられない「ブロック」、そして順序を表す「先行」です。
工程の管理で効くのは、ブロックと先行の2つです。ブロックを設定しておくと、前提が終わっていないのに完了扱いにする操作を、道具の側が止めてくれます。人が気をつける代わりに仕組みが止めるので、確認の手間が減ります。
先行の関係は日付に連動します。公式の説明によれば、BがAに続く設定のとき、Bの開始日をAの終了日以下にはできません。さらに、Aの終了日を2日延ばすと、Bの開始日と終了日も2日ずれます。工程が押したときに、後ろのチケットを1件ずつ手で直す作業が消えるということです。
ただし、この連動は諸刃です。関係を張りすぎると、1件の遅れが連鎖して大量の日付が動き、何が起きたのか追えなくなります。実務では、必ず守る前後関係だけに絞って張るのが扱いやすいです。「なんとなく順番がある」程度のものは、関連づけずに並べておくほうが混乱しません。
通知は最初に絞る
導入直後に最も多く出る不満が、メールの多さです。既定のままだと、関係するチケットが動くたびに通知が飛びます。人数が増えるほど通知は増え、やがて全員がフォルダに振り分けて読まなくなります。読まれない通知は、無いのと同じどころか、大事な連絡まで埋めてしまいます。
最初に決めるべきは、「何が起きたときだけ知らせるか」です。実務でよく採られるのは、自分が担当のチケットが動いたときと、自分が明示的に関係者に追加されたときだけに絞る形です。すべての更新を受け取る設定にしてよいのは、全体を見る立場の1人か2人だけで足ります。
あわせて、チーム内の合意も要ります。急ぎの連絡はチャットで、記録はチケットで、という住み分けです。この線引きが無いと、「チケットに書いたのに見ていない」という言い争いが起きます。書く場所を分けるのではなく、急ぎかどうかで分けるのが実用的です。
通知を絞ると、今度は「動きに気づけない」という別の不安が出ます。ここを埋めるのは、通知を増やすことではなく、決まった時間に一覧を見る習慣です。朝に自分の担当分を開き、期日が近い順に並べて上から確認する。この3分の習慣がつくと、通知で追いかける必要はほぼ無くなります。とりまとめる立場の人は、期日を過ぎたチケットだけを抜き出した一覧を保存しておくと、週に1度そこを見るだけで抜けを拾えます。
なお、メールを送る設定そのものは全体の管理画面にあり、送信元のサーバーの情報を入れる必要があります。社内の送信サーバーを使うのか、外部の配信の仕組みを使うのかで、届き方が変わります。導入直後に「通知が1通も来ない」という相談の多くは、この設定が未完了か、送ったメールが迷惑メールとして振り分けられているかのどちらかです。
運用が止まる場所を先に知っておく
導入した仕組みが止まるとき、原因は道具ではなく運用の設計にあることがほとんどです。よく聞くのは次の4つです。
・登録する人が特定の1人に偏り、その人が忙しくなると板が更新されなくなる ・状態を動かすのが面倒で、終わった仕事が開いたまま残る ・必須項目が多く、思いついたことをその場で書けない ・見る人が別の資料（表計算ソフトの一覧など）を作り始め、二重管理になる
どれも、最初の設計で減らせます。1つ目は、登録できる人を増やして、書き方の型を配ることで和らぎます。2つ目には、状態の数を減らすことと、一覧から複数のチケットをまとめて更新できることを教えるのが効きます。3つ目は必須項目を見直せば済みます。
4つ目がいちばん厄介です。誰かが表計算ソフトに転記を始めたら、その人が板の見せ方に満足していない証拠です。理由を聞くと、たいてい「報告に必要な形で出せないから」です。表示する列の組み合わせを保存できる機能があるので、その人が欲しい形の一覧を作って渡してしまうのが早い対処になります。転記の習慣が根づく前に手を打つほうが、あとから止めるより楽です。
作業時間の記録をどこまで求めるか
Redmineには作業時間を記録する仕組みが標準で入っています。チケットに対して、何時間かけたかを日付ごとに残せます。受託の仕事で工数を根拠に請求する現場や、案件ごとの採算を後から振り返りたい現場では、この機能が導入の目的そのものになることもあります。
ただし、この記録は入力する人の手間を確実に増やします。チケットの状態を動かすだけなら1操作ですが、時間を残すとなると、いつ何にどれだけかけたかを思い出す作業が毎日発生します。1日の終わりにまとめて入れる運用にすると、記憶が曖昧なぶん数字が丸まり、集計しても実態と離れます。
導入するかどうかは、その数字を誰が何に使うかで決めてください。請求の根拠にするなら必須です。採算を見るためなら、案件の単位で大づかみに取れれば足りることも多く、チケット1件ごとの精度は要りません。逆に、集めた数字を誰も見ないまま入力だけ続いている状態がいちばん良くありません。入力する人はそれを敏感に察して、やがて適当な数字を入れるようになります。
ロールの設定では、作業時間の記録の見え方も選べます。すべての記録を見せるか、自分が記録したものだけを見せるかの2択です。個人ごとの作業時間は評価と結びつきやすい情報なので、外部の協力会社が入るプロジェクトでは、渡す前にこの設定を確かめておくのが安全です。
最初の2週間をどう進めるか
設定を完璧にしてから配ろうとすると、いつまでも配れません。実務で回っている進め方は、範囲を絞って先に動かす形です。
第1週は、1つの案件だけを対象にします。関わる人は3人から5人。トラッカーは2種類、状態は4つ程度にとどめ、必須項目は表題と担当だけにします。この段階の目的は、道具の善し悪しを測ることではなく、書き方の型を1つ作ることです。
第2週は、その案件で出た不満を拾います。「状態が足りない」「この項目が要る」「通知が多い」のどれかが必ず出ます。出たものだけを直して、他は触りません。ここで先回りして設定を増やすと、使う前の想像で作った項目が残り、あとで誰も埋めなくなります。
全体に配るのは3週目以降で十分です。そのとき配るのは設定の説明書ではなく、よく使う操作を5つだけ書いた1枚の手順にしてください。チケットを作る、担当を変える、状態を動かす、コメントを書く、自分の担当分を一覧で出す。この5つができれば、あとは触りながら覚えられます。分厚い手順書は、作る側の時間も読む側の時間も奪います。
更新の期限は自分たちで持つことになる
自分たちのサーバーで動かす道具は、更新の判断も自分たちに残ります。公式のダウンロードページには、どのバージョンがどこまで面倒を見てもらえるかが明記されています。
7.0.x Latest stable version. Fully supported with new features, bug fixes, and security updates. 6.1.x Latest stable version. It will receive only bug fixes and security updates. 6.0.x Legacy stable version. It will receive only important security updates. 5.1.x Unsupported. 出典: redmine.org
同じページには、公開の方針として、可能な範囲で細かい更新は3か月ごと、大きな更新は1年に1回、重大な不具合や安全上の修正はできるだけ早く出す、と書かれています。2026年8月26日には7.0.1を含む3系統が同じ日に公開されました。
とりまとめる立場で意味があるのは、この方針を運用の予定に落としておくことです。更新を1年放置すると、追いつくための作業がまとまった塊になり、業務の合間ではこなせなくなります。半年に1回、半日を確保して当てる。それだけ決めておけば、追加の機能を入れるかどうかとは別に、安全上の修正だけは受け取り続けられます。ここを決めずに始めた仕組みは、数年後に「動いてはいるが誰も触れない」状態になりがちです。
他の道具と並べて考えるときの見方
Redmineの設定項目の多さは、そのまま自由度の高さです。種類も状態も権限も自分たちの形に合わせられます。この自由度が要る仕事なら、他の道具に替える理由はほとんどありません。工程の型が繰り返し発生し、決めた型を守らせたい現場では、この作り込みが効きます。
逆に、案件ごとに工程が違い、型を決めても次の案件では当てはまらない仕事だと、設定にかけた時間が回収できません。この場合に効くのは、決めることを減らして、板を見れば状況が分かる形にすることです。板の並びで進み具合を表し、必要なときだけ工程表に切り替える。決める項目が少ないぶん、入力する人の負担も軽くなります。
道具を並べて比べるときは、機能の一覧よりも「区切り方」を見てください。人数で区切るのか、機能で区切るのか、保存容量で区切るのかで、増えたときの費用が変わります。国産のボード型で比べるならBacklogとの比較やJootoとの比較に、それぞれの区切り方と向き不向きを整理しています。海外の道具と並べたい場合はTrelloとの比較、Asanaとの比較、Notionとの比較、monday.comとの比較が使えます。どれから読めばよいか決めかねるなら、比較の一覧から近い形のものを選ぶのが早いです。
比べるときの観点として、ボード型のプロジェクト管理ツールでは機能で絞らず、区切るのは人数とボードの数だけという考え方を取っているものもあります。使える機能が契約の段階で変わらないので、「この機能を使うには上の契約に上げてください」という説明が要りません。導入して2週間で全員に配る場面では、この説明の少なさが効きます。何ができるかはできることに、費用の区切り方は料金に整理してあります。
ただし、この形にも認めておくべき制約があります。ソースコードのリポジトリを内蔵する機能はありません。自動化や外部サービスとの連携の豊富さで勝負する作りでもありません。画面は日本語のみで、自動で取り込めるのはTrelloからのデータだけです。開発の作業とチケットを1つの画面で結びつけたい現場や、外部との連携を前提に組みたい現場では、Redmineの作り込みのほうが向きます。移行の可否を具体的に確かめたい場合はTrelloからの移行に手順が、データの扱いの考え方は安全性の考え方にまとめてあります。判断に迷う細かい点はよくある質問を先に見ると、確認の往復が減ります。
自前で持つか、預けるか。この選択は、機能の優劣ではなく、保守を引き受ける人がいるかどうかで決まります。引き受ける人がいて、工程の型を自分たちで定義したいなら、設定の自由度は資産になります。いないなら、その自由度は将来の負債になります。導入の前に確かめるべきは、この1点です。
Q1. Redmineを使い始めるのに、最初に決めることは何ですか？
プロジェクトの単位、チケットの種類、状態の並び、役割ごとの権限の4つを、この順番で決めてください。種類が決まらないと状態が決まらず、状態が決まらないと「誰がどの状態に動かせるか」を定義できないためです。特にプロジェクトの識別子は作成後に変更できないので、命名の決め方を先に用意しておくと安全です。
Q2. ガントチャートに何も表示されないのはなぜですか？
ガント画面はチケットの開始日と期日を横棒にして描くため、日付が入っていないチケットは現れません。ロードマップの場合は、プロジェクトにバージョンを作り、チケットをそこへ紐づけ、そのトラッカーが「ロードマップに表示する」設定になっている必要があります。3つのどれかが抜けていることがほとんどです。
Q3. チケットはどのくらいの大きさで切ればよいですか？
1件が1人の担当で、3日以内に終わる大きさが目安です。担当が複数人になる粒度だと誰が動かすか決まらず放置されます。2週間かかる粒度だと状態が変わらないため、進んでいるのか止まっているのかが外から見えません。大きな仕事は親のチケットにして、手を動かす単位を子で切ります。
Q4. バージョンの更新はどのくらいの頻度で必要ですか？
公式のダウンロードページには、細かい更新は可能な範囲で3か月ごと、大きな更新は1年に1回という方針が示されています。最新の系統は新機能と修正の両方、1つ前は修正のみ、2つ前は重要な安全上の修正のみが対象です。半年に1度、半日を確保して当てる形を予定に入れておくと、まとまった作業になるのを避けられます。