チケット説明欄に書いていいのは「会話のメモ」だけ

複数ベンダーが参加する月次定例に向けて、結節点チケットの説明欄にできる限り情報を詰め込んだことがあります。「見れば全部わかる」状態を目指したつもりでした。ところが会議が始まると、誰も説明欄を見ておらず、チケットより先に口頭確認が動いていました。そこから「書くべきでない情報がある」という考えに至るまで、少し時間がかかりました。

説明欄が「形骸化」していませんか？

複数チーム・複数ベンダーにまたがるプロジェクトを管理していると、チケットの説明欄がいつも二極化します。

• 何も書いていないチケット（誰かが後で書くつもりで放置）

• 誰も読まない長文が詰まったチケット（網羅しようとして飽和）

後者のほうが問題に見えますが、実際は前者と同じ状況です。情報があっても参照されないなら、ないのと同じです。「説明欄を見てください」と伝えた会議で、参加者の誰も内容を把握していない経験は、多くのPMにとって心当たりがあるのではないでしょうか。

「全部書いた」のに誰も読まなかった

ある月次定例で、複数ベンダーが絡む結節点チケットに詳細を書き込みました。関連するバックログのURLも説明欄にテキストとして貼り込みました。「ここを見れば状況がわかる」という設計でした。

ところが翌月の定例でそのチケットを開くと、URLが変わっていたり、別ベンダーが自分のシステムで更新を進めていたりして、説明欄の内容が実態とずれていました。結果として、会議中に口頭で一から確認する時間が生まれ、チケットは飾り物になっていました。

問題は情報量ではありませんでした。「どこに書くか」の設計が間違っていたのです。

「書ける情報」と「書くべき情報」は別物

チケット管理ツールには、説明欄以外にも情報を置く場所があります。

• リンク・依存関係: 「関連Issue」などのプロパティ

• 担当・期日: 専用の構造化フィールド

• ステータス・優先度: ビューやフィルタで一覧表示できるフィールド

これらはプロパティとして設定すれば、機能で一覧表示できます。説明欄にURLをテキストで書くと、表記ゆれや書き忘れで検索に引っかからなくなります。「アプローチ」と書いたつもりが「アプローt」と書いていた、というだけで絞り込み結果から消えます。プロパティで設定すれば、そのリスクはなくなります。

私が「説明欄に書く必要がある情報」として残したのは、ひとつだけです。

その場で会話した内容のメモ。

月次定例や調整会議で、そのチケットについてどんな話がされたか。どちらのベンダーが何を確認したか。次回までに持ち越した論点は何か。これは会話の場でしか生まれない情報であり、プロパティでは表現できません。だからこそ説明欄に書く価値があります。

逆に言えば、会話以外の情報は書かない、が基本方針です。

チケットの説明欄を棚卸しする3つの問い

今のプロジェクトで使っているチケットの説明欄を確認するとき、次の問いを当てはめてみると整理がはかどります。

• プロパティで表現できる情報か？（リンク・依存関係・期日・担当）

• 外側から一覧表示できる情報か？（フィルタ・検索で取り出せる）

• 会話でしか生まれない情報か？（その場で決まったこと、温度感、経緯）

3番に該当するものだけが、説明欄に残るべき情報です。1番と2番は、それぞれ適切な機能に移動します。

この棚卸しをしてみると、説明欄に書いていた情報の大半が「プロパティに移せる」か「外側から見えるはずのもの」だったと気がつきます。結果として説明欄はほぼ空になりますが、それが正常な状態です。

自問リストとして使えます。

• 今の説明欄のうち、「関連Issue」プロパティに移せるURLはいくつあるか？

• 説明欄に書いてある情報を、ビュー・フィルタ・検索で取り出せる状態になっているか？

• 説明欄に残った情報は「この場で決まった話」として記録されているか？

「書かない」が場の会話を呼ぶ

説明欄がシンプルであればあるほど、月次定例での会話に必然性が生まれます。「チケットに書いてあるから」で済む情報がなくなると、参加者は集まった場でその結節点の状況を直接確認します。その会話の内容が、次の説明欄に書かれるメモになります。

説明欄に何も書かれていないチケットは、準備不足の証拠ではありません。「会話が必要な場所」として設計された、正しい状態かもしれません。

あなたのプロジェクトで、説明欄が「形骸化している」と感じるとしたら、書き方を変える前に「そもそも何を書くべきか」を一度問い直してみると、見え方が変わります。