ベンダー依存のシステム開発から脱却する“7つのポイント”：まずは受け入れテストの見直しから
「ベンダー任せのシステム開発からの脱却」は難しい。だが、情報システム部門の組織力を段階的に向上させることで、その実現が可能になる。H社が実施した改善策は、まず「受け入れテスト」の主導権を握ることだった。
“ベンダーがいないと何もできない”現状
一般にシステム開発は「V字型のプロセス」によって実施されることが多い。このプロセスには「ユーザー主体の作業」と「開発ベンダー主体の作業」が存在する。上流工程では、ユーザーが主体となりシステム化構想が行われ、ユーザーがベンダーの支援を受けてシステム要件を定義する。その後、ベンダーがシステムを実装し、その成果物をユーザーが受け入れテストとして検証するという流れである。
しかし、多くの企業では「ユーザー側が主体となるべき工程までベンダーに依存している」のが現状ではないだろうか。
本稿で紹介するH社は、システム開発のほとんどを特定のベンダーに委託しており、システム開発の主導権をベンダーが完全に握っていた。このため、以下に挙げるようなさまざまな課題があった。
- 開発コストがベンダーによってコントロールされてしまう
- 長い付き合いによる慣れから緊張感がなくなり、システム品質の低下が発生する
- 多少問題があっても、ベンダーを切り替えられない
- システム構築に関する技術的な知識やその経験が社内で蓄積できないため、社内の人材が育たない
- ベンダーが提供する技術や製品に固定されてしまう
受け入れテストの重要性
H社は創業から100年を超える大手製造企業である。メインフレーム全盛の20年ほど前には、同社の情報システム部門は300人を超える体制を誇り、システムの構想から要件定義、システム設計などのほとんどの開発工程を、同部門に所属するシステムエンジニア（SE）が担当した。同社のSEは情報システムの技術知識だけでなく、業務知識も豊富であり、業務部門からの信頼も厚かった。
しかし現在、30人体制になった情報システム部門では、システム開発に関する事務的な処理を主に担当している。開発案件が発生すると、業務部門がシステムに対する要求を簡略にまとめて、情報システム部門に開発を依頼する。情報システム部門では、要件定義以降のプロセスを「お抱えベンダー」に一括で委託。システム開発が完了すると、契約内容に基づき、成果物が整っているかどうかといった形式的な検証を行っていた。H社におけるシステム開発では、システムが稼働するまでのプロセスのほとんどをベンダーが取り仕切っていた。
また業務部門では、主要な機能の動作確認は行っていたが、テスト計画やテストシナリオを策定した受け入れテストを実施していなかった。その結果、以下のような問題が過去に発生していた。
- 実際の業務とシステムの仕様が乖離（かいり）しており、業務を遂行できない
- 業務の遂行に必要な機能が不足しており、想定外の運用を強いられた
- 開発環境では想定できなかった環境面の問題が発生し、業務が長時間停止した
受け入れテストの定義
そもそも、受け入れテストとは何の目的でどのような作業を実施するのだろうか？
日本におけるソフトウェアテスト技術者資格認定を運営する「JSTQB（Japan Software Testing Qualifications Board）」の標準用語では、以下のように定義されている。
システムが、ユーザーのニーズ、要件、ビジネスプロセスを満足するかをチェックするための公式のテスト。このテストにより、システムが承認基準を満たしているかを判定したり、ユ−ザ、顧客、そのほかの認可主体がシステムを承認するかしないかを判定できる。
つまり、受け入れテストとは「ユーザー企業が主体となって利用者の視点でシステムを検証し、稼働可否を判断する最終的なテスト」のことである。
本来、ユーザーによる受け入れテストは、前述したようなトラブルを未然に防ぐ最終手段となるはずだ。しかしH社では、テストや検証をほとんど実施せずに、ベンダー主導で開発されたシステムをそのまま受領していたのだ。
Copyright © ITmedia, Inc. All Rights Reserved.