経済産業省が公表したDXレポートにおいて、DXを通じてユーザー企業が目指す姿として、「顧客、市場の変化に迅速・柔軟に対応するために、クラウド、モバイル、AI等のデジタル技術を、アジャイル開発、DevOps等で迅速に取り入れる」ことを推奨しています。
また、デジタル時代を勝ち抜くため、ユーザー企業は顧客ニーズや市場の変化に迅速に対応するために、ベンダ企業へ全体を委託する体質からIT部門の内製化に組織構造を変化させることが求められています。
本稿では、内製化の重要なキーワードである「アジャイル開発」に焦点を当てていきます。
アジャイル開発を取り入れるメリットは、ウォーターフォール開発に比べて「仕様変更や追加に対応可能なので、ユーザーのニーズに最大限応えることができる」ことです。一方、デメリットとしては、ウォーターフォールのように十分な開発期間を取ることができないため、非機能品質の積み上げにおけるベストプラクティスが確立されておらず、企業毎に品質保証プロセスが異なることです。
一例として、某プロジェクトにおいては、スクラム内にITアーキテクトが不在で、設計段階から非機能設計が考慮されておらず、JSON（※１）に数GBのデータをサーバー間でやり取りしているがために、オンライン処理が大幅に遅延してしまうような事象が発生していました。結局のところ品質向上のスプリントが大量に走り、アジリティを損なっているといった事例が発生しました。
上記の通り、アジャイル開発は、システム開発における柔軟性・迅速性を確保する事は得意ですが、性能、セキュリティ、信頼性/可用性といった非機能品質を短期間の中で作りこむ事は、各社の裁量に任されており、一つ間違えると不安定なシステムで、エンドユーザーの不満が蓄積されてしまう結果となってしまいます。
（※１）JSON（JavaScript Object Notation）
非機能品質改善のプロセス
今回は、アジャイル開発における非機能品質をどのようなプロセスで積み上げていくべきか、その考え方をご紹介します。（図１）
①～④は、非機能品質を担保するにおいて全て大事な要素となります。
本稿では特に①、②を重点的に紹介していきます。
③、④については、「アジャイル時代の継続的な性能担保」をご参照ください。
①各スプリント開発における機能テストと合わせ、非機能品質テストを自動化する
ウォーターフォール開発においても非機能品質は（図２）に示す考え方で品質を積み上げていくことで保証されます。アジャイルにおいても基本的な考え方は、ウォーターフォールと同様に、非機能品質を積み上げて担保することですが、単性能試験のように手動で確認していくことは、アジャイルが本来持つメリットであるアジリティを損ねてしまうリスクがあります。
そこで、ビルド時の機能テストのパイプラインの中に非機能テストとして自動化に取り込み、可能な限りテストを省力化していく方針を考えていきます。（表１）
| 性能 | ・単体レスポンス評価（APIやページアクション毎） ・単体モジュールの多重実行による性能劣化確認 |
| セキュリティ | ・脆弱性を減らすための静的チェック |
| 可用性/信頼性 | ・特になし |
＜本項目をやらないと直面する落とし穴の例＞
某プロジェクトでは、各スプリントの中では機能品質を迅速に作りこむことに専念し、非機能品質については各スクラムチームの裁量に完全に依存してしまっていました。そのため、最終チェックとしてのシステムテストに相当するフェーズで、大量の非機能バグが多発してしまう結果となりました。
モグラ叩き方式でバグを収束させていったものの、先に述べたJSONで数GBのデータ通信をしたり、DBへの一括更新処理などをせず、１行ずつのループ処理の中で更新処理を実装したりするなど、１行ずつのループ処理の中で更新処理を実装するなど、ソフトウェアアーキテクチャ面の品質が悪く、システムテストを中断せざるを得ない状況を迎えてしまいました。そのため、品質向上を目的としたスプリントが追加となり、再度システムテストをトライするなど、当初予定していた期間の3倍もの期間を要し、リリースが大幅に遅れました。
②システムテストのフェーズを設け、リリース前に非機能品質の最終チェックを行う
本フェーズでは、（表２）に記載の非機能テストを実施します。
| 性能 | ・ピーク負荷テスト ・限界負荷テスト ・長時間安定性テスト |
| セキュリティ | ・ペネトレーションテスト ・脆弱性診断（第三者チェックが好ましい） |
| 可用性/信頼性 | ・信頼性/可用性テスト |
ウォーターフォールとの大きな違いとしては、目標を満たしていないケースでも、ウォーターフォール開発のように、目標で定めたSLAを満たすまで品質向上を行うのではなく、ユーザー影響がクリティカルなものでなければ、バックログに先送りし、後続のスプリントで吸収するなどの判断を都度していくことで、アジリティを保った開発を心掛けていく必要があります。
＜本項目をやらないと直面する落とし穴の例＞
筆者自身がトラブルシューティングの専門部隊に従事しているため、そこで直面した事例を紹介します。
某ECサイトのリリース時期の約1か月後に大規模なセールを行いましたが、アクセス集中により、システムがスローダウンをして、ユーザーが購入できない事態になってしまいました。専門部隊が問題を特定し、トラフィックの流量を監視・制御しながらその場は乗り切りましたが、約2日間はECサイトが不安定で、当初予定していた受注の1/2しか売り上げる事ができませんでした。
よくよく非機能テストをどこまでやったか聞いてみると、アジリティを担保するために非機能テストは各スプリントの中で簡易なものしかやっておらず、今回のような特定イベントによるセールを想定したテストは行っていないことが分かりました。
高品質を担保しようとするとアジリティは損なわれてしまい、アジリティに重点を置くと、システムダウンリスクの高い状況を想定した試験ができずに商用トラブルを引き起こす可能性があります。高品質とアジリティのバランスを意識することが、重要なポイントです。
最後に
非機能品質を担保することで大切なことは、性能、セキュリティ、信頼性/可用性に大きなインパクトがあるリリースを行う場合は、システムテストに相当するフェーズを設け、非機能品質を保証した後、リリースすべきです。しかし、インパクトを与えない程度の機能追加/変更のスプリントであれば、システムテストを行わず、ユーザーインパクトを与える問題が発生した場合の切り戻しを考慮したシステム/リリース設計が必要です。
また、システムテストにおいて発生した問題に対し、エンドユーザーへの影響を鑑みた際に、クリティカルなものか、そうでないのかを見極め、対応方針を策定することで、迅速性を失わないことも合わせて重要です。
そのためには、発生した非機能品質に関わる問題が、エンドユーザーへの影響の有無を判断できるITアーキテクトを育てていく必要があります。
運用の中で問題が発生した場合に即座に問題を検知・改善することでエンドユーザーへの影響を最小限にとどめるため、問題解決のスペシャリストも合わせて育成していく必要があります。
アジャイル開発は、これまで以上に多様化するユーザーニーズに応えていくために適した開発手法ですが、非機能品質担保を意識した開発プロセスの確立、IT人材の確保をしながら、安定運用を目指していきたいものです。