Backlogの課題には「なぜ」を書きなさい！マジで！絶対書きなさい！【仕事の依頼のお作法について】
システム改修において何が困るかっていうと、該当の処理を修正していいのか判断がつかないことである。これは実に困る。
処理の内容はコードを読めばわかる。単純なバグなら修正してそれで終わりだ。しかし、実装された経緯のわからない正常に動いているプログラムほど厄介なものはない。
その処理がどんな経緯で追加されたのか不明
誰の要望によって追加されたのか不明
なぜその処理方法や技術が選択されたのか不明
こうなっちまったら、いざシステムを新たに作り直しましょう！ってなった際に考慮しなければいけないことが無茶苦茶増える。お手上げだ。
Gitのログ見りゃいいじゃんと思う人もいるだろう。それは甘い！
もちろん実装者を探し出すことはできるが皆経緯なんて覚えていない。もしくは指示されたから作ったとか、もう猫にでもなって布団に潜り込みたくなるような回答が得られるだろう。
だから！課題には！「なぜ」を書いてくれ！
具体的には以下を書いてくれ！これはシステム開発だけの話ではない！！
なぜその課題に対応する必要があるのか
なぜその対応方法でなければいけないのか
なぜその期限までに対応する必要があるのか
なぜその課題に対応する必要があるのか
課題対応で解決したい問題およびその問題の起点を必ず書くこと！
❌ BAD : この処理を実装してください。この資料を作ってください。
🟢 GOOD : XXな問題がXX(環境や人や)にて発生したので、対応策としてこの処理を実装してください。XX社への定例会でXXについての説明をしたいので、補足資料として、この資料を作ってください。
課題をコードと結びつける（コミットログに課題NOを入れる）ことで、該当の処理が何を解決したいのかを後から追うことができる。
何もプログラムだけの話ではない。どんな依頼事項に対しても背景を丁寧に説明することはものすごく大切だ。この手間を惜しんでいたら後からものすごく面倒なことになるぞ！
なぜその対応方法でなければいけないのか
これがわからないとプログラムを修正する際にものすごく困る。技術選定やロジック等々、その対応方法を選択した理由に明確な意図があるのであれば必ず書いてほしい。もしないのであれば、他の方法でもいいよって書け！
❌ BAD : このフレームワークを使ってください。Excelにまとめてください。
🟢 GOOD : XXな技術制約があり、XXのライブラリを使用したいので、このフレームワークを使ってください。後日グラフ化して顧客に見せたいので、Excelにまとめてください。
これが明確にされていないと他の方法で課題解決をしてよいのか判断がつかない。よりよい方法を作業者が知っていたとしても、それを採用した場合に起こる問題を恐れて従来の方法のまま対応する羽目になる。改善の目をつぶす。
なぜその期限までに対応する必要があるのか
依頼事項には期限が設定されるものだ。期限の設定されていない課題など論外だ！今すぐ期限を設定しろ！そして期限設定の背景を課題に記載しろ！締め切りは人の心を蝕む。せめて理由を教えてくれ。
❌ BAD : 期限日 XXXX年XX月XX日
🟢 GOOD : 当処理の実装後、別チームにて検証を行い、XX月XX日には一度顧客に見せたいので納期遅延不可。期限日 XXXX年XX月XX日
期限の背景がわからないと優先順位がつけられない。時間は有限だ。クリティカルな課題から対応するための検討材料をくれ！
締め切りを守れないってのは非常に心苦しいもので精神にくる。当記事の締め切りを既に守れていない僕が言うんだ。間違いない。
Backlogのテンプレート機能ってやつを使うといいよ
強制的に課題に「なぜ」を書いてもらうために、テンプレート機能を使うとよい。書いてね！って言っても皆の書き方がバラバラだと非常に見辛いものだ。
テンプレート機能について説明しよう、と思ったら既に非常にわかりやすい記事があったのでこちらを見て欲しい。meganeさんありがとうございます！
ちなみに僕たちのチームはこんな感じのテンプレートを使っている。
# 課題の完了条件
こうなったら課題は完了！ってものを具体的に書いてね。
# 課題の内容
具体的な課題の内容を書いてね。
# なぜか
なぜその課題に対応する必要があるのか背景を書いてね。
「なぜ」を書くと、皆のアイデアが集まる
大切なのは、課題に対応によって根源的な問題を解決することだ。「なぜ」を書くことで対応者も考えることができる。解決方法は起票者だけが考える必要はない。むしろ対応方法は詳しい人が自由に選択できた方がよい。
課題の背景を書かないことで対応者の自由を奪うことができる。言われたまま決められた方法で、淡々と働いて欲しいのであればいいが、間違いなく生産性は上がらない。何よりつまらない。
人間一人の脳味噌なんてちっぽけなもんだ。皆のアイデアを持ち寄り、よりよい方法で課題解決をした方がよいに決まっている。
主にシステム開発の観点で書いたが、仕事の依頼全般において大切なことだと思う。
いい加減な依頼からは、いい加減な成果物しか上がってこない。成果物がちょっと思ってたのと違うなーと感じることがあれば、自身の依頼内容を見返してみるといいだろう。
とにかく！Backlogの課題には「なぜ」を書いてくれ！マジで！僕からのお願いだ！以上！！
この記事はBacklogアドベントカレンダー2022の12月5日分として書きました。他の投稿もぜひ読んでみてね！