2024.09.09

W字モデルとは？V字モデルとの違い、導入するメリット・注意点を解説

著者株式会社SHIFT　マーケティンググループ

Introduction

W字モデルとは、従来の開発モデルを改良し、開発フェーズにテスト担当者が入ることで、品質を大幅に向上できる開発モデルです。W字モデルの導入により、早期に不具合を発見でき、大幅に品質を向上させられる可能性もあります。また、開発と同時にテスト準備を開始するため、リリースまでの期間を短縮できるのも大きなメリットです。

この記事では、W字モデルについて導入するメリットと注意点、ほかの開発モデルとの違いについて解説します。

W字モデルとは？

W字モデルとは、開発工程にテスト担当者が入ることで、従来の開発モデルの問題を解決できる発展形の開発モデルです。

ここでは、W字モデルの基本事項や、よく似ているV字モデルとの違いについて解説します。

開発工程とテスト工程を同時並行で進めるモデルのこと

開発工程にテスト担当者が入ることで、問題を早期に解決しながら開発を行えるのが、W字モデルです。

一般的にITの開発工程は、要件定義→基本設計→詳細設計→実装→コンポーネントテスト→結合テスト→システム／受入テストと進んでいきます。このときに、この工程の流れを、実装工程を中心にしてV字の形に折り曲げると、以下のように対応します。

・要件定義⇔システム／受入テスト
・基本設計⇔結合テスト
・詳細設計⇔コンポーネントテスト
・実装

それぞれの工程で、開発担当者とテスト担当者が以下のように並行して作業を進めます。

工程名	開発担当者	テスト担当者
要件定義	要件定義	仕様テスト・テスト設計
基本設計	基本設計	テスト設計
詳細設計	詳細設計	設計レビュー
実装	コーディングコードレビュー	コードレビュー
コンポーネントテスト	コンポーネントテストデバッグ・修正	―
結合テスト	デバッグ・修正	結合テスト
システム／受入テスト	デバッグ・修正	システム／受入テスト

なお、詳細設計、実装、コンポーネントテストの工程にはテスト担当者が参加できないことが多く、プログラミングスキルなどの高度な開発スキルがある場合のみ対応します。

従来の場合、開発担当者が要件定義からコーディングまでを行い、その後にテスト担当者がテストを行っていました。しかし、W字モデルでは、上記のように、それぞれが並行して作業を行うことがわかります。

開発工程ではまだテスト対象ができあがっていませんが、テスト担当者が加わって仕様レビューを行うことが可能です。また、要件定義書や設計書から、テスト観点やテスト項目も抽出できます。

テスト作業を開発が終わってからはじめると、テスト担当者の観点からのレビューを開発当初から受けられません。後になって、仕様レベルの不具合が発生すると手戻りが大きいため、はやめの対処ができるW字モデルにより品質を高めることが可能です。

ソフトウェアテストに関してはこちらもご覧ください。
＞＞ソフトウェアテストとは？種類や目的、重要な7原則を紹介のページへ
＞＞ソフトウェアテストのよくある質問にお答えします。目的や種類、作業内容、外注先の選び方などを解説のページへ
＞＞ソフトウェアテストを効率化するには？テスト設計・テスト実行それぞれの方法を解説のページへ
＞＞「良い」ソフトウェアテストの定義～プロが教える４つのポイント～のページへ

V字モデルとの違い

V字モデルも、W字モデルと同様に、要件定義工程とシステムテスト工程など、開発工程とテスト工程が対応しています。ただし、W字モデルのように、テスト作業を開発工程で同時並行するわけではありません。対応する各工程の仕様書に沿ってテストをするため、テスト内容や責任者が明確になるという開発モデルです。

開発とテストの各工程を対応させたのがV字モデルであり、それをさらに発展させて並行作業を行うようにしたのが、W字モデルといえます。

W字モデルの要素と対応関係

W字モデルの要素と各工程の対応関係について、解説します。

要件定義＝システム／受入テスト

