はじめに

皆さんこんにちは。GC編集部です。ソフトウェア開発において、「どのように開発を進めていくべきか」は重要な問いです。開発の規模が大きくなるほど根性論は通用せず、なんらかの開発モデルと言われる方法論を踏襲してスムーズな開発を目指すことが一般的です。本コラム記事では、そんな開発モデルの中で最もよく知られているウォーターフォールモデルとその中でのソフトウェアテストの位置づけを考えていきたいと思います。ウォーターフォールモデルについて聞いたことはあったけれどよくわからないという方は特にご一読ください。

開発モデルとは〜SDLC〜

そもそも開発モデルとはどういったものでしょうか。ソフトウェア開発における開発モデルとは、基本的にソフトウェアの開発を行うプロセスをまとめたものを言います。よく知られているソフトウェア開発のモデルとしてはソフトウェア開発ライフサイクル（Software Development Life Cycle ：SDLC）というものがあります。

※SDLCはSystems Development Life Cycleの略でシステム開発ライフサイクルを示す場合もあります。意味は同じです。

SDLCではソフトウェア開発が6個程度のフェーズで括られていて、ライフサイクルという名前の通り、それぞれのプロセスが終了した後にまたはじめのフェーズに戻ってソフトウェアの開発が続けられることを意味します。

SDLCでは、まずPlanning：計画からソフトウェア開発は始まります。計画フェーズでは、いわゆる要求分析が行われ、ビジネスレベルでどういったものを作成したいか要求が分析されます。次に、Defining：定義フェーズに移ります。定義フェーズでは分析した要求を基に要件が定められます。要件定義とも言いかえられます。その次はDesigning：設計フェーズです。設計フェーズでは、作りたいソフトウェア（プロダクト、システム）全体の設計が行われます。そして、設計を基に次はBuilding：開発フェーズに移ります。開発フェーズでは、文字通り開発が行われます。コーディングやインフラ環境の準備も含みます。開発フェーズの次はTesting：テストフェーズです。テストフェーズでは、開発されたプロダクトが要件を満たしているか確かめられます。そして一定の基準を満たしたプロダクトは市場に投入 Deployment：展開されます。市場に展開されたプロダクトは、メンテナンスの対象となり、必要に応じて追加機能が計画されます。こうして、二回目の計画フェーズが行われていき、ライフサイクルとして2週目に突入するわけです。

ソフトウェア開発ライフサイクルはソフトウェア開発における一つのスタンダード的な考え方です。実際の現場において、「今回がSDLCの2週目ですね」、といったやり取りが行われることはありませんが、それでも考え方という意味ではソフトウェア・システム開発に関わる方なら必ず知っておくべきものの一つです。そういう意味では、次に紹介させていただくウォーターフォールモデルも必ず知っておくべき考え方の一つです。

https://ja.wikipedia.org/wiki/システム開発ライフサイクル

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

ウォーターフォールモデルとは、ソフトウェア開発モデルの一つで、滝の水が落ちるように一方向的にソフトウェア開発が流れていくことを表す開発モデルです。ウォーターフォールモデルは基本的にプロセスとしてはソフトウェア開発ライフサイクル（SDLC）と同じです。ただ、ウォーターフォールモデルはその特徴として、プロセスが完全に終わってから次のプロセスへ移り、一度そのプロセスが終わったら前のプロセスには戻らないことが上げられます。これが、ウォーターフォールモデルがウォーターフォールモデルたる所以です。

ウォーターフォールモデルで存在するプロセスは、その多くが先程のソフトウェア開発ライフサイクルの説明と重複するので、設計に関してのみ詳細に説明いたします。

ウォーターフォールモデルでは設計プロセスを外部設計と内部設計という言葉で二分することが多いです。外部設計は概要設計とも言われ、作成しようとしているプロダクト（システム）の全体像を設計するプロセスです。具体的には、ソフトウェア構成や外部インターフェースの設計が外部設計で行われます。

内部設計は詳細設計とも言われ、ソフトウェアの内部を詳細に設計するプロセスです。実際のデータの流れやデータベースにどのように値が格納されるか（DB設計）の設計も内部設計プロセスに含まれます。

このようにウォーターフォール・モデルでは大きな枠組みとしてはソフトウェア開発ライフサイクルのプロセスと同じです。ただ、開発チームでウォーターフォールモデルを採用した場合は、それぞれのプロセスごとに達成すべき要件についてしっかりと話し合い、いかに手戻りを少なく開発を行うか、が重要となります。

https://ja.wikipedia.org/wiki/ウォーターフォール・モデル

ウォーターフォールモデルにおけるソフトウェアテスト

さて、ウォーターフォールモデルにおけるソフトウェアテストはどのような扱いになるでしょうか。ウォーターフォールモデルにおけるソフトウェアテストは、ソフトウェア開発ライフサイクルにおけるテストに記載した通り、「開発」の後続プロセスに位置します。ソフトウェアのコーディングが終わった後にテストが行われることは実際にソフトウェア開発に関わったことがある方であれば、イメージしやすいかと思います。また、いわゆるQAチームというチームが存在した場合にタスクとしてテストを担うのは、その多くがテストプロセスに入ってからです。

※QAチームがテスト工程に入ってからメインに関わることの是非は本コラム記事では触れません。

さて、ここで、ウォーターフォールモデルにおいてソフトウェアテストはどのように実施すべきでしょうか。これまでに別の記事で紹介させて頂いたとおり、ソフトウェアテストはそれ自体にも多くのプロセスが存在します（ソフトウェアテストとは）。つまり、ソフトウェアテストはそのプロセスの中でも計画・設計・実行・・・と観点を明確にした上でしっかりと管理された上で行われるべきというのが基本的な考え方です。

