障壁の解体
- パターン：障壁の解体（原題 Break Down Barriers, 原著 Joseph W. Yoder, Rebecca Wirfs-Brock, Hironori Washizaki）[3]
「障壁に焦点を当てることもできるし、壁を乗り越えたり問題を再定義したりすることに焦点を当てることもできる」――Tim Cook
ほとんどのアジャイルプロセスは、機能要件、それらの優先順位をつける方法、およびプロダクトオーナー、スクラムマスター、開発チームを完全に関与させるコラボレーション環境に焦点を当てるのに適しています。しかしながら、ソフトウェアプロジェクトの成功にとって重要な役割とタスクは他にもあります。QA担当者は、システムが正しく機能していることを確認し、品質要件を満たしていることを確認する必要があります。アーキテクトはインフラストラクチャを設計し、アーキテクチャ機能を実装します。アジャイルプロジェクトに貢献するグループや個人は、プロジェクトに関与し、ソフトウェアの成功に対して価値ある貢献を果たしていると感じる必要があります。このことはプロジェクトにフルタイムで従事していない貢献者にとって特に重要です。
開発チームの「内部」にいない、または開発チームとの関係が希薄と感じている人々の間に障壁が存在しているかもしれません。これにより、チームの全体的な進捗やソフトウェアの品質ではなく、自分の仕事のみに焦点を当てるようになる可能性があります。開発者は品質の問題を「他の人」の問題と見なし、QA担当者をプロダクトの出荷に対する障害と見なすようになるかもしれません。また、QA担当者は、自分たちの意見が傾聴され、理解されていないことに対して不満を感じる可能性があります。
アジャイルチームはどのようにしたら障壁を取り除き、品質に関してよりアジャイルになることができるでしょうか？
＊＊＊
多くの場合、チームの他のメンバーから、QA担当者は単なる最終的なゲートキーパーと見なされます。QA担当者がリリースサイクルの最後にのみソフトウェアを検証している場合には、上流側（開発者）からの圧力によってQA担当者が非難され、常に応答モード（頼まれたことしか行わない状態）になる可能性があります。QA担当者としてはもっと助けたいと思っていますが、時間も人員も十分ではありません。品質の問題が開発の終盤に発生した場合、QA担当者は、リリースを妨げているトラブルメーカーと認識されてしまうことがあります。場合によっては、QA担当者は、実際の開発プロセスでテスターとして貢献していないために、アプリケーションがどのように機能するかを理解してはいないと認識されます。
プロダクトオーナーと開発チームは、中核となる機能要件など、進行状況が分かりやすい目に見えるアイテムに焦点を合わせたいと考えています。これにより、重要なシステム品質が軽視されたり、見逃されたりする場合があります。実動コードと単体テストを作成している開発者は、作業を高速化するアプローチを選択する場合があります。その結果、開発者は自分達の作業速度（ベロシティ）だけを気にして、自分達の設計上の選択が、品質を保証する責任者を含む他の人々にどのように悪影響を与えるかに気づかないかもしれません。
QA担当者および／またはプロダクトオーナーは、ソフトウェアエンジニア、管理者、さらにはビジネスアナリスト（BA）の観点からの実際の要件でさえも、十分に捉えていない場合があります。特定の契約または法律または政府規制に実際の要件が含まれている場合でも、プロダクトオーナーまたはQA担当者は、それらの要件を達成する方法について独自の解釈を行ってしまう場合があります。彼らは不注意に重大な問題を引き起こし、それが重要な要件の開示の遅れにつながることがあります。結果として、開発が混乱し、品質管理が期限を守ることができなくなります。
組織にはさまざまな障壁があります。障壁には、物理的、経験的、または文化的なものがあります。これらの障壁がすべて悪いわけではありません。時には障壁が、チームにタスク完了をさせまいとする外部の力から、チームを保護することがあります。ただし、いくつかの障壁は問題を引き起こす可能性があります。QAチームが別々の部屋や建物に配置されているなど物理的な障壁がある場合、グループ間の距離はグループ間の違いを拡大するかもしれません。中核の開発チームの外側にいる人は孤立していると感じることがあり、その結果、「我々と（我々とは異なる）あいつら」のメンタリティが生じる可能性があります。QA担当者が同じ建物、場合により同じ物理的空間にいる場合でも、文化や言語の違い、背景や専門知識の違いが存在することもあります。
＊＊＊
したがって、早い段階でQA担当者をチームに含めるなど、さまざまなアクションを通じてコミュニケーションを妨げる障壁や壁を取り壊します。QA担当者をスプリントの一部にして、チームに取り込み、品質に対してチーム全体に報酬を与えます。
ほとんどのアジャイルプラクティスにおける重要な原則は、「Oneチーム」というコンセプトです。このコンセプトの下では、人々は協力して高品質の製品を生産します。品質を気にする必要があるのはテスターだけではありません。チームの全員が、仕事にさまざまな強みと経験をもたらしますが、品質にも注意を払う必要があります。QA担当者を最初からチームの一員として組み入れることで、品質に関する考え方をチームに浸透させ、品質に関する関心をより合理化されたプロセスの不可欠な部分にします。どのシステム品質が重要であり、プロセスにどのように適合するか（異なる品質に対して何を行うか）をチームの全員が理解するようQA担当者が支援することができます。QA担当者は、システムの品質と、品質確保の役割に焦点を当てていますが、同時に、チームの他のメンバーは全体的な品質目標に対する責任を感じることが重要です。
QA担当者と他のチームの間にある障壁を打破するためには多くの方法があります。例えば以下のようなものがあります。
- QA担当者がチームの見積セッションに完全に参加できるようにする。
- QA担当者が別のエリアにいる場合は、同じスペースに移動させ、チームの一部として参加させて、専門知識をグループに伝えることができるようにする。
- プロダクトオーナー（PO）、開発チーム、およびQA担当者を同じ部屋に配置し、今後のスプリントの前に計画に参加させる。
QA担当者はアセスメントの機会と、自らの経験を使って「イリティーズ（ilities）」（＊）を指摘することができます。QA担当者は、QAプロダクトチャンピオンとなり、リスクを指摘し、チーム全体でハイレベルのテストと統合ポイントの作成を支援します。
（＊注釈）イリティーズ（ilities）
拡張性（scalability）、安全性（security）、信頼性（reliability）、相互運用性（interoperability）などの品質属性の総称です。”ility”で終わる英単語が多いためこのように呼ばれることがあります。品質属性は見落とされることが多いので、確実に対処する必要があります。
QA担当者を早期かつ頻繁に含めることの利点は、他の人が要件を理解し、検証できるようにすることです。また、早期の関与は、QA担当者がプロジェクト全体のビジョンを理解し、品質目標が満たされていることを確認するためのより良い方法を見つけるのに役立ちます。アジャイルグループのQA担当者はより積極的になり、開発プロセスのあらゆる面で品質を確保するように働くことができます。密接に連携し、ビジネス、管理、開発者の間で調整できるようになります。さらに、スプリント中に開発者は、QAリーダーとペアリングを行うことが可能です。
障壁を解体する最良の方法の1つは、人々を物理的に近いところに配置し、定期的に連絡を取るようにすることです。たとえば、人々が国や世界のさまざまな場所にいる場合、顔合わせのための会議を開催することは理にかなっているかもしれません。これは、プロジェクトの初期段階に、チーム内の緊密性と相互理解を構築するのに特に役立ちます。また、チームが同じ場所に配置されていない場合は、定期的な仮想オンライン会議を開催することで、さまざまな懸念事項に対し全体的な視野を保ち、QAを含むOneチームとしてのつながりを感じることができます。QA担当者が開発チームと同じエリアに配置されている場合、QAチームは1週間に数回、開発チームと共同作業ができます。QA担当者の人員が不足している場合は、経験を共有しプロジェクトに対する洞察を得るために、複数のプロジェクトを巡回することができます。開発者は、品質作業の分散を実践することによりQAに貢献することもできます。
すべての開発チームに十分な数のQA担当者がいない場合は、まずチーム間でローテーションを行い、いくつかの日常的なタスクでペアを組みます。価値を高めるものに焦点を当てます。QA担当者に実動コードの作成またはレビューを強制したり、すべてのスタンドアップに参加させたりすることは、生産的ではないかもしれません。一部のQAテストは非常に専門的であるため、システムのパフォーマンス、スケーラビリティ、またはその他のシステム品質に精通したアジャイル品質スペシャリストとペアを組むことで、機能テスターが、負荷テストおよびその他のタイプのテストに精通できるように、品質エキスパートをシャドーイングすることができます。
夏のインターンを使用しようとしたり、リモートで誰かを雇ったりすることは、長期的にはうまく機能しないことが明らかになっています。より良いアプローチは、QA担当者の専門知識を増やし、最初からアジャイルチームの一部にすることです。これは、トレーニングとメンタリングを通じて行うことができます。また、プロセス全体を通じた品質への長期的なコミットメントをQA担当者から得ることになります。
大胆な変化パターン（Fearless Change Patterns）[MR]の多くは、障壁を克服して、チームメンバーと上級管理職から賛同を得るのに役立ちます。協力を求めること、経営層の支持者を見つけること、根回し、可視化して、橋渡しする必要があるかもしれません。あなたがチームを進化させて品質と安全性を確保する際に、またあなたが成長し作業方法を調整する際に、ふりかえりの時間を取る必要があります[MR]。アーキテクチャ、文書化、QA担当者、またはUXデザイナーなど、アジャイルプロジェクトにフルタイムで参加していない専門スキルを持つ人々を、チームを継続的にサポートするように割り当てることで、チームの一員であると感じさせることができます[RN]。これらの人々は、アジャイルチームとともに、必要に応じて、チームとの継続的な会議に参加し、作業に取り組むことができます。
おわりに
本稿では、アジャイル開発において効率的かつ効果的に品質保証を進めるために有用な実証済みのパターン集QA2AQの全体像を解説し、全パターンに共通する考え方やプロセスをまとめた二つの中核パターンアジャイル品質プロセス（Integrate Quality）と障壁の解体（Break Down Barriers）の和訳を提供しました。本連載の以降では引き続き、他のパターンの和訳を提供する予定です。
参考文献
- [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,
- [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.
- [MR] Manns, Mary Lynn and Rising, Linda, Fearless Change: Patterns for Introducing New Ideas, Addison-Wesley, 2005.（和訳：川口恭伸 監訳、木村卓央、高江洲睦、高橋一貴、中込大祐、安井力、山口鉄平、角征典 訳、『Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン』丸善出版、2014.）
- [RN] Raines, Brandon and Neher, Judy, “No Way! Agility in the Federal Government”, Agile 2014 Conference, Orlando, Florida, USA.
