Lychee Redmineの使い方｜最初のプロジェクトをどう組み立てるか
Lychee Redmineの使い方を検索している人の多くは、ボタンの位置ではなく「最初のプロジェクトをどう作れば、2か月後も動いているか」を知りたがっています。この製品はRedmineを土台にしているため、画面を開いてすぐ触れる状態にはなっていません。先に決めることがあり、その順番を間違えると、機能は全部あるのに誰も更新しない箱になります。ここでは、最初の30日で何をどの順で決めるかを、進行を預かる立場から書きます。
触る前に、プロジェクトを1本だけに絞る
導入の初日にやりがちなのが、社内の案件を全部登録することです。これはほぼ確実に失敗します。設定の良し悪しがまだ分からないうちに10本のプロジェクトを作ると、後から直すときに10倍の手間がかかり、そのうち直すのをやめます。
最初に選ぶ1本の条件は3つです。期間が1か月から3か月で終わること。関わる人が3人から6人であること。そして、いま実際に動いていて、終わりの日が決まっていることです。過去の案件を再現しても、誰も真剣に更新しません。動いている案件でなければ、道具が使えるかどうかは判定できません。
この1本を「型を作るための案件」と位置づけます。ここで決めた形を、後から他の案件に写します。写す作業を軽くする仕組みも用意されていて、料金ページの機能表にはプロジェクトテンプレートとチケットセットが並んでいます。よく使うプロジェクトの形や、決まって発生するチケットの束を、型として保存しておく機能です。どちらもフリープランでは対象外で、有料プラン側に付いています。似た案件を繰り返し回すチームなら、この2つが後半の作業量を大きく変えます。
もうひとつ、最初に決めておくべきことがあります。この案件で「何が見えたら成功か」を1つだけ書き出すことです。工程表を関係者に見せたいのか、誰がどれだけ抱えているかを知りたいのか、実際にかかった時間を集めたいのか。3つ全部を同時に狙うと、入力する人の負担が3倍になって続きません。1つに絞ると、後で決める設定がほとんど自動的に決まります。
トラッカーとステータスを、増やす前に減らす
Redmine系の道具では、すべての作業がチケットという単位に落ちます。そのチケットの「種類」がトラッカー、「状態」がステータスです。最初に触る人が真面目であるほど、ここを細かく作り込んでしまいます。
現場でしばしば出るのは、トラッカーを「作業」「不具合」「質問」「依頼」「調査」「レビュー」と6種類に増やした結果、起票する人が毎回どれを選ぶか迷い、結局すべて「作業」で起票されるという話です。分類は、後から集計したい単位でだけ作ってください。集計しないなら分ける必要はありません。最初は2種類か3種類で足ります。
ステータスも同じです。「新規」「進行中」「レビュー中」「保留」「完了」「却下」と6段にすると、更新の回数が増えます。カードを動かす手間は1回ずつは小さくても、20枚あれば20回です。まずは「未着手」「進行中」「完了」の3段で回し、詰まる場所が見えてから足すほうが、定着が早くなります。
そのうえで、ワークフローとロールの設計に入ります。誰がどの状態に動かせるかを決める部分です。ここを空のままにすると、レビュー前の作業を本人が完了にしてしまい、進捗の表が実態から離れます。逆に厳しくしすぎると、承認者が不在の日に全部止まります。5人から数十人のチームなら、完了に動かせるのはレビュー担当と進行のとりまとめ役だけ、それ以外の遷移は全員が自由、くらいの粗さがちょうどよく回ります。
料金ページの機能表を見ると、ロールと権限はフリープランでは対象外で、有料プラン側の機能として並んでいます。無料の範囲で試している段階では、この設計を確かめられない点に注意が必要です。
ガントチャートは、粒度を決めてから引く
工程表の画面は、スタンダードプラン以上で開きます。フリープランの欄には「※ガントチャートは含まれません」と明記されているので、工程表を目的にしているなら、この時点で有料プランを前提にすることになります。
引くときにいちばん効くのは、機能の使い方ではなく棒の粒度です。1本の棒を何日分にするかを先に決めてください。目安は、1本が3日から10日に収まる大きさです。1日の粒度で刻むと本数が増えすぎて、更新が追いつきません。1か月の粒度でまとめると、半分過ぎた時点で遅れているかどうかが分かりません。3日から10日なら、週に1回の更新で状態が追えます。
次に決めるのが、依存関係をどこまで引くかです。全部の棒を線で繋ぐと、1本ずらしたときに画面全体が動いて、誰も触りたがらなくなります。繋ぐのは「これが終わらないと次が始められない」場所だけにしてください。多くの案件では、その本数は全体の2割から3割です。
3つ目が、担当者を棒に載せるかどうかです。載せると誰が詰まっているかが一目で分かりますが、そのぶん棒の本数が人数分に増えます。1人が同時に2本以上を持つ案件では、載せたほうが結果的に見やすくなります。1人1本で回る案件なら、工程だけで足ります。
工程表は、引いた後の運用のほうが難しくなります。よく聞くのは、遅れが出るたびに引き直していたら、引き直す作業自体が仕事になってしまったという話です。対策は単純で、動かすタイミングを週に1回に固定することです。日々の遅れはチケットのステータスとコメントで残し、棒を動かすのは定例のときだけ。こうすると、工程表が「合意した計画」として意味を持ち続けます。
工数の入力は、目的を先に言わないと止まる
プレミアムプラン以上では、タイムマネジメント（工数の記録）とリソースマネジメント（負荷の配分）が開きます。受託の案件を持つチームでは、ここが実質的な導入理由になることが多い機能です。
ただし、工数の入力は導入で最も定着しにくい部分でもあります。理由ははっきりしていて、入力する人にとって直接の見返りがないからです。書いても自分の仕事は減りません。ここを乗り越えるには、集めた数字を何に使うのかを、入力を頼む前に本人たちに伝える必要があります。
伝え方には効くものと効かないものがあります。効かないのは「原価を把握するため」「管理のため」という説明です。効くのは、その人の負担が減る形で返す説明です。次の見積もりを厚くするために使う、無理な納期の依頼を断る根拠にする、来期の増員を通す材料にする。実際にそう使い、結果を本人たちに戻すところまでやって初めて、入力が続きます。
運用の面では、記録の単位を粗くすることが効きます。15分単位で正確に付けさせようとすると、思い出す作業に時間がかかって続きません。0.5時間単位で、その日の終わりにまとめて入れる。この程度でも、月次で集計すれば案件ごとの傾向は十分に見えます。
なお、EVMやCCPMといった、より踏み込んだ分析の機能も同じプレミアム以上に含まれます。ただし、これらは工数と進捗が継続して入力されていることが前提の機能です。入力が半分しか埋まっていない状態で出した数字は、実態より良く見えるほうに偏ります。分析の画面を開くのは、入力が3か月ほど安定してからにしてください。
更新されないチケットを、聞いて回らずに直す
導入して2か月ほど経つと、ほぼどのチームでも同じ問題が出ます。担当者がチケットを更新してくれず、進行のとりまとめ役が聞いて回って代理で更新している、という状態です。これは提供元も認識している課題で、2026年8月18日のプレスリリースには次のように書かれています。
実際の現場からは「なかなか担当者がチケットを更新してくれない」「チケット更新が後回しになり、PMやリーダーが聞いて回って代理で更新している」といった、入力にまつわるお困りの声が絶えませんでした。 出典: agileware.jp
同じリリースによれば、この課題に対する答えとして、ダッシュボードに「今日のトピック」が常設表示されるようになりました。未完了のチケットを6つの状態（遅延、期日超過、未着手、更新停滞、担当者未設定、予定工数未設定）で自動集計し、対処すべき度合いの高い順に並べる機能です。各チケットには操作ボタンが並んでいて、期日変更、ステータス更新、担当者変更、進捗更新、予定工数入力、コメント投稿を、画面を移動せずにその場で行えるとされています。提供開始は2026年8月18日で、使えるのはスタンダード以上のプランです。
運用の組み立てとしては、朝会でこの画面を全員で開くのが素直な使い方になります。赤の状態（遅延、期日超過、未着手）から順に見て、その場で期日と担当を直す。聞いて回る時間と、代理で入力する時間が同じ場所にまとまります。
とはいえ、道具の側で全部が解決するわけではありません。更新されない本当の理由が「そのチケットがもう不要になっている」ことである場合、状態を直しても意味がありません。月に1度は、3週間以上動いていないチケットをまとめて見直して、閉じるか、担当を変えるか、期日を引き直すかを決める時間を取ってください。この掃除をしないチームでは、半年で一覧が読めなくなります。
アジャイル開発で回すなら、専用の画面がある
スクラムのような枠組みでスプリントを回しているチーム向けに、別の画面が用意されています。2026年3月にNeoバックログ、2026年5月19日にNeoカンバンが提供開始されました。
提供元のリリースによれば、Neoバックログでスプリントゴールと優先順位を決め、Neoカンバンでスプリント中の状況を1画面で見る、という組み合わせを想定しています。Neoカンバンの側では、スプリントゴールを画面の上部に常時表示すること、プロダクトバックログアイテムごとに紐づく子タスクをグループ表示すること、ステータスの更新をドラッグ操作で行えること、複数人が同時に開いていても他の人の更新が自動で反映されることが挙げられています。対象プランはスタンダード、プレミアム、ビジネスです。
工程表とスプリントは、同じ案件で両方を使うと管理が二重になります。どちらか一方を主にしてください。納期と工程が外部との約束で決まっている案件は工程表、作るものを走りながら決めていく案件はスプリント、という分け方が実務的です。両方が混ざる案件では、外部に見せる粒度を工程表で、内部の日々の動きをスプリントで、と役割を分けると衝突しません。
2本目以降を、型で増やす
1本目のプロジェクトが2か月ほど回ったら、型を写す段階に入ります。ここで手作業で同じ設定を作り直すと、細かい差が積み上がって、半年後には案件ごとにルールが違う状態になります。
料金ページの機能表に並んでいるプロジェクトテンプレートは、プロジェクトの構成そのものを型として保存しておく機能です。チケットセットは、決まって発生するチケットの束を保存しておく機能で、たとえば「新規案件の立ち上げ時に必ず起こす7枚」のような形で使えます。どちらも有料プランに含まれ、フリープランでは対象外と示されています。
型を作るときのコツは、盛り込みすぎないことです。案件の8割で必ず起きるものだけを型に入れ、案件ごとに違うものは入れません。型に入れたチケットが実際には不要で、毎回削除する運用になると、削除の手間のぶんだけ型が邪魔になります。実務では、最初の型は5枚から10枚程度に収めておくと使い続けられます。
同時に、この段階で「型を直す担当」を決めてください。案件を回すうちに、型に足したいものが必ず出てきます。誰も直さない型は、3か月で実態と合わなくなり、使われなくなります。四半期に1回、型を見直す30分を予定に入れておくだけで、この劣化は止まります。
動く場所と、最初につまずく設定
クラウド版はブラウザで使います。公開されている動作環境のページでは、Google Chrome（推奨）、Chromium版Edge、Firefoxの最新バージョンに対応と示されています。社内標準のブラウザがここに入っていない場合、導入の前に確かめておく価値があります。
設定で最初につまずきやすいのが、会社休日の設定です。これを入れないまま工程表を引くと、土日を作業日として計算した日程が出ます。料金ページの機能表では、会社休日設定はフリープランを含む全プランで使える基本機能として並んでいます。プロジェクトを作ったら、真っ先にここを入れてください。
もうひとつが通知の設定です。既定のまま人を入れると、チケットが1枚動くたびに関係者全員にメールが飛び、2週間で全員がメールを無視するようになります。通知は「自分が担当のもの」「自分がウォッチしているもの」に絞り、全体の動きはダッシュボードで見る形にしたほうが、結果的に情報が届きます。
3つ目が、公開プロジェクトの扱いです。誰でも閲覧できる設定にして、非メンバーにLychee Redmineの権限を付与すると、価格表の記載ではRedmineに登録されている全ユーザーが契約対象の人数に入ります。見やすさのつもりで開いた設定が、そのまま請求に効く形です。使い勝手と費用の両方に関わるので、公開範囲は最初に方針を決めておいてください。
チケットの書き方を、3行のひな型で揃える
設定を整えても、書かれる中身がばらばらだと一覧は読めません。「修正対応」というタイトルのチケットが5枚並んでいる状態は、どのチームでも起きます。ここを揃えるのに、道具の機能は要りません。書き方のひな型を1つ配るだけで済みます。
有効なのは3行のひな型です。1行目に「何を」、2行目に「終わったと言える条件」、3行目に「誰の確認が要るか」。タイトルには対象と動詞を必ず入れて、「請求書の出力処理を修正」のように、後から検索して見つかる形にします。「対応」「確認」「調整」といった動詞だけのタイトルを禁止するだけで、一覧の読みやすさは大きく変わります。
2行目の「終わったと言える条件」が、実は最も効きます。これが書かれていないチケットは、担当者と依頼者で完了の基準がずれ、完了にした後で差し戻される確率が上がります。この項目を埋める手間は1枚あたり30秒ほどですが、差し戻し1回で失う時間は数十分です。
料金ページの機能表には、チェックリストという機能が有料プラン側に並んでいます。チケットの中に完了条件を箇条書きで持たせる機能で、この2行目をそのまま構造化できます。また、2025年11月18日に提供が始まったAIアシスタントについて、提供元のリリースには、チケットの内容をもとに作業の完了条件を提案する用途が挙げられています。ただし同じリリースには、この機能の利用にOpenAIまたはAzure OpenAIとのAPI契約が必要である旨も明記されているので、すぐ使える前提では考えないほうが安全です。
もうひとつ、書き方で決めておくとよいのが期日の意味です。「作業を終える日」なのか「相手に渡す日」なのか「相手の確認まで終わる日」なのか。ここが人によって違うと、遅延の判定が意味を持ちません。チーム内で1つに決めて、ひな型に書いておいてください。
権限の設計は、3つの役割から始める
ロールと権限は、細かく作るほど正確になりますが、同じだけ運用が重くなります。5人から数十人のチームなら、最初は3つの役割で足ります。
1つ目が「進行のとりまとめ役」です。プロジェクトの設定、工程表の変更、チケットの一括操作、完了への遷移を担当します。人数は1名か2名に絞ってください。ここを3名以上にすると、工程表を同時に触って上書きが起きます。
2つ目が「作業する人」です。チケットの起票、自分の担当分のステータス更新、コメント、工数の入力ができます。他人のチケットの期日を動かす権限は与えません。与えると、遅れの原因が誰の判断だったのか追えなくなります。
3つ目が「見るだけの人」です。営業、経営層、発注元の担当者などがここに入ります。閲覧とコメントだけができる形にします。ここで注意が要るのが人数の数え方で、価格表の記載によれば、契約対象になる人数はRedmineに登録されているユーザーのメールアドレスの数です。見るだけの人にもアカウントを配れば、そのぶん契約人数に乗ります。月次の報告を見るだけの相手なら、画面を配るのではなく出力した資料を渡すほうが安く済むこともあります。
また、システム管理者は所属しているプロジェクトに関わらず無条件にカウントされる旨も価格表に書かれています。運用のために作った管理用アカウントが3つあれば、3人分です。権限の設計は、使い勝手だけでなく毎月の金額にも直結します。
定例の30分を、どう使うか
道具が定着するかどうかは、週に1回の定例の中身でほぼ決まります。ここで画面を開かないチームは、道具を別の場所に置いたままになります。30分の配分を提案します。
最初の10分は、ダッシュボードで赤の状態を潰す時間です。期日超過と遅延のチケットを上から順に見て、その場で期日を引き直すか、担当を変えるか、閉じるかを決めます。判断を持ち帰らないことが肝心で、持ち帰った瞬間に翌週も同じチケットが並びます。
次の10分は、工程表を動かす時間です。日々の遅れはチケット側に記録されているので、ここでは棒の位置だけを直します。前の節で書いたとおり、棒を動かすのはこの時間だけと決めておくと、工程表が合意した計画として意味を持ち続けます。
残りの10分は、来週の分を作る時間です。翌週に着手するチケットに担当と期日を入れます。ダッシュボードの黄色の状態（更新停滞、担当者未設定、予定工数未設定）は、まだ遅れていないが火種になりうる項目として自動で拾われるので、この時間に潰しておくと翌週の赤が減ります。
この30分を4週続けると、更新の習慣がだいたい付きます。逆に、定例で画面を開かないまま「各自で更新してください」と依頼するだけの運用は、現場ではほぼ続かないと言われています。道具の設定より、この30分を守るほうが効果が大きい場面は多くあります。
立ち上げの30日を、どう配分するか
30日間の無料トライアルが用意されています。ユーザー数無制限で、クレジットカードの登録は不要、本契約に移るときにプランの変更もできると記載されています。この期間の配分を提案します。
・最初の3日 … プロジェクトを1本だけ作り、トラッカー2種類、ステータス3段、会社休日、通知の絞り込みまでを決める ・4日目から10日目 … 実際の担当者3人から6人に入ってもらい、チケットの起票と状態の更新だけを回す。工程表と工数はまだ触らない ・11日目から20日目 … 工程表を引く。棒は3日から10日の粒度で、依存関係は必要な場所だけ。週に1回だけ動かす運用にする ・21日目から30日目 … 工数の入力を足す。0.5時間単位で、その日の終わりにまとめて入れる形を試す。入力率を数える
この配分にした理由は、負担を一度に増やさないためです。チケットの起票、工程表の更新、工数の入力は、担当者から見るとどれも「本来の仕事ではない作業」です。3つを同時に始めると、いちばん面倒なものから順に止まり、結果として全部が止まります。1週間ごとに1つずつ足していくと、前の週に足したものが習慣になってから次が乗るので、最後まで残る確率が上がります。
各段階で数えておく数字も決めておいてください。10日目に「起票されたチケットの枚数」、20日目に「期日が入っているチケットの割合」、30日目に「工数が入力された日の割合」です。この3つが順に育っていれば、その道具はこのチームで動きます。どれかが最初の週から伸びていないなら、原因は機能ではなく運用の設計にあります。
最後の入力率が、そのまま契約するプランの判断材料になります。工数の入力率が半分を超えないなら、プレミアムの機能は当面使われません。スタンダードで始めて、入力の習慣ができてから上げるほうが無駄が出ません。
なお、2026年9月10日の時点では、提供元が2026年9月3日付で公式サイトのサーバー障害を告知しており、新規トライアルの申し込みと問い合わせを受け付けられない状態が続いています。トライアルを始めたい場合は、運営会社側の問い合わせ窓口を使うか、復旧を待つことになります。
内部の比較データから見た、立ち上げのつまずき方
比較の記録を並べていくと、道具を替えたチームが最初に詰まる場所は、機能の不足ではなく設定の量に集中していることが分かります。決めることが多い道具ほど、決められる人が1人しかいない小さなチームでは止まります。逆に、決めることが少ない道具は、案件が複雑になったときに足りなくなります。この境目がどこにあるかは、チームの規模と案件の型で変わります。
カードを並べるだけで回るチームが、設定の多い道具に移ると持て余します。その落差の実際はTrelloとの比較に書いています。案件を横断してタスクを追う形での違いはAsanaとの比較、ドキュメントと台帳を同じ場所に置く発想との違いはNotionとの比較、表形式で状態を管理する形との違いはmonday.comとの比較にあります。開発の課題管理から入る場合はBacklogとの比較、無料からの入り方はJootoとの比較が近い読み比べになります。全体を見渡したいときは比較の一覧からどうぞ。
こちら側の弱いところも書いておきます。ソースコードの置き場は用意しておらず、外部サービスとの連携の本数を増やす方向にも寄せていません。画面は日本語だけで、自動の取り込みに対応しているのは現時点でTrelloのみです。ワークフローを細かく作り込んで、承認の経路まで道具に載せたいチームには、素直に別の道具が合います。できる範囲はできることに並べ、その範囲をどう区切って売っているかは料金に書いています。
移し替えの手順はTrelloからの移行に、情報の預かり方の考え方は安全性の考え方に、細かい判断はよくある質問にまとめました。立ち上げに詰まったときの相談先も、料金の内側と外側で分かれています。基礎講座（座学と動画）は無料で何名でも参加できるとされる一方、訪問して手を動かすハンズオン形式の講座や、業務フローに合わせた運用の設計を一緒に考える運用支援は、いずれも有料のサービスとして別に用意されています。運用支援については初回の相談が無料と記載されているので、社内に前例がまったくない場合は、この初回相談だけ使ってみる手もあります。
最後にひとつだけ。立ち上げがうまくいくかどうかは、機能の数ではなく「最初の30日で何本のプロジェクトを作ったか」でほぼ決まります。1本で始めて、型ができてから増やしてください。
Q1. 最初に何から設定すればよいですか？
プロジェクトを1本だけ作り、トラッカーを2種類か3種類、ステータスを3段に絞り、会社休日設定を入れ、通知を自分が担当のものだけに絞る。この4つを最初の3日で決めてください。全案件を最初に登録すると、後から設定を直すときに手が回らなくなります。
Q2. 無料のフリープランで工程表の練習はできますか？
できません。公開されている料金ページでは、フリープランの欄に「ガントチャートは含まれません」と明記されています。フリーで触れるのはカンバンと基本機能の一部です。工程表を試すなら、30日間の無料トライアルでスタンダード以上を使う形になります。
Q3. ガントチャートの棒は、どのくらいの細かさで引くべきですか？
1本が3日から10日に収まる粒度が目安です。1日単位で刻むと本数が増えて更新が追いつかず、1か月単位でまとめると途中で遅れが見えません。依存関係の線は「これが終わらないと次が始められない」場所だけに引き、棒を動かすのは週に1回の定例だけに固定してください。
Q4. チケットが更新されないときはどうすればよいですか？
2026年8月18日から、ダッシュボードに「今日のトピック」が常設表示されるようになりました。未完了チケットを遅延・期日超過・未着手・更新停滞・担当者未設定・予定工数未設定の6つの状態で自動集計し、その場で期日や担当者を直せます。朝会で全員がこの画面を開く運用にすると、聞いて回る時間が減ります。