PMの皆様、いつも issue を書いてくれてありがとう。 1つだけお願いがあります。

How（方法）のみのだとモヤッとする

issue が「Aリストから○○を削除する」といった具体的な作業手順（How）のみに言及するケースがあります。 このケースだとエンジニアが疑問を抱え、着手に時間がかかることが多いです。

• ○○を消す理由は？
• ○○は別の場所にもあるけどそれも消す？
• 消すとは非表示するだけ？それともコードからも消す？
• API側の制御も入れる？

具体的な How を書いてしまうと、実は○○は別箇所にもあるのにAリストのみを消しただけになる。という影響範囲漏れを誘発することにもつながります。

Why（理由）と To-Be（あるべき姿）を教えて

『ログを見た感じ、○○は使われてない機能なので削除が決定した。よって○○を削除お願いします。』

のように、

• Why：ログから使われていない機能だとわかった
• To-Be：機能の削除をお願い

の情報が最低限あると作業に取り掛かれます。

How は実装者の腕の見せ所

『○○機能を消すには、なにをすればいいのか』

という How の部分は是非エンジニアに任せてください！！ コードから影響範囲を調査して方法を明確にしてから作業します。

例外

• 担当エンジニアがジュニアレベルなど、まだ未熟
• 担当エンジニアの稼働が数時間/週など、極端に少ない

のときは、例外です。 限られた時間の中で作業を完了してもらうためにも How まで指示して issue を依頼した方が効率がいいです。

ただし、この場合でもPMが書く issue は同じ Why と To-Be だけで大丈夫です。How は別のエンジニアが調査して追記してから、作業者に渡します。