社内の受託開発のQA担当として行動をしていたときのこと。
レビューのチェックリスト作ったり、プロジェクトの運用フロー作ったり、
第三者レビューとしてレビューに参加してみたりしましたが、
プロジェクト都合を鑑み始めた途端、もろ形骸化してしまいました。
時間がないことや
プロジェクトのボリュームが小さいからということで
特例を認めたり、レビューを簡略化したりし始めた途端
こぞってほとんどのプロジェクトが楽なほうへ流れてしまう結果となったわけです。
組織としての強制力を持っていなかった為、
QA担当が決めたことを「やれ」といっても、プロジェクト側の力が強いので
やってくれないこともあったわけです。
やったとしても形式的なものばかりで、再度実施するように伝えてもスルーされたりもしました。
その時は、「こちら側に強制力があれば」と歯ぎしりしながら思ったこともありました。
で、しばらくしてプロジェクトを回す側に戻ったのですが、
今ではQA側に強制力があってもレビューやチェックリストの実施は
形骸化してしまうと考えを改めています。
開発プロジェクトであれば、コーディングすることについては、
そもそも納品物が完成されないので実施の可否については誰も疑問を持たないでしょう。
ですが、レビューやドキュメント作成することの意味を理解していない場合、その作業は「やらされ」になります。
強制的にやらされていると思えば、苦痛にしかならず
手を抜いて早く終わらせることを考えるようになります。
(それこそ、余計な工数がかかって利益が減るとか上申してやらなくて済むようにしたくなります)
ですが、本当に「自分の作業」として認識できれば前向きになりやすく、
単純に手を抜く為だけでない、新しい提案が発生しやすくなるでしょう。
受身では前向きなものは生み出しにくいはずです。
納品したものの品質やトータルコストについて、
レビューの有無によってどうなったかをアナログでなく、デジタルで数値化しないと納得してもらえません。
でも、全く同じ条件のプロジェクトなんてありえないので、その数値も眉唾モノです。*1
経験則で言っても、QAで決めたフロー通りに開発プロジェクトを実施したとしても、
結局プロジェクトをうまく回せる奴は回せるし、そうでない奴は失敗するのです。
誰がやっても成功させるようにするためには、プロジェクトメンバーとして参画して都度アドバイスするくらいしないと駄目だと思うんです。
結局プロジェクト側からやるように仕向ける必要があるなー、と思っております。
誰がやっても一定以上の結果を出す為の仕組みを作ると、その仕組みの言いなりになってしまい、
自分で考えることをしなくなります。厳しければ厳しくなるほどその傾向になりがちです。
もちろん製品開発等で、出荷基準を満たさないものは出荷できない仕組みがあって、
不備があった時の全責任をQAが持つのであればその限りではありません。
単体テストにおいて、テストクラスを作ることに対してメリットは理解しつつも
工数やスケジュールの絡みで実施できない場合なんかは
単体テスト仕様書やエビデンスの作成を免除する等しても良いかもしれません。*2
「逃げる、回避する」みたいな後ろ向きな考えをする為に頭を悩ませるより、
「こうすればできる」的に前向きな方向に頭を悩ませたほうがみんなハッピー。