SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

Developers Summit 2023 セッションレポート(AD)

アジャイル開発で行いたいテストの準備、進め方とは?──品質保証を行うプロセス、フレームワークを紹介

【10-B-2】アジャイル開発に必要なテストの準備、進め方

  • X ポスト
  • このエントリーをはてなブックマークに追加

ウォーターフォールからアジャイルへの移行で見られる失敗例

 アジャイルの手法はいくつかあるが、船橋氏は世界のアジャイル開発の取り組みを調査した「State of Agile Report」の2021年の結果では、66%がスクラムを採用していることから、スクラムをベースにその後のセッションを展開した。

 ウォーターフォール(V字モデル)のプロセスを採用したプロジェクトでは、インプットとアウトプットが明確に定義されていて、そのアウトプットである成果物や書類を完成していること、そしてそのレビューをして次の工程にすすみ、リリースを目指す。後工程での変更は前工程にさかのぼって反映させる必要がある。V字の前半(要件定義や設計、実装、初期のテスト)は開発チーム、後半(結合テスト、総合テスト、受け入れテスト)は品質保証のチームが担当する。

 要求要件定義、基本設計と詳細化していく過程で、個々の機能詳細化、明確化していくので、フロントエンドの担当、バックエンドの担当など役割が固定される。各インターフェースは仕様書をもとにつながっているものの、個別具体的な部分の担当となっているので、担当外の領域がわからず全体的な把握がしにくい。

V字モデルの分担のままアジャイルに移行してしまう
V字モデルの分担のままアジャイルに移行してしまう

 一方、スクラムの場合は最大4週間のスプリントを繰り返す活動となります。工程の概念はなく、開発活動期間も短いので必要最低限のドキュメントによってチームが共通認識を得る形を重視して進む。優先順位をつけたプロダクトバックログに順々に対応していくため、プロダクトバックログには改善事項だけでなく、どのような価値を与えるかにまで言及することも多い。設計、実装、テストの過程において全体の統制が意識される。

 船橋氏は、ウォーターフォール(V字モデル)からアジャイル(スクラム)への移行がうまくいかない組織は、従来の開発チームが担当していた部分をスクラムチーム化して、品質保証チームは変わらず最後に対応する体制を構築しがちだと指摘した。

 「その結果、本来動くプロダクトを重視しているはずが、スプリント内でリリースすることができないため、フィードバックを得られません。品質保証担当が取り残されているためリリース頻度の早期化というのも行いません。継続的に価値を提供することができない典型的な例です」(船橋氏)

 船橋氏は、SHIFTが改善を担当した、ある金融プロジェクトを具体例として紹介した。SHIFTはこのプロジェクトのチームAから総合テストをしてほしいと依頼を受けた。スプリントは4回実施され、スプリントのたびに不具合の数は増え、スプリント4では重大な不具合が生じてテストが中止となり、アジャイルをやめてウォーターフォールに戻すこととなった。

アジャイルを断念したケース
アジャイルを断念したケース

 「開発部隊と品質保証部隊は分かれているのだから、スクラムチーム化しても結果的にプロセスは変わりません。プロジェクト全体で一つのチームになれば解決すると考えますが、そう簡単にはいかないです。従来の工程に縛られて各々のタイミングで活動していた部隊同士がある日突然今日から一緒に活動しましょうっていうのは無理があります」(船橋氏)

 完成に近づいたプロジェクトに対して総合テストをし、非機能テストをするなどの活動をしていたウォーターフォール型チームの場合、アジャイルになってさまざまなテストをどのタイミングで行えばいいかわからないという問題が生じるのだ。

 続いて船橋氏は、同じ金融プロジェクトの別のチームの例(チームB)を示した。スプリント5回のうち、スプリント3と4では不具合の検出は低いものの、スプリント5ではテストケースがほかと比べて多く、テストケースが実施できていないように見える。このチームは開発や評価の方法も定まらずメンバーの関係がぎくしゃくしてしまい、安定したパフォーマンスが出せなかったという。

メンバーの関係が円滑でなく、品質が安定しないチームの例
メンバーの関係が円滑でなく、品質が安定しないチームの例

次のページ
SHIFTが生み出し実践する、品質保証フレームワーク

関連リンク

この記事は参考になりましたか?

  • X ポスト
  • このエントリーをはてなブックマークに追加
Developers Summit 2023 セッションレポート連載記事一覧

もっと読む

この記事の著者

森 英信(モリ ヒデノブ)

就職情報誌やMac雑誌の編集業務、モバイルコンテンツ制作会社勤務を経て、2005年に編集プロダクション業務やWebシステム開発事業を展開する会社・アンジーを創業。編集プロダクション業務においては、IT・HR関連の事例取材に加え、英語での海外スタートアップ取材などを手がける。独自開発のAI文字起こし・...

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

CodeZine編集部(コードジンヘンシュウブ)

CodeZineは、株式会社翔泳社が運営するソフトウェア開発者向けのWebメディアです。「デベロッパーの成長と課題解決に貢献するメディア」をコンセプトに、現場で役立つ最新情報を日々お届けします。

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

丸毛 透(マルモ トオル)

インタビュー(人物)、ポートレート、商品撮影、料理写真をWeb雑誌中心に活動。

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

提供:株式会社SHIFT

【AD】本記事の内容は記事掲載開始時点のものです 企画・制作 株式会社翔泳社

この記事は参考になりましたか?

この記事をシェア

  • X ポスト
  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/17432 2023/04/03 12:00

おすすめ

アクセスランキング

アクセスランキング

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング