チケットの書き方 - Qiita

メンバーの一部がスムーズに情報共有できるチケットを書けず 苦戦しており、相談を受けた時に色々言った内容を 書き起こしたもの。 荒いけど誰かの参考になるかもしれないので共有。 2019/09/07 宣伝追記 技術書典サークル参加します。 チーム運営どう考えて何をやったかまとめた本とセキュリティの 入門書を頒布するので気になった方は是非。 https://techbookfest.org/event/tbf07/circle/5671044488626176 書いた人の環境 業務ツールとしてチャット、Redmine、Wikiを使用。 チャットで会話して相談・整理・調整する。 タスク、課題はチケット化して管理。 ナレッジはWikiに書いて共有。 業務内容はシステム開発と運用保守でソフトウェア開発ではない。 Redmineはタスク・課題管理に使用。 以下、メンバーに伝えたことを清書したもの。 前提

[skyfall007]

“事実か否かは厳密に分けて書くこと。” これ大事だよねえ

[kino2nd]

こういうの気にしないベテラン見かけると辛い、属人化の鬼

[sasasin_net]

非常によいガイドライン。「ちゃんと書いてください」「具体的には」「この記事を読んでください」ができるようになり画期的

[name-25137412]

憶測や勘も書いていいけど事実と混ぜるな、はチケット以外にも通じる至言

[nishiotsutomu]

書き方を書くの大事

[ku_marin]

“事実、憶測、勘をきちんと明確に分ける”

[braitom]

スムーズに情報共有できるためのチケットの書き方について。何を書くべきか、細かく書かないといけない理由、事実/憶測/感を明確に使い分けるなど。

[hinatadegorone]

最近、最低でも Purpose, Approach, Definition of Delivery を書くといいよって教えてもらって実践してる。特にこのチケットのゴールが何なのかを明記するの大事。

[xlc]

管理者がどこにもおらず、思いつきで仕事してるみたいだな。制御された現場ではチケットでタスクは追加されない。チケットは仕様変更、レビュー指摘、バグ指摘のみとなる。

[turu_crane]

＞後でチケット見返す詳細を忘れた自分は他人。

[findup]

「チャットで会話して相談・整理・調整する」1対1のクローズチャットってことでは無いよねきっと…うちに1対1で会話して物事決める人がいて他人が全く経緯を知らなかったりして辛い

[hase0831]

ためになるガイドラインだ

[masatomo-m]

それなりに実力やコンテキストが共有されている身内相手なら、手順書は起票者じゃなくて作業者が書けばいいとは思う。手順の記録自体は大事よね

[JULY]

あまり意識してないけど、個人的には、だいたい、こんな感じで書けている。逆に、結論だけ書いて、しかも、その結論も別なファイルに書いて、「終わりました」の連絡として書いているのを見ると、イラッとする。

[mayumayu_nimolove]

チケット書くのにそんなに時間かけたくねーわ。ツイッターみたいに140文字制限だけ決めると良い。多少荒削りな文章も理解できる。

[tkmkg8m]

″大原則として「誰が、何を見て、どう考えて、何を決めて、何をして、どうなったか」を明示的にする″。Redmine x チケットじゃなく例えばGitHub x Issueでも大事なことが書いてある。

[nunulk]

"「誰が、何を見て、どう考えて、何を決めて、何をして、どうなかったか」 がはっきりしてないと見た人が判断のために情報収集する手間が掛かる。"