第4回、第5回では、「頭ではわかっているのにプロジェクトがトラブってしまうのはなぜか」というテーマで、プロジェクトの現場で起きている現象の背景を紐解き、その原因について考えてみた。そして、ユーザー企業、SIベンダーそれぞれの事情が折り重なってトラブルが避けられないポイントについては、企業内で、プロジェクトのマネジメント支援を専門に実施する第三者の部門「PMO」の力も借りて乗り切り、プロジェクトの成功に向けて集中できる体制を作ることの大切さについても触れた。
今回は、より具体的に「テスト」のアプローチを例に、新しいプロジェクトの進め方を考えてみる。
「刺身」の出現と同時に簡単に吹っ飛ぶ「テスト設計と準備」
多くの読者は、ウォーターフォール型開発の品質保証における「Vモデル」という手法をご存知だと思う。提案時にテストの成功要因としてVモデルの活用を強調するSIベンダーも多い。しかしながら、実際にプロジェクトを走らせてみると、テスト設計や準備作業の遅延がたびたび発生しているのが現状だ。
システムテストや受入テストの設計、準備の作業を検討できる立場の人間は誰か、というと、SIベンダー側で業務領域の設計に責任を負うリーダー（業務リーダー）である。普通に考えれば、業務リーダーは、システム設計を終えて開発工程（コーディング／単体テスト）に入ってしまえば、工数に余裕ができて余裕をもってテスト準備に入れると思われがちだ。
しかし実際には、業務運用の詳細定義や、クレンジングやシステム対応検討を含めた移行・教育の準備といった膨大な作業があり、特にユーザー企業側メンバーを巻き込んでの動きに追われている。
ここに、「上流で仕込まれたトラブルの種」が花開き、システム設計の品質問題、開発者のスキル問題で単体テストにトラブルが勃発したりすると、それでなくてもギリギリで動いている業務リーダーのワークロード（作業負荷）は逼迫する。SIベンダーにとって、担当領域の遅延は言い訳無用なので、後ろのテストの準備があろうがなかろうが、業務リーダーは開発領域の火消しを最優先に飛び回ることになる。
そして、各フェーズのスケジュールが折り重なった「刺身状態」が出現すると、最後の山場となるはずのテストに向けた設計や準備といった、下工程で最も重要なステップがなし崩されたまま、プロジェクトは最終局面に突入することになる。
日本人はなぜ「テストツール」を使いたがらないのか
こうならないために「上工程の問題は上工程で潰そう」、ということは、連載の中で一貫して述べてきた通りだが、本稿では下工程側から見たときの1つの問題解決策として、Wモデルとテストツールの併用をお勧めしたい。このアプローチで、テストフェーズの効率化、そして遅延リスクと品質リスクの大幅な低減が可能だ、と筆者は考える。
既にご存じの通り、テストツールにはいろいろな種類があり、うまく活用するとテストの品質向上や工数削減の効果を期待できる。だが、負荷テスト用のツールは昔からよく使用されているものの、テスト自動化ツールやスタブ提供機能などは、日本ではまだ活用事例は少ない。
| テストツール 例 | 内容 |
|---|---|
| 負荷テストツール | 昔からよく使われている、多ユーザー同時アクセス状態や高負荷状態を作り出すツール |
| テスト自動化ツール | 決まったシナリオやデータでのテストを自動で繰り返し行えるツール （データをファイル等から読み込みループ処理をすることもできる） |
| ソースコード自動解析 | ソースコードを自動で解析し、バグやリスク要素を自動で洗い出すツール |
| スタブ機能提供ツール | スタブ（複数機能の連携テストにおいて、相手側機能が出来上がっていない際に準備する相手側の代替機能）を容易に準備できるツール |
