SHIFTが生み出し実践する、品質保証フレームワーク
これまで別に活動していた開発チームと品質保証チームの間には障壁がある。これを取り除かない限り、アジャイル開発はうまくいかない。船橋氏はSHIFTが構築・実践しているフレームワークの説明を始めた。
障壁の1つが、物理的な壁。開発チームと品質保証チームの部署が違っているプロジェクトや、セキュリティのベンダーに脆弱性診断を依頼しているプロジェクトなどの組織の壁だ。指揮系統が一貫しておらず、問題が生じやすい。
「作る側」と「指摘する側」というチームの関係の壁もある。品質保証チームは製品出荷のゲートキーパーを担っており、開発チームの意図を汲み取らず完成品について指摘をするので、軋轢が生まれやすい。価値を提供したいと考えている者同士で不協和音を奏でてしまうのだ。ウォーターフォールでは設計書を完成して実装し、検証という流れで役割分担もされて進んでいたので、それぞれの責任がわかりやすかった。船橋氏は、アジャイルの場合は特に「完成の定義」が重要だとした。
ソフトウェア開発において不具合の混入、検出はコーディングの時点で多く発生するが改修はしやすい。リリース近くになると不具合の原因調査、そして改修にはより多くの時間と労力がかかる。コードだけでなく環境の問題などもあるからだ。コーディング時点で1とした改修コストは、リリース直前には640倍にもなるという。そのため、不具合を検出するのではなく予防をする活動が求められる。
アジャイルでは不具合の予防のために自動テストの仕組みを入れたり、CI/CDによって継続的な発見をしたりすることが考えられるが、船橋氏は「完成の定義」がなされないとうまくいかないと述べた。
「完成の定義」とは、プロダクトの品質基準を満たすインクリメントの状態を示したもので、リリースできる状態を示しているものだ。これは、機能や要件だけでなく、受けるテストが完了していること、発見された不具合の扱いが決まっていることなど、品質の状態の定義も求められる。
船橋氏は「テストだけではなく、その環境はどこなのか、どのブランチに保存されたプログラムをデプロイ・ビルドデプロイするのか。コーディングする際に絶対にやっておかなければならないことはないか。開発と品質保証、それぞれが完成の定義に向き合う必要があります。チームの壁の問題があるので、プロジェクト発足当初のチームビルディングの際に検討する必要があります」と語り、戦略、スプリント活動両方を考えるフレームワークを紹介した。
このフレームワークでは、左の青い円上部「テストタイプ・レベル整理」から始まり「テストアプローチ検討」「完成の定義」「テスト方針検討」と進み、右の赤い円「テスト計画」「テスト分析・設計」「テスト実装・実行」「テストレビュー」のスプリント活動へと進む。スプリントのレビューによってテスト戦略の検討の見直しが必要であれば青の円に戻り、問題なければ次のスプリント活動を繰り返しすすめていく。
テストタイプ・レベル整理の段階では、対象となるシステムの構成を検討・整理する。外部サービスとの連携やテスト環境の準備なども考慮していく。どのようなテストを行うかの共通認識を持つことも重要だ。同じ組織、部署、プロジェクトでも、メンバー個人の認識が異なっている場合があるため、事前にプロジェクトチームの中で認識を合わせておかなければ後々問題が生じる。
テストアプローチ検討の段階では、各テストをどういった方法で実施するか検討する。テストケースや手順を設計書として作成して実行する手動テストや、コーディングによって実行する自動テスト、探索的テストの3手法から定義していく。
チームビルディング時には、ソースの管理方法、ブランド戦略、不具合が発生したときの報告ルートなど、テスト戦略以外のことも検討しているはずだ。それらの情報とそれまでに検討したテストの情報をつなぎあわせて行うのが「完成の定義」だ。そうすることで、チーム全体の意識を合わせるため、詳細に決定していく必要がある。
テスト方針検討の段階では、バックログリファインメントを開催する。実施した内容の価値や対応内容、受入基準などを決めていくなかで、それぞれのバックログで実施が必要なテストタイプまでチームの意識をあわせていく。
スプリントの活動では、各イベントにチーム全員で参加し、開発担当・品質保証担当という責任分担、責任転嫁をせずに常にチーム全体で確認していく。船橋氏は「積極的に情報共有をすることで、チームの品質意識を向上させ、不具合の予防につなげることも可能です」と付け加えた。
品質保証フレームワークをベースに、チームとプロダクトを成長させていく。
先に挙げた、スクラムからウォーターフォールに戻さざるを得なかった金融プロジェクトのチームは、別のプロジェクトにおいてこのフレームワークを導入し、各スプリントでの不具合数の予防に成功して数が減少し、本番障害も半年間ゼロとなった。メンバーの関係が円滑でなく、テストケースの消化が不安定だった金融プロジェクトの別チームも、不具合を予防できる傾向にあり、本番障害は半年間で5件に抑えている。いずれのチームも見事にアジャイルチームの変貌を遂げたのだ。
しかし船橋氏は、このフレームワークは盲信できるものではないと注意を促し、最後に次のようにコメントした。
「このフレームワークはあくまでスターターキットです。プロダクトの成長に合わせて改善、見直しを進めていく流れとなっています。最初はフレームワークに沿ってチームビルディングの過程でテストタイプやアプローチを検討し、完成の定義に品質を盛り込む。そしてスプリントにおいてもテスト戦略を守りながら活動し、必要に応じて戦略を改善していく。この流れによってアジャイル開発の成功に近づいていくと考えます」
