できるだけ自動化
- できるだけ自動化（原題Automate As You Go, 原著 Joseph W. Yoder, Rebecca WirfsBrock, Hironori Washizaki）[6]
「ビジネスで使用されるテクノロジの一つ目のルールは、効率的なオペレーションに自動化を適用すると、より効率が上がるということである。二つ目は、非効率的なオペレーションに自動化を適用すると、より非効率になるということである」――Bill Gates（マイクロソフトの共同創業者兼元会長）
アジャイルプロジェクトの開始時には、エンドユーザーに何かを提供し、最初の反応やフィードバックを得なければならないという多くのプレッシャーがあります。それを可能にするためには、頻繁な納品の流れとツールを確立することが重要です。
この環境を作る際には、品質関連の項目も考慮する必要があります。システムが進化していく中で、重要な品質が満たされているかどうかを定期的に評価することが重要です。
アジャイルチームはシステムの重要な品質特性について、迅速なフィードバックを支援し、現在の状態を共有し可視化するために、ツールや環境をどのように確立できるのでしょうか？
＊＊＊
重要な品質特性に早期に焦点を合わせないと、重大な問題、遅延、手戻りを引き起こす可能性があります。パフォーマンスやスケーラビリティの欠陥を改善するには、システムのアーキテクチャに大幅な変更と修正が必要になることがあります。ただし、開発サイクルのあまりに早い段階でシステム品質に焦点を合わせすぎると、過剰設計と誤った最適化につながる可能性があります[Knuth]。
アジャイルチームは、プロジェクトの初期段階では機能要件の実装に焦点を当てます。多くの場合、できるだけ早くシステムの機能に対する顧客のフィードバックを得るために、動作可能な成果物を提供するための最低限必要な作業を行うことが優先されます。そのため、成果物提供への近道を走り、手動テストのような手作業を多く行ったりします。これだと、迅速なフィードバックを得られるメリットはありますが、プロジェクトが拡大すると、手作業の数が増えてチームの速度が低下し、システムを安全に検証し、進化させることが難しくなります。
最近宣伝された最新かつ最高のツールを使用したいという思いは誰でもあります。しかし、時間とリソースが限られている中で、できるだけ早く何か成果を出さなければというプレッシャーもあります。自動化環境のセットアップには時間と労力が必要であり、メリットがすぐに分からないときもあります。アーキテクチャがテスト可能なように設計されていない場合、一部のタスク、特に品質のテストと検証については自動化が難しい場合もあるでしょう。
自動化に集中しすぎると、チームがツールに囚われてしまい、自動化に多大な労力と時間を費やしてしまうリスクがあります。別のリスクは、あまりにも多くのタスクを自動化することで、テストをあまりにも頻繁に、間違ったタイミングでテストしてしまい、結果的にビルドとデプロイの速度の低下を招いてしまうことです。
環境のセットアップとシステム品質特性のテストの自動化には、専門的なスキルと専門知識が必要になる場合があります。また、機能を十分に定義するまで、品質特性について何を測定すべきかが分からない場合もあるでしょう。後で価値にならないかもしれないタスクの自動化にコストをかけるのは避けたいものです。そして、アジャイルであるからこそ、自動化もJust In Timeで進めたいと思うでしょう。
＊＊＊
環境を整え、ツールを使用して、バリューを高める部分をできるだけ早く自動化しましょう。開発の終盤まで自動化のタスクを先送りしないようにしましょう。
開発の初期段階から、自動化を行うことが重要なところがあります。まず最初に行うのは、ビルド、結合、およびテストの環境を作ることです。次に、機能テストとシステム品質テストを自動化します。しかし、これはほんの始まりに過ぎません。受け入れテスト、パフォーマンスの測定、コードの臭いの検出、アプリケーションのセキュリティチェック、アーキテクチャの適合性など、自動化できるものが他にもあります。また、繰り返し行う退屈な作業や、ミスが発生しやすい作業があった場合は、それらも自動化できるか検討してください。作業を自動化すると、それは、プロジェクトのリズムを生み出すようになります。
反復的な手作業を自動化すればするほど、より多くの時間を自由に使えるようになります。探索的なテストに時間を費やすこともできるでしょう。自動化によって、システムをより安全に進化させることもできます。自動化により、小さなステップで作業を行うことができ、ミスを減らしてフィードバックを迅速に得られるようになります。自動化されたテストを使用すると、テストしている項目に問題が発生したときにすぐに分かります。自動化された作業をより頻繁に実行することで、重要な品質特性がちゃんと維持されていることが確認できるでしょう。
リリース前に負荷をかけてパフォーマンステストをする必要がある場合は、専用の環境を構築する必要があるかもしれません。そのために、データベースやネットワークなどのセットアップが必要になる場合があるでしょう。これを毎回手作業でセットアップすると、時間もかかりますし、ミスも発生しやすくなります。このセットアップを自動化するスクリプトを使用して仮想環境を作成することで、この作業をはるかに簡単に実行することができます。このような、繰り返す必要がある手作業を、自動化することで簡単にできることが分かっているならば、自動化のタスクをバックログに追加しましょう。
何を自動化するか判断する際には、自動化タスクの実行にかかる時間と実行頻度を考えると良いでしょう。頻繁に実行されないタスクについても、特にエラーが発生しやすい場合や、多くのステップを必要とする場合は、自動化を検討する必要があります。作業の自動化にコストがかかり、実行頻繁が少ない作業は、手動でも良いかもしれません。たとえば、1年に1回実行する1日分の手作業を、5日で自動化できる場合、自動化に費やした時間に対するリターンは5年後になってようやく得ることができるからです。
自動化された作業を実行するのにかかる時間は、通常のビルドとデプロイを行うプロセスに組み込むか、そのワークフローから除外するかを考慮すべきです。短時間で簡潔なフィードバックを得ることができる自動化は、長時間実行され詳細で包括的なフィードバックを得ることができるテストや自動化と同じくらい価値があります。たとえば、デプロイされたアプリに対する侵入テストを実行するセキュリティスキャンは自動化できますが、自動ビルドプロセスの一部にするには時間がかかりすぎるかもしれません。セキュリティ上の欠陥を探すことができる静的コード分析は、セキュリティスキャンほど包括的ではないかもしれませんが、有用なフィードバックを短時間で提供してくれます。
システム品質特性には、さまざまなテストサイクルがあります。ユニットテストなどの一部のテストは、1時間ごとなど、短い間隔で頻繁に実行されます。コードをチェックインするときには、いくつかの簡単な結合テストが実行されます。ただし、様々なテストをその時にやり過ぎると、チェックインプロセスの速度が大幅に低下する可能性があります。そのため、これらの品質テストやリグレッションテストは、結合テストに含めず、夜間に実行するなど工夫する必要があります。
自動化は、アーキテクチャスタイルやフレームワークの選択、インターフェイス設計、および多くの設計詳細に影響します。たとえば、様々な自動化テストを行うことにした場合、これらを簡単に追加できるようにシステムを設計する必要があります。また、システムの一部を単独でテスト可能にしたい場合は、意味のある結合テストを実行する方法を検討する必要があります。
どの部分に自動化が必要なのか、いつ自動化されたテストとタスクを実行する必要があるかを知ることが重要です。アジャイル品質スペシャリストは、自動化を支援するための専門知識を提供できます。品質テストの中には、セットアップが難しく、実行に多くの時間がかかるものがあります。これらを正しく設定し、いつ実行するのが適切かを判断するためには、賢明でなければなりません。自動化の結果はフィードバックとして、チームに可視化されることが重要です。これは、システム品質ダッシュボードおよびシステム品質アンドンで実現できます。ただし、情報が多すぎて圧倒され、重要な情報が見過ごされたり無視されたりすることは望ましくありません。チームは、どのフィードバックが有用であるかと、それが更新される頻度を決定する必要があります。
継続的インテグレーションには、簡単なテストやビルドを実行するだけでなく、さらに追加すべきアクティビティ（デプロイメント、IDE結合など）もあります[Duv]。
継続的インテグレーションに役立つアクティビティの1つに、継続的検査（Continuous Inspection）があります。継続的検査には、結合前に一般的な問題を見つける自動化されたコード分析を実行する方法が含まれています。また、継続的検査では、特定の品質特性とアーキテクチャの制約が満たされていることを保証するのに役立つ、多くの追加の自動化されたタスクについても説明されています[MYGA]。
自動化ツールは、使用しているアーキテクチャやプラットフォームに大きく依存します。たとえば、Javaを使用して開発している場合、SonarQube、PMD、Checkstyle、FindBugs、JaCoCo、Jenkins、Maven、および、JUnitやコード分析ツールなどのさまざまなプラグインを備えたEclipseを検討してはいかがでしょうか。
ツールを選択するときは、静的分析を実行できるツールを1つ以上、評価して選択することも有用です。ツールの評価基準には、ソフトウェアプロジェクトで使用されるプログラミング言語やスクリプト言語、ツールでサポートされる言語を含める必要があります。また、ツールはカスタマイズできるように拡張点としてAPIが提供されているか、IDEとうまく組み合わせることができるか、CIサーバーとうまく組み合わせることができるか、ツールが提供する組み込み検証のプロジェクトへの適切性などを評価基準とするとよいでしょう。ツールの選択では、専門家がサポートしてくれるでしょう。
おわりに
4回目の連載では、アジャイル開発において効率的かつ効果的に品質保証を進めるために有用な実証済みのパターン集QA2AQから、アジャイルプロセスにおける品質保証のあり方や役割のパターンをまとめた、分類「品質のアジャイルなあり方」から3つのパターン品質エキスパートをシャドーイング（Agile Quality Specialist）、QAリーダーとペアリング（Pair with a Quality Advocate）、できるだけ自動化（Automate As You Go）の和訳を提供しました。次回の連載から、アジャイルで重要な品質を特定するためのパターンをまとめた、分類「重要な品質を特定するためのパターン」から3つのパターンの和訳を提供する予定です。
参考文献
- [1] Joseph Yoder, Rebecca Wirfs-Brock, Ademar Aguilar, “QA to AQ: Patterns about transitioning from Quality Assurance to Agile Quality,” 3rd Asian onference on Patterns of Programming Languages (AsianPLoP 2014), Tokyo, Japan, 2014.
- [2] Joseph W. Yoder and Rebecca Wirfs-Brock, “QA to AQ Part Two: Shifting from Quality Assurance to Agile Quality,” 21st Conference on Pattern Languages of Programs (PLoP 2014), Monticello, Illinois, USA, 2014.
- [3] Joseph W. Yoder, Rebecca Wirfs-Brock, Hironori Washizaki, “QA to AQ Part Three – Shifting from Quality Assurance to Agile Quality – Tearing Down the Walls,” 10th Latin American Conference on Pattern Languages of Programs (SugarLoafPLoP 2014), Pousada Armação dos Ventos, Brazil, 2014.
- [4] Joseph W. Yoder, Rebecca Wirfs-Brock, Hironori Washizaki, “QA to AQ Part Four - Shifting from Quality Assurance to Agile Quality - Prioritizing Qualities and Making them Visible,”22nd Conference on Pattern Languages of Programs (PLoP 2015), Pittsbirgh, USA, 2015.
- [5] Joseph W. Yoder, Rebecca Wirfs-Brock, Hironori Washizaki, “QA to AQ Part Five,” 5th Asian Conference on Pattern Languages of Programs (AsianPLoP 2016), February 24-26, 2016, Taipei, Taiwan.
- [6] Joseph W. Yoder, Rebecca WirfsBrock, Hironori Washizaki, “QA to AQ – Part Six – Being Agile at Quality,” 23rd Conference on Pattern Languages of Programs (PLoP 2016), Monticello, Illinois, USA, OCTOBER 24-26, 2016.
- [BBC] Bransford T., Brown A., and Cocking, R., How People Learn: Brain, Mind, Experience and School. National Academy Press, 2000.
- [Brown] Brown T., The hunt is on for the Renaissance Man of computing, in The Independent, September 17, 1991.
- [CH] Coplien J. and Harrison, N., Organizational patterns of agile software development. Wiley, 2004.
- [Duv] Duval, Paul. Continuous Integration: Patterns and Anti-Patterns. DZone, 2010.
- [Knuth] Knuth, D., “Structured Programming With Go To Statements,” Computing Surveys, Vol 6, No 4, December 1974, pp. 261-301.
- [MR] Manns, M. L., and Rising, L. Fearless Change: Patterns for Introducing New Ideas. Addison-Wesley Professional, 2004.
-
[MYGA] Merson P., Yoder J., Guerra E., and Aguilar A., “Continuous Inspection: A Pattern for Keeping your Code Healthy and Aligned to the Architecture,” 3rd Asian Conference on Patterns of Programming Languages (AsianPLoP), Tokyo, Japan, 2014.
