Agile Japan 2016 セッションC-1

あらすじ

ソニーでQAを担当している永田さんは、スクラムマスターであるニッポンダイナミックシステムズの豊田さんと一緒にアジャイル開発を行っていました。昨年のAgile Japan 2015では、アジャイルとQAがどう関わっていくのか試行錯誤の過程を紹介しています(小冊子『アジャイルの魂2015』掲載の「QAおじさんのアジャイル奮闘記」)。
そこでたどり着いたのは、「イテレーティブ開発×3スプリント+システムテスト」という形。それは、QA担当者にとってはウォーターフォールと変わりがありません。品質が悪く、あとでバタバタすることも間々ありました。

品質を良くすることができなければ
アジャイル開発は成功しない

公開資料「新米スクラムマスタとQAおじさんのアジャイル珍道中」p.4

という永田さん。早期からQAが介入できる仕組みが必要だと感じていました。
今回の発表はこの「早期からQAが介入できる仕組みづくり」に挑んだお話です。

aj2016report_12_05_600

仕様の無駄をなくしたい

「早期からQAが介入できる仕組みづくり」のきっかけは、「仕様の無駄をなくす」活動からでした。仕様の無駄につながる以下の課題が生まれていたのです。

  • POが感性に任せてリッチな仕様にしてしまう
  • 費用対効果の悪い仕様にしてしまう
  • よかれと思ってつくった機能が使われない

これらの課題を解決するにあたり、永田さんと豊田さんは次のコンセプトを掲げました。

完璧な人間はいない。
スーパーマンでもない。
だからこそ、
皆で助け合うことが大事

公開資料「新米スクラムマスタとQAおじさんのアジャイル珍道中」p.13

解決には、みんなが自然と助け合うプロセスが必要です。「仕様レビューをQA、PO、開発者で一緒に行う」プロセスです。これは「開発者から、開発観点でフィードバックをもらい複雑なものをつくらない」という考えから、「QAから、ユーザー観点でフィードバックをもらい無駄なものをつくらない」という考えへの切り替えを伴います。
どんな方法にするか議論し、形が見えてきた矢先、大きな壁が立ちはだかりました。組織の壁です。組織の体制変更によって、アジャイル経験のあるQA担当者から、アジャイル経験のない新しいメンバーに替わることになったのです……。

スキルのギャップを埋める

新しく参加したQA担当者は、これまでの経緯を知りません。加えて、アジャイル経験がないのでマインドセットが必要です。

QA担当者にどのようになってもらいたいか、どう成長してほしいか。豊田さんは考えているうちに、あることに気が付きました。豊田さん自身が「アジャイルはわかるが、QAはあまりわからない」ということです。そこでお互いの理解を深めるために、スクラムマスターとしてQA担当者と一緒にQAを行うことにしました。

テストのペア設計とフィードバックループ

まず、スクラムマスターの豊田さんがテスト設計を行い、QA担当者に肉付けしてもらう作戦をとりました。次のような流れです。

  1. QA担当者は、仕様レビューに参加し仕様の理解に徹する。
  2. スクラムマスターは、テスト設計を行う。マインドマップを使用し、ユーザーストーリー単位に設計。
  3. QA担当者は、スクラムマスターが作成したテスト設計を確認し、テスト観点を肉付けする。
  4. QA担当者は、テスト設計に足りない情報をPOにフィードバックする。

QA経験のない豊田さんは、仕様から機能に落とし込んでテストを考えました。それに対し、QA担当者はユーザーストーリーから運用を考えていきました。QA担当者の考え方だと、仕様面からは見逃しがちな「非機能要件」や「細かい画面遷移」に気づくことができました。

永田さんは豊田さんのやってきたことを、こう評価しています。

全部一人でやるのではなく、
ほかの人の考えを取り込み、一緒に参加するよう促す仕組みづくりがうまい
「仕様書がないと動けない」ではなく、
一緒に考え、濃いものができあがるのはすばらしい

永田敦さん(ソニー株式会社

これは二人が掲げたコンセプト、「完璧な人間はいない。みんなで助け合うことが大事」の賜物でもありました。

テスト設計を進めながら、QAからPOへ「テスト設計から仕様へのフィードバック」を、POからQAへ「QAがほしい仕様の提示」を行っていきます。
aj2016report_12_01_600

このサイクルを回すことで、QAとPOの関係が強くなっていきます。最初はそのまま仕様をのんでいたQAも、フィードバックし合うことで理解が深まり、提案するように変わっていきました。
aj2016report_12_02_600

豊田さんはかつての現場で、QA担当者から「仕様がないとテスト設計ができません」とシャットアウトされたことがありました。完璧な仕様をつくることは現実的ではなく、とてもつらかったそうです。
今回、このフィードバックのループができたことで、いい関係、いい製品をつくることができました。開発者は、コードを書く前にテスト設計を確認して評価内容を把握し、技術面から評価してほしい点をQAにフィードバックしています。開発者、QA、POが信頼し合える関係を築いているのです。

テストケースが神になる日

開発プロセスも「イテレーティブ開発×3スプリント+システムテスト」から、「テストも行うスプリント×3+テストスプリント」に変化しました。スプリントではユーザーストーリーごとのテストを、テストスプリントでは負荷テストや全体のワークフロー、長期安定性テストなど非機能要件やユーザー目線のテストが中心です。

QAがつくるテストケースは、開発者やPOのフィードバックを受け、製品の詳細なふるまいが記述されます。次第に開発部隊は、最初につくった仕様書ではなくテストケースを開発のリファレンスにするようになっていきました。テストケースがマスター資料、すなわち神様的なドキュメントとなったのです!
aj2016report_12_03_600

挑戦はつづく

今回のお話は、一晩でできたことではありません。テスト設計、仕様書、開発プロセスと携わる人たち自身が変わっていった結果です。スクラムマスターがQAを巻き込み、フィードバックを続けた成果なのです。この背景にあるのは信頼関係です。
aj2016report_12_04_600

「どの現場でもこうあるべきだ、というわけではない」と前置きしたうえで、永田さんと豊田さんは「今はすごく楽しい」と言います。今回の発表もまた、変化のスナップショットであり今後も変わっていくと宣言し、こう締めくくりました。

「信頼関係と成果物」
これだからアジャイルってやめられない

永田敦さん(ソニー株式会社)、豊田昌幸さん(株式会社ニッポンダイナミックシステムズ

日ごろQAを担当している私は、QAの力が加わったループとその成果を垣間見ることができ、勇気をもらいました。多くのQA担当者は、どんなユーザーにどんな使われ方をするのかを想像し、現在の仕様が合致しているか判断する観点を持っています。こういった観点が、アジャイルの現場でも生かせることを改めて知りました。
アジャイル×QAの融合に、これからも目が離せません。

永田さん、豊田さん、つづきのお話、楽しみにしています!


Agile Japan 2016

Agile Japanとは

レポートコーナー

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です