開発タスクの決まり方は組織によって色々だろうけれど、いきなりポンとタスクを渡されて 「そもそもこれなんでやるんだっけ？」「他のタスクと比べて今やる意味あるんだっけ？」という気持ちになったことはないだろうか。工数かかるなーと思いながらよくよく課題を聞いてみたら、実はもっと簡単なやり方でスマートに解決できそうだったとか。
開発する時には、課題と解決策の納得感を持って進めたい。結果的にその解決策の筋がよかったとしてもだ。こういった意識を持っている開発者は意外と多い印象だが、チームで働く上でそのマインドを統一するのは意外と難しい。
そこで、開発タスクを決定する際の思考整理としてIssueテンプレートというものを用意してみたことがある。やろうとしているタスクに関して、一度このテンプレートに沿って埋めてみるのだ。書いている途中であれ？となるかもしれないし、書いたものを叩き台にして開発者からもっといい解決策を提案してもらえるかもしれない。アイデアを出す時にこれを強いるのはつらいかもしれないので、タスクを決める時の思考整理として使うとよい。
このIssueテンプレートがうまくいったか定量的には測っていないが、少なくとも自分の肌感では解決策だけ渡されて戸惑うといった経験は減ったように思うのでメモしておく。
解決したい課題
- やることではなく、どういう問題を解決したいかを書いてください。
経緯
- どういう経緯で話が出てきたかを書いてください。
- 経緯を聞いてみたらそもそも課題が違った、ということを防ぎます。
やりたいこと
- 解決策として何をやりたいかを書いてください。
- 上で解決すべき課題が明確になっていれば、開発者からより良い解決策を提案できるかもしれません。
予測KPI
- 結果を何の数字で判断するのかを書いてください。
- どのくらいの効果が予想されるのかによって優先度も変わるので、定量的に書いてください。
- 現状の数字がないものも、予測でいいので書いておいてください。
リリース希望日
- 開発やデザインの都合は一旦無視して書いてしまって大丈夫です。
- 希望日の理由があれば書いてください。
- ASAPは優先度を判断できないのでダメです。
リスク
- 数字が下がるなど、考えられるリスクがあれば書いておいてください。
イメージ
- 手書きや他のアプリのキャプチャがあれば貼ってください。
参考リスト
- データのURLや関連するIssueなどがあれば書いておいてください。
ステークホルダー
- このIssueを知っておいてほしい人にメンションしてください。
- 法務など、GitHubにいない人も書いておいてください。
