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