• BPnet
  • ビジネス
  • IT
  • テクノロジー
  • 医療
  • 建設・不動産
  • TRENDY
  • WOMAN
  • ショッピング
  • 転職
  • ナショジオ
  • 日経電子版
永井昭弘のそれって丸投げ?ユーザー責任を斬る

重要な受け入れテスト、甘く見ずに主体となる

永井 昭弘=イントリーグ 2017/01/11 日経SYSTEMS
出典:日経SYSTEMS 2017年1月号p.8
(記事は執筆時の情報に基づいており、現在では異なる場合があります)
目次一覧

 システム構築プロジェクトにおいて、発注者側の作業と位置付けられているのが「要件定義」と「受け入れテスト(ユーザーテストとも呼ぶ)」である。もちろんプロジェクトの性質や契約内容によって異なる場合もあるが、たいていの場合、この二つは発注者責任で行う作業となる。

 この二つは、いわゆる「開発V字モデル」でも対になっている。要件定義と受け入れテストはどちらも業務目線で行うべき作業。新たなシステムの導入によって業務がどう変わるのか、あるいはどのように変えたいのかを最終的に評価できるのはユーザーだけなので、発注者の責任となるわけだ。

 このうち要件定義の「丸投げ」の弊害は以前に触れているので、今回は受け入れテストに関して論じたい。

遅延の影響を受けやすい

 受け入れテストは多くのプロジェクトで最終フェーズとされる。だから、スケジュール遅延の影響を受けやすい。当初計画ではきちんと独立した作業として3カ月行うはずが、実際にはベンダーテストのバグ対応や急きょ追加した機能の開発などとごっちゃになりながら1カ月でやるしかない、といった場合も少なくない。

 理想的には、受け入れテストのシナリオ作成は要件定義と同時期にやるのが良いとされている。だが、要件定義そのもので四苦八苦しているプロジェクトでそれは無理である。受け入れテストの開始時期にバタバタとシナリオ作成を始めることになり、それで時間を使ってしまう。

 厄介なのは、ユーザーがテストそのものを甘く見ている場合だ。「画面に入力できるか」「入力後、正しい処理や計算がされるか」「画面が見やすく分かりやすいか」ということを確認すればよいと考えているユーザーは少なくない。それだけでは機能の確認であって、業務がきちんと回るかどうかの確認にはならない。

 テストを甘く考えていると、テストデータも簡略なもので済ませてしまう。テストの目的から見れば限りなく本番に近いデータで行うべきである。

 ベンダーに受け入れテストを「丸投げ」することは非常に危険だ。ベンダーは基本的に機能の確認テストはできても、業務視点でのテストはできない。より正確に言うならば、テストという作業は代行できても、その結果が業務として正しいかどうかは判断できない。ベンダーにはテスト作業支援を委託してもよいが、最終判断だけはユーザーがしなければならない。

 契約面でも受け入れテストは重要である。いわゆる「検収」の対象として最も重要なのはプログラムそのものの品質である。甘いテストを基に安易に検収すると、あとあと大変なことになる。テスト期間中に見つかった不具合であれば、ベンダーも対応しやすい。だが、検収後となると「瑕疵担保責任」の対象か否かという論点になるので簡単には対応できない。これは発注者だけでなく、ベンダーにとっても厄介なことなのだ。

 発注側は、受け入れテストの主体者が自分たちなのだという当たり前のことを再認識しよう。そして、きちんと準備と計画をしてほしい。

あなたにお薦め

連載新着

連載目次を見る

今のおすすめ記事

  • 【速報】

    DAZN、J1リーグ開幕戦で障害発生

     英パフォームグループが手掛けるスポーツ映像のライブ配信サービス「DAZN(ダ・ゾーン)」で2017年2月25日、映像配信の障害が発生。同日に開幕したJ1リーグ1試合の映像が30分ほど正常に配信されない状態が続き、そのあと復旧した。

  • 【ニュース解説】

    提唱者が解説、なぜ「情報銀行」を設立するか

     GPS(全地球測位システム)データや鉄道の乗降データなど「人の動き」に関するビッグデータを解析し、防災や医療に役立つように可視化する。この一連の研究に取り組むのが柴崎亮介氏だ。個人のデータの蓄積が進めば社会はより良くなるとの考えの下、技術の研究に留まらず「情報銀行」の設立を推進する。

ITpro SPECIALPR

What’s New!

経営

アプリケーション/DB/ミドルウエア

クラウド

運用管理

設計/開発

サーバー/ストレージ

クライアント/OA機器

ネットワーク/通信サービス

セキュリティ

もっと見る