要件定義工程では、開発担当者がユーザーや性能面からの要件を洗い出して、定義していきます。要件定義書を作成し、システムの要件を明確にまとめます。

これと並行して、テスト担当者が仕様レビューを行うのが特徴です。開発担当者は、どうしても開発者の目線で開発を行ってしまうため、ユーザー目線、テスト目線の対応が漏れることがあります。

たとえば、ECサイト開発において、以前のバージョンのシステムでは取引手数料情報をつねに表示しており、その流れで次の機能追加でも同じように手数料情報を記載したとします。しかし、実際は手数料を負担するユーザーはほとんどおらず手数料表示欄は不要だとユーザーの評判が悪かった場合、手数料表示の要件を見直す必要があるでしょう。開発者は出せる情報はすべて出した方がユーザーは喜ぶと考えがちですが、実はそうでもないのです。

テスト担当者はユーザー寄りの目線をもっているので、その要件の不備に気づくかもしれません。このように、システムそのものはまだできあっていませんが、仕様検討段階で行えるテストもあります。

また、要件定義書に沿ってテスト担当者がテスト観点や項目を抽出し、それにしたがってシステムテスト、受入テストを行います。テスト担当者が要件定義書に沿ってテスト準備を行う際に、要件バグを発見できる可能性も高いです。

基本設計＝結合テスト

基本設計では、要件定義工程で定義された要件をもとに基本設計を行います。

テスト担当者は基本設計書ができあがったら、それをもとに結合テストのテスト観点や項目の抽出を行います。設計段階でテストについて考えることで「このテストを実施したら本当にこの設計で問題ないのか？」という観点が生まれます。設計をするというスタンスでは見つからないミスも、テスト項目を考えるというスタンスだと見つかることもあるのです。

たとえば、スマホで日づけを入力するフォームの仕様を決める際、開発者が何も考えずに、前バージョンのシステムと同じ入力規則を指定したとします。しかしユーザーは、年と月と日を別々に入力させられるうえ、数字で入力すると決まっているのに、いちいち文字入力モードに戻されるのは面倒と考えるでしょう。このようなユーザー目線をもつテスト担当者ならではの設計レビューを行うことが可能です。

そして、結合テスト工程では、準備しておいたテストを実施します。

詳細設計＝コンポーネントテスト（単体テスト、ユニットテスト）

詳細設計工程では、基本設計で定義されたモジュールやコンポーネントごとに、詳細な設計を行います。

コンポーネントテストができるプログラミングスキルをもつテスト担当者がいれば、コンポーネントテストをテスト担当者が行うこともあります。しかし、一般的には開発担当者がコンポーネントテストを担当することが多いです。

テスト担当者はできあがった詳細設計書をもとに、コンポーネントテストのテスト観点やテスト項目を抽出し、テストの準備を行います。上記の基本設計時と同様に、設計段階でテスト項目を抽出することで、設計ミスが見つかることもあるのです。

そして、コンポーネントテストの工程に入ったら、テストを実施します。

コーディング

コーディング工程で、開発担当者はコーティング作業を行います。プログラミング能力が高いテスト担当者がいれば、コードレビューを行います。開発担当者がコードレビューを行うと気づきにくいコーディングミスも、テスト担当者の目でレビューすると気づくことがあります。

W字モデルのメリット

ここでは、W字モデルを導入するメリットについてご説明します。

早期に準備を開始できる

従来の開発モデルだと、テスト担当者がテスト準備を行うのは、テスト工程がはじまる直前の場合が多いです。しかし、それだと、品質の高いテストを行うための準備ができないことがあります。

W字モデルの場合、要件定義工程で対応するシステムテストや、受入テストの準備を行うなど、対応する工程のテスト準備を先行して実施します。そのため、早期にテスト準備を行えて、品質の高いテストを行うことが可能です。

設計の抜け漏れ・矛盾を発見しやすくなる

開発フェーズで、テスト担当者がチェックの目を光らせることにより、早期に設計の抜けや漏れ、矛盾などの不具合を発見しやすくなります。

