全11082文字
PR

 アジャイル開発プロジェクトで初回リリースにこぎ着けるには、シナリオを使ったユーザー受け入れテストやパフォーマンスチューニング、データ移行といった、ウオーターフォール型開発プロジェクトと同様のタスクをこなす必要がある。一方でアジャイル開発は全てのタスクに優先順位を付け、効果的なタスクから優先的に実行していく。

 各種のテストやデータ移行で優先度を意識して実行していくにはどうすればいいのか。実践編の第4回は、効率的なタスクの順番や濃淡の付け方、優先順位の考え方を5つのポイントに分けて説明する。

ポイント1:シナリオテストは「開発前から」準備する

 アジャイル開発において品質を高める手法の1つが「テスト駆動開発(TDD)」である。TDDとは一般に、「プログラミングの前に単体テストのテストコードを作成し、そのテストコードに合格するようプログラミングをする開発手法」を指す。

 最近ではTDDの考え方をシステムテストに広げ、業務シナリオに沿ったテストシナリオを先につくり、それを満たすように機能を実装していく「受け入れテスト駆動開発(ATDD)」の重要性も高まっている。実際に、ATDDで重要となるテストシナリオ(業務手順と入力値、期待結果を記載したドキュメント)の記述方式に関する話題や記事も多くなっている。

 ただ今回解説するのは、開発手法やテストシナリオの記述方式といった開発者側からのアプローチではなく、業務部門や管理者側からのアプローチである。具体的には、システムテストで実施する「シナリオテスト(業務シナリオをベースとしたテスト)」を開発前に準備するメリットや、シナリオテストに備えて何を準備すればよいのかについて解説する。

 まず「テストシナリオの作成」に関して説明する。基幹システムが代表するSoR(System of Record)領域のシステムにおけるアジャイル開発では、シナリオテストは専用のイテレーションを用意して実施すべきである。

 それぞれのイテレーションで開発された機能は、機能単体で正しく動くことは確認できているものの、実際の業務に沿って一連の機能をつなげて操作をした結果、当初想定していた検索条件や表示項目では業務が進まないといったケースが珍しくない。ウオーターフォール開発では当たり前のシナリオテストだが、機能をイテレーションで分割して開発・確認していくアジャイル開発では、なおさら重要といえる。

 シナリオテストは作業ボリュームが多く、対象の機能が出来上がってから実施する必要があるため、初期計画の段階から専用のイテレーションを見込んでおくことが重要となる。また各機能の開発と並行してシナリオテストのイテレーション開始までに準備を進めることも大切だ。

 ウオーターフォール型開発では、多くのプロジェクトはテストシナリオをシナリオテスト開始直前に作成する(「V字モデル」)。だが、一部ではテストシナリオを要件定義が完了した後につくるケースもある(「W字モデル」)。

図 「V字モデル」と「W字モデル」の違い
図 「V字モデル」と「W字モデル」の違い
テスト設計を開発プロセスと並行して実施(出所:シグマクシス)
[画像のクリックで拡大表示]

 W字モデルの場合のメリットは、要件定義の記憶が鮮明なうちに要件定義に関わったユーザー部門代表者と協力してテストシナリオをつくるため、時間の経過とともに記憶が薄れたり要件定義の決定事項がブレたりする前に、要件定義と正対した明確なドキュメントとして残しておけることにある。

 アジャイル開発でもW字モデルと同様にシナリオテストのテストシナリオを早い段階で作成したい。そうすることで、実際の開発では、ユーザーストーリーを補足する参考情報として使えるため、ユーザー部門代表者と開発メンバーとの間に生じる仕様に関する認識の食い違いを減らせる。

 あるケーブルの製造販売会社が見積もり機能をアジャイル開発でつくっていたときのことである。見積金額を算出するロジックは非常に複雑で、10~19メートルならいくら、20~30メートルならいくらとケーブルの長さに応じて単価が階段状に決まっており、そこに様々なパラメーターが絡み合うものだった。

 パラメーターは、例えば注文量に応じて設定されているボリュームディスカウント、カットに必要な工賃などだ。当初、開発チームはユーザー部門代表者から見積金額の算出ロジックを教えてもらい、その複雑な計算ロジックを実装してレビューに臨んだ。