基幹システム関連のプロジェクトと言えば、アジャイルよりもウォーターフォール型が現在でも主流です。
しかし、長期間・大規模なシステム導入のプロセスを終えてから開始される、システム運用フェーズはどうでしょうか？
ユーザーの希望や業務の実態に合わせて、少しずつシステムを改修する、複数の追加要件から優先順位を付けて実装～レビューにまわしていく…
「これってかなりアジャイルなアプローチなのでは？」
実際のシステム運用プロジェクトの中で、アジャイルアプローチの適用を挑戦したコンサルタントの経験をもとに、アジャイルによる業務のアップデートのやり方をレポートします。
とあるお客様企業にERPを導入するプロジェクトに関わっていた経験をもとに「アジャイルソフトウェア開発宣言」と「アジャイル宣言の背後にある原則」に沿って、プロジェクトでアジャイルアプローチを可能にしている要素、アジャイルアプローチのメリット、デメリットなど気づいたことを共有していきたいと思います。
「アジャイルソフトウェア開発宣言」「アジャイル宣言の背後にある原則」って何？という方は第1回でご紹介していますのでそちらを参照してください。
今回はアジャイル宣言の背後にある原則その3「動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします」について、ERP導入後の運用フェーズで継続的に行っている機能改修リリースの「受入テスト」をテーマに紹介したいと思います。
受入テストで心がけている3つのこと
月に10～20件の改修をリリースしているので、ユーザサイドでは受入テストを頻繁に実施することになります。受入テストは、要件通りの仕様になっているか？をリリース前に確認する最後の砦なので品質管理上重要なプロセスですが、とはいえ限られた工数の中で実施しなければなりません。
ユーザサイドの受入テスト実施を支援する中で、心がけていることを３つ挙げたいと思います。
1.受入テストの比重は柔軟に変える
受入テストにかける工数はテストケース×人で見積もることができます。テストケースを増やせば増やすほど不具合検知率を上げることができますし、同じテストケースでもなるべく多くの人の目を通すことで違った観点に気付くことができるからです。
このプロジェクトでは機能によってその比重を変えながら行っています。中規模以上の改修であれば、開発プロセスと並行して受入テストシナリオとテストデータを作成し、チーム内でレビューしたのち複数名で受入テストを実施します。軽微な改修であれば担当者が自身でシナリオ・データを簡単に作成して探索的にテストをして終わらせることもあります。
工数をかければかけるほどリリース後の不具合発生のリスクを下げることができますが、ERPの運用をサポートしながらの受入テストとなるとそればかりに手をかけられないのも現実です。そんな時は、０か１かではなく場合によって比重を変えて、可能な限り最大限の効果を生むように努力しています。
2.テストデータ集めは上流フェーズから
テストで不具合検知率を上げるためには、なるべく本番環境に近い条件でテストすることが必要です。当たり前のようですが、これが簡単にいかないこともあります。
不具合が発生するのは８割の正常系フローではなく、２割の異常系のフローです。そしてテストで再現するのが難しいのも、この２割です。データの中には業務サイクルに合わせて年に１回しか発生しないようなパターンや、特定の条件が揃ったときにだけ現れるパターンがあります。
こうしたレアなデータは受入テスト期間にタイミングよく現れてくれるものではないので、要件定義などの上流フェーズからデータ収集したりパターン抽出したりしておくことをお勧めします。
3.受入テストは早めに着手
テストフェーズでは手戻り・作業の重複を防ぐため単体テスト・結合テスト・受入テストと順番に行うのが基本ですが、重要な機能ほど結合テストフェーズに入ったら、ユーザサイドでも受入テストに着手することをおすすめします。
なぜなら、まずベンダーサイドで行う結合テストとユーザサイドで行う受入テストは観点が異なるからです。ベンダーサイドでは「システムが正常に動作するか」に主眼が置かれるのに対して、ユーザサイドでは「これで業務が回るのか」という観点でのテストになります。テストフェーズで修正も含めて十分な工数が確保できることは困難なので、早い段階で業務観点でのチェックを行うことは非常に有効です。
第3回はアジャイル宣言の背後にある原則その3「動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。」について、受入テストでの工夫をご紹介しました。
次回はその8「アジャイル･プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなければなりません」について紹介します。お楽しみに。
ライター
基幹システム導入PJを中心に、IT導入PJにおけるユーザー側タスクの支援に一貫して携わるビジネスアナリスト。構想策定から導入後の運用安定化支援まで、システム導入のライフサイクル全てに関わる。Scrum Alliance認定スクラムマスター（CSM）。（2021年6月時点）
