Redmineで進捗をどう見せるか｜報告のために作り直さない組み方
Redmineに進捗を入れているのに、報告の前になると別の表を作り直している。この状態はかなり広く起きています。原因は入力する人の怠慢ではなく、Redmineの画面が報告に使える形になっていないことです。この記事では、報告のために作り直す作業をなくすために、Redmineの中で何を設定し直せばよいのかを順に見ていきます。
進捗の表を2つ持つと、必ず片方が嘘になる
まず、いま何が起きているのかを言葉にします。
Redmineにチケットがある。担当者も期日も入っている。それとは別に、報告用の表がある。エクセルか、スライドか、共有の文書か。会議の前日にとりまとめ役がRedmineを開いて、報告用の表に写す。
この形には、避けられない問題があります。写した瞬間から、2つの表がずれ始めることです。会議の翌日にチケットが更新されても、報告用の表は前日のままです。次の会議までの1週間、決裁する側が見ているのは古い情報です。
そしてもう1つ。写す作業をしているのはとりまとめ役1人なので、その人が休むと報告が止まります。週2時間この作業に使っていれば、月8時間です。年間では96時間になります。
写す作業をやめるには、Redmineの画面をそのまま会議で映せる状態にする必要があります。映せない理由は、たいてい次のどれかです。列が多すぎて何を見ればよいか分からない。終わったチケットが混ざっていて数が読めない。プロジェクトをまたいだ全体が見えない。進捗率が入っていないので割合が出ない。
どれも設定で直せます。順に見ていきます。
Redmineで進捗が見える場所は4つある
Redmineには、進み具合を見る画面が4つあります。それぞれ向いている用途が違うので、混ぜずに使い分けます。
1つ目は、チケットの一覧です。絞り込みの条件を付けて、必要な列だけを並べます。件数が数字で出るので、「開いているのは何件」「期限切れは何件」という話ができます。日々の確認に向いています。
2つ目は、ガントチャートです。開始日と期日を入れたチケットから自動で線が引かれます。全体の期間と、どこが重なっているかを見るのに向いています。
3つ目は、ロードマップです。バージョンという単位にチケットを割り当てると、そのバージョンごとに、終わった件数と残りの件数、そして達成の割合が出ます。締めのある仕事に向いています。
4つ目は、サマリです。プロジェクト全体の課題を、種別別、優先度別、担当者別、分類別に集計した表が出ます。件数の偏りを見るのに向いています。
会議で映す画面は、この4つのうち1つに固定します。毎回違う画面を出すと、見る側が数字の意味を覚えられません。締めのある案件ならロードマップ、複数の案件を横に並べて見るならチケットの一覧、日程の重なりが問題ならガントチャート、という選び方になります。
固定したら、その画面を開くための条件を保存します。保存の仕方は次の節で書きます。会議のたびに絞り込みを作り直しているなら、そこがまず削れる作業です。
保存した条件で、報告の形をそのまま作る
Redmineには、絞り込みの条件を保存する仕組みがあります。公式の説明では、こう書かれています。
Filters you built can be saved as custom queries. And you can apply the saved filters with a single click. 出典: redmine.org
保存するときに名前を付けられ、一覧に表示する列も一緒に決められます。標準の項目も独自項目も列に出せます。公開の設定を入れると全員から見え、入れなければ自分だけに見えます。保存した条件は画面の右側の一覧に並び、1回の操作で呼び出せます。
ここが、報告用の表を作り直さないための中心になります。報告で見せたい形を、そのまま条件として保存しておきます。
具体的には、次のような条件を作ります。
・今週が期日のもの。絞り込みは期日で、範囲を今週にする。列は題名、担当者、期日、ステータス、進捗率 ・期限を過ぎて開いているもの。絞り込みはステータスが未完了、かつ期日が今日より前。列は同じ ・担当者が空欄のもの。誰も見ていない作業を拾うための条件です ・直近30日更新されていないもの。放置されているチケットを拾います
これらは全員に公開しておきます。公開しておくと、各自が会議の前に自分で見られるようになり、とりまとめ役が集計する必要が減ります。
保存した条件は、プロジェクトをまたいで使えるものと、特定のプロジェクトの中だけで使えるものが作れます。複数の案件を横に並べて見たいなら、プロジェクトをまたぐ条件を作ります。
もう1つ。列を欲張らないでください。列が10個を超えると、画面に収まらず横に流れます。会議で映すなら、列は5個から6個までに抑えます。何を見せたいのかが決まっていれば、それで足ります。
進捗率をどう決めるかで、表の信頼性が変わる
Redmineのチケットには進捗率という項目があります。ここの扱いが、進捗管理でいちばん揉めるところです。
決め方は2つあります。1つは、担当者が手で選ぶ方法。0から100まで10刻みで選びます。もう1つは、ステータスに割合を割り当てて、ステータスを変えると自動で決まる方法です。管理画面でこの切り替えができ、ステータス側に割合を設定すると、チケットの進捗率の欄は自動で決まるようになります。
手で選ぶ方法の問題は、意味が人によって違うことです。「50%」が、作業の半分が終わったという意味の人と、時間を半分使ったという意味の人と、なんとなく真ん中という意味の人が混在します。この状態で集計しても、出てくる割合には意味がありません。
ステータス連動にすると、この揺れが消えます。「着手」なら10%、「作業中」なら50%、「レビュー中」なら80%、「完了」なら100%というように決めておけば、誰が触っても同じ値になります。進捗率を選ぶ手間も無くなるので、入力が1つ減ります。
ステータス連動の弱点は、細かさが出せないことです。1件のチケットが2週間かかる場合、その間ずっと50%のまま動きません。これが困るなら、チケットを分割するほうが早い解決になります。2週間を超えるチケットは、たいてい分けられます。分ければ、件数の増減で進みが見えるようになり、進捗率の細かさは要らなくなります。
どちらを選ぶにせよ、チーム内で意味を1つに決めることが先です。決めずに数字だけ集めても、その集計は判断に使えません。
親子チケットと、集計のされ方
大きな作業を分解して、親と子で管理している場合、親の進捗率がどう決まるかを知っておく必要があります。
Redmineには、親チケットの属性をどう扱うかの設定があります。子から自動で計算するか、親に直接入力するかを選べます。自動で計算する設定にすると、親の開始日と期日は子の範囲から決まり、進捗率も子から算出されます。
この設定を確かめないまま親子を使うと、親に入れたはずの日付が勝手に書き換わって混乱します。逆に、親に直接入力する設定のまま子を作ると、子がどれだけ進んでも親の数字が動かず、報告が実態と合わなくなります。
どちらがよいかは、親の位置づけによります。親が「工程のまとまり」を表しているなら、自動計算が合います。親が「それ自体も作業である」場合は、直接入力が合います。混ぜると分からなくなるので、プロジェクトの中でどちらかに寄せます。
もう1点。子チケットの数を増やしすぎないでください。1つの親に子が30件を超えると、一覧で親を折りたたんでも見通しが悪くなります。階層を1段深くするか、親を分けるほうが読みやすくなります。
階層を使わずに、板の上のカードとして並べる形の道具もあります。階層が浅い仕事では、そのほうが更新の手数が少なくなります。考え方の違いはTrelloとの比較で機能ごとに並べてあります。
ロードマップで、締めの単位を作る
チケットの一覧だけを見ていると、「全体としてどこまで来たのか」が出せません。ここで使うのがバージョンです。
バージョンは、もともとソフトウェアの版を表すための仕組みですが、名前は自由に付けられます。「第1次納品」「9月末締め」「フェーズ1」といった名前でかまいません。チケットに対象のバージョンを設定すると、ロードマップの画面にバージョンごとの進み具合が出ます。
ロードマップの画面には、そのバージョンに割り当てられたチケットの総数、終わったものの数、残っているものの数、そして達成の割合が表示されます。会議で「9月末締めは72%まで来ています」と言えるようになります。この1行があるかどうかで、報告の質が変わります。
バージョンを使うときのこつは、期間を短く切ることです。3か月のバージョンを1つ作ると、2か月目まで数字がほとんど動かず、見ても意味がありません。2週間から1か月で区切ると、毎週数字が動きます。動く数字は見られますが、動かない数字は誰も見なくなります。
もう1つ。バージョンに割り当てないチケットを残さないでください。割り当てのないチケットは、ロードマップの数字に入りません。全体の進み具合を出しているつもりで、実際には一部しか数えていない状態になります。定期的に「対象バージョンが空欄」の条件で絞り込んで、拾い上げます。
ガントチャートを報告に使うときの注意
ガントチャートは見栄えがよいので、会議で映したくなります。ただし、いくつか知っておくことがあります。
まず、線が引かれるのは開始日と期日が両方入っているチケットだけです。片方でも空欄だと、そのチケットは線として出ません。一覧では見えているのにガントに出てこない、という現象の原因はほぼこれです。ガントを報告に使うなら、開始日と期日の入力を必須にしておきます。管理画面で、種別ごとに必須の項目を決められます。
次に、表示できる件数に上限があります。管理画面に「ガントチャートに表示する項目の最大数」という設定があり、これを超えるチケットは表示されません。大きなプロジェクトでガントを開いて「途中までしか出ない」場合は、この設定を確かめます。上げすぎると画面の描画が重くなるので、絞り込みで対象を減らすほうが実用的です。
3つ目に、画像として書き出す場合の条件です。ガントチャートをPNG画像として書き出す機能を使うには、サーバ側にImageMagickが入っている必要があります。公式の導入手順では、任意の構成要素としてImageMagickが挙げられ、ガントチャートのPNG書き出しとサムネイルの生成のために必要と記載されています。自分で立てている場合、この構成要素が入っていないと書き出しのボタンが機能しません。
4つ目に、Redmineのガントは線をドラッグして日程を動かす作りではありません。日程を変えるにはチケットを開いて日付を書き換えます。会議の場で日程を調整したい使い方には向いていないので、その用途なら別の道具を並べて検討することになります。ガントの操作感の違いはmonday.comとの比較やBacklogとの比較で項目ごとに整理されています。
作業時間の記録と、進捗を混ぜない
Redmineには作業時間を記録する機能があります。プロジェクト単位でもチケット単位でも入力でき、利用者別、種別別、分類別、活動別の集計が出せます。
ここでよく起きる混乱は、作業時間と進捗を同じ話にしてしまうことです。予定工数10時間の作業に5時間を使ったから50%進んだ、という計算は、多くの仕事で成り立ちません。難しいところで詰まっていれば、時間を使っても進んでいません。
報告で見せるべきは、次の2つを分けた形です。
・進み具合。終わった件数と残りの件数、あるいはバージョンごとの達成の割合 ・使った時間。予定工数と実績の差
この2つを並べると、「進んでいるが時間を使いすぎている」「時間は予定内だが進んでいない」という状態が見分けられます。1つの数字に混ぜると、どちらの状態も見えなくなります。
作業時間の入力を求めるなら、入力の手間を最小にします。チケットの画面から直接入力できる導線を用意し、活動の分類は5個以内に絞ります。分類が多いと、選ぶのに迷って入力が止まります。請求の根拠として使うなど、明確な目的が無いのに全員に時間の入力を求めると、続きません。
サマリの画面で、偏りを見つける
チケットの一覧やロードマップは「どこまで進んだか」を見る画面ですが、サマリは「どこに寄っているか」を見る画面です。会議で毎回映す必要はありませんが、月に一度は開いておきたい画面です。
サマリを開くと、プロジェクトの課題が種別別、優先度別、担当者別、分類別、対象バージョン別に集計された表が並びます。それぞれ、開いている件数と閉じている件数と合計が出ます。
ここで見るのは、次の3つです。
1つ目は、担当者別の偏りです。開いている件数が特定の1人に集まっていないか。よくあるのは、いちばん慣れている人に4割以上が集まっている状態です。この人が休むと全部が止まります。件数が見えると、割り振り直しの話を数字で始められます。
2つ目は、優先度の分布です。優先度が「高」以上のものが全体の半分を超えていたら、優先度の設定が機能していません。全部が高いなら、それは全部が普通と同じです。設定し直すか、優先度の運用をやめて期日だけで判断するほうがすっきりします。
3つ目は、種別の偏りです。「作業」ばかりで「不具合」が0件なら、不具合が別の場所で扱われている可能性があります。別の場所があるなら、進捗の全体像はRedmineだけでは見えていないことになります。
サマリはプロジェクト単位の画面なので、複数の案件をまたいだ偏りは出ません。案件をまたいで担当者の負荷を見たいなら、プロジェクトをまたぐ保存済みの条件を作り、担当者で並べ替える形になります。
通知を絞らないと、期日の連絡が読まれなくなる
進捗の画面を整えても、通知の設定を放っておくと運用が崩れます。通知が多すぎると全部読まなくなり、本当に見てほしい期日の連絡まで流れます。
Redmineでは、通知の範囲を利用者ごとに選べます。関わっているプロジェクトの全部の更新を受け取る、自分が見ているものと自分に関係するものだけ受け取る、自分が担当か作成者のものだけ受け取る、といった段階があります。既定のまま全員が最初の設定になっていると、1日に数十通が届きます。
進行のとりまとめをしている人は、全部を受け取る設定でよいことが多いです。作業者は、自分に関係するものだけに絞ります。この2段階に分けるだけで、読まれる通知の割合が変わります。
もう1つ、更新のたびに自分にも通知が届く設定があります。自分が書いた内容が自分に返ってくるので、これを切ると通知の数がはっきり減ります。個人の設定画面から変えられます。
管理者側では、通知の対象とする出来事を選べます。チケットの追加と更新だけに絞り、Wikiの更新やフォーラムの投稿を通知から外すと、量が半分近くになることがあります。ここは全体に効くので、慎重に決めて全員に伝えます。
通知を絞ると、今度は見落としが心配になります。その対策が、保存した条件です。通知で気づくのではなく、決まった時間に決まった画面を開いて確かめる形に変えます。毎朝1回、「自分の担当で今週が期日」の条件を開く。これが定着すると、通知はほとんど要らなくなります。
社外の協力会社に進捗を見せるとき
進行のとりまとめでは、社内だけでなく協力会社や発注元と同じ画面を見たい場面があります。Redmineでこれをやる場合、決めることが3つあります。
1つ目は、招く場所です。同じプロジェクトに招くと、そのプロジェクトのチケットが全部見えます。見せたくないものがあるなら、別のプロジェクトを作って、そこだけに招く形にします。プロジェクトは入れ子にできるので、親を社内用、子を共有用にする組み方が使えます。
2つ目は、役割の設計です。Redmineでは役割ごとに権限を細かく決められます。協力会社向けの役割を作り、チケットの閲覧とコメントの追加はできるが、他人のチケットの編集や削除はできない、という形にします。作ってみると分かりますが、権限の項目は数十あります。1つずつ見る時間が無ければ、既存の役割を複製して、危ないものだけ外す進め方が早いです。
3つ目は、見せる項目です。独自項目には、特定の役割からは見えないようにする設定ができるものがあります。原価や単価を独自項目で持っているなら、ここを必ず確かめます。一覧の列に出していなくても、チケットの詳細画面には表示されることがあります。
招いた後で確かめるべきなのは、実際に協力会社の側でどう見えているかです。管理者の画面で「見えないはず」と思っていても、設定の組み合わせで見えていることがあります。テスト用の利用者を協力会社の役割で作り、その利用者でログインして目で確かめます。この確認を省くと、後で気づいたときには手遅れです。
外部の人を招く場合の権限やデータの扱いの考え方は安全性の考え方に整理してあります。招く相手が増えると費用の条件も効いてくるので、人数の数え方は先に確かめておきます。
更新されない原因は、たいてい入力の重さ
ここまで見せ方の話をしてきましたが、そもそもチケットが更新されていなければ、どの画面も嘘を映します。
現場では、更新が止まる理由として「意識が低い」と言われがちですが、実際に効いているのは手数です。1件のチケットを更新するのに、開いて、ステータスを選んで、進捗率を選んで、コメントを書いて、保存する。この5手を、1日に10件やると50手です。これが毎日続くと、忙しい日から順に飛ばされます。
手数を減らす方法は、Redmineの中にもあります。
・進捗率をステータス連動にする。1手減ります ・必須の項目を見直す。作成時に必須になっている項目が多いほど、チケットを作るのが億劫になります ・一覧の画面で右クリックして、ステータスや担当者をその場で変える。チケットを開かずに済みます ・複数のチケットを選んで、まとめて変更する。同じ状態にするものが並んでいるときに効きます
このうち、まとめて変更できることを知らないまま1件ずつ開いている人は多くいます。一覧でチェックを入れて右クリックすれば、選んだ全部の状態を一度に変えられます。この操作を全員に伝えるだけで、更新の負担がはっきり下がります。
それでも更新が止まるなら、入力の粒度が細かすぎる可能性があります。チケットを1日単位に割っていると、毎日新しいチケットを作ることになります。3日から5日で終わる大きさに揃えると、作る数も更新する数も減ります。機能で絞らず、区切るのは人数とボードの数だけという考え方の道具では、この粒度の調整がもっと自由になります。
遅れをどうやって早く見つけるか
進捗管理の目的は、進んでいることを確かめることではなく、遅れを早く見つけることです。ところが、期日を過ぎてから気づく形になっている運用が多くあります。過ぎてから気づいたのでは、打てる手が限られます。
早く見つけるには、期日そのものではなく、期日の手前を見ます。具体的には、次の2つの条件を作ります。
1つ目は、「期日が3日以内で、まだ着手されていないもの」です。ステータスが新規のまま期日が近いチケットは、ほぼ確実に遅れます。着手していれば残りが見積もれますが、手が付いていなければ何も分かりません。この条件に出てくる件数は、遅れの先行指標として使えます。
2つ目は、「期日が空欄で、開いているもの」です。期日が入っていないチケットは、どの集計にも遅れとして出てきません。期日が無いまま数か月放置され、あるとき急に「これはどうなった」と聞かれる。この形が繰り返されているなら、期日の入力を必須にする設定を検討します。
もう1つ、期日の変更履歴に注目する見方があります。同じチケットの期日が何度も後ろへずらされている場合、そのチケットは見積もりを外しているか、優先度が実際には低いかのどちらかです。Redmineでは項目の変更履歴がチケットの中に残るので、開けば何回ずらしたかが分かります。3回以上ずらしているチケットが並んでいるなら、計画の作り方そのものを見直す材料になります。
遅れを見つけたときにやることも、先に決めておきます。担当者を替えるのか、期日を動かして後ろの工程に伝えるのか、範囲を削るのか。この3つのうちどれかしかありません。会議の場で「がんばります」で終わると、次の週も同じチケットが同じ場所に出てきます。
会議の前にやることを、3つに減らす
最後に、報告用の表を作り直さない状態がどういうものかを、具体的に書きます。
会議の前日、とりまとめ役がやることは3つだけです。
1つ目。「担当者が空欄」と「30日更新なし」の保存した条件を開いて、出てきたチケットを担当者に投げる。数分で終わります。
2つ目。ロードマップを開いて、締めの単位ごとの達成割合を確かめる。数字が想定と大きく違えば、その理由を担当者に1つ聞く。
3つ目。会議で映す画面を開いておく。画面は1つに固定してあるので、迷いません。
これだけです。写す作業も、集計する作業もありません。会議の場では、その画面をそのまま映して、数字が動いていないところだけを話します。
この形が回り始めると、会議の時間そのものも短くなります。数字を読み上げる時間が要らなくなり、動いていないところの理由を聞く時間だけが残るからです。1時間かけていた進捗の会議が30分で終わるようになった、という話はよく聞きます。参加している人数を掛けると、削れる時間はかなり大きくなります。
この形にするために必要な準備は、保存した条件を数個作ること、進捗率の決め方を1つに決めること、バージョンで締めの単位を作ること、この3つです。どれもRedmineの設定の中で完結します。導入している道具を替えなくても、ここまでは詰められます。
そのうえで、それでも更新が続かないなら、道具の側の手数の問題です。入力の手数がどう違うのかはできることに機能ごとの説明があり、費用の条件は料金で比べられます。他の道具との違いを機能単位で見たいときは比較の一覧から、いま使っているものに近い項目を選んで読むのが早い進め方です。運用に乗った後で出てくる細かい疑問についてはよくある質問にまとまっています。
Q1. Redmineの進捗率は、手入力とステータス連動のどちらがよいですか？
チームで意味を1つに決められるなら、ステータス連動が確実です。管理画面でステータスごとに割合を設定すると、誰が触っても同じ値になり、入力の手数も1つ減ります。細かさが足りないと感じる場合は、2週間を超えるチケットを分割するほうが早く解決します。
Q2. 報告のたびにエクセルへ写す作業をやめられますか？
やめられます。報告で見せたい形を絞り込みの条件として保存し、表示する列も一緒に決めておきます。公開の設定を入れれば全員から見えるので、とりまとめ役が集計する必要がなくなります。会議で映す画面は1つに固定してください。
Q3. ガントチャートに一部のチケットが出てこないのはなぜですか？
線が引かれるのは開始日と期日が両方入っているチケットだけです。片方でも空欄だと出ません。もう1つ、管理画面にガントチャートの表示件数の上限設定があり、これを超えた分も表示されません。絞り込みで対象を減らすのが実用的です。
Q4. 全体の達成割合を報告で出すにはどうすればよいですか？
バージョンを作り、チケットに対象のバージョンを設定してください。ロードマップの画面に、総数と完了数と残数、達成の割合が表示されます。期間は2週間から1か月で区切ると毎週数字が動きます。対象バージョンが空欄のチケットは集計に入らないので、定期的に拾い上げてください。