自分の中の課題管理に対する考え方を整理するため、ブログにまとめておく。
課題を管理する
ソフトウェア開発ではGitHub IssueやRedmineなどで課題を管理する。
基本的に「課題を登録する量 >> 完了する量」であり、多くの課題が登録されるため、優先度をつけて順番に対応していく事になる。
課題に優先度をつける
課題が 一意に並ぶ ように優先度をつけて、上から順番に対応する。
「どの "緊急" の課題を対応すべきですか?」と質問しなくて済む状態にする。
課題の管理工数を意識する
課題が増えると管理する工数も増えるため、以下の2つを意識する必要がある。
また、代案を出しやすくするため、課題を登録するときに Why(なぜ)とHow(どのように)が混ざらない ように気を付ける。
課題として登録する内容
以下を課題として登録する。
- 機能要望(Feature Request)
- バグ修正(Bug Report)
- 雑用(Chore)
- ライブラリのアップグレード対応など
開発者の「Modelを実装する」などのタスクを登録し始めると管理工数が増えてしまうため、これらは登録しない。*1
仕様を確認するより、改善要望として登録する
機能が分かりづらいという事なので「UIを改善する」「コードにコメントを残す」などの改善を検討する。
自社開発のwebサービスにおいて、仕様書は作らない方が良いのかもしれない。
— 神速 (@sinsoku_listy) 2022年7月13日
今の動作が正しいわけで、何か動作に違和感あったら、それを改善要望としてIssueに挙げる運用の方が良さそう。
そもそも仕様って「動かない…?いや、それ仕様通りなので、直す必要ないですね」って断る以外に存在価値がない。
— 神速 (@sinsoku_listy) 2022年7月13日
操作性やUXが悪い時点で改善すべき課題なので、Issueに挙げて良いし。(優先度は開発チームで決めるとして)
課題に記載する項目
課題管理のテンプレで使えるように、マークダウン形式で項目を記載しておく。
「Howは課題の登録者の提案であり、唯一の解決方法ではない」ことを意識し、開発者は 少ない工数で済むように提案する ことを意識する。
機能要望
<!-- 現状の顧客の課題と要望する機能について記載してください。 --> ## 現状の課題(Why) ## 要望する機能の説明(How) ## 備考
バグ報告
<!-- 開発者がバグを再現・修正できるように、具体的な再現手順を記載してください。 --> ## 概要(Why) ## 再現手順 ## 実際の挙動 ## 期待する挙動(How) ## 備考
雑用
## 作業内容(How) ## 作業の利点、実施しない場合のリスク(Why) ## 備考
作業内容だけを書きがちなので、実施した時の利点や実施しない場合のリスクも書いておくこと。
*1:一覧に出ない形で別管理はアリ。課題のコメント欄に残すなど