プロジェクトを運営する中で、「課題」は出てくるものです。
その課題管理の方法は、BacklogやRedmine、はたまたExcelやGoogleスプレッドシートなど、様々です。当然、ChatWorkで質疑応答をすることもあるでしょう。
今はBacklogを利用することが多いので、Backlogを基準に記載しました。
伝わらない課題
究極に簡潔すぎる件名
伝わらない例
PROJECT-1 確認依頼
「何を」が汲み取れないため、件名から課題の概要が掴めません。
伝わる例
PROJECT-1 ○○画面で■■のボタンが押せなくなるので確認してほしい
件名に主語と述語を加え、何を確認してほしいのか伝えると良いと思います。
ポイント
5W1Hを意識する
※What(何を), When(いつ), Why(なぜ), Where(どこで), Who(誰が), How(どのように)
5W1Hを全て加える必要はありません。
なぜなら、課題の詳細に、期限日(When)、担当者(Who)が含まれているからです。
件名には、何を(What)をどうする(How)のかを意識するだけでも伝わりやすくなります。
主語と述語を意識する
不具合の報告に課題を発行する時に
PROJECT-1 【バグ】●●画面
と記載されてもまったくわかりません。
ここに主語と述語を加えて、改善します。
PROJECT-1 ●●が、●●画面で、●●を行うと、●●となる。
などとして、不具合の事象が予測できるようにすると伝わりやすいです。
ちなみに、【バグ】等は課題の種別で設定するなどし、件名にタグは入れないようにすると良いと思います。
件名と詳細が合っていない
PROJECT-1 ○○画面で■■のボタンが押せなくなるので確認してほしい
詳細：
修正をお願いします。
件名は確認すると表記しているのに対し、詳細は修正してくれ。と記載されています。
第三者が件名を見ると、対応内容に齟齬が生まれるため、気をつけましょう。
PROJECT-1 ○○画面で■■のボタンが押せなくなる
詳細：
再現確認を行ってください。
修正が必要なら修正をお願いします。
憶測が生まれる表現であれば、書かないほうが良いです。
詳細欄で明確な依頼を行ないましょう。
文章が長すぎる詳細欄
PROJECT-1 ○○画面で■■のボタンが押せなくなるので確認してほしい
詳細：
件名の通りの事象が発生しています。再現手順は、●●のユーザで◯◯画面に遷移したあとに、▲▲▲のを■■■しました。その結果、■■のボタンが押せなくなりました。この場合は、■■のボタンは押せないのが正しい動きなのでしょうか、それとも、■■のボタンは押せる必要があるのでしょうか。その場合、どのような条件で押せるべきなのか確認してください。
頑張ればわかりますが、結局なにが言いたいのかわからなくなります。
PROJECT-1 ○○画面で■■のボタンが押せなくなるので確認してほしい
詳細：
再現手順
1. ●●のユーザで◯◯画面に遷移する。
2. ▲▲▲のを■■■する。
発生事象
■■のボタンが押せなくなった。
期待動作
不明
確認事項
■■のボタンは押せないのが正しい動きなのか、■■のボタンは押せる必要があるのか。
押せる必要がある場合、どのような条件で押せるべきなのか確認したい。
ある程度、観点を纏めて箇条書きを含めて説明すると伝わりやすいです。
件名にタグはいらない
PROJECT-1 【バグ】●●が、●●画面で、●●を行うと、●●となる。
種別： バグ
種別にある情報をわざわざ件名に入れる必要はありません。
カテゴリ等で活用できない場合は仕方ありませんが、可能であればカスタムフィールドの利用を検討してはどうでしょうか。
重要なことは詳細に追記する（詳細を編集する）
PROJECT-1 ●●が、●●画面で、●●を行うと、●●となる。
種別： バグ
詳細：
再現手順
1. ●●のユーザで◯◯画面に遷移する。
2. ▲▲▲のを■■■する。
発生事象
■■のボタンが押せなくなった。
期待動作
不明
確認事項
■■のボタンは押せないのが正しい動きなのか、■■のボタンは押せる必要があるのか。
押せる必要がある場合、どのような条件で押せるべきなのか確認したい。
...
コメント：
▲▲▲が◯◯のとき、■■のボタンは押せるべきです。
コメントで、確認結果が連絡された場合、この重要なコメントはこのまま放置すれば、別のコメントでコメントのログが流れてしまいます。
確認担当者と、改修担当者が違う場合、コメントを追わないとわからなくなります。
確認担当者と、改修担当者が同じだとしても、対応日まで期間が空いてしまうと、忘れてしまいます。
結局、流れてしまったログを追ってコメントを確認したり、確認し直す必要が出ていまいます。
詳細：
再現手順
1. ●●のユーザで◯◯画面に遷移する。
2. ▲▲▲のを■■■する。
発生事象
■■のボタンが押せなくなった。
期待動作
▲▲▲が◯◯のとき、■■のボタンは押せるべき
上記の通り、期待動作を更新し、確認依頼は削除してしまうのが良いでしょう。
種別やカテゴリーを使い倒す
| 種別 | 説明 |
|---|---|
| タスク | 何にも属さないが、作業が必要なこと。 |
| 要望 | 要望事項。明確な要望がある課題に設定する。 |
| 問題 | 問題。解決すべき課題に設定する。 |
| 質問 | 質問事項。質問に回答がされたら終了させる。回答により作業が発生したら課題を作成する。 |
| リスク | 懸念事項。潜在的なリスクに気づく為に設定する。 |
そもそも、課題を発行する時点で、その課題はタスクとなります。
タスクに対する種別を与える工夫をしましょう。明確に種別を与えられないケースには使えます。
カテゴリーも同様です。
| カテゴリー | 説明 |
|---|---|
| 計画 | スケジュールに関わる課題に設定する。 |
| 環境 | 環境に関わる課題に設定する。 |
| ◯◯工程 | 各工程で発生する課題に設定する。 |
| ◯◯機能 | 課題に対する機能に設定する。 |
| ◯◯誤り | 不具合に対する品質見解を設定する。 |
カテゴリーは、種別と掛け合わせて効力を発揮します。
きっちり管理しないと複雑になるだけですが、その時その時の状況でカスタマイズすると良いでしょう。
種別やカテゴリーを駆使すると、規模が大きなプロジェクトになるにつれて、
Backlogの課題検索機能を十分に活用できるようになるはずです。
長い期間クローズされない課題を作らない
課題が長い期間オープンされたままの状態に良いことはありません。
永遠のコメント地獄への一本道です。
PROJECT-2 テスト後の修正依頼
種別： バグ
詳細：
1つ目は、□□の○○が動いてない。
2つ目は▲▲の●●がない。
3つ目は・・・
全部直すのに1ヶ月掛かるとします。この課題は1ヶ月以上オープンされたままです。
たとえ詳細に書かれた 999/1000 の依頼内容を終えていようと。
途中で作業者が変わった場合、この作業者は戦慄を覚えるでしょう。
重要なこと
考えないと理解できない課題は駆逐しましょう
- 表題がキャッチコピー化している
- 詳細が曖昧な表現だらけ
- コメントに歴史を刻む
- どんな目的を達成して完了になるのか不明
こんな課題は纏めて削除です。
作り直したほうが幸せになります。
最後に
Backlog、というキーワードで記載しましたが、
RedmineやExcel管理の課題管理をしている場合も同じです。
第三者に伝わらない課題は ノートに書かれたメモ書き だと思っています。
質疑の嵐を生まないためにも、このメモをきっちり纏めて 伝わる日本語 で記述することを意識すると良いと思います。
プロジェクトメンバー同士で指摘しあい、
伝わる課題を起票できるようにすることが大事だと思います。
プロジェクトメンバー間で繰り返すことで、
いつ(When)
どこで(Where)
誰が(Who)見ても、
何を(What)
なぜ(Why)
どのように(How)しなければならないか
が、わかるようになると思います。
クドいようですが、プロジェクトリーダーだけが実施することではありません。
他人事には捉えず、プロジェクトを円滑に回すために自分事として取り組めれば幸せになれます。
「伝わる課題」は、「伝えたいという気持ち」から出来上がると思います。