教科書には載っていないアジャイル開発現場のリアルな課題【後編】

前編では、アジャイル開発普及の背景と、アジャイル開発案件の立ち上げ期に注意すべき既存の社内規約・文化との向き合い方やドキュメント成果物スコープについて紹介しました。

後編は、「アジャイル開発におけるテストの考え方」と「スクラムチームの各ロールが十分に機能するための工夫」をテーマにして、引き続きアジャイル開発現場のリアルな課題とその対策についてお伝えします。

著者プロフィール

伊藤忠テクノソリューションズ株式会社
新事業創出・ＤＸ推進グループ　ＤＸビジネス推進事業部
デジタルイノベーション部　データ・アジャイル課　横尾　和哉 

2017年伊藤忠テクノソリューションズ株式会社に入社後、金融・流通業界のお客様を中心にDX企画・開発を担当。
お客様企業の内製化支援及びアジャイル開発推進を経験。

アジャイル開発におけるテストの考え方

従来のウォーターフォール開発では、V字モデルに則り実装まで終了して仕様凍結されたプログラムに対して、順番に単体テスト、結合テスト、システムテスト、受け入れテストを実施することで、システムの品質を担保してきました。一方で、アジャイル開発では繰り返し開発を行うこと、仕様変更を柔軟に受け入れることが前提となるため、それらを考慮したテストを行う必要があります。開発手法によってテスト方法やテスト実施タイミングは変わってきますが、十分な品質担保をしようとすると開発手法に関係なくテスト工数はそれなりにかかるものです。しかしながら、アジャイル開発を初めて採用する現場でよくある話として、顧客側はアジャイル開発だと素早く開発・リリース出来るという期待を抱きます。一方で、開発エンジニアは確実な品質担保をしようとテストに時間をかけるため、必死に作業しているにも関わらず開発スピードに対して顧客から評価して貰えないということ場合があります。そのため、アジャイル開発におけるテストについては、顧客と十分に協議しながら検討を進めて、品質の基準や各テスト手法について双方の理解を深めることが大事になります。今回は、このようなケースにおいて役に立つアジャイル開発テストの考え方と具体的なテスト手法について紹介します。

アジャイルテスト4象限

アジャイル開発におけるテストについて網羅的に議論する場合、アジャイルテスト4象限を使うのが有効的です。縦軸が「ビジネス面」または「技術面」を表し、横軸は「製品の批評」または「チームの支援」を表しています。各象限でテストの目的が分かれ、テスト自動化のしやすさも異なるため、象限別にテスト方針を検討する必要があります。

例えば、システム重要度が高く十分に品質を担保する必要がある場合、第一象限から第四象限まで全て事前に作成したテストケースに則りテストを実施して、エビデンスも全て取得する従来のやり方が考えられます。その場合、当然ながらテストに時間がかかるためスプリント期間(リリース単位)を長く設ける、あるいはテスト専門のチームを個別に立ち上げるなどの対策が必要になります。しかしながら、やはりアジャイル開発を採用するからには、出来るだけテストを効率的に済ませて素早くリリースしたいという想いを持つ方は多いと思います。その場合に有効なのが、テスト駆動開発や探索的テストです。

テスト駆動開発

テスト駆動開発では、事前に正常系、異常系のテストコードを作成しておき、そのテストをクリアできるように後からプログラムを実装します。開発の早い段階でテストを繰り返すため、比較的早くバグの検知や修正がしやすく、何よりテストコードによりテストを自動化するので、繰り返し行う作業負荷の軽減や手戻りによるロス防止の観点で非常に効果があります。ただし、テストコード作成工数がかかり初期コストが膨らみやすいため、初回リリース後の更新頻度や繰り返し作業回数の観点から中長期的に効果が期待できるケースにおいて採用するのが望ましいです。主に第一象限あるいは、第二象限で採用されることが多いテスト手法です。

探索的テスト

探索的テストとは、従来のテストケースに基づいて行われるテスト「テストケース・ベース・テスト」とは反対に、事前にテスト仕様書を作らず、テスト担当者が以前のテスト実施経験や、事前に整理しておいたテスト観点に則り、探索的に行うテストのことを指します。テストカバレッジの管理が難しく品質の保証を公式にしづらい、テスト担当者により品質がバラつきやすいといったデメリットがある一方で、仕様書作成の時間を省略できる、十分なノウハウがある場合、テストケース・ベース・テストより欠陥を多く検出しやすいといったメリットがあります。従来はユーザビリティテストでの適用、あるいは第一象限、第二象限にてテストケース・ベース・テストと組み合わせて実施することで更なる品質向上を図る使い方が一般的でした。しかしながら、対象システムの重要度や業務影響度が低く、またアジャイル開発チームが成熟しており、テスト担当者が十分にテストに必要な知識を持っている場合、思い切って第一象限から第三象限まで仕様書作成及びエビデンス取得を廃止して、探索的テストのみ実施する方針にすることも選択肢の一つとして考えられます。その場合、以下3点が注意ポイントとなります。