そもそも、開発担当者の目線とテスト担当者の目線は、まったく異なるのです。開発担当者はどうしても、仕組みやつくりやすさの面で設計を行う傾向があります。しかし、テスト担当者は、純粋に仕様や設計に間違いや矛盾がないかという目線で確認するため、開発担当者目線では気づかない不具合を見つけやすいのです。

手戻りを減らせる

要件定義段階でテスト担当者が仕様チェックを行うため、はやめに仕様の漏れや誤りを発見できます。また、設計段階でテスト項目を抽出することで、開発担当者が思いつかないような不具合を発見できることもあります。また、開発作業を開発担当者だけが行うのではなく、テストの目線をもったテスト担当者が参画することで、不具合を見つけやすいのも大きなメリットです。

このように、W字モデルは通常の開発モデルと比べると、漏れや誤りを早期に見つけやすい作業プロセスになっています。そのため、テストを実施してはじめて不具合を見つけるよりも、手戻りを減らせることがわかります。

担当者間のコミュニケーションが円滑化される

W字モデルでは、開発担当者とテスト担当者が一緒に開発作業を行います。そのため、担当者間のコミュニケーションが円滑化されることもメリットです。

開発担当者とテスト担当者は、その仕事内容の違いから、どうしても敵対してしまう傾向があります。開発担当者にしてみると、テスト担当者は、自分たちの仕事の不備を見つける敵のような存在と感じることもあるでしょう。テスト担当者のなかには、開発者はバグをつくり込む存在と考える人もいるかもしれません。

しかし、実際はバグのない品質の高いシステムや、ソフトウェアを開発するという同じ目的をもって、協力して開発を行うメンバーです。W字モデルでは、はやい段階から両者が一緒に作業を行うことで、コミュニケーションをとりやすく、敵対関係になりにくいでしょう。

リリースまでの期間を短縮できる

開発フェーズからテスト担当者が並行して作業を行うことで、リリースまでの期間を短縮できることもメリットです。

テスト工程に入る前にテスト準備がすでに終わっているので、すぐにテストを実施できます。また、開発工程でテスト担当者によるレビューを挟んで、手戻りを減らせます。そのため、開発期間の短縮が可能です。

W字モデルの注意点

W字モデルにはメリットもありますが、注意すべき点もあります。ここでは、W字モデルを導入する際に知っておくべき注意点について、解説します。

管理がむずかしくなる

従来の開発工程で開発を行う、テスト工程でテストを行うなどの単純なやり方ではないため、プロジェクト管理がむずかしくなることに注意が必要です。

開発工程に、開発担当者だけでなくテスト担当者も参画するため、お互いの情報共有なども重要です。たとえば、開発担当者が要件定義書や設計書などを変更する際は、テスト担当者にも変更を周知する必要があるでしょう。

通常の開発モデルよりも参画する担当者が多く、作業内容も複雑になるため、プロジェクトマネジメントを適切に行う必要があります。

上流工程の可視化を進める必要がある

上流工程である要件定義、設計工程で、開発担当者とテスト担当者が同時並行で作業を行います。その際に、ドキュメントや作業進捗などを適切に共有しなければなりません。作業内容を可視化し、異なる立場の担当者が協力して、作業しやすい体制を整える必要があるでしょう。

経験豊富なテストエンジニアを必要とする

W字モデルの作業内容は複雑なので、経験豊富な担当者が必要です。とくに、テスト担当者は仕様レビューや設計への参画、コードレビューなどテスト以外の作業を行う場合、相応のスキルが必要です。たとえば、コードレビューやコンポーネントテストを担当してもらうなら、高度なプログラミング能力が必要になります。そのため、テストエンジニアに多くの役割を分担させるなら、経験豊富な人材を割り当てなければなりません。

W字モデル以外の開発モデルとの違い

W字モデルとそれ以外の開発モデルの違いについて、ご説明します。

ウォーターフォールモデル

ウォーターフォールモデルとは、上流から下流へ水が流れるように、開発工程からテスト工程へと作業が行われるモデルです。W字モデルとは異なり、テスト作業がはじまるのは、テスト工程に入ってからであることが多いです。

最初に計画を固めて、開発からテストまでを行うウォーターフォールモデルは、大規模システム開発に適しています。開発フェーズではテスト担当者、テストフェーズでは開発担当者のスケジュールが空きます。そのため、何度も機能追加を重ねる大規模システム開発で、開発担当者とテスト担当者が交互にプロジェクトに入ることもあるのです。

アジャイル開発

アジャイル開発は、開発からテスト終了までのプロセスを何度も繰り返す手法です。短いスパンの開発サイクルを何度も繰り返しながら、問題点を把握して解決し、ユーザーのニーズを次々ととり入れられます。

システム開発における「テスト分離」「第三者テスト」の導入

※ご登録いただくとその場で無料動画の視聴が可能です。
本動画では、システム開発の「テスト分離」「第三者検証」の導入やメリットのほか、その実現に向けたアプローチについて、専門知識と経験豊富なテストの専門家が解説しています。
昨今のシステム開発は、ITシステムの有識者不足や開発効率に影響する品質など、さまざまな課題が発生しています。こうした問題を解決する一つの方策である「テスト分離」「第三者検証」をわかりやすく説明した内容になっておりますので、ぜひご視聴ください。

ダウンロード

まとめ

この記事では、W字モデルについて導入するメリットと注意点、ほかの開発モデルとの違いについて解説しました。

W字モデルでは、開発工程にテスト担当者が入ることで、早期に不具合を発見でき、品質を向上させやすいなどのメリットがあります。

SHIFTでは、徹底して精度と品質を高めるソフトウェアテスト・第三者検証サービスを提供しています。自社のシステム開発の品質があがらないなどの場合には、ぜひご相談ください。

＞＞ソフトウェアテスト・第三者検証のページへ
＞＞導入事例ページへ
＞＞料金についてページへ
＞＞お問い合わせページへ

監修

株式会社SHIFT
「ヒンシツ大学」クオリティエヴァンジェリスト　永井敏隆

大手IT会社にて、17年間ソフトウェア製品の開発に従事し、ソフトウェアエンジニアリングを深耕。SE支援部門に移り、システム開発の標準化を担当し、IPAのITスペシャリスト委員として活動。また100を超えるお客様の現場の支援を通して、品質向上活動の様々な側面を経験。その後、人材育成に従事し、4年に渡り開発者を技術とマインドの両面から指導。2019年、ヒンシツ大学の講師としてSHIFTに参画。

担当講座

・コンポーネントテスト講座
・テスト自動化実践講座
・DevOpsテスト入門講座
・テスト戦略講座
・設計品質ワークショップ
など多数

――――――――――
ヒンシツ大学とは、ソフトウェアの品質保証サービスを主力事業とする株式会社SHIFTが展開する教育専門機関です。
SHIFTが事業運営において培ったノウハウを言語化・体系化し、講座として提供しており、品質に対する意識の向上、さらには実践的な方法論の習得など、講座を通して、お客様の品質課題の解決を支援しています。
https://service.shiftinc.jp/softwaretest/hinshitsu-univ/
https://www.hinshitsu-univ.jp/
――――――――――

この記事を書いた人

著者株式会社SHIFT　マーケティンググループ

SHIFTは「売れるサービスづくり」を得意とし、お客様の事業成長を全力で支援します。無駄のないスマートな社会の実現に向けて、ITの総合ソリューションを提供する会社です。

サービスサイト：https://service.shiftinc.jp/
コーポレートサイト：https://www.shiftinc.jp/
X（旧Twitter）：https://twitter.com/SHIFT_cp

ご支援業種

製造、金融（銀行・証券・保険・決済）、情報・通信・メディア、流通・EC・運輸、ゲーム・エンターテイメント

など多数

前のページへ

次のページへ

コラム一覧に戻る

W字モデルとは？V字モデルとの違い、導入するメリット・注意点を解説

Introduction