ウォーターフォール開発とアジャイル開発における品質管理について現役コンサルタントが解説
COLUMN

RGS株式会社コンサルタントの君塚です。今回は開発工程に品質をどのように組み込むのか見ていきたいと思います。代表的な開発工程であるウォーターフォール開発とアジャイル開発を取り上げて、品質へのアプローチを見てみましょう。

ウォーターフォール開発モデルにおける品質管理

ご存じのようにウォーターフォール開発でテストは最終工程であり、品質のカギを握る最も重要な工程と言えます。開発の最終段階で結合テスト、総合テスト、セキュリティテストなど開発を終えたプログラム群に対するテストを行うことでシステム全体の品質を確保することが目的です。

図1：ウォーターフォール開発

しかし、この段階で要件の不足、仕様の齟齬、仕様のミスが発見されると場合によっては要件定義にまで遡って修正または追加の工数が発生、そこまで遡らずとも開発の手戻りはコードや成果物の修正が必要となりコストやスケジュールに大きな影響を与えます。こういう事態を防ぐためプロジェクトは各フェーズでレビューを行い品質の確保に努めるのが常です。要件定義や基本設計など上流工程ではエンドユーザーを交えたレビューで要件、仕様の確認を、詳細設計では開発チームでレビューして開発レベルの仕様の誤りを防ぎます。しかし、エンジニア同士では開発目線のレビューになり要件レベルの視点が欠けてしまい必要な要件を見落としてしまうことも想定されます。

このため最近では「品質は上流工程から作り込む」という考え方の下、要件定義フェーズ、あるいは設計フェーズからテストを担うエンジニアが入り業務要件、システム要件を踏まえた上で開発工程、テスト工程に要件のあいまいさ、不明確・不明瞭な仕様を残さないようにする取り組みをしているプロジェクトもあります。この作業には経験を積んだエンジニアが必要ですが、規模の大きなプロジェクトとなると重要な役割となります。

テスト工程ではテスト自動化も考慮すべきでしょう。人手のテストよる以下の欠点をカバーすることがきます。

• 人為的なミスの発生
• 同様の作業を繰り返す単純であるが多くの工数が必要なテスト
• リグレッション要素のテストが随所に必要なため同じテストを繰り返す

人による作業の繰り返しはミスあるいは抜けの侵入の余地が高まるため、それを防ぐための自動化は貴重な対策になるでしょう。

ところで、ウォーターフォールモデルは、開発プロセスとテストプロセスを俯瞰した視点からV字モデル（図２）といわれることがあります。

図2：V字モデル

V字モデルに従って、開発工程を実施すると次に示すようなアプローチとなります。

• 要件定義では運用テストあるいは総合テストの設計を同時に進める、あるいは念頭に置いて作業を進める
• 基本設計では結合テストの設計を並行作業する、あるいはテスト工程をイメージして作業を進める

プログラミングまでの工程が長くなりますが、結果として設計・開発工程に相対するテスト工程がリンクして一貫性を伴った品質を確保できる枠組みとなっています。また、各々の工程で作成される成果物はテストを意識した結果、仕様の矛盾やあいまいさがを極力排除でき品質が確保されたものになるでしょう。また、上流工程から品質担当のエンジニアが入ることで上流から下流にかけて安定した品質が保てるでしょう。このモデルは組織という観点では工程ごとに要件、仕様が定まるため異なる組織が作業を担うことが可能となります。要件定義、設計、開発（プログラミング）、テストと分業体制が成立するためそれぞれの工程を得意とする組織が担うことができます。ただ、現実的にはリソース配分、スケジューリングが複雑になるなどの難しさがあると思います。

上流工程からQCエンジニアが参画する場合、次のような作業の進め方となるでしょう（これ以外のプロセスも考えられますがあくまで一例としてとりあげます）。

• 要件定義工程でQCの視点で要件の矛盾、あいまいさをあぶり出して開発メンバーと要件を詰めていく
• 設計工程ではシステム設計に基づいてQCメンバーが結合テスト、総合テストの設計を行い、設計レベルの齟齬を開発部隊にフィードバックする

この場合、開発工程とQC工程が並走しますが、システム設計とテスト設計のタイミングの問題が発生します。

• テスト設計はシステム設計の内容を確認しながら進めるため、ある程度システム設計が進まないと開始できない（テスト設計の開始タイミングのずれ）
• 開発チームのプログラミングの終了とQCチームのテスト設計の終了タイミングが合わない（プログラミングがある程度進まないと結合テストはできない。プログラミングが終了してないと総合テストの実施は難しい）

