「開発がスクラム導入するんだって！試験どーしよ！？」 -サイボウズQAスクラム奮闘記-

Editor's Notes

• #3: このセッションはAJとJaSSTのコラボ企画です。和田さん経由でAJにコラボ企画の相談があり、QAとアジャイルという観点でコンテンツを検討しました。その中で私がサイボウズのQAプロセスがスクラム導入とあわせてすごく変わったという話をして、それを事例として提供させていただくことになりました。 登壇者はこちらの5名です。サイボウズの2名にはQAの現場メンバーとしてアジャイルなQAに取り組んだ事例を発表していただきます。私はモデレータとして全体の進行をお手伝いします。AJ実行委員の2名はグループワークなどのお手伝いをさせていただく予定です。
• #4: 全体の進行はこのように進めます。各事例の中で、実際に遭遇した問題や現在直面している問題についてグループワーク形式で議論してみましょう。イメージは「世界ふしぎ発見!」です笑 サイボウズでの事例を通して、アジャイルなQAについてみなさんで議論を深めていければと思います。
• #7: サイボウズ株式会社グローバル開発本部 東京品質保証部の矢引達教と申します。 2012年に新卒でサイボウズに入社して以来、 主にクラウドサービスのアプリケーションのQAを担当しています。 趣味はヨガと書きましたが、2週間前にヨガ教室に通い始めてまだ3回しか行っていないので、 これから趣味になってほしいなという気持ちを込めてここに記載しています。
• #8: まずは弊社について簡単にご紹介します。 サイボウズ株式会社は、 「チームワークあふれる社会を創る」というミッションのもと、 グループウェアの開発・販売・運用をしています。
• #9: 主な製品は企業向けグループウェアのサイボウズOffice,ガルーン、 業務アプリ構築クラウドのkintone、メール共有システムメールワイズといった製品があります。
• #10: 2011年に提供を開始したクラウドサービスcybozu.comでは、 これらのアプリケーションをクラウドサービスとして提供し、 導入者数2万社以上、契約ユーザーライセンス数80万人以上のお客様にご利用いただいています。
• #11: まずは私達のチームの開発体制についてお話しします。 クラウドサービスcybozu.comの管理機能の開発を行なっています。 こちらは画面の例なのですが、 kintoneやガルーンといったアプリケーションを利用するユーザーやその組織の情報をシステム管理者が管理をするための機能です。 こういった機能を開発しています。 開発は日本で行い、試験は日本と上海の2拠点体制です。 メンバー構成は、プログラマは4〜5名、QAは5名、プロダクトオーナーは1名です。
• #12: ユーザー管理機能とは、こういった、組織やユーザーの情報を管理するためのシステム管理者向けの機能のことです。
• #13: スクラム導入前の開発プロセスについて説明します。
• #14: スクラム導入前は、ウォーターフォール型を採用していました。 テスト設計の一部は開発期間と並行して進めていましたが、 開発期間が終わってからテスト実行を開始していました。 開発期間と試験期間はどちらも1.5ヶ月くらいずつでした。 
• #15: スクラム導入前に感じていた問題点は、次のようなものがありました。 実装から試験開始までにラグがあるため、どうしてもバグの検出が遅くなってしまいます。 それによって、原因が似たようなバグが複数箇所に埋め込まれてしまったり、 テスト対象に関する質問をしても、実装担当者が記憶が薄れているため調査に時間がかかることがありました。  また、先ほどウォーターフォール型と言ったのですが、 設計に着手する前に要件のチェックを行うプロセスが明確には存在していなかったので、 要件が曖昧な状態で開発を開始してしまい、 要件の考慮漏れに気づくのが遅くなり手戻りが発生してしまうことが何度かありました。 さらに、試験期間は開発者はもう次のバージョンの開発に着手しているため、 開発チームとして同じものを開発しているという感覚が薄く、チームとしての一体感が薄いという状態でした。 また、共通管理機能という製品の都合上、社内の他のチームが開発する製品との結合試験が度々必要となるのですが、 開発者間では共有されていた情報がQAには伝わっていないことが何度かありました。
• #16: そんな中、去年の1月に部署でスクラムトレーニングを受講する機会があり、 私達のチームメンバーは全員研修を受けました。
• #17: ただ、スクラムトレーニングでは主に考え方を学ぶというところがメインの目的であり、 特に試験をどのように進めるかという具体的な説明はあまりなかったので、 「試験プロセスはほんとうにスクラムに対応できるのかな・・・？」という不安を抱えていました。
• #18: とはいえ、既に社内の他のチームでスクラムを採用しているチームがあり、 その雰囲気が良さそうだったということもあり、 不安はあるけど私達のチームでもまずはスクラムをやってみよう！ということになりました。
• #19: スクラム開始までは少し時間があったので、スクラム開始までにいくつか準備作業を行いました。 やったことを4つ紹介します。 まず1つ目は、開発チームのチームメンバー全員で「カンバン仕事術」の輪講をしました。 この輪講をしたことで、各自の作業を見える化することの大切さや、 WIP制限と呼ばれる同時に進める仕事の数を制限することで、 仕事一つ一つが早く終るという、スクラムにも役立つ知識を付けることができました。 これはとても大事な考え方だと思いますので、 スクラムをやらない会社でもカンバンはおすすめです。
• #20: 実際の私達のチームのカンバンの様子です。 ToDo, Doing, Review, Doneといった列があります。
• #21: 二つ目は、Readyの定義をチームで話し合いました。 Readyの定義とは開発チームが着手できるバックログの基準で、 これを満たさないと開発チームは設計や実装に取り掛かることができないというルールです。 テストに関係するところでは、 「開発チームが納得できるユーザーストーリーがある」 「受け入れ条件が定義されている」 といった内容をReadyの定義とすることにしました。
• #22: 3つ目は、スプリント単位での完了の定義について話し合いました。 完了の定義とは、何を持って「完了」とするかを定義したリストであり、 スプリントでどこまでやるか、の基準です。 カンバン仕事術を読んでいたこともあり、 開発チーム内では、実装だけではなくテストに関する項目を含めることまではみんなが合意していましたが、 どこまで含めるかは議論の余地がありました。 例えば、テスト設計が完了するところまででよしとするのか、 機能試験から性能検証に至るまで全てのテストをスプリト内で完了するところまでを含めるか、ということです。
• #23: ここで大切なのは、 達成できない理想を掲げるのではなく、現在の開発チームの実力に合わせることが大事だと考えています。。 具体的には、私たちの実力に合わせて、次の2つは完了の定義に含めないことにしました。 テスト実行完了については、次のスプリントで完了することをチームの目標にしました。 また、脆弱性検証と性能検証については、社内の脆弱性検証チームと性能検証チームが行うのですが、 1スプリントごとの実施が難しいということだったので2,3スプリントまとめて実施するようにしました。 完了の定義に含めたことは、 「テスト設計を完了させる」ことです。これをチームで合意しました。
• #24: さらに、アジャイルQAをすでに実施されている方の講演を聞きました。 弊社の天野の紹介でアジャイルQAの実践者である日新システムズの永田さんに社内勉強会に来て頂き、 DevQAについての講演をしていただきました。 この講演の中で、QAから開発への素早いフィードバックの重要性を再認識しました。 正直なところ、それまでスクラムに対する不安の方が大きかったのですが、 この講演を聞いて大変そうだけどスクラムやってみようという覚悟ができました。
• #25: それでは、スクラム導入によってどのような変化があったということについて説明します。
• #26: スクラム導入後は、1スプリントを2週間とし、リリース単位は6スプリント+リリーススプリントとしました。 リリース頻度は3ヶ月で、これはスクラム導入前後で変化していません。 先ほど説明しましたが、テスト設計はそのスプリントで完了し、 テスト実行はその次のスプリントで完了できるように進められるようになりました。 最近はすべてのタスクというわけではないですが、 1 Sprintで開発からテスト実行完了までを終えられるようになって来ています。
• #27: スクラム導入によって得たメリットを紹介します。
• #28: スクラムのフレームワークを取り入れたことによって、 主にQAの活動に対して与えた大きな効果は以下の3つだと思っています。 バグの早期検出、要件の明確化、そしてチームの一体感の向上です。
• #29: まず、次のスプリントでテスト実行まで完了するようにしたことで、 実装からテスト実行開始までの期間が短縮されました。  これによって、作り込まれてしまったバグを早く検出できるようになりました。 バグが作り込まれてから検出するまでの期間を調べてみると、 スクラム移行前は平均28日だったのが、約7日に短縮しました。  また、類似バグが量産されてしまうことを防ぐことができたり、 開発者の記憶が新しいので、調査を依頼してもすぐに返答が返ってくるようになりました。
• #30: 二つ目のメリットは、。 Readyの定義として「開発チームが納得できるユーザーストーリーがある」を含めたため、 要件が曖昧なまま実装に入ることを避けることができ、 認識の齟齬による手戻りが減少しました。 また、サイボウズでは社内に脆弱性検証を行うチームがいるのですが、 最近では、要件検討のミーティングにその担当者も同席してもらえるようになり、 要件定義の段階でセキュリティの観点を含めることができるようになりました。
• #31: 3つ目のメリットは、開発チームとしての一体感が高まったことです。 デイリーミーティングやカンバンによって開発チーム内のコミュニケーションがより深まったことで、 QAは開発者のリクエストをより柔軟に聞くことができるようになりました。 例えば、「この機能の実装が終わったので、ちょっと早めに動作確認してほしい」といった要望があれば、本格的な試験の前にさっとQAが動作確認したりすることができるようになりました。  逆に、開発者もQAのことをより気にかけてくれるようになりました。 「次のスプリントで試験が終わる」ことをチームが目指していて、かつカンバンで進捗が逐一わかる状態担っているので、 開発者も自然と試験の進捗が気になるようになります。 そうなると、例えば、試験容易性を高める機能を追加する提案をしてくれたり、 「この部分は確認しづらいので次のスプリントで実装する機能と一緒に試験した方が確認しやすいかもしれない」 といった提案をしてくれるようになりました。
• #32: ここまでスクラムのメリットを紹介してきましたが、 それではスクラムを採用すれば必ず 生産性が向上し、メンバーが成長し、プロダクトが改善するようになるのでしょうか？ 自分もスクラムを取り入れる前はそのような理解をしていた面があったのですが、
• #33: 実際にスクラムをやって見ると、スクラムは問題を発見しやすいフレームワークであると実感するようになりました。 どういうことかというと、 どこがうまくいっていないかを特定しやすく、 それを解消する機会が与えられている、ということです。 発見した問題を解決することで、結果的に生産性の向上につながる場合があるということです。
• #34: そこで、ここからは、私のチームがスクラム移行時に直面した問題と、それをどう解消したかを紹介します。
• #35: これから紹介する問題をこの後のグループワークの題材とします。 もしかするとみなさんのチームとは状況が異なるかもしれませんが、 「自分だったらどう対応するか？」を考えてみてください。
• #37: 遭遇した問題は、「試験設計のレビューが間に合わない！？」という問題です。
• #38: 背景を説明します。 スクラム導入以前は、テスト設計レビューを2段階で実施していました。 テスト設計は上海のQAが担当し、レビューの1回目はクロスチェックという形で上海のQAメンバー内で行なっていました。 その後、2回目のレビューを東京QAが担当し、それを通過すればテスト実行の工程に進むというプロセスでした。  スクラム導入以前から、このレビュー2にタスクが溜まりがちになるという状況は発生していましたが、 スクラム以前は試験期間が1.5ヶ月あり、その長い期間内でなんとか都合をつけて行っていました。 ただ、スクラムを導入したことより2週間以内にテスト設計を完了する必要が出てきたため、 このボトルネックが深刻化しました。
• #39: 東京QAは1名のみで、直近での増員は難しいという状況でした。 レビュー２でのレビュー観点は主に以下の２つです。 一つ目はテスト観点に不足はないかという「漏れがないか」の確認で、 レビュー観点は東京QAに属人化していました。 二つ目は、省略できるテストケースの組み合わせが無いかという「無駄がないか」の確認で、 テストケースの組み合わせが爆発する場合、東京QAが開発担当者に相談しつつ、 開発の視点で省略できるテストケースがあれば省略するといったレビューを行っていました。 ということで、グループワークの題材は、 「スクラム導入により深刻化した試験設計プロセスのボトルネックをどう解消するか？」です。
• #41: グループワークでの議論ありがとうございました。 唯一の解決策は無く、皆さんが挙げていただいたいろんな方法で解決できると思いますが、 ここでは私たちのチームが実際にどうやって解決したかを紹介します。
• #42: まず、レビュー２でチェックしているレビュー観点のうち、「漏れが無いか」については観点をチェックリスト化し、 試験設計とレビュー１でチェックしてもらうようにしました。 次に、無駄のチェックについては、 開発者にも試験設計レビューに参加してもらい、直接チェックしてもらうようにしました。 このような対策を行うことにより、試験設計レビュー２のレビュー観点を他のフェーズに移管することができました。 これによって、スクラムのタイムスケジュールに合わせて試験設計を行うことが可能になりました。
• #43: ここで、なぜ解決できたかを振り返ってみると、 試験設計という問題をQAのみで解決しようとせずに、 チームの問題としてチーム全体で取り組めたことが解決につながったと思っています。 ではチーム全体で解決に取り組むために何をしたか？を考えてみると 次の3つが大きかったと考えています。 1つ目はカンバンによって試験の進捗についても見える化したことで、 どこにどれだけのボトルネックが発生しているかが分かりやすくなり、 チーム内で問題に対する共通認識を持つことができたことです。 2つめは、完了の定義にテストに関する事項を含めてチームで合意したことで、 チームで共通の理想を持てたことです。 そして3つめは、なるべく職能間のスキルの障壁を無くすことです。 それまでは試験仕様書の形式をExcelにしていましたが、 試験仕様書を初めて見る開発者にとってはテストケースの意図を汲み取るのは難しいものがありました。 そこで形式をマインドマップに変えて、開発者がレビューしやすいようにしました。 テストに関する問題はどうしてもQA内で解決しようとしてしまいがちなのですが、 チームの問題としてチーム全体で取り組むことが重要で、 スクラムはそれをやりやすくしてくれるツールであると考えています。
• #44: 今日は私のチームのスクラム移行の話をしましたが、まだまだ課題が残っています。 リリースサイクルはスクラム移行前後で変わっておらず、今でも6スプリント＝3ヶ月単位となっているので これを1ヶ月単位にしたいです。 また、1スプリント内でテスト実行まで完了するようにしたいです。 そのためにはスプリント開始前のテスト工数の見積もりをどうするかといった問題も解決する必要があります。 また、それとも関連するのですが、開発チーム外が行っている、性能検証や脆弱性検証も高速に実施できるように 関係部署と調整を進めていく必要があります。 また、拠点間でコミュニケーション不足が発生してしまいがちなのでそれも改善したいです。 テスト自動化は現在開発者が行っていますが、今後はQAがテストコードを書けるようにしたいです。
• #45: ここまでの発表をまとめます。 私たちのチームがウォーターフォールからスクラム移行した際に 行った準備作業を紹介し、 スクラム移行によって得たメリットを紹介しました。 また、スクラムは問題発見のフレームワークであり、 チームに問題はチームで解決することが大事であるということを紹介しました。 ご静聴ありがとうございました。
• #55: ・チーム名は実際に使われているチーム名です 星座や惑星をモチーフにしたチーム名になっています
• #59: 現在の複数拠点大規模スクラムへどのように移行していったかを紹介しようと思います
• #60: 去年、スクラムトレーニングをキッカケにスクラム導入を決めたのですが・・・
• #62: ただでさえ分からないことだらけの状態で複数拠点同時導入はハイリスク！失敗が目に見えています。 ・導入時の鉄則、スモールスタート ・失敗したときのリスクを小さく ・プロセス改善の意思決定/反映を素早く
• #65: はじめのほうでもお伝えしたように日本のQAはマネジメント中心だったため、もともとQAの人数が少ない状態でした
• #67: ・日本ですぐにQAリソースを増やすのは困難。 ・このときはまだ職能に対する壁があり、チームでバックログをdoneにするという意識が低かった・・・
• #70: ・紫ラインが実績、緑ラインが理想線 ・バーンダウンなのに途中で上がってるのは、バックログを追加したため
• #71: 一方でこんな声も・・・ ・コミュニケーション増えた！（PG/QA/PO）・カンバン好評。（見える化）・問題点を共有しやすい。（デイリースクラム）・気持ちを切り替えやすい。（スプリントによるタイムボックス）・ワイワイやるのが楽しい！
• #74: これにより日本チームも含めて各チームにQAが配置されて自分のチームで完結できる体制になった
• #75: ・日本ですぐにQAリソースを増やすのは困難。 ・このときはまだ職能に対する壁があり、チームでバックログをdoneにするという意識が低かった・・・
• #76: ・現地企業によるスクラム研修
• #77: ・約3週間ほど現地に出張してOJTを実施・出張者のうち2名は開発チームの一員として活動・帰国後も同スクラムチームに所属して日本/越南混合チームを形成
• #79: ・テスト設計、テスト実施のやり方、タイミングなど
• #81: 一度に変更するのではなく徐々に適用させていった
• #84: 前のスライドでもあったように今まではテストは開発した次のスプリントで実施していました。 それは、このような問題・課題があったためです。
• #86: ・ギルド：興味のあるコミュニティの集まり ・ABD：1冊の本を裁断し、担当パートごとに読み、要約文を作ってリレープレゼンを行う 　　　　　 その後感想や疑問について話し合う