課題管理に対する考え方とテンプレ

自分の中の課題管理に対する考え方を整理するため、ブログにまとめておく。

課題を管理する

ソフトウェア開発ではGitHub IssueやRedmineなどで課題を管理する。

基本的に「課題を登録する量 >> 完了する量」であり、多くの課題が登録されるため、優先度をつけて順番に対応していく事になる。

課題に優先度をつける

課題が 一意に並ぶ ように優先度をつけて、上から順番に対応する。

「どの "緊急" の課題を対応すべきですか?」と質問しなくて済む状態にする。

課題の管理工数を意識する

課題が増えると管理する工数も増えるため、以下の2つを意識する必要がある。

  1. 情報を過不足なく、分かりやすく記載する
    • 課題の登録者に質問しないようにする
  2. 少ない工数で解決する
    • 工数の少ない代案を積極的に挙げる

また、代案を出しやすくするため、課題を登録するときに Why(なぜ)とHow(どのように)が混ざらない ように気を付ける。

課題として登録する内容

以下を課題として登録する。

  • 機能要望(Feature Request)
  • バグ修正(Bug Report)
  • 雑用(Chore)
    • ライブラリのアップグレード対応など

開発者の「Modelを実装する」などのタスクを登録し始めると管理工数が増えてしまうため、これらは登録しない。*1

仕様を確認するより、改善要望として登録する

機能が分かりづらいという事なので「UIを改善する」「コードにコメントを残す」などの改善を検討する。

課題に記載する項目

課題管理のテンプレで使えるように、マークダウン形式で項目を記載しておく。

「Howは課題の登録者の提案であり、唯一の解決方法ではない」ことを意識し、開発者は 少ない工数で済むように提案する ことを意識する。

機能要望

<!-- 現状の顧客の課題と要望する機能について記載してください。 -->

## 現状の課題(Why)

## 要望する機能の説明(How)

## 備考

バグ報告

<!-- 開発者がバグを再現・修正できるように、具体的な再現手順を記載してください。 -->

## 概要(Why)

## 再現手順

## 実際の挙動

## 期待する挙動(How)

## 備考

雑用

## 作業内容(How)

## 作業の利点、実施しない場合のリスク(Why)

## 備考

作業内容だけを書きがちなので、実施した時の利点や実施しない場合のリスクも書いておくこと。

*1:一覧に出ない形で別管理はアリ。課題のコメント欄に残すなど