QCチームとしては要件定義、テスト設計、テスト実施するメンバーとそれぞれ別のリソースをアサインして柔軟に対応できれば、タイミングのずれでリソースが空くということもなく進められます。しかし、開発を専門とする会社（SI企業）がそこまでのQCチームを持つのは開発コストへの負担と提供価格への影響から考えても難しいのではないでしょうか。

そこで近年注目されているのが第三者検証機関といわれるテストを専門としたエンジニアの集団です。チーム体制としてテスト設計を担うチーム、テストを実施するチームで構成され開発企業が開発をしている間に要件定義書を基に要件の把握を行い、システム設計書を参照しながらテスト設計を行います。テスト設計の終了を見込んでテスト実施チームが参画するのでリソースの空きが発生することなくテスト作業を進められます。すべてのテスト設計エンジニアがテスト終了までプロジェクトに残る必要ないため作業が終了した時点で核となるエンジニアを残して次のプロジェクトに移っていくので効率的な動き、リソース計画が立てられます。

アジャイル開発モデルにおける品質管理

アジャイル開発はシステムを小さな機能単位に分け、分けた機能ごとに計画、設計、開発、テスト、リリースを繰り返す手法です。機能ごとに開発、リリースすることで次に挙げるような利点があります。

• 開発工程を短縮できる
• ユーザーの意見を開発に反映してリリースすることを繰り返すためユーザーの満足度が高い
• 機能単位でリリースするためウォーターフォール開発に比べて品質を確保し易い

図3：アジャイル開発モデル

機能ごとにユーザーとコミュニケーションを重ねリリースしていくため、ユーザーとの要件の齟齬や仕様のミスなど開発工程の上流で発生する問題を未然に防ぐことができます。また、小さな単位でのリリース、ユーザー確認ができるため全体の開発工程を短くすることができます。機能単位でのリリースを繰り返すこのモデルはCI/CDツールと非常に相性がよく、CI/CDはこのモデルに不可欠のツールと言ってもよいでしょう。コード開発、ビルド、テスト、デリバリー、デプロイを自動化できるため、それぞれを手作業で行う手間とミスをなくすことができ、作り込んだユーザー要求をすぐに確認できます。ただし、テストにおいて自動化を実現するためにはテストコードの作成は必須となります。ちなみにATgoはテストプロセスとしてCI/CDに組込むことができます。しかもテストコードはAIによる自動生成が可能です。

しかし、アジャイル開発は次に挙げる欠点、あるいは難点があることは確かです。

• 小さな開発単位に集中するため全体の方向性を見失いやすい
• プロセスに習熟しユーザーとのコミュニケーションを円滑に進められる開発者でないとスケジュール、品質を確保が難しい
• アジャイルの手法を踏まえた上で全体の進捗を管理できるPMが必要

また、アジャイルは早期にリリースすることが主眼なのでドキュメントが不足しがちなのは否めません。最近はテスト工程を専門会社に委託するプロジェクトが多いですが、ドキュメントに頼れないため、ユーザーや開発者からのヒアリングで補うことも多々あるようです。

これらの問題に対しては次のような対策が考えられます。アジャイル開発に習熟してない開発者に対しては習熟者がある程度サポートする、あるいはPMレベルがユーザーとのコミュニケーションに参加するなどの配慮。アジャイル開発といえどもすべてのドキュメントを排して作業を進めることを意味していません。システム設計の教科書に則るのではなく発注者との認識共有、設計の意図を残す、後を継ぐ開発者への指南書など必要なドキュメントは記載すべきです。どのドキュメントを残すかはプロジェクトによって異なるので開始時点で定めておきましょう。

しかし、アジャイルに限らずPMにはプロジェクトの全体を俯瞰して進捗をリードできる力、スキルが求められることは言うまでもありません。

さいごに

まだまだ多くの視点があることと思いますが、ここまで二つの開発手法に対する品質の作り込みについて見てきました。

ウォーターフォール開発では、手戻りを防ぐために「上流工程からの品質作り込み」や「第三者検証機関の活用」が有効です。一方、アジャイル開発では「CI/CDや自動化による高速なサイクル」が品質を支える一方で、適切なドキュメント管理や全体を俯瞰できるPMの存在が成否を分けます。

テスト自動化やAI活用など品質確保の手段は進化していますが、「どの工程で、どう品質を担保するか」を初期段階で定義する重要性はどちらのモデルでも変わりません。

プロジェクトの特性を正しく理解し、最適な品質管理アプローチを選択・実践していくことこそが、システム開発を成功へ導く重要なミッションと言えるでしょう。