システム案件を対応する若い開発者やシステム担当者の方々に伝えておきたい事があります。要件定義に記載のないあやふやなモノをテストするのは危険です。場合によってはしない方がいい事もあります。
例えば、、、、
既存のシステムに改修が入り、対象となる箇所のテスト仕様書を作成する際、既存のシステムのここにも影響が出そうだな、と気を利かせてテスト仕様書に落とす。コレ、実は落とし穴があるんです。
その変更の仕様が明確になっていて、要件定義に記載があるとか、正解がどうあるべきか？がハッキリしていればOKです。ハッキリしていないけど、多分今までと同じでこうだろうな、としてしまうとこのテスト仕様書を作成したあなたに責任が生まれます。もし、正解が違った場合、テストOKとしてしまった、あなたの思い込みや認識違いとなるのです。ですが、ここでSEやPMに確認をして正解を聞いていればどうでしょう。少し話しが違ってきます。この場合はQAに落とす等してエビデンスを残しておきましょう。責任の所在がハッキリするようにしておくのです。これで後で不具合が発覚した場合、SEやPMの考慮漏れになります。この人達がもし、分からん。というのであればやらなきゃいいのです。このシステム改修により、このような変化が発生しますが、今回の改修のスコープ対象外という事でテストはしませんね。と、これも履歴を残しましょう。この場合も、後で何かあればこの人達の考慮漏れとなります。これらのエビデンスや履歴が、あとでトラブルになった時、あなたを守ってくれるのです。あなたの忠告を無視した者達へのデスノートになるのです。
チョット待ってください。ここまで読むと、自分が責任を問われなければ会社やお客様が、どうなろうが知ったこっちゃない。というように見えてしまうかもしれません。そうではありませんよ。ちゃんと考慮しておいた方がいいぞ、コレワ！と思った事はプロジェクトメンバーには発信していきましょう。若いあなたの意見を聞き入れてくれるかどうか？は周りのメンバー次第ですね。
まとめ
過去、長年色々な案件に携わってきました。仕様確認や影響範囲の考慮漏れ、何度も見てきました。こういう、ケースはアルアルなので気を付けて下さい。良かれと思った事が後で仇となって跳ね返ってくる事もあります。また、分かりやすいかなと思って開発担当者を例に書いてしまいましたがSEやPMの立場になれば仕様を確認する相手はお客様だったりします。この事例は開発案件でしたが、ビジネスシーンではシステム以外でも、コレに似たような事はよく起こります。自分の立ち位置に置き換えて思い返してみて下さい。
広告
最後まで読んで下さってありがとうございました。快適且つ、ストレスレスなビジネスライフを楽しんで下さい。
[btn class=”rich_blue”]カテゴリーＴＯＰはコチラ[/btn]
コメント