RedmineやBacklogなどのプロジェクト管理ツールを使い慣れていない組織だと、課題・チケットを担当者に対しての依頼形式で書く人が多いのですが、色々と問題があるのでやめたほうがいいです。

対象

ここでは開発チーム内で自分達がやるべきタスクを管理するようなプロジェクトを対象とした話をします。

部署間での作業依頼を管理することを目的にしたプロジェクトは対象外です。

尚、ツールによって「課題」「チケット」など呼び方は違いますが、ここでは「課題」と表現しています。

依頼形式で書かれた課題とは

依頼形式で書かれた課題とは、課題登録者が担当者に対しての作業依頼という形になっているものです。

件名:
xxx機能追加のお願い

内容:
Aさん
xxx機能の開発をお願いします。
仕様は以下の通りです。
- xxxの時にはxxxになるようにしてください。
- xxxはxxx機能を参考にしてください。

ここまで極端な例は稀ですが、「xxxをお願いします」と書かれた課題は結構見かけます。

依頼形式で書くことの問題点

課題を依頼形式で書くことが多いプロジェクトでは、以下のような問題が発生することがあります。

• 担当が決まるまでタスクが管理されない
• 人に依頼するタスク以外が管理されない
• 着手中のタスクしか管理されない
• 残タスクがわからない
• 依頼者以外が課題を編集しづらい

担当が決まるまでタスクが管理されない

依頼形式の課題は担当者に依頼する形で書かれるので、担当者が決まってから登録されます。
逆に言うと、担当者が決まるまでは課題が登録されないことになります。

つまり、プロジェクトでやるべきタスクが発生してから担当が決まるまでの期間は、タスクが管理されてない状態になってしまいます。

人に依頼するタスク以外が管理されない

依頼形式の課題は人に依頼する形式で書くので、作業を依頼する立場のリーダーや上流工程の担当者が自分でやるタスクは登録されない傾向があります。

こういった立場の人のタスクは仕様検討や調査、他部署との調整といったクリティカルなタスクになるのですが、これらの重要なタスクが管理されていないことが多いです。

着手中のタスクしか管理されない

依頼形式で課題を書いていると、担当が決まっていてもすぐに着手するタスク以外は登録しない傾向があるようです。

恐らく担当者が混乱しないように直近のタスクのみ登録しているのかもしれませんが、これだとプロジェクト全体のタスクが把握できない状態になってしまいます。

残タスクがわからない

前述したように依頼形式で課題を書いていると一部のタスクしか管理されないので、残タスクがわからない状態になってしまいます。

依頼形式の課題しか書かないようなプロジェクトでは、以下のような状況に陥りがちです。

• プロジェクトスタート直後の上流工程の段階ではタスク管理が全く行われず、スケジュールがわからずに無駄に日数が経過する
• 実装がスタートする頃になってタスクが登録され始めるが、直近のタスクしか登録されていないので残タスクがわからないまま炎上状態となる

依頼者以外が課題を編集しづらい

依頼形式で課題を書かれると、担当者が課題を編集するのが難しくなります。

例で示したような書き方をされた課題に仕様の記述漏れがあったとして、担当者が課題を編集するとしたらどのように記述すれば良いでしょうか？

• 他の部分と同じように「して下さい」という文言で追記する
  • 自分自身への依頼として書くので、なんかむず痒い
• 追記する部分だけ「xxxとする」という形式で追記する
  • 文体が違うので読み返すとそこだけ違和感がある

どうすればいいか

依頼ではなくタスクを書くようにする

担当者への依頼として書くのではなく、プロジェクトでやるべきタスクとして記載します。

件名:
xxx機能追加のお願い

内容:
Aさん
xxx機能の開発をお願いします。
仕様は以下の通りです。
- xxxの時にはxxxになるようにしてください。
- xxxはxxx機能を参考にしてください。

↓

件名:
xxx機能追加

内容:
xxx機能を開発する。
仕様は以下の通り。
- xxxの時にはxxxになるようにする。
- xxxはxxx機能を参考。

担当者宛のメッセージはコメントに書く

担当者へ伝えたいことがあれば、課題の本文ではなくコメントで記載します。

コメント:
Aさん
今のタスクが完了したらこちらをお願いします。

プロジェクトでやるべきタスクを網羅する

プロジェクト管理ツールの課題は、プジェクトでやるべきタスクを管理する為のものです。

タスク管理は、一部のタスクだけ登録していてはできません。
プロジェクトでやるべきタスクを網羅的に管理してこそ意味があります。