Redmineおじさん
近頃Redmineおじさん業をやっています。自分のチームでやってるサービスの改善についてチーム内でちゃんと課題・タスク管理やっていくぞという機運が高まり、取り敢えずExcelでやっていたやつをRedmineに移して使い始めた。自分以外はほぼ使ったことがなかったのでまずは書き始められるようにと、以下の内容をRedmineのWikiに書いて共有しました(多少変えてるけどほぼ同じ内容)。
チケットの起票のしかた
Redmineで管理するもの
このRedmineで管理するのはサービスの課題と課題に対するタスクです。
そもそも課題とタスクってなに？
- 「課題」は起きている「事象」です
- 「タスク」は課題を解決するためにする「作業」です
チケットって何をするもの？
- チケットは管理対象の課題・タスクを記録するためのもの
- タスクの内容、担当者、ステータス、タスクの履歴を入力する
- チケット≠課題を書いた付箋。課題を書くだけではなく、担当・ステータス・作業履歴等を記録するためのもの
何をすればいいの？
- やることは「チケットの登録」「チケットを完了にする」「記録を残す」の3つのみ
- 上記を取り敢えずやっていれば大丈夫です
チケットの起票
- チケットは、各担当者が気付いた時に発行する
- 重複しても良いので起票する。(後から消せばいいし、誰も登録しないよりは100倍マシです)
- 起票した後に内容を色々変えるのは問題なし。やりつついい感じに修正していきましょう
- 不要になったチケットはプロジェクトの管理者が廃棄しましょう
チケットの書き方
- 概要(背景、目的、理由等)、やる事、完了条件 を基本的に書く(テンプレート化している)
「大きな課題」は親チケット(粒度が大きい)にして、子チケット(粒度細かい)に分割する
- 大きい場合は親チケットを起票し、さらに親チケットに紐づく子チケットを複数起票してタスク分解する
- 粒度が巨大すぎるとどこから手を付けていいか分からず、チケットが完了しない
- ひとつのチケットに複数の課題を書かないようにする
チケットの粒度について
- チケット名が「~~~ について」といった曖昧な形式になっているのは宜しくない。多少説明的でも、チケット名だけで作業のイメージができるように心がける
- 逆に粒度が細かすぎるのは不要 ⇒ 例「シャワーを浴びる」を「タオルを準備する、お湯の温度を調整する、シャンプーを手に出す」などのレベルに細かく分けなくて良い
- 伝言レベルの話やルーチンワークはチケットとして起票しなくても良い
- 感覚的に5分～10分で終わるようなものは単一チケットにしなくて良さそう
- 作業時間で30分～数時間～半日ぐらいの範囲が目安かも？
- 数日以上かかるようなものは子チケットに分解した方が良さそう
- やる活動の要約よりも、”タスクが完了した状態の要約”を名前に書くと分かりやすい (○○を確認する ⇒ ○○の設定が××か確認する）
起票の流れ
- [チケット] タブを選択する
- [新しいチケット] を選択する
- トラッカーを選ぶとテンプレートが表示されるので選択する
- チケットを登録する
登録内容については以下を参照
| 項目 | 内容 |
|---|---|
| [トラッカー] | チケットの種類を指定する(一覧は下部表を参照) |
| [チケットテンプレート] | トラッカー毎に設定されたテンプレ(デフォルト選択済み) |
| [題名] | チケットの題名。作業のイメージが出来る粒度で入力する |
| [説明] | 概要(背景、目的、理由等)、完了条件などを基本的に書く |
| [ステータス] | 新規の場合は「新規」 |
| [優先度] | デフォルトは「通常」。急ぎの場合は「高」「緊急」を利用。期日が遠い、重要度が低い場合は「低」 |
| [担当者] | 担当者を入れる(自分以外を入れるのも問題ない) |
| [親チケット] | 課題として上位階層のチケットがある場合は入力(必須項目ではない) |
| [開始日] | 基本的に入力する(後から調整可能) |
| [期日] | 基本的に入力する(後から調整可能) |
| [予定工数] | 取り合えずで入れる(時間単位で入れる⇒3.0h等) |
| [進捗率] | 担当者の判断で進捗度合いを入力(完了時は100%) |
| [ファイル] | いまは特に不要(添付したいものがあれば使用) |
| [ウォッチャー] | いまは特に入力不要 |
トラッカー一覧
| トラッカー名 | 内容 |
|---|---|
| ドキュメント整備 | 資料や設計書などドキュメントの作成・更新など |
| 調査・検証 | サービスの調査、技術サポートへの問い合わせや機能検証など |
| 機能追加・変更 | サービスの新機能の開発やプログラム・運用スクリプトの改修や変更 |
| 不具合・バグ | 障害に対する対応や、バグへの対応 |
| ユーザーサポート | 利用者からの問い合わせへの回答、アンケート等の実施 |
| サービス運用 | サービスについてのアナウンス、KPI算出、定期メンテナンス作業 |
| 運用整備 | 監視運用や構成管理の棚卸、連絡体制の整備など |
| アイデア | アイデアレベル、検討レベルのタスクを書いてみる系 |
| その他タスク | 上記以外のその他系 |
バージョンの考え方
- サービスの改善は一気にめちゃくちゃ良くなるということはない。段階的にやっていく必要があり、フェーズを分けて考えていく。
- フェーズ＝バージョンと考え、期間で区切ってやっていくことで、大量のチケット(タスク)を一部集中してやっていけるようにする。
- やることはいっぱいあるが、すべて実施するのは難しい。フェーズ単位でがんばる⇒フェーズを重ねる⇒改善のストーリーになっていく
プラグインは取り敢えず以下を追加。issue templatesとchecklistsは初めてでも使いやすいので便利。agileとeasy ganttはGUIでいじれると良く分かってない人でも感覚的で楽しいので入れた。
まだ初めたばかりで全然だけどガリガリとチケット追加して入力してくれる人もいてありがたい。課題がふわふわ宙に浮いたまま消えていく感じからは変えていけそう。
