最近バグの報告に、Redmineだけではなく、Github/GitlabのIssueで報告したり、ヌーラボ社のBacklogを使って報告することも増えてきました。
使うにあたっての背景
- チケットによるメトリクスはとっていない
どうして乗り換えたか
エンジニアが楽なのがいいから
この一点につきます。
開発する上で、ツールが複数あるよりも少ない方が楽なはずです。
社内テストの確認のためだけにRedmineを開かなければならないのは（Slack連携で楽になってきたにしろ）あまりうれしいことではないな。と思いました。
また私の方では、記載する時は以下の項目が殆どなので、GithubでもBacklogでも問題はありませんでした。
- 発生した画面タイトル
- スクリーンショット
- 手順や内容
メリット
お客さまも読まれることで「ここまでテスト確認してもらえるのですね」と褒めてもらえた！
エンジニアが楽になるように。ということでお客さまも見える場所と意識していなかった（もちろん見られてもよい表現、データ、内容を書くようにしています）ので、こんな相乗効果があるのかーと目からうろこでした。 私は普段お客さまと接する機会がないのですが、こういった形で弊社がシステムをリリースする前に「不具合を報告する」だけではなく「リリース前により使いやすくするにはどう改善した方がよいか」をテスターから提案している流れを公開するのっていいな。と思いました。
私が書くことでお客さま自身も「こういう視点で見ると受け入れテストもやりやすいな」とか「こういう書き方をすれば、もっと伝わりやすくなるのね」といったヒントやお手伝いがも今後できるといいなぁと思っています。
なにより、私からお客さまに届けるものが今まで直接的になかったので、とても嬉しかったです。社内テストも公開することで、お客さまにより明確な開発ができるのかもしれないと思いました。
- エンジニアは少しは楽になったのだろうか？←誰かおしえてください
とかいてたら、エンジニアが教えてくれました（ありがとうございます♡）
バグとコードが一緒に管理（紐づけ）されているので非常に管理しやすいです。 今まではRedmineみて、Gitみての行ったり来たりだったので、それが無くなったことで楽になったと感じてます。
Github/Gitlab
- 変更したプログラムコードが追えるはず
- Margeしたかどうかはっきりするので、マージ漏れなのかデプロイしていないのかエンジニアに聞かなくてもわかるように（今後）なる予定！がんばれ、私！
デメリット
- 画像以外のファイルが添付できないと困ることがあるかも。
- お客さまの目に触れる環境で書くので、相応の表現を気をつける必要がある（案件によっては問題になるかもしれないですね）
- 案件によってどれに何を書いたか最近よくわからなくなってきた
- チケットのメトリクスをとっているところがあるならば、複数にわかれるのはよくないかもね。。
- 当然ながら、セキュリティ対策はしっかりと！テスト環境やテストデータには最善の注意を！
おわりに
１年くらい前にバグやチケットをBTS管理しているところとITS管理することにどういった効果や違いがあるのだろう？と疑問に思っていました。
自分がちょっと「やってみる」と言うと、すぐチャレンジさせてくれるプロジェクトにいられるのはいいなぁと思いました（なので、フィードバックもできるだけしたいと思う）
・・・となると次はJIRAではないか・・・という話になるのかもしれないけど、それはまた未来の話。。