1. 今までのテスト経験により、テスト担当者及びレビュアーである顧客サイドが品質担保に必要なテスト観点を十分に理解していること。
2. 探索的テストを採用するにあたって、顧客側の責任者と品質レベルや障害発生時の責任について十分にすり合わせをしてリスク管理しておくこと。
3. 共通のテスト観点チェックリスト等を設けておき、成果物レビューなどのタイミングで顧客側と一緒にチェック項目を確認するなどして品質のバラツキを抑えること。

テスト方針の一例

筆者が取り組んでいたアジャイル開発案件では、システム重要度が高いシステム領域においては、テストケース・ベース・テストを実施することで確実な品質担保を行っていました。逆にシステム重要度が低く障害発生時の業務影響リスクもほとんど無いようなシステム領域においては、担当者が対象領域に対する一定のテスト経験を積んで成熟したタイミングで、顧客側と相談して探索的テストのみ実施して素早くリリースしていく方針に切り替えていました。

一概にウォーターフォール開発だから重厚にテストをしなければいけない、アジャイル開発だからテストは簡略化して良いとはいえなく、開発手法の特性は考慮しつつも、システム重要度、障害発生時の業務影響リスク、対外的な影響リスクなどを考慮して必要十分な品質担保ができるテスト方法の採用が重要であると考えています。

スクラムチームの各ロールが十分に機能するための工夫

主流なアジャイル開発手法の一つにスクラム開発が挙げられます。スクラムチームのロールは、プロダクトオーナー(PO)、スクラムマスター(SM)、開発者の3役だけですが、各ロールが十分に機能するためには、いくつか乗り越えるべきハードルが存在します。

プロダクトオーナー

まず初めに、POとはスクラムチームが開発する製品の価値を最大化する役割を担う人であり、主に顧客企業の業務部門のリーダークラスの人が担うことが多いです。そのため、アジャイル開発チームの専任になることは難しく、業務部門と兼務をするケースが多々あります。そのような場合、本業が忙しくスクラムチームの活動に割ける時間が限られてしまいPOが機能不全に陥ると、以下の問題が発生するリスクが高まります。

1. 各種ミーティングやセレモニーへのPO不参加やレビューが滞ることでリリースが遅延する。
2. ステークホルダーとの調整や課題・要望ヒアリングが十分に行われずプロダクトが本来のニーズを満たさないものになってしまう。
3. バックログの内容や優先順位を適切に維持出来なくなり、開発作業が滞ってしまう。

POが全ての役割を果たすことが難しい場合や兼務により稼働時間を十分に確保できない場合は、代理プロダクトオーナー(PPO)をチームに組み込んでおき、調整事やPO不在時の意思決定を行なってもらうようにすると状況の改善が期待できます。ただし、PPOはあくまで補佐的な役割であるため、やはりPOの選出や育成は慎重に行う必要があります。

開発者

次に、開発者の役割について触れていきます。ウォーターフォール開発では、統制型マネジメントを前提として、プロジェクトリーダーが顧客交渉及び作業計画やタスク分担を行い、開発者は作業計画に従って担当タスクを進めるような役割分担でした。しかしながら、スクラム開発では、開発者が機能横断的に作業を実施できるスキルを備え、時には顧客交渉をしながら柔軟かつ迅速に開発を進められるようになるのが理想形です。基本的にスクラム開発では、自主性を尊重するプロジェクト管理方針であるため、良い面では開発者の自主性や対顧客能力の向上が期待できます。一方で受け身な姿勢のメンバーが多いと、チームとして成立しなくなってしまうため、例えばスクラムマスターが立ち上げ期は統制型のマネジメントを行い、徐々に開発者の主体的な関わりを促していくような工夫を状況に応じてしてあげる必要があります。

スクラム開発を担える人材の育成には時間がかかるため、各メンバーが研修などを通してスクラム開発手法やそれぞれの役割について理解を深めつつ、スプリント毎の振り返りの際に、SMが中心になって各ロールが十分に役割を果たせているのか意見交換しながら、細かい軌道修正を重ねて成熟したスクラムチームを目指していく必要があります。

まとめ

前後半に分けて、アジャイル開発現場のリアル課題を紹介してきました。プロジェクトの数だけ未知の課題は現れると思いますが、普遍的な勘所として、これからアジャイル開発に取り組もうとしているエンジニアの皆様の力添えに少しでもなれることを願っています。

※部署名、役職名、その他データは公開当時のものです。