バグが多発！受入テストを止めてベンダーに責任をとらせるべきか？

ユーザーの怒りが止まらない

「バグが多すぎて、やってられない！」

ある現場で、受入テストを実施中です。

数ヶ月前、要求機能テストでバグが多発しました。そのため、ベンダーが自主的にプロジェクトを止めて「品質強化」を行います。

プロジェクトを止めることは、ベンダーにとっては「赤字」を意味します。延びた分だけ、計算外の人件費がかかるからです。

それを自主的に申し出てきたので、とても感心しました。

そして、2ヶ月後に受入テストを再開します。

品質強化しただけあって、何とか要求機能テストは終わりました。

ところが、今度はシナリオテストでつまずきます。

システムエラーは発生しないけれども、動きがおかしい。

件数や金額が合わない、表示すべき項目が異なる、等々。

叩けば叩くほどホコリが出ます。

障害管理表を見ると「こんな品質では使えない」「本当にテストしたのか」「話にならない」と、ユーザーのコメントも荒くなっています。

「我々が『テスター』だと勘違いしていないか？」

と怒り出すのも無理はありません。

「もう一度止めて、ベンダーに品質改善させるべきだ！」

と息巻くユーザー。

この状況で、情シスPMOは、どうすべきでしょうか？

ベンダー品質強化の限界

現場のユーザーは、動かすとすぐにバグを見つけます。でも、品質強化してきたはずのベンダーには、気付けません。

この状況で、ベンダーに「品質強化しろ！」といって、解決するのでしょうか？

残念ながら、ベンダーの品質強化には限界があります。

なぜなら、ベンダーが解決できるのは「開発バク」や「製造バグ」だからです。システムでエラーが出たり、モジュール間で不整合だったり、設計書と異なる動きをしたりするケースは、ベンダーが自主的に発見し、修正できます。

しかし今回は、すでに2ヶ月止めて、品質強化を行っています。上記のような不具合はすべて対応済みなのです。

この状態で、さらに品質強化を強いても、効果は薄いでしょう。形式的な「テスト結果報告書」が提出されるだけです。

さらには、ベンダーは大幅な赤字となり、感情的な対立が深まります。積極的な提案はなくなり、言われたことだけしか、やらなくなっていきます。お互い協力していく姿勢が崩壊し、少しでも要望を出せば、「仕様変更」扱いとなっていくのです。

このような関係性では、成功も難しいでしょう。

断言しておきます。

プロジェクトで「感情的」な対立は、良いことは一つもありません。

受入テストの存在意義

現状、「開発バク」や「製造バグ」は発生しておらず、ユーザー目線での「要件バグ」が多発しています。

この要件バグは、ベンダーが自力で改善するのは不可能です。なぜなら、ベンダーは「業務知識」が乏しいからです。

業務フローと業務プロセスのイメージをもっている現場ユーザーでないと、気付けないことは多くあります。

だからこそ「ユーザー受入テスト」が存在するのです。

ベンダーが気付けない「要件バグ」を見つけることが、受入テストの最大の目的です。

言い換えれば、要件定義書に記載しきれなかった部分を見つけるということ。

記載しきれなかったベンダーにも責任はありますが、伝えきれなかったユーザーにも責任はあります。

要件定義書を拝見しましたが、記載がものすごく荒く、抽象的。このドキュメントを「検収」してしまったのは、ユーザー側の責任ともいえます。

一方的にベンダーが悪いとは言えないのです。

受入テストを止めるな！

では、どうするべきか？

「受入テストを止めない」こと。

ユーザーのストレスが大きすぎるのは、承知しています。ですが、最後までやりきることが最短なのです。

おそらく「狭く深く」掘れば、細かなバグはたくさん出るでしょう。でも、いま必要なのは、それではありません。「広く浅く」、致命的なバグを早期に見つけること。細かいバグは後回しです。

まず、シナリオテストの「ノーマルパターン」が動くようになること。これが最優先です。「見積もり」がバグだらけだからと、そこで止めません。その先の「受注」「売上計上」と続けていき、そこでバグが出ても止めません。最後の「請求」「入金」「会計連携」まで、すべてをやりきること。

そのノーマルパターンで発見したバグを、ベンダーは「最優先」で修正する。そして2周目から、もう少し細かく見ていく。

受入テストでは、この「広く浅く」で最低限を確保した後に「狭く深く」とステップを踏んでいく。これがお互いに手が止まることなく、現実的な「最速」なのです。

情シスが成功に向けてコーディネートする

ただし、このやり方には大きな副作用があります。

ユーザーに「強烈なストレス」が発生すること。

ユーザーは感情的になります。ベンダーに腹が立ちます。ベンダーのせいで、余計な手間が次々と増えるからです。

そこをケアするのが、情シスPMOです。

ユーザーの過度な負担を理解し、最大限にフォローしていきます。

バグの起票を「代筆」したり、ベンダーとの調整を「代行」したり、テストデータ作成を「肩代わり」したり、ユーザーがテストに専念できるよう、負担を和らげていきます。

また、ユーザーの反発が収まらない場合は、経営層からトップダウンで「広く浅くテストをやりきる」「協力してほしい」と発信してもらうよう、裏で働きかけます。

延期するのは簡単ですが、ベンダーとの対立は間違いなく深まります。

止めた期間、ユーザーの手が止まるのはもったいないし、ベンダーに効果の薄い自主対策をさせるのももったいない。

致命的なバグをユーザーが早期に見つけ、ベンダーが最優先で対処するのが、最短距離なのです。

もう、ユーザーとベンダーは同じ船に乗っています。

もちろん、状況によっては本当に止めた方がいい場合もあるでしょう。特にベンダー起因の製造バグが多発する場合は、いったん止めて、品質改善を要求すべきです。

そうでない場合、まずは「リスケしない」やり方を、感情論抜きで考えるべきです。

そこを主導するのが、情シスPMOといえます。

台風が去った

「受入テストの進捗率を毎週確認する」

プロジェクトオーナーである社長から、トップダウンで発信してもらいました。

同時に情シスからも、ユーザーに手厚いフォローを実施します。

ユーザーは、どんなにバグが出ようが、ひたすら受入テストを進めました。

もう…、ものすごい数のバグが出ました。

ベンダーは「平謝り」で、一心不乱にバグを修正します。

ユーザーと情シスPMOは、本当に大変だったと思います。

その結果、爆発的に発生したバグが、嘘のように収束していきました。細かいバグだけが残っています。

致命的な金額バグはもうありません。「ノーマルパターンは全て動く」というのは、大きな安心材料です。

その後、このプロジェクトは「再延期」することなく、無事にリリースできました。

貴社のIT部門・情報システム部門は、ユーザー受入テストでバグが多発したときに、どう対応していますか？