--- title: 使われ続けるRedmineの運用法 tags: #第23回redmine大阪 author: [ワテ](https://www.docswell.com/user/wate) site: [Docswell](https://www.docswell.com/) thumbnail: https://bcdn.docswell.com/page/PEXQ9RPZJX.jpg?width=480 description: 導入したはずのRedmineが、いつのまにか使われなくなる。その裏には運用と入力にまつわる2つの原因があります。 書く人も見る人も迷わないチケットの構成と、登録時点でAIが情報を補うヒアリングを組み合わせた、 無理なく使い続けられる運用の工夫をお話しします。 published: September 06, 26 canonical: https://www.docswell.com/s/wate/5Y8Q4P-2026-09-06-121229 --- # Page. 1 ![Page Image](https://bcdn.docswell.com/page/PEXQ9RPZJX.jpg) Redmine大阪 2026-09-05 使われ続けるRedmineの運用法 ワテ # Page. 2 ![Page Image](https://bcdn.docswell.com/page/3EK9PRDVED.jpg) 自己紹介 ワテ • 自社プロジェクトとクライアント支援の両方でRedmineを運用 • フリーランスとしてRedmineの構築・運用設計を支援 • 現場で自分が苦労した経験を共有し、同じ悩みを持つ人の役に立ちたい 01 / 12 自己紹介 # Page. 3 ![Page Image](https://bcdn.docswell.com/page/L73WX8PQ75.jpg) 導入したはずのRedmineが、 使われなくなっていく。 そんな経験、ありませんか? 02 / 12 つかみ # Page. 4 ![Page Image](https://bcdn.docswell.com/page/87DK2MLWJG.jpg) プロジェクト管理ツール導入の動機 情報は、気づけば散らばっていく。 チャット・口頭・個人の頭の中に情報が分散し、プロジェクトが属人化する。 情報の一元化は、プロジェクトを健全に保つための必要条件。 今回はRedmineを使って、この課題への向き合い方を考えていく。 もちろん、他のツールを使っていても同じ話です。 03 / 12 導入の動機 # Page. 5 ![Page Image](https://bcdn.docswell.com/page/VJPK1R2XE8.jpg) なぜ運用が定着しないのか 大きく2つの観点が考えられる。 04 / 12 全体像 観点1 観点2 運用設計を 整える余地 入力のしやすさを 高める余地 # Page. 6 ![Page Image](https://bcdn.docswell.com/page/2EVVYRD3EQ.jpg) 観点1: 運用設計を整える余地 初期データは最小構成。運用設計を加えずに始めると悪循環が起きる。 1 デフォルトのまま運用開始 2 足りない項目が随時発生 3 場当たり的にトラッカー追加 この悪循環が繰り返される 4 取り決めなく各人が運用 5 構造が整理されない状態 05 / 12 観点1: 課題 # Page. 7 ![Page Image](https://bcdn.docswell.com/page/57GL9MYYEL.jpg) 観点1: 結論 — トラッカー構成のベストプラクティス案 対応未定のものを受け止めるトラッカーを、ベストプラクティスとしてあらかじめ用意する。 対応段階 検討段階 アイデア 背景・理由は未言語化でよい入口 タスク 不具合 具体化 トラッカーを変更 要望 背景・理由がある程度分かっている 優先度だけでは表せない「準備状態」を、トラッカーの時点で識別できる。 06 / 12 観点1: 結論 運用保守・問い合わせ など # Page. 8 ![Page Image](https://bcdn.docswell.com/page/4EQYWRM6JP.jpg) 観点2: 入力のしやすさを高める余地 気軽な登録と情報量はトレードオフ。後から人が埋めても負荷が移るだけ。 入力が手間に感じる 何を書けばいいか考えるのが負担になる チケットが育ちにくい 登録時の薄い内容のまま止まる 「Slack で話す方が早い」 読んでも分からず、結局その場で聞く 実態と差が出てくる Slack でまとまった話がチケットに戻らない 運用が定着しにくい 後から見ても何をしたかったか分からない 07 / 12 観点2: 課題 # Page. 9 ![Page Image](https://bcdn.docswell.com/page/KJ4WK8VM71.jpg) 観点2: 結論 — 節目ごとにヒアリングするというベストプラクティス 人が何を書くか考えるのではなく、節目ごとにAIがヒアリングする。チケットは書き足されながら育っていく 。 登録時 トラッカー変更時 着手時 What / Why の2つだけ 対応に必要な不足分を追加 ヒアリングは基本不要 思いついた時点で気軽に置ける やると決めた段階で詰める 育った状態になっている 思いつきで置いたチケットが、着手する頃には自然と育っている。 ミーティングで話す前にチケットへ書いておく。Redmineを起点にすれば、議論もそこに集約されていく。 08 / 12 観点2: 結論 # Page. 10 ![Page Image](https://bcdn.docswell.com/page/LE1YX23Y7G.jpg) 最も伝えたいこと 探す負荷も、書く負荷も、軽くなる。 両方揃って、初めて効いてくる。 トラッカー構成 (探す負荷を下げる) + AIヒアリング (書く負荷を下げる) トラッカー構成があるから、探さなくていい。AIヒアリングがあるから、書くのに悩まない。 だから、Redmineは使われ続ける。 この負荷軽減、実はもう一段効率化できる。 09 / 12 クライマックス # Page. 11 ![Page Image](https://bcdn.docswell.com/page/GEWGNRP1J2.jpg) 音声入力で、手入力そのものをなくす 答え方が変わるだけ。打つ代わりに、話す。 Before: キーボードで入力 After: 話すだけ 1. 質問に、一つずつ打ち込む 2. 移動中や作業の合間は答えにくい 3. 結局、後回しになりがち 移動中でも、作業の合間でも、 話すだけでヒアリングに答えられ、 その場でチケットになる。 10 / 12 手入力ゼロへ # Page. 12 ![Page Image](https://bcdn.docswell.com/page/47ZL3RKXJ3.jpg) どう実現するか 権限や技術スキルの制約に応じて、2つの入口がある。 アプローチ1 アプローチ2 Redmine AI Helperへの機能提案 手元で試せるAIヒアリング 後から見ても分かるチケットが、無理なく登録できる 権限やスキルの制約があっても、今日から試せる 登録するとき、AIが必要なことを聞いてくれる。答えるだけ でチケットが埋まる。 詳しくは懇親会で。 11 / 12 橋渡し Redmine本体には手を入れず、Claude Desktopのプロジェ クト機能でヒアリングし、Redmineへ登録する形。手間はあ るが、体制を問わず今すぐ試せる。 # Page. 13 ![Page Image](https://bcdn.docswell.com/page/YJ6WXRQPJV.jpg) まとめ 01 運用が定着しない 2つの理由 02 それぞれの結論 03 組み合わせて 初めて機能する 運用設計の余地／ トラッカー構成／ 探す負荷も書く負荷も 入力のしやすさの余地 AIヒアリング 両方揃って軽くなる。 使われ続ける運用に 12 / 12 まとめ # Page. 14 ![Page Image](https://bcdn.docswell.com/page/GJ5MX8RPJ4.jpg) 関連リンク • Handy(オープンソースの音声テキスト変換アプリ) handy.computer • Aqua Voice(音声入力サービス) aquavoice.com • Structured Prompt-Driven Development(SPDD) martinfowler.com/articles/structured-prompt-driven/ バックアップ