受け入れテストの丸投げ回避の鍵となる、ユーザー企業の「納得感」 - 電気通信大学 西氏 講演

ビジネスにますますスピードが求められている昨今、ITシステムにも"必要なもの"を"必要な時"に手に入れる必然性が増している。これに伴いその重要性が見直されるようになってきたのが、システム開発における「テスト」である。なかでもとりわけ重要視されているのが、本番稼働直前の「受け入れテスト」だ。システム開発の「最後の砦」ともいえるこの工程は、システムを開発する側(＝ベンダー側)に委ねられているケースが少なくない。しかし"本当に欲しいシステム"を手に入れるには、システムを発注する側(＝ユーザー企業側)にも知見を蓄積し、主体的にテストを実施する必要がある。

そうしたなか、6月26日に都内で開催された「ソフトウェア品質サミット」では、ユーザー企業が受け入れテストを主体的に行う必然性をはじめ、"ムリ・ムダ・ムラ"や"属人性"を排除してツール導入を成功させるためのポイント、人材育成の勘所などについて詳しく解説が行われた。

セミナーの基調講演には、電気通信大学 情報理工学部の講師、西康晴氏が登壇。「ソフトウェア品質は"ユーザー主導"の時代へ」というテーマで、"ベンダー丸投げ"が常態化している「受け入れテスト」の現状を知らしめるとともに、ユーザー企業自らがテストを主体的に実施することの重要性、そして今後の受け入れテストがどうあるべきかについて言及した。

ユーザー企業の理解不足が「丸投げ」の一因に

西氏はこれまで、数多くのユーザー企業の情報システムの受け入れテストに関わってきた。なかにはSier自身の社内システムの受け入れテストもあったという。そんな数々のテストの現場を見てきた同氏が指摘するのが、ユーザー企業側の受け入れテストに対する理解度の低さである。

「まず、IT部門のなかでも受け入れテストの担当者の数は本当に少ない。そして、実際にどのようなテストをするのかわかっていないにもかかわらず、目の前の仕事はどんどん進んでいってしまうので、いざ納品の時期になったら受け入れテストを自分たちでするか、ベンダーにやってもらうかということになる。しかしそこでは、テストが本当にうまくいっているのかどうかについて誰もわからないという状況が生じてしまっているのだ」と西氏は訴えた。

こうした状況の背景にあるのは、開発時のコストや工数の不足ではなく、ユーザー企業とシステム子会社、ベンダーとの間で、それぞれの役割分担やいかに合意形成するかについてしっかりと取り決められていないという現実だ。

そのため、受け入れテストにおけるユーザー企業の悩みの中でもとりわけ深刻だと西氏が指摘する「丸投げ」の悩みが生じてしまうのである。

丸投げの実態について、同氏は次のように主張した。「ものづくりにおいて、日本の製品の品質が優れているのは、メーカーに納品する部品メーカーがプライドにかけていいものを作ってくるからというのが一つ。そしてもう一つは、メーカー側が、外注している部品に対しても、どのように作ればいいのかという原理をだいたい理解しているからだ。なので、どこを検査すれば品質を保証できるかがわかるし、部品メーカーが実施する検査についても、その会社が適切な検査を実施しているかどうかを把握できるのである。対してユーザー企業のIT部門には、必ずしも専門知識が十分とは言えないところも多い。なので、ベンダーが何を言っているか本当はよくわかっていないのに、つい『ふんふん』と頷きがちになってしまうのではないか。そうなると、結局のところベンダーの言いなりになり、丸投げ状態に陥ってしまう。ユーザー企業にノウハウがなければベンダーはその足元を見てくることもある。少なくともユーザー企業は、ここをこうして検査をすれば品質についてしっかりと抑えることができるという部分についてわかっていなければいけない」

最初に考えなければいけないのは納得感

では、テストにおける丸投げの悩みから解放されるためにはどうしたらいいのか──西氏は「まず最初にいかに納得感を得るかを考えることが大切だ」とアドバイスする。

