![見出し画像](https://assets.st-note.com/production/uploads/images/17792840/rectangle_large_type_2_d420deb29146f1e8ab15b276b57e8fc0.jpeg?width=1200)
収束したはずの不具合が多量に出て困ったんだけど(妄想)
ある程度の改修規模がある、影響範囲が広めの対応があったとき、いろんなチームと足並みをそろえる必要がある。例えば、ECサイトだと、税対応、支払い方法追加(xxPay)、発送方法の変更対応みたいなやつ。
「外部連携もある最後の総合テストが予定通り開始できるだろうか?」
「リリース判定日までに、xxのシナリオまで確認できるだろうか?」
不安は尽きない。
自分たちのチームは、実施予定のテストケースの消化も進み、出る不具合の数も収束しつつある。
大丈夫そうだ。
ホッと胸をなで下ろす。
・
・
・
それが、何かを見落としていたために、総合テストの段階になって、
「設計で気づけよ!」
「単体(テスト)やったのかよ!!」
みたいな他チームからの攻撃にさらされる。
もう逃げてしまおう。
そう思ってしまうような事態に陥ることがあるかもしれない。あるかもしれない。
ちゃんとテストしたはずなのに・・どこで間違ってしまったんだろう・・・
そんな気持ちがわかるプロジェクトマネージャー、チームリーダー、システムのプロダクトオーナー、情報システム部門の担当者の方に読んでいただきたい記事があります。
『ベリサーブナビゲーション2019年12月号』
特集3
「工程実施の質を可視化するデファクトスタンダード
~不具合を残存させる「やり方」を正すODC分析~」
開発にまつわる様々な情報を無理に収集しなくても、不具合の種類・不具合が検出された箇所などの情報があれば、見直すべきフェーズが特定できるというお話です。プロジェクト全体に迷惑をかける前に、リカバリーできるかもしれません。
あぁ、前職のときに、こういう視点を持ってたらなぁ。。
いいなと思ったら応援しよう!
![のーどみたかひろ](https://assets.st-note.com/production/uploads/images/132861420/profile_fc184b6ef2d1270bac6cbe266b641499.jpeg?width=600&crop=1:1,smart)