たまにプロジェクト管理ツールを使っているのに誰も残タスクが分かってないチームを見ます。
何故そんなことが起きるのか？
それはチームメンバーのほとんどが課題を書くのが下手くそだからです。

課題を書くのが下手な人の共通点は日本語ができてないに限ります。
尊敬語？　謙譲語？　そういうこと？
いえ、そんなのなんてどうでもいいです。
伝わる言葉を使える人なら敬語が使えないなんて取るに足らない問題です。

（プロジェクト管理ツールは沢山ありますが、私の会社では Backlog を使っているので、Backlog を例にさせて頂きます。）

伝わらない課題

表題が 5W1H （主語と述語）になってない

BACKLOG-1 確認依頼

これでアサインされて自分が何をすればいいかが分かる人はエスパーです。

BACKLOG-1 ○○画面で■■のボタンが押せなくなるので確認してほしい

これが正しい言葉の使い方です。
もちろん、5W1H の要素をすべて使う必要はありません。
何がどうなの？　何をどうするの？
これだけでも十分伝わります。つまり主語と述語が必要なのです。

表題と詳細が噛み合ってない

BACKLOG-1 ○○画面で■■のボタンが押せなくなるので確認してほしい
詳細：
修正をお願いします。

表題は確認するなのに詳細は直せ。
確認だけかと思って臨むと手厳しいしっぺ返しを喰らいます。
「確認だけなのに、どうして時間がかかってるの？」
などと表題だけ見たプロジェクトリーダーに言われた日には血の雨が降るでしょう。
　

BACKLOG-1 【バグ】○○画面で■■のボタンが押せなくなる
詳細：
状況を確認してください。
修正が必要なら修正をお願いします。

これでやっと文句もなしに「直さないと・・・」と思えてきます。

表題と種別が噛み合ってない

BACKLOG-1 【バグ】○○画面で■■のボタンが押せなくなる
種別： 実装

実装なのかバグのなのか区別できてない。
実装とバグでは対応の仕方が違います。
作業見積もりだって変わりますよね？　仕様変更なら追加料金が発生しますよね？

BACKLOG-1 【バグ】○○画面で■■のボタンが押せなくなる
種別： 社内FB

「すみません！わかりました！直します！」
詳細を見る前でも言える良い課題です。
※ FB: フィードバック。差し戻し、バグ、要望など、多岐の意味で使われます（業界や会社によって異なる事が多いです）。ココではバグという意味で使用しております。

上級編

もっと課題をわかりやすくするための工夫です。

表題にトピックなんていらない

BACKLOG-1 【バグ】○○画面で■■のボタンが押せなくなる
種別： 社内FB

こういった書き方は表題のテンプレートが統一されてなければ意味がありません。
チームメンバーが多ければ多いほどテンプレートは下記のように崩れていきます。

種別	キー	件名
社内FB	BACKLOG-2	【△△の画面】文言間違いがある
社内FB	BACKLOG-1	【バグ】○○画面で■■のボタンが押せなくなる
実装	BACKLOG-3	実装　買い物カゴ機能

はっきり言うと表題の書き方独自ルールなんて覚えたくありません。
よく「パッと見でわかりやすくしたい」と言われます。
そのパッと見はすべてのシチュエーションに対応できているのでしょうか？
その強調は本当に必要ですか？　もっと重要な他の課題の主張を潰してませんか？
　

BACKLOG-1 ○○画面で■■のボタンが押せなくなる
種別： 社内FB

これでも十分見やすいし伝わります。

重要なことは詳細に追記する（詳細を編集する）

BACKLOG-1 ○○画面で■■のボタンが押せなくなる
種別： 社内FB
詳細：
再現できません。
状況を確認してください。
修正が必要なら修正をお願いします。
...
コメント：
○○の画面で◇◇を行うと発生する不具合です。

コメントで調査結果が報告されたとします。とても重要なコメントです。
このまま放置すれば別のコメントによってログが流れてしまいます。
調査した人と修正する人が違ったらどうしますか？
同じ人が修正を行うにしても、それが半年後だったとしたら？
不具合内容がわからなくなります。
コメントを調査しなければなりません。
結局、再調査です。

BACKLOG-1 ○○画面で■■のボタンが押せなくなる
種別： 社内FB
詳細：
○○の画面で◇◇を行うと発生する不具合のようです。
状況を確認してください。
修正が必要なら修正をお願いします。

コメントをすべて確認しなくても状況が分かるようになりました。

※ Backlog は書き直しのログも残るので伝言ゲームのように初めと終わりで内容が異なってしまっても調査が可能です。

別課題を立ち上げる

BACKLOG-1 ○○画面で■■のボタンが押せなくなる
種別： 社内FB
詳細：
○○の画面で◇◇を行うと発生する不具合のようです。
状況を確認してください。
修正が必要なら修正をお願いします。
...
コメント：
この不具合はボタンが押せなくなる事が問題ではありません。
□□が有効でないので■■ボタンが押下できるとデータの不整合が発生します。
問題は「非表示になっていない」もしくは「非活性表示になっていない」ことです。

このように調査の結果、当初に書いた主題が間違っていることが往々にして発生することがあります。
主題や詳細を書き直すべきか迷うところです。
書き直しは必ずしも正義ではありません。
この場合は当初の課題を「完了」または「Close」とし、新しい課題を立ち上げる方が良いでしょう。