ソフトウェアテスト実施の観点を明確にする上で重要な考え方にテストレベルという観点が存在します。こちらについても詳細は別記事にてご説明させていただきました（ソフトウェアテストのテストレベル）。テストレベルでは、その対象範囲によって基本的に実施者を切り分けて捉えます。単体テストは開発者自身が行い、受け入れテストはテスターが担う、というようなことです。つまり、ウォーターフォールモデルにおけるソフトウェアテストは、プロセスとしては一段階として捉えられているものの、テストレベルで分断され、かつその中でも実施者が異なる（可能性が高い）ということです。

このようにソフトウェアテストはソフトウェア開発ライフサイクルの中においても概念が入り乱れており複雑になっています。プレーヤー目線で捉えると、業務としては定式化されていることは多いものの、ソフトウェア開発全体という視点で考えるとソフトウェアテストはプレーヤーも変わるため非常に捉えにくいです。こうしたソフトウェアテストの開発プロセスにおける全体感を理解するためのモデルとして、V字モデルというものが存在します。

V字モデルとは

V字モデルとはウォーターフォール・モデルが修正された開発モデルとして位置づけられているもので、それぞれ開発フェーズに紐付いてテストレベルが存在します。要求分析に対して受け入れテスト（AT）が位置し、仕様に対してシステムテスト（ST）が位置し、概要設計に対して統合テスト（IT）が位置し、詳細設計に対して単体テスト（UT）が位置します。V字モデルの意図するところとして、この対応関係はそれぞれのテストが左に定められたものを確かめる存在であるということです。ビジネス側の要求は受け入れテストで確かめられ、仕様はシステムテストで、概要設計の内容は統合テストで、詳細設計の内容は単体テストでそれぞれ確かめられるということです。実質的にウォーターフォール・モデルもこの対応関係で行われますが、V字モデルではより厳密にテストレベルと開発プロセスの対応関係を図示しています。

以下、執筆者の所感として補足

QAチームの開発への関わり方〜シフトレフトという考え方〜

さて、QAチームは開発に対してどのように関わることが理想でしょうか。近年、そもそもウォーターフォール型の開発モデルは時代遅れとされ、アジャイルと言われる反復を何回も繰り返してスピーディーに機能をリリースしていくモデルが主流とされてきています。これまでの箱売りの時代からソフトウェアをサービスとして販売するモデルへの変遷の中ではウォーターフォールモデルのような小回りが利かないモデルではなく、機能ごとに修正内容に対応し、リリースが可能なアジャイルモデルの方が適しているため、開発モデルの変化は自然と言えます。ただ、とはいえ、開発そのもののプロセスは刷新されたわけではなく、設計フェーズはアジャイル開発の中でも存在し、ソフトウェアテストの重要性がアジャイル開発でなくなるわけではありません。それゆえウォーターフォール型の開発モデルにおけるQAチームの立ち位置を思考することは令和の現代においても意義があるのです。

これまでに別記事でもQAチームは基本的にはテストフェーズにおいても後半に関わることを記載させていただいてきました。テストレベルで言うところのシステムテスト、受け入れテストがQAチームのメインのスコープです。ただ、一般的な原則として、開発後半にバグが見つかるほど、その修正には時間が掛かることが知られています。これは当たり前の話で、開発プロセス後半のほうが関連するシステム・コードが増えているので、そもそも原因の究明に時間がかかり、さらにその変更箇所による影響も増えるためです。ウォーターフォールモデルで当てはめて考えると、イメージはつきやすいと思います。滝の水が落ちきったような地上近くにおける修正は多くのエネルギーを必要とするのです。つまり、実際の感覚と一致して、基本的にバグは開発全体の中で前半に見つけたほうがよいのです。

このように、開発全体の中で前半にバグが見つかったほうがよいことを前提にソフトウェアテスト自体も前半に移行するような考え方をShift left testing（シフトレフト）といいます。JSTQB Foundation 第4版にも記載されており、日本においてもソフトウェアテストに関わる方の中ではよく知られた考え方です。シフトレフトは言葉としては海外の方が知名度が高く、ソフトウェア開発の効率性という文脈でよく用いられています。

ただ、シフトレフトのような考え方はマネジメント層が主な対象で現場の実際にソフトウェアテストを担うプレーヤーからは関係が無い話であると考える方が多くいらっしゃいます。また、ソフトウェア開発における前半部分のテストは開発者がその担い手で、シフトレフトという考え方を知ってはいても、QAチームは関わることが出来ない、と考える方もいらっしゃいます。実際にそうでしょうか。

もちろん、Role and Responsibilityという観点からもまずは組織の中の自身の役割をしっかり果たすことが重要です。ただ、コミュニケーションとして伝え方という問題はあれど、テスターも含めてシフトレフトの考え方を持つことは、その組織全体の開発の効率性において重要です。例えば、より詳細にバグの発見をレポートで報告することで、そのバグがどのテストレベルで見つけるべきバグであったかプロダクト（システム）の管理者は把握することができます。また、現場のテスターのときからこうしたソフトウェア開発の全体感の概念も身につけておくとリーダーとなったときに俯瞰して開発の全体感を把握することができ、全体のプロセスを意識した提案が可能となって、結果としてソフトウェアの品質向上に向けての貢献が大きなものになり得ます。

以上、いかがでしたでしょうか。

開発モデルとは何かから、ソフトウェア開発ライフサイクル、そしてウォーターフォールモデル、V字モデルの説明、さらにシフトレフトの話もさせていただきました。

ソフトウェアテストという観点においては、いずれにおいてもまずはテストレベルの考え方が重要です。もしテストレベルの理解を深めたい方がいらっしゃいましたら、過去記事をご覧ください。

本コラム記事がソフトウェアテストについて学習したい方の一助となればと思います。

まとめ