アジャイルな現場やサービスだと、開発速度が早すぎて、とにもかくにもリリースが優先させることがある。
僕は個人的に仕様書を書いたり、テストをしたりな時間を十分に確保しないで新機能をバンバンつけていく状態は正直よくないとは思っている。
開発速度が大事なのもわかるけど、それにしても品質を軽視しすぎてる。
壊れてるのわかってる車をそのまま出荷したら、困るのはユーザだし、リリースした会社も評判を落とすでしょうに。
って僕は思うんだけど、どう言っても会社や職場、プロダクトの方針がそれなら仕方がない。
のでQAの僕がとった行動はとにかく欠陥（故障）は作りこむ前につぶすこと。
JSTQBだと静的レビューに分類されるんだろう。
とにかくレビューとか仕様策定とかの段階で課題をみつけては指摘する。
ただし、ブレストとかは文句言わない。
仕様書などのドキュメントがほぼなくても
「こういうのを作りたい」「作ろう」って、打ち合わせなりチャットなりが必ずある。
組織なんだからある。（いや、他社は知らない。。）
そこに加わって、その機能やサービスを作るにあたっての懸念点をその場で指摘することに注力してる（した。）
あと、口頭で仕様変更されることがあるので、そこはいろいろと注意してる（した。）
雑談しに行ったり、ご飯食べに行ったりして
「どうっすか」
な話をするとか。
偉い人を捕まえるとか。
ソフトウェアのいわゆるバグ（不具合）は、早めの工程でつぶした方が後戻りが少ない。
とにかく早めに見つけて指摘することで、そもそも不具合の発生頻度を下げることにした。
テストにかける時間も限られることが多いので、そもそも不具合を作りこむことを避けた。
けど、やりすぎると嫌われるのが厄介なところ。。。。
あれねー。
スライド数枚に50件指摘したのはやりすぎたかもしれないね。
いや、それでも絶対外せないと思われるところ以外の非機能要件は指摘を避けたんだけどさ、、、
品質はすごい大事なんだけど、そのために人間関係悪くしちゃうと、良いものも作れなくなる。
難しいところ。