BACKLOG-1 ○○画面で■■のボタンが押せなくなる
状態: 完了
完了理由: 対応しない
種別： 社内FB
詳細：
○○の画面で◇◇を行うと発生する不具合のようです。

☆☆さんから ○年○月○日 に調査結果のコメントがありました。
https://xxx.backlog.jp/view/BACKLOG-1#comment-101

この不具合は■■ボタンが押せなくなる事が問題ではありません。
□□が有効でないので■■ボタンが押下できるとデータの不整合が発生します。
問題は「非表示になっていない」もしくは「非活性表示になっていない」ことです。

上記とのことです。
「押せなくなる」の原因は追求できたので、この課題は解消されたこととして「完了」にします。
正しい原因である「非活性表示になっていない」は下記の課題として立ち上げます。
BACKLOG-4 ○○画面で◇◇をすると■■ボタンが非活性表示になるはずがならない

---

BACKLOG-4 ○○画面で◇◇をすると■■ボタンが非活性表示になるはずがならない
種別: 社内FB
詳細:
下記の課題を調査した結果判明しました。
BACKLOG-1 ○○画面で■■のボタンが押せなくなる

修正をお願いします。

完了させる課題には新しく立ち上げた課題を書き、新規の課題には完了させた課題を書くと繋がりが追いやすくなります。
１つの課題が混乱し始めたら課題を「完了」させるという選択も視野に入れた方がいいです。

種別を使い倒す

種別	説明
タスク	どれにも属さない行動すべきこと。
実装	予定されていた実作業。実作業者のタスク。（コーディング等）
先方FB	先方指摘による修正依頼。不具合報告も含む。
社内FB	上記以外、社内指摘による修正依頼。不具合報告も含む。
質問	質問事項。質問に回答がされたら終了させる。回答により作業が発生したら課題を作成する。
要望	要望事項。FBではないもの。検討が必要なものなど。

そもそも「課題＝タスク」ですので「タスク」という種別は「作業者に何も伝えようとしていない」ネガティブな種別です。
種別「タスク」はなるべく少なくなるように心がけるか、そもそも利用しない前提であるといいです。

また、「質問」種別の「質問に回答がされたら終了させる」ことは徹底させるべきです。
質問で求められているのは回答です。必ずしも成果物ではありません。質問には回答で返すようにするべきです。

そして Backlog には素晴らしい課題検索機能があるのですから活用するべきです。
検索機能が有効になると下記のような運用も可能になります。

• 「先方FB」のみを抽出して優先度をつける。
• 「実装」「先方FB」「社内FB」がリリースに含まれるものとしてリリースノートをつくる。
• 「質問」「要望」は技術的情報を交換する場所にする。

検索できることの重要性を軽んじてはいけません。

発生バージョンとマイルストーンを切り分ける

新規プロジェクトでは発生バージョンとマイルストーンが同一になってしまうことがあります。
これを回避するために、「新規開発」という発生バージョンをつくります。
このバージョンはマイルストーンになることはありません。

例：

• v0.0.0 （新規開発）
• v1.0.0 （1st release）

生存期間の長い課題を作らない

生存期間が長い課題にいいことなんて1つもありません。積読の本と同じです。

BACKLOG-7 テスト後の修正依頼
種別： 社内FB
詳細：
１つめは、□□の○○が動いてない。
2つ目は▲▲の●●がない。
3つ目は・・・

全部直すのに半年掛かるとします。この課題は半年以上生き残り続けるのです。
たとえ詳細に書かれた 99/100 の依頼内容を終えていようと。
途中で作業者が変わった時の引き継ぎはどうするのでしょうか？

何よりも重要なこと

考えないと理解できない課題は消滅すべし

• 表題がキャッチコピー（イ◯テル入ってる）
• 詳細がクイズミリオ◯ア（Call 使いますか？）
• コメントが世界史（正しい時系列で記憶してくださいね）
• 何を行動すれば完了になるのかは「神のみぞ知る」（一生終わらない）

こんな課題はゴミ箱へダンクシュートです。

最後に

他人に伝わらない課題は机に書かれた落書きと同等の価値しかありません。
落書きと思われたくないのなら伝わる日本語を書くことを心がけるしかありません。

Aさん「この課題、何言ってるのか分からない・・・」
Bさん「直します！」

Bさん「マイルストーンが違う。検索に紛れ込んでるよ。」
Aさん「あ、直しますー。」

これを沢山繰り返せば、
　いつ(When)
　どこで（Where）
　誰が（Who）見ても、
　何を（What）
　なぜ（Why）
　どのように（How）しなければならないか
わかります
プロジェクトリーダーだけがやるのではありません。
みんなでみんなの課題の書き方を指摘しあうのです。
これも１つのプロジェクトに参加することだと思います。

追記（2017/02/01）

こちらの記事が最近読まれていることを受けて、少し書き足したいと思います。
上記、書いたことはかなり攻撃的に見えると思います。
でも本当に言いたいことは無駄な言い争いを避けて円滑にプロジェクトを回すために思いやりの心を持とうということです。

自分が分かりやすいではなく、相手に分かりやすいを心がけてください。
「伝わる」とは「伝えたい」という気持ちから出来上がると思うのです。

指摘するときは、否定的な正論ではなく、肯定的な正論にしてください。
この記事を読んで実行しようと思って下さった方々に、私からよろしくお願いしたいと思います。