Redmineが使いにくいと感じるとき｜合っていないのは道具か、組み方か
Redmineが使いにくいという声は、実は3つの別々の立場から出ています。毎日チケットを書く人、設定を変える立場の人、そしてサーバーを保守する人です。この3つは詰まる場所も、直し方も、直せる人も違います。とりまとめる立場でやるべきなのは、どの立場から出た声なのかを最初に分けることです。分けずに「使いにくいから別の道具にしよう」と決めると、次の道具でも同じ場所で詰まります。
声の出どころを3つに分ける
同じ「使いにくい」でも、指しているものが違います。出どころを分けると次の3つになります。
・入力する人の声。書くのに手数がかかる、状態を動かせない、探しているものが出てこない ・設定する人の声。変えたい項目にたどり着けない、自分の権限では触れない ・保守する人の声。更新の作業が重い、動いている環境を止めたくない
この3つは、直せる人がそれぞれ違います。1つ目はプロジェクトの担当者と全体の管理者の両方が関われます。2つ目は全体の管理者だけです。3つ目はサーバーを触れる人だけです。声を聞いた人が直せる立場にいないと、話はそこで止まります。
聞き取りのときに使える質問は1つで足ります。「その操作は、いつ、どの画面で止まりましたか」です。画面の名前が返ってくれば入力の話、設定の画面の名前が返ってくれば権限の話、画面の話が出てこなければ保守の話だと分かります。
もう1つ、3つのどれでもない声も混ざります。習っていないだけ、という状態です。導入したときに説明を受けた人はいても、あとから入った人には誰も教えていない。この場合、道具も設定も問題ありません。よく使う操作を5つ書いた1枚の紙を配れば声は止まります。試す価値のある、いちばん費用の低い対処です。
状態を動かせないのは、権限の設計で起きている
入力する人からいちばん多く出るのが、「終わったのに完了にできない」という声です。これは不具合ではなく、設計どおりの動作であることがほとんどです。
Redmineでは、どの状態からどの状態へ動かしてよいかを、チケットの種類と役割の組み合わせごとに定義します。つまり、同じチケットでも、開発の役割の人には見えている選択肢が、確認する役割の人には出ません。定義を作った人にとっては意図どおりでも、使う人には「選べない理由が画面に書かれていない」ので、不具合に見えます。
役割の考え方は公式の説明に整理されています。
A role is a collection of permissions. It lets you define the permissions that the members have on a project. Each member of a project has one or multiples Role(s) for the project. If a member has multiple roles in a project, the permissions applied to the member is the combination of all roles' permissions. A user can have different roles for different projects. 出典: redmine.org
権限は足し算で効き、同じ人でもプロジェクトごとに別の役割を持てます。この柔軟さが混乱の元にもなります。Aの案件では状態を動かせるのに、Bの案件では動かせない。本人からすると、道具の挙動が日によって変わるように見えます。
対処は2つあります。1つは、遷移の定義を減らすことです。この定義は種類と役割の掛け合わせで増えていくため、どちらも4つずつあるだけで16枚の表を持つことになります。全部を最新に保ち続けられるチームは多くありません。実際に守らせたい制限だけを残し、他は自由に動かせるようにするほうが、運用の摩擦は小さくなります。
もう1つは、制限の理由を人が伝えることです。「確認前に完了にできないのは、確認漏れを防ぐためです」と1度説明すれば、同じ声は出なくなります。画面が説明してくれない部分は、人が補うしかありません。
見えるはずのものが見えない
次に多いのが、「他の人が作ったチケットが見えない」という声です。これも設定で起きます。
役割の設定には、チケットの見え方を選ぶ項目があります。すべてのチケットが見える、非公開でないものと自分が作成または担当のものが見える、自分が作成または担当のものだけが見える、の3つです。既定は真ん中で、非公開に設定されたチケットは作成者と担当者以外には現れません。
同じように、作業時間の記録の見え方と、利用者そのものの見え方も役割ごとに選べます。利用者の見え方を絞ると、関係者を追加しようとしたときに候補に名前が出てきません。「あの人を追加できない」という声は、たいていここが原因です。
外部の協力会社にアカウントを渡している場合、この3つの設定は渡す前に確認してください。逆に、社内のメンバーに対して既定のまま絞っていると、必要な情報が見えずに「使いにくい」につながります。見せない設計と、見せる設計のどちらを既定にするかは、扱っている情報の性質で決めるべきものです。
プロジェクトの公開の設定も影響します。公開にすると、メンバーでない利用者からも内容が見えます。閉じておくと、関係者を追加するまで何も見えません。案件が始まるたびに追加の作業が発生するのが煩わしいなら、社内向けは公開、社外が入るものは非公開、と方針を決めてしまうのが楽です。
設定を変えたいのに触れる人がいない
設定する立場から出るのが、「変えたい項目の画面が開けない」という声です。Redmineでは、プロジェクトの担当者が触れる範囲と、全体の管理者だけが触れる範囲がはっきり分かれています。
プロジェクトの設定画面でできるのは、用意されているものから選ぶことです。公式の説明では、使うチケットの種類を選ぶことはできても、新しい種類を定義できるのは管理者だけだと明記されています。追加項目（カスタムフィールド）も同じで、選べるだけで、作れるのは管理者です。
つまり、「この案件だけ入力してほしい項目がある」という要望は、プロジェクトの担当者だけでは実現できません。管理者に依頼し、全体の設定として追加してもらい、そのうえで自分のプロジェクトで選ぶ、という3段階になります。
ここで詰まりが起きやすいのは、管理者が兼務で、依頼が滞る場合です。1週間待たされると、依頼した側は表計算ソフトで代用を始めます。1度代用が始まると、その情報は二度と板に戻ってきません。
現実的な手当ては、管理者を2人か3人に増やし、変更したら記録を残す運用にすることです。1人だけだとその人が休んだ日に止まり、全員が管理者だと誰かが状態を1つ消しただけで全プロジェクトの流れが変わります。あわせて、追加項目を増やす依頼には基準を持つほうがよいです。「その項目を、後で誰が何のために見るか」に答えられない依頼は、増やしても埋まりません。
探しているものが出てこない
一覧の画面が使いにくい、という声も定番です。中身を聞くと、たいてい2つに分かれます。条件を指定する操作が分からない場合と、欲しい列が出ていない場合です。
Redmineの一覧は、条件を足して絞り込み、表示する列を選び、その組み合わせを保存できる作りになっています。この「保存できる」ことを知らないと、毎回同じ操作を繰り返すことになり、面倒だという感想になります。
とりまとめる立場の人がやると効果が大きいのは、よく使う一覧を自分で作って配ってしまうことです。自分の担当で期日が近い順のもの、期日を過ぎているもの、今週更新されていないもの。この3つを用意しておくと、探す操作そのものが要らなくなります。
もう1つ、一覧から複数のチケットをまとめて更新できることも、意外と知られていません。10件の担当をまとめて変える、期日をまとめてずらす、といった操作が1回で済みます。1件ずつ開いて直していた人にとっては、作業時間が大きく変わります。
こうした操作を教える場は、導入時の説明会ではなく、困っている場面のほうが向いています。誰かが1件ずつ開いて直しているのを見かけたときに、その場で教える。まとめて覚えさせようとすると、必要になったときには忘れています。
画面の言葉が、そのチームの言葉と違う
見落とされやすいのが、用語のずれです。チケット、トラッカー、ロードマップ、作業時間。これらは道具の側の言葉で、そのチームが普段使っている言葉とは限りません。
制作の現場では、1件の仕事を「案件」と呼び、その中の作業を「タスク」と呼んでいることが多いです。そこへ「チケットを起票してください」と言うと、まず言葉の翻訳が挟まります。翻訳が挟まる操作は、慣れるまでの間ずっと心理的な負担になります。「使いにくい」の一部は、この翻訳の負担です。
さらに紛らわしいのが、トラッカーという言葉です。追跡するもの、という語感から進捗の追跡機能だと受け取られがちですが、実際にはチケットの種類を指します。種類ごとに既定の状態や使う項目、ロードマップに出すかどうかを決める単位です。この誤解を抱えたまま設定を触ると、意図しない場所を変えてしまいます。
対処は難しくありません。用語の対応表を1枚作って配ることです。左に道具の言葉、右に自分たちの言葉。5語か6語で足ります。表を配っただけで質問が半分になった、という話は珍しくありません。名前を変えられる項目は自分たちの言葉に合わせて変えてしまうのも手ですが、公式の資料や検索で出てくる説明と食い違うようになるので、変えるならその点も含めて伝える必要があります。
更新するのが特定の1人に偏る
チームで使い始めてしばらくすると、板を更新しているのが実質1人だけ、という状態になることがあります。とりまとめる立場の人がその1人になっている場合、本人の作業時間が削られ続けます。
偏りが起きる原因は、たいてい入力の手数です。1件を書くのに項目が8つあると、思いついたことをその場で書く気になりません。結果、口頭やチャットで伝えられたものを、まとめ役が代わりに登録することになります。代行が始まると、書く人はますます書かなくなります。
もう1つの原因は、書いても反応が無いことです。書いたチケットに誰も触れず、状態も変わらないままなら、書く意味を感じられません。逆に、書いた翌日に担当が入って状態が動けば、その体験が次の入力を呼びます。最初の2週間だけでも、登録されたチケットにその日のうちに何らかの反応を返すと、定着の度合いが変わります。
構造として直すなら、必須の項目を減らすことが最優先です。表題と担当だけ必須にして、他は空でも登録できるようにする。詳しい情報は、必要になった時点で足せばよいものがほとんどです。入口を狭くしたまま「みんなで書こう」と呼びかけても、行動は変わりません。
現場や移動中から更新したい場合
外出が多い仕事や、現場で作業する仕事では、手元の端末から更新できるかどうかが定着を左右します。事務所に戻ってから入力する運用にすると、その日のうちに入らず、翌日にまとめて入れることになり、日付の正確さが失われます。
ここは設定では解決しにくい部分です。画面の作りそのものに関わるので、外観を変える部品を入れるか、別の入口を用意するかの判断になります。メールから登録する仕組みも標準で用意されているので、現場からは短いメールを送るだけにして、整理は事務所側で行う、という分業が成り立つ場合もあります。
判断の材料として確かめておきたいのは、現場の人に求めている操作が何かです。新しく登録することなのか、状態を1つ動かすことなのか、写真を添えることなのか。状態を動かすだけなら一覧からまとめて操作すればよく、必ずしも1件ずつ開く必要はありません。求めている操作を絞ると、必要な作りも小さくなります。
写真の添付が中心なら、扱いが変わります。件数が多いと保存領域の設計が要るうえ、現場の通信環境では送信に時間がかかります。写真を残すこと自体が目的なのか、写真に紐づく作業の状態を残したいのかを分けて考えると、道具に求める条件がはっきりします。
二重管理が始まったら、それが合図
いちばん分かりやすい不調の合図は、誰かが表計算ソフトで一覧を作り始めることです。この時点で、板の見せ方がその人の必要を満たしていません。
理由を聞くと、返ってくるのはたいてい「報告に必要な形で出せないから」です。上長に出す資料の形と、板の一覧の形が違う。その差を毎回手で埋めているうちに、表計算ソフトのほうが正だと感じるようになります。
対処として効くのは、その人が欲しい形の一覧を作って渡してしまうことです。条件と表示する列の組み合わせは保存できるので、報告に使う並びをそのまま用意できます。書き出して加工したいなら、一覧をそのまま外部の形式に出す機能も標準で用意されています。
放置すると、二重管理は固定します。板と表計算ソフトの数字が食い違い、どちらが正しいのか誰も判断できなくなり、最終的に「板は形だけ」という状態になります。転記の習慣が根づく前に手を打つほうが、あとから止めるより確実に楽です。
保守の負担は、使う人には見えない
3つ目の立場は、サーバーを保守する人です。この負担は、使う人からは見えません。だからこそ、とりまとめる立場の人が把握しておく必要があります。
公式の導入手順には、バージョンごとに必要なRubyとデータベースの組み合わせが表で示されています。7.0系ならRuby 3.2から4.0、Rails 8.1、PostgreSQLは14、MySQLは8.0から8.4という具合です。本体を上げるだけでなく、その土台も条件を満たす必要があるということです。
どこまで面倒を見てもらえるかも公開されています。最新の系統は新機能と修正の両方を受け取り、1つ前は修正のみ、2つ前は重要な安全上の修正のみ、それより古いものは対象外という並びです。手元の版がこの並びのどこにいるかを知らないまま使い続けると、いつの間にか修正の届かない位置に落ちています。細かい更新が可能な範囲で3か月ごとに出る以上、放置した期間はそのまま差になります。
この期限を運用の予定に入れていないと、数年放置したあとに大きな塊の作業が残ります。業務の合間ではこなせない量になり、「動いてはいるが誰も触れない」状態が生まれます。使う人からは何も変わって見えないので、危うさが伝わりません。
追加した機能が、更新を止めることがある
自由度の高さの裏側にあるのが、追加の部品（プラグイン）との付き合いです。足りない機能を補うために入れた部品が、本体のバージョンを上げるときの制約になります。
部品は本体とは別の人が作っているので、本体が新しくなってもすぐには追随しないことがあります。業務に必須の部品が対応していない場合、本体の更新を待つしかありません。安全上の修正が出ているのに当てられない、という状況になると、判断が難しくなります。
導入の段階でできることは2つです。1つは、入れる部品を最小にすること。「あれば便利」で入れたものが、後で更新を止める原因になります。もう1つは、入れる前に、その部品が過去にどれだけ本体の更新へ追随してきたかを見ることです。長く手が入っていないものは、次の更新でも追随しない可能性が高いと考えるほうが安全です。
見た目を変える部品も同じ扱いです。画面が古いという声に応えて外観を変えると、本体を上げたときに崩れることがあります。外観の不満は、実際には情報の並び順や項目の多さから来ていることも多く、標準の設定を整えるだけで和らぐ場合があります。
設定で直せることと、直せないこと
ここまでを整理すると、設定で直せる範囲は次のとおりです。
・必須の項目が多くて書けない。項目の見直しで直る ・状態を動かせない。遷移の定義の見直しで直る ・他の人のチケットが見えない。役割の可視性の設定で直る ・通知が多い。購読の設定で直る ・欲しい一覧が出せない。条件と列を保存して配れば直る
直らないのは次のようなものです。
・案件ごとに工程が違い、種類や状態の型が次の案件で当てはまらない ・保守を引き受ける人が社内にいない ・現場が屋外や移動中で、手元の端末から片手で更新したい
上の3つは設定の問題ではありません。型を決めて守らせる作りと、案件ごとに形が変わる仕事が噛み合っていない、という構造の話です。型を決める価値は、同じ工程が何十回も回ることで初めて回収されます。回らない仕事に持ち込むと、実態と合わない項目を毎回埋めることになり、入力が形だけになります。
組み方を直すなら、範囲を絞ってやり直す
設定で直る範囲だと判断できたら、全体を作り直す必要はありません。1つの案件を選んで、そこだけで組み直すのが早いです。
やることは3つです。必須の項目を表題と担当だけに減らす。状態を4つ程度に絞る。遷移の制限を、本当に守らせたいものだけ残す。この状態で2週間動かして、出てきた不満だけを足していきます。
先回りして項目を用意すると、使う前の想像で作ったものが残り、あとで誰も埋めなくなります。埋まらない項目が並んだ画面は、それ自体が「この道具はいい加減でよい」という合図になります。1度そうなると、精度は戻りません。
あわせて、書き方の型を1つ示してください。表題は動詞で終わる形にして、名詞だけで置かない。中身には、いま確定している範囲と、まだ決まっていない論点、そして次に手を動かす人の名前を残す。この3点が揃っていれば、担当が替わっても引き取れます。型は説明するより、良い例を1件見せるほうが早く伝わります。
他の部署に広げるときに起きること
開発の部署でうまく回っている状態を見て、他の部署にも広げようという話が出ることがあります。ここで「使いにくい」の声が一気に増えるのは、よくある展開です。
理由は、前提の違いにあります。工程が繰り返し発生する仕事では、種類と状態を型として決めておく価値があります。決める手間が、繰り返しの回数で割り戻されるからです。一方、営業の提案準備や、総務の依頼対応のように、案件ごとに形が違う仕事では、型を決めても次の案件では当てはまりません。それでも型を作ると、実態と合わない項目を毎回埋めることになります。
広げるときにやるべきなのは、既存の設定をそのまま複製しないことです。新しい部署には、種類1つ、状態3つ、必須項目は表題と担当だけ、という最小の形から始めてもらう。開発の部署が使っている設定は、その部署の仕事に合わせて育ってきたものなので、他所に移植しても合いません。
もう1つ、広げる前に決めておきたいのが、部署をまたいだ見え方です。プロジェクトを公開にするか閉じるか、役割ごとの可視性をどうするかを、部署が増えるたびに個別に決めていると一貫性が失われます。「社内向けは公開、社外が入るものは非公開」といった方針を先に置いておくと、判断のたびに悩まずに済みます。
乗り換えを決める前に確かめる3つ
道具を替える判断をする前に、確かめておくと後悔が減ることが3つあります。
1つ目は、いま出ている不満が設定で直る側かどうかです。上に挙げた5つ（必須項目、遷移の定義、可視性、通知、一覧の保存）のどれかに当てはまるなら、替えても同じ場所で詰まる可能性があります。替える前に1つの案件で直してみて、それでも残る不満だけを持って比較に進むほうが確実です。
2つ目は、いま蓄えている情報のうち、何を持ち出す必要があるかです。過去のチケットを全部運ぶのか、進行中のものだけでよいのか。全部運ぶと決めた瞬間、移行の作業は数倍になります。終わった案件は元の環境を読み取り専用で残す、という選び方もあります。
3つ目は、次の道具を保守する人が誰かです。自分たちのサーバーで動かす形をやめて外部の仕組みに移すなら、更新の作業からは解放されますが、費用が人数に比例して増える形に変わります。どちらが自分たちに向くかは、人数の増え方と、社内に技術の担当がいるかどうかで決まります。
道具のほうを見直すときに見る観点
構造の問題だと分かった場合は、道具の形そのものを見ることになります。このとき、機能の一覧を並べて比べても判断はつきません。どの道具にも一覧表にすれば載る程度の機能はあり、差が出るのは使い続けたときの摩擦の大きさだからです。
見るべきは3つです。決めなければ使い始められないことがいくつあるか。使う人が覚える操作がいくつあるか。人が増えたときに費用がどう変わるか。設定の自由度が高い道具は、1つ目と2つ目が大きくなります。そのぶん、型を守らせたい現場では強く働きます。
国産のボード型と並べたい場合はBacklogとの比較とJootoとの比較に、それぞれの区切り方を整理しています。海外の道具ならTrelloとの比較、Asanaとの比較、Notionとの比較、monday.comとの比較が該当します。どれが近いか決めかねる場合は比較の一覧から形の似たものを選ぶのが早いです。
区切り方の例として、ボード型のプロジェクト管理ツールの中には機能で絞らず、区切るのは人数とボードの数だけという考え方を取っているものもあります。契約の段階で使える機能が変わらないので、「その機能は上の契約です」という説明が要りません。設定を任される人が兼務のチームでは、この説明の少なさがそのまま負担の軽さになります。使える範囲はできることに、区切り方は料金にまとめてあります。
ただし、こうした形が向かない場面もあります。コードを置く場所を同じ画面に持つ作りにはなっておらず、外部の仕組みと細かくつなぐ用途にも向きません。表示できる言語は日本語だけで、既存のデータを自動で引き取れる相手はTrelloに限られます。開発の作業と課題を1つの画面で結びつけたい現場や、独自の工程を細かく定義したい現場では、設定の自由度が高い道具のほうが向きます。移行できるかどうかを具体的に確かめるならTrelloからの移行に手順が、データの扱いの考え方は安全性の考え方に書いてあります。細かい条件はよくある質問を先に見ると、問い合わせの往復が減ります。
使いにくいという声は、道具への評価ではなく、噛み合っていない場所を教える情報です。3つの立場のどこから出たのかを分けてから動けば、直すべき場所はたいてい1つに絞れます。声を上げた人に「どの画面で止まったか」を聞き、直せる立場の人へその場でつなぐ。この往復を2週間続けるだけで、残る不満は驚くほど少なくなります。残ったものが、本当に道具の形を見直す理由です。
Q1. チケットを完了にできないのは不具合ですか？
不具合ではなく、設定どおりの動作であることがほとんどです。どの状態からどの状態へ動かしてよいかは、チケットの種類と役割の組み合わせごとに定義されています。同じチケットでも役割によって選べる状態が変わります。制限を残す理由を1度説明するか、実際に守らせたい制限以外を外すかのどちらかで解決します。
Q2. 他の人が作ったチケットが見えないのはなぜですか？
役割の設定に、チケットの見え方を選ぶ項目があるためです。すべて見える、非公開でないものと自分が作成または担当のものが見える、自分のものだけが見える、の3つから選ぶ形で、既定は真ん中です。非公開に設定されたチケットは作成者と担当者以外には表示されません。
Q3. 追加したい入力項目があるとき、誰に頼めばよいですか？
全体の管理者です。プロジェクトの設定画面でできるのは用意されているものから選ぶことだけで、新しい種類や追加項目を定義できるのは管理者に限られます。依頼が滞ると表計算ソフトでの代用が始まるため、管理者を2人か3人にして、変更の記録を残す運用にしておくと止まりにくくなります。
Q4. 設定を直しても改善しないのは、どんな場合ですか？
案件ごとに工程が違って型が当てはまらない場合、保守を引き受ける人が社内にいない場合、現場が移動中で手元の端末から片手で更新したい場合の3つです。これらは設定ではなく、道具の作りと仕事の形が噛み合っていない状態なので、決めることの少ない道具を並べて比べる段階に移ります。