「説明責任というのは、説明を受ける側にも生じるのだということを心して欲しい。ベンダーから説明を受けた時に、内容に納得しないまま流れに任せてしまうと、ベンダーは説明責任を果たすために自分たちは何をしたのかをこと細かく説明しなければならない。これは何かしているようでいて実は何もしていないということだ。もし問題が起きた時に自分たちに責任が生じないよう、"これだけ仕事をしたんだ"という言い訳をしているに過ぎない。これでは『説明無責任』と言っても過言ではないだろう。説明が膨大になりその分のコストも発生してしまい、ユーザー企業にとって何の価値も生まない。にもかかわらず、ユーザー企業のテスト担当者にしても、上司に対して"これだけやった"と説明ができるのでつい受け入れてしまっているのではないか。ユーザー企業側に『納得しよう』という意思がないのでこうなってしまうのだ」(西氏)

こうなると、ユーザー企業の納得度が上がるような仕事をベンダーはしなくなり、結果、ソフトウェアの品質も下がってしまう。これこそが、丸投げの本質的な問題なのである。

「そうならないよう、受け入れテストをベンダーに委託するにしても、まず自分たちで全体図を描いて、どうしてそのような図になるのかを把握しなければならない」と西氏は説く。

受け入れテストの丸投げで発生している問題を解決するために、ユーザー企業が納得感を高める取り組みを進めるためには、まずは主導的に受け入れテストに関与することが大切なのである。ユーザー企業が受け入れテストを主導的に行う際に参考となるのが、新たなソフトウェアテストの国際標準として今年度中にも発行予定のISO/IEC/IEEE 29119のテストプロセスモデルだ。

「"ユーザーが納得しないのに、ベンダーがいい仕事をできるわけがない"という欧米企業では主流となっている考え方に基づいて国際標準化されたモデルだ」と西氏は説明する。

ISO/IEC/IEEE 29119を象徴する考え方に、リスクベースのアプローチがある。これは、何を達成したいのかというテストのゴールを決め、どのテストを間引いた場合にどんなリスクが発生するのか、その際にどう対処するのかなどをきちんと考える真っ当なアプローチだ。だからこそ、ユーザー企業とベンダーが納得するまで話し合わないと上手くいかないのである。

「ISO/IEC/IEEE 29119のすべてを読む必要は必ずしもないが、受け入れテストで困っているユーザー企業の担当者であれば、その考え方を知り、"自分たちがテストを主導するんだ"という感覚を身につけることはとても大切だ」(西氏)

ユーザー企業とベンダーの"Win-Win"な開発を目指して

ISO/IEC/IEEE 29119に限らず、受け入れテストにどういった考え方や概念、用語があるのかを身につけることは、これからのユーザー企業のテスト担当者には必須だと言える。まずは自分たちでこれらを整理することが、丸投げを脱却する第一歩となるからだ。そこで西氏が推奨するのが、JSTQBテスト技術者認定制度のシラバスや用語集だ。これらは無償であり、しかもよく整理されているのだという。

「JSTQBのシラバスを使って、どんな考え方があるのかをまず身につけていただきたい。自分たちやベンダーが馴染む言葉遣いを極力活かしつつ、混同している用語や新しい概念を整理するための土台となるはずだ。ただし、用語定義や暗記にこだわりすぎないように注意しなければならない」と西氏は強調した。

JSTQBを理解することは、ベンダーと共通の認識を持つことにつながる。そしてその後は、Webサイトや書籍、セミナーなどを活用して受け入れテストへの理解を深めていくのが肝要だ。無償のオープンな勉強会も開催されており、そうした場所に参加することで、知り合いもできてくる。そうなれば、懇親会やツイッターなどで自身が抱える悩みや疑問などについて質問しやすくなるだろう。

ここまで来たら、オープンソースのテストツールを使い、まずはコストをかけずに自らテストの自動化にチャレンジすることも可能となる。

「そこで効果を実感できたら、次にはコストをかけて商用ツールを使ってみれば、その"ありがたみ"がよくわかるはず」(西氏)

こうした納得感を高める取り組みを進めていけば、丸投げの問題も少しずつ解消されていくのである。

「"少しずつ"がとても大事だ。今すぐに高い納得感を出さねばならないと焦ってムリをしたり、いつかやればいいと先送りをしている組織は、5年後も成長していない自分たちを目の当たりにして愕然とする。少しずつでも納得感を高める取り組みを続けていれば、5年後に大きな差ができる。ユーザーが受け入れテストを主導することで納得感を高める取り組みを続けることこそが、ユーザーとベンダーの"Win-Win"な開発を可能にするのだ」と西氏は熱く語り基調講演を締めくくった。

[PR]提供：