【自戒】タスク外のバグ報告、ただの「事実共有」で終わらせていた話
【自戒】タスク外のバグ報告、ただの「事実共有」で終わらせていた話
先週の業務中、自分のタスクを進めている最中に「あれ、これバグじゃない？」という事象（インシデント）を見つけました。
その時のチームへの共有の仕方が正直あまり良くなく、上司から「次はこうするともっと良いよ」とアドバイスをもらいました。
ハッとする内容だったので、自戒も込めて共有します。特に私と同じくらいの歴の浅いエンジニアの方に届くと嬉しいです。
前提：チームの状況
私のチームでは定期的な進捗共有の場があります。
そこでは各々の進捗報告だけでなく、開発中に見つけた課題（Issue）を管理ツールに記載し、チーム全体で「これ誰がやる？」「重要度は？」といった議論を行っています。
今回私が遭遇したのは、自分の担当タスクのテスト中に見つけた、主目的とは異なる箇所の改善点でした。
やっていた報告：事象と手順だけポン置き
当時の私は、そのインシデントについて以下の2点だけを記載して報告していました。
- どんな事象か
- どうやったら再現するか（手順）
正直なところ、自分の本来のタスクの進捗もあまり良くなく、インシデント報告については「とりあえず見つけたことだけは伝えないと」という気持ちで精一杯でした。
MGからのアドバイス
この報告に対して、MGからはこうフィードバックをもらいました。
「基本的には自分のスコープ外の対応になるから、事実報告だけでも問題はない。
ただ、もし少し時間に余裕があれば『エラーログ』も貼っておくとか、ログを見て『ここが怪しいかも』という仮説まで共有してもらえるとすごく助かる。
そうすると、後続で対応する人が『調査』から始めなくて済むから、チーム全体の工数が浮くんだよね」
これを聞いて、「確かに...」と納得しました。
報告だけだと、対応する人はまた１から「ログを見る→調査する」という手順を踏むことになります。
発見したその場であれば、目の前にエラーログが出ているし、なんとなく「この辺の処理かな？」という勘が働いていることもあります。その「生の情報」を捨ててしまうのはもったいないことでした。
今後のアクション：+αの情報を残す
もちろん、自分の担当タスク（スコープ内）を完遂させることが最優先ですが、今後は以下の2点を意識しようと思います。
1. ログを添付する
これは技術云々ではなく、意識の問題です。「どんなに時間がなくてもできる可能性が高い」ので、スクショ一枚、テキスト貼り付け一回の手間を惜しまないようにします。
2. 仮説を立てて残す
「ログを見る限り、〇〇のパラメータがおかしい気がする」程度でも、あるとないのとでは大違いです。
あわよくば自分で原因特定までして、「ついでに直しておきました〜（ドヤ）」と言えるようになれば、エンジニアとしてもう一歩成長できるチャンスかもしれません（笑）。
まとめ
「自分が調査するか、後続のメンバーが１から調査するか」。
チーム開発である以上、自分のタスクを守りつつ、チーム全体のコストを下げられる動きができるようになりたいなと改めて感じました。
これらを意識して、より「頼られるエンジニア」になれるよう精進します！
Discussion