Issue の立て方を改めてまとめてみる

こんにちは、 Gaji-Labo フロントエンドエンジニアの鈴木です。

新メンバーと一緒に仕事している中で、自分では当たり前になっていたことでも改めて言語化するタイミングが多く、それと同時に「意外とうまく伝えられない、、」と感じる時もあります。

またいつか同じように伝える時や、新メンバーが誰かに話すようになった時のヒントになればと思い、ブログとして残しておきます。

今日はその第一弾（仮）として、Issue の立て方についてまとめてみました。

Issue ってどんなもの？

Issue と一口に言ってもいろいろな種類があると思います。

• 自分の作業を分解し、1つ1つ粒度の小さいタスクに切り出す Issue
• 自分以外の誰かに特定の作業をしてもらうための Issue
• 誰がどうする、は決まっていないが、現状認識していて解決が必要な課題をあげた Issue

他にもありますが、よくあるのはこのパターンかなと思います。起票者と作業者が常にイコールではないですし、スコープや期限を Issue 内でやりとりする場合もあります。

Issue に必要な情報とは？

前述の通り Issue と言ってもさまざまありますが、以下の情報はほとんど、どの Issue でも記載しています。

• なにをするか
• 必要な仕様や情報

なにをするか

まず Issue で、なにをするのかを明確にします。例えば実装関連の Issue であれば以下のような情報です。

• コンポーネントの作成
• 既存コンポーネントを実装に組み込み
• 既存コンポーネントの更新

これらの情報である程度、作業範囲が明らかになります。単純に「〇〇機能の実装」としてしまうと、実装とはなにを？どこまで？と曖昧になってしまいます。

また、「なにをどうするのか」はなるべく Issue タイトル内で表すようにしています。

必要な情報

「なにをどうするのか」の根拠や、参考になる情報は必ず入れておきます。
作業者だけでなく、レビューする側も作業が妥当かどうか判断する材料になります。

• 仕様へのリンク
• デザインデータへのリンク
• 作業範囲のスクリーンショット

Issue を立てたあとに

Issue を立てる時には、タスク整理できているかが重要なポイントになると感じています。起票者はやることが明確になっているつもりでも、他のメンバーが見た際に「結局これはなにをする Issue なんだろう？」となる場合もあります。

Issue を立てるのに慣れないうちは、作業内容の認識合わせとして、Issue のレビューをするのもいいなと思いました。

それ以外でも範囲が広かったり内容が複雑、などであればいつでもすり合わせをして「起票して終わり」ではなく、 Issue をもとにコミュニケーションしていけるのが最適だと思っています。