まずは受け入れテストの見直しからベンダー依存のシステム開発から脱却する“7つのポイント”
「ベンダー任せのシステム開発からの脱却」は難しい。だが、情報システム部門の組織力を段階的に向上させることで、その実現が可能になる。H社が実施した改善策は、まず「受け入れテスト」の主導権を握ることだった。
“ベンダーがいないと何もできない”現状
一般にシステム開発は「V字型のプロセス」によって実施されることが多い。このプロセスには「ユーザー主体の作業」と「開発ベンダー主体の作業」が存在する。上流工程では、ユーザーが主体となりシステム化構想が行われ、ユーザーがベンダーの支援を受けてシステム要件を定義する。その後、ベンダーがシステムを実装し、その成果物をユーザーが受け入れテストとして検証するという流れである。
V字型のシステム開発プロセスしかし、多くの企業では「ユーザー側が主体となるべき工程までベンダーに依存している」のが現状ではないだろうか。
本稿で紹介するH社は、システム開発のほとんどを特定のベンダーに委託しており、システム開発の主導権をベンダーが完全に握っていた。このため、以下に挙げるようなさまざまな課題があった。
- 開発コストがベンダーによってコントロールされてしまう
- 長い付き合いによる慣れから緊張感がなくなり、システム品質の低下が発生する
- 多少問題があっても、ベンダーを切り替えられない
- システム構築に関する技術的な知識やその経験が社内で蓄積できないため、社内の人材が育たない
- ベンダーが提供する技術や製品に固定されてしまう
受け入れテストの重要性
H社は創業から100年を超える大手製造企業である。メインフレーム全盛の20年ほど前には、同社の情報システム部門は300人を超える体制を誇り、システムの構想から要件定義、システム設計などのほとんどの開発工程を、同部門に所属するシステムエンジニア（SE）が担当した。同社のSEは情報システムの技術知識だけでなく、業務知識も豊富であり、業務部門からの信頼も厚かった。
しかし現在、30人体制になった情報システム部門では、システム開発に関する事務的な処理を主に担当している。開発案件が発生すると、業務部門がシステムに対する要求を簡略にまとめて、情報システム部門に開発を依頼する。情報システム部門では、要件定義以降のプロセスを「お抱えベンダー」に一括で委託。システム開発が完了すると、契約内容に基づき、成果物が整っているかどうかといった形式的な検証を行っていた。H社におけるシステム開発では、システムが稼働するまでのプロセスのほとんどをベンダーが取り仕切っていた。
H社のシステム開発の体制（改善前）また業務部門では、主要な機能の動作確認は行っていたが、テスト計画やテストシナリオを策定した受け入れテストを実施していなかった。その結果、以下のような問題が過去に発生していた。
- 実際の業務とシステムの仕様が乖離（かいり）しており、業務を遂行できない
- 業務の遂行に必要な機能が不足しており、想定外の運用を強いられた
- 開発環境では想定できなかった環境面の問題が発生し、業務が長時間停止した
受け入れテストの定義
そもそも、受け入れテストとは何の目的でどのような作業を実施するのだろうか？
日本におけるソフトウェアテスト技術者資格認定を運営する「JSTQB（Japan Software Testing Qualifications Board）」の標準用語では、以下のように定義されている。
システムが、ユーザーのニーズ、要件、ビジネスプロセスを満足するかをチェックするための公式のテスト。このテストにより、システムが承認基準を満たしているかを判定したり、ユ−ザ、顧客、そのほかの認可主体がシステムを承認するかしないかを判定できる。
つまり、受け入れテストとは「ユーザー企業が主体となって利用者の視点でシステムを検証し、稼働可否を判断する最終的なテスト」のことである。
本来、ユーザーによる受け入れテストは、前述したようなトラブルを未然に防ぐ最終手段となるはずだ。しかしH社では、テストや検証をほとんど実施せずに、ベンダー主導で開発されたシステムをそのまま受領していたのだ。
主導権を取り戻すためのキーワードは「5R2P」
こうした現状を受けて、H社ではシステム品質を向上させるための施策を検討した。まずは、簡単な要求だけで開発案件を発注していた点を見直すことを考えた。しかし、要件定義をユーザー主導で実施するためには、体制やスキル面などを大幅に改善する必要があったため、H社では今後の検討課題とした。次に、自らが主導権を握れる工程として受け入れテストに着目し、その改善に乗り出した。
H社の情報システム部門では、年間100件程度の大小さまざまなプロジェクトを取り扱っている。そのため、すべてのプロジェクトに対して受け入れテストを行うことは難しいと判断した。プロジェクトの規模や期間、業務面での重要性、技術的難易度などを考慮し、リスクの高いプロジェクトを「重点管理プロジェクト」と位置付けて、当面の改善対象とした。次に、すべての重点管理プロジェクトに対して、以下に挙げる7つの改善策を適用することでシステム品質の向上を目指した。
| キーワード | 改善内容 |
|---|---|
| Request | ユーザー受け入れテストのシナリオ作成の効率化を図る |
| Review | 業務部門によるテストシナリオのレビューを実施する |
| Resource | ユーザー側でのプロジェクト管理体制を確立し、テストに専念する業務部門の体制を構築する |
| Responsibility | H社の各部門が責任を持ってテストに参画する |
| Real time | テスト結果や進ちょく状況をリアルタイムで情報共有できる仕組みを導入する |
| Place | 業務部門、情報システム部門、ベンダーが協力してテストを実施できる環境を構築する |
| Process | プロセスの標準化 |
H社では改善策を、改善ポイントの頭文字を取って「5R2P」と称して社内への浸透を狙った。ここからは、7つの改善ポイントである「5R2P」を順に説明していく。
Request （要件定義からユーザー受け入れテストのシナリオを考える）
ユーザー受け入れテストでは、要件定義の成果物からテストシナリオのテストケースを考えることが基本である。テストシナリオは、業務フロー図や業務要件、運用要件などをベースに策定され、またユーザーマニュアルや運用マニュアルを参考にすることも可能だ。
H社では、ベンダーに委託する際、受け入れテストのシナリオ作成の参考となる成果物の提出を必ず盛り込むようにすることで、シナリオ作成作業の効率化を目指した。
Review （業務部門のレビューを受けてテストシナリオを作成する）
H社では、情報システム部門のSEが受け入れテストのシナリオを作成し、その内容については、業務部門のレビューを受けることを原則とした。また、レビューでの役割や手順などをあらかじめ決めておき、レビュー結果や指摘事項の管理、最終承認者などを明確にした。より業務の実態に適合したテストシナリオを作成し、テストの有効性を高めるように努めた。
Resource／Responsibility
（自社のプロジェクト管理体制を確立し、テスト実施の責任と役割を明確にする）
受け入れテストでは、比較的短期間で効果的に実施することが求められる。そのため、テスト担当者の役割と責任を明確にした体制を構築することが重要である。
H社では、システム開発に対して自らが積極的に関与するために、情報システム部門がプロジェクトの全般調整を担う体制を構築した。また、受け入れテストについては、業務部門のプロジェクト担当とともにかかわることにした。その際には、テスト計画やテストシナリオ、テスト結果に対する承認責任を業務部門が、体制や環境構築などの実施責任を情報システム部門が、それぞれ負うことにした。
H社のシステム開発の体制（改善後）Real time （テスト結果や進ちょく状況を情報共有する仕組みを作る）
テスト結果は日々積み重なっていく。テストの進ちょく状況や摘出された不具合をまとめて目に見える形で情報共有しておくことで、成果物の品質が高まり、ゴールに一歩ずつ近づいていることを実感できる。
このため、H社ではツールを導入することで、テスト結果の可視化や情報共有を図るための環境整備を行った。H社では、問題管理には「Trac」、構成管理には「Subversion」、進ちょく管理には「Microsoft Office Excel」をそれぞれ標準ツールとして採用した。
Place （業務部門、情報システム部門、ベンダーの距離を縮める）
H社では2つの「場」の改善を実施した。1つは、開発拠点の集約化だ。業務部門と情報システム部門のオフィスは別の場所にあったが、プロジェクト期間中は専用の作業場所を確保し、業務部門、情報システム部門、ベンダーを同じ場所に集めてプロジェクトを遂行することをルール化した。これによりシステム開発の一体感を醸成することを心掛けた。
もう1つは、本番環境を利用したテストの実施だ。今までは、開発環境で最終テストまでを実施し、そのまま本番環境へ移植して実稼働を迎えることが多かった。しかし、本番環境を利用して最終テストを実施するように変更した。これにより、移行後に発覚していた環境面での障害を事前に検知し、対処できるようになった。
Process （受け入れテストプロセスを標準化する）
一般に受け入れテストは以下のような手順となる。また、この手順において、障害が発生した場合の報告やテスト進ちょくの管理手順などについてもルールとして規定することも重要だ。
- テスト計画 → テストケースとシナリオの設定 → 環境の構築 → テスト実施 → テスト結果への対応
H社では、これらの項目を「受け入れテストプロセス標準」として規定し、情報システム部全員で共有した。さらに、受け入れテストで確認すべき項目を網羅したチェックリストを策定し共有化することで、テストケースの漏れを防止する配慮を行った。
その改善効果は？
H社ではこれらの対策によって、前述した業務とシステム仕様との乖離、本番環境での環境面におけるトラブルが、受け入れテストの段階で検知できるようになった。そのため、本番稼働後に発生していた同様のトラブルが発生しなくなった。
また、受け入れテストに掛かる工数はプロジェクト全体の平均5％程度であり、こうした取り組みによって、業務を長時間停止するトラブルが激減するという改善効果が得られたのである。
“水際対策”こそが、トラブルを防ぐ現実的な手段
企業経営に情報化戦略は欠かせない。今や情報システムが企業の生命線になっており、それを支える同部門の役割と責任は重大である。仮に、ベンダーにシステム開発を委託する場合でも、その成果に対する「目利き」は必要である。この目利きを効果的に実施するためには、「ユーザー企業として実施すべき役割を適切に実施する」ことと「その役割をこなすための人材を育成する」ことが大切である。
しかし、さまざまな要因から一足飛びに情報システム部門の強化を図ることは現実的ではない。その際の「水際対策」として、受け入れテストの主導権を握っておくことは、情報システム部門としても、ユーザー企業としても大変重要である。こうした現実的な手段と方策を少しずつ段階的に進めていくことが、自社の組織力を強化する近道だといえるだろう。
（参考）システム管理基準
経済産業省がまとめた「システム管理基準」（2004年10月8日策定）にユーザー受け入れテストの記述がある。
5．システムテスト・ユーザ受入れテスト（13）
（1）システムテスト計画は、開発及びテストの責任者が承認すること。
（2）ユーザ受入れテスト計画は、ユーザ及び開発の責任者が承認すること。
（3）システムテストに当たっては、システム要求事項を網羅してテストケースを設定して行うこと。
（4）テストデータの作成及びシステムテストは、テスト計画に基づいて行うこと。
（5）システムテストは、本番環境と隔離された環境で行うこと。
（6）システムテストは、開発当事者以外の者が参画すること。
（7）システムテストは、適切なテスト手法及び標準を使用すること。
（8）ユーザ受入れテストは、本番同様の環境を設定すること。
（9）ユーザ受入れテストは、ユーザマニュアルに従い、本番運用を想定したテストケースを設定して実施すること。
（10）ユーザ受入れテストは、ユーザ及び運用の担当者もテストに参画して確認すること。
（11）システムテスト及びユーザ受入れテストの結果は、ユーザ、開発、運用及び保守の責任者が承認すること。
（12）システムテスト及びユーザ受入れテストの経過及び結果を記録及び保管すること。
（13）パッケージソフトウェアを調達する場合、開発元が品質テストを実施したことを確認すること。
受け入れテストとシステムテストとの違いがよく分かるので、ぜひ確認してほしい。
＜筆者紹介＞
堀江弘志
株式会社豆蔵 BS事業部 プロセスエンジニアリンググループ 主幹コンサルタント
専門分野：プロジェクトマネジメント、プロセス改善
ユーザー系のSI企業でソフトウェア開発やプロジェクトマネジメントに携わった後、2005年より株式会社豆蔵に在籍。現在はコンサルタントとして、システム開発プロジェクトのプロジェクトマネジメント支援コンサルティングや、プロジェクト管理標準や開発標準の策定と定着化支援、プロジェクトマネジャーの育成など幅広く手掛ける。PMP資格保持。PMI会員。
この記事を読んだ人にお薦めのホワイトペーパー
この記事を読んだ人にお薦めの関連記事
ITmediaはアイティメディア株式会社の登録商標です。