Appresso Engineer Blog

アプレッソのエンジニアが書く技術ブログです。

Agile Japan 2016 にワイワイ参加してきました!(2/2 : どうやってテストするのさ 編)

開発部の野口です。

アプレッソから 10 名で参加してきた Agile Japan 2016 の感想シリーズ、後編をお届けします!

前編はこちら。

appresso.hatenablog.com

さて、アプレッソには QA チームがあり、開発と QA でどうアジャイルにやっていくかというのが一つの大きなテーマになっています。
この後編では、アジャイルなテストにまつわるセッションの感想をお届けしてまいります。

目次

特によかったセッション!

前編と同様、各参加メンバーに特によかったセッションを選んでもらいました。

セッションの簡単な紹介は私(野口)、感想は参加メンバー各位の文責にてお届けします。
多くの講演資料が、Agile Japan 2016 のプログラムページからダウンロードできるようになっています。

アジャイル開発に適した要件の作り方 ~何をどこまで決めればよいのか~

アジャイルなソフトウェア開発の特徴の一つとして、まとめて開発し、まとめてテストするのではなく、機能を小さな単位で一つひとつ着実に完成させていく(動くソフトウェアに変換していく)、ということがあります。

小さな単位で開発し、テストしていくためには、要求の切り出し方も従来通りにはいかず、工夫が必要となります。
そのための方法を紹介するセッションだったようです。

DEEP 特性と INVEST 特性を意識してユーザーストーリーを作っていく(谷平)

自分はテストエンジニアで、今までアジャイルという概念を本でしか読んだことはなく、実践はこれから始めていくという立場です。

Scrum などでの開発の進め方というのは本を読んである程度こんなものかというのが想像でき、テスターはプロダクトオーナーから要求を引き出すのを手助けできるポジションにある! という話を聞いてなるほどー、と思いはしたのですが、そもそもその要求ってどう決めてプロダクトバックログに落とすんだっけ? というところがよくわかっていなかったので、このセッションを参考にしようと思い参加をしました。

プロダクトバックログに求められる DEEP 特性や、その特性を満たす目的、手段、使用できるフレームワークが体系的にまとめられていました。
書き留めることができたものを以下に記載しますが、なんの目的を満たすために何を使えばよいのか、という組合せのところがすっきりまとめられていて、わかりやすくてよかったと思います。

  • Detailed appropriately : 適切な詳細さ
    • 目的 : Sprint 計画に着手したい
    • 手段 : 要件記載ルール、画面イメージなど
    • フレームワーク : ユーザーストーリー、Storyboard
  • Estimated : 見積り済み
    • 目的 : 開発する順番を決めたい
    • 手段 : 相対的、大まかに見積もる
    • フレームワーク : Planning Poker
  • Emergent : 創発的(後発的な技術要求をチームが発見した場合にあとから進化させられる)
    • 目的 : 開発チームやユーザーとの対話で機能を改善したい
    • 手段 : ビジネスモデルやユーザー像を共有して創発を促す
    • フレームワーク : Lean Canvas、Pragmatic Persona
  • Prioritized : 優先順位づけがなされている
    • 目的 : 開発する順番を決めたい
    • フレームワーク : User Story Mapping

また、この中でユーザーストーリーが満たすべき特性として INVEST 特性というものがあるそうです。
検索すると以下のページが見つかりました。

www.infoq.com

このセッションで、どうやるとうまくいきそうか、ということはわかりました。
実際にやってみると最初は大変に苦労しそうですが、それでも何も知らない状態から始めるのに比べると数段楽になりそうというのは確かです。
あとで DEEP 特性について検索してみると『スクラムを活用したアジャイルなプロダクト管理』という本が引っかかってきたので、これも読んでみて次の開発に役立てていこうと思います。

アジャイル開発における品質保証と人材活用

続いては、品質マネジメント部のマネージャーである東と、同じく品質マネジメント部のメンバーである金澤が聞いてきた話です。

かなり毛色の違う業界の話ながらも、期待に沿う内容だったようです。
スピーカーはグリーの村上薫さん、市原楓さん。

エンタープライズでもゲームでも、苦労しているところは同じ(東)

私はエンタープライズパッケージの QA エンジニアですので、コンシューマー向けゲームの QA をどのようにやっているのか、とても興味がありました。

はじめチョロチョロ なかパッパ

開発の状況に応じてテストのやり方を変える(はじめチョロチョロ = 仕様の変化が激しいうちは正常系に注力、なかパッパ = 仕様が落ち着いてきたら網羅的に確認する)という考え方は、我が QA チームも取り入れているので、頷きながら話を聞けました。
一方で、開発・QA フェーズの後にユーザー参加の「ベータテスト」という概念が存在し、「ベータテストで "面白さ" を評価してほしいので、それを阻害するバグはその前までに取り切っておく」という考えは新鮮でした。

これまでは、アジャイルで開発フェーズに QA も入った際に何をしよう……と漠然と考えていましたが、この話を聞いてたとえば「使いやすさ」といったキーワードを立てて、それの評価を阻害するような問題の検出を開発フェーズ内で行う、というようなアプローチを行ってみても面白いな、と思いました。

繁忙期に対応できる柔軟な体制作り

次に、QA は繁忙期に人が足りなくなるということがあり、それを克服するために「社内の手が空いている人に助けてもらう」「特例子会社*1に協力してもらう」という施策を行っているという話がありました。
それを実現するために、(ほとんどが QA 経験なしの方であるため)徹底した作業マニュアル化やコミュニケーション手段の工夫などを行っているとのことです。

確かに、QA フェーズは開発の遅れや想定外の不具合による戻りなど諸問題を吸収しがちになるため、状況に応じて増員が必要になります。
最大人数を常時確保するのはコスト面から承認されにくいため、柔軟に対応ができる体制を整えておくことは、安定して QA を行うためにとても大事なことです。

ただ、単純にマニュアル化すれば誰でも QA ができるのか、というとそれは違うと思いますので、運用できるようになるまでは相当の苦労があったのではないかと想像しました。
また、「誰でもできる」ということになってしまうと、それまでの QA 専任の方のプライドも気になります。

このあたりは、専任の方はより高度で専門的な QA を担当し、本来であれば自動化すべきだがサイクルの早いゲームでは自動化しても使い捨てになってしまう定型的なテストを非専任の方に回して、バランスを取っているのではないかと推測しています。

エンタープライズの対極に位置するように感じていたゲームの QA を通して、結局は自分たちのことのように聞くことができました。
みんな苦労しているところは同じですね!

他部署のメンバーが自社プロダクトを理解する機会にする(金澤)

コンシューマ向けのゲーム開発としての講演なので参考程度の受講でしたが、いくつか面白い取り組みがありました。

  • 社員のタスクをすべてカンバン化(可視化)していること
  • テストの負荷が高い際には他部署の人にもテスト実施してもらうこと

一点目は、直感的に効果を想像できます。

二点目について、コンシューマ向けプロダクトの品質には暗黙的に「誰でも理解でき、操作できること」が求められると思いますが、それを有効に確認できる面白い取り組みだと思いました。

また、開発部署以外の人は自社プロダクトに触れる機会が少なく、十分に理解できていない場合が少なからずありますが、この取り組みによって自社プロダクトの理解が進むことも期待できると考えます。
アプレッソでいうなら、主にセールス担当やサポート担当の方に触れていただき、フィードバックを得る機会があってもよいのではないでしょうか。

新米スクラムマスタとQAおじさんのアジャイル珍道中

そしてそして、アプレッソ参加者から圧倒的な支持を得たこのセッションです。
私も気になっていたのですが、同時間帯の平鍋さんのセッションが気になって断腸の思いで……。(平鍋さんのセッションもとてもよかったので悔いはありませんが!)

内容はまさに開発と QA でやっていこうとしているアプレッソの先を行くような、期待に応える大充実のものだったようです!
スピーカーはソニーの永田敦さんと、ニッポンダイナミックシステムズの豊田昌幸さん。

開発プロセス全体を通して、「神様」であるテストケースを目指す(陳)

アジャイル開発のプロセスにおいて、開発担当と QA 担当の理想的なつきあい方を提示してくれました。
アジャイルの取り組みを始めて間もないアプレッソにとって、実に学ぶところの多いセッションでした。

私の偏見かも知れませんが、よく見かけるアジャイルの事例の多くでは、要求仕様と開発の間のギャップを埋めることに着目していて、QA 担当がいるような大きなチームでの QA のあり方はもちろん、QA とのつきあい方にもあまり触れていませんでした。
そういう着目点の穴を埋めるように、このセッションでは、一緒に仕様を作るところから始めて、最後の評価まで、開発プロセス全体を通して、「神様」であるテストケースにたどり着くまでに、フィードバックループがどのように広がっていくかを説明しました。

まず、仕様設計段階の開発と QA による仕様レビューは常に違う視点からフィードバックをもらい、仕様が必要以上に複雑にならないよう、盛りすぎないように防ぎます。
そして QA のテスト設計と開発の詳細設計の段階でも、テストの評価内容を共有しておくことで、違う視点からフィードバックをもらい、テストケースの漏れと実装上の穴を防ぎます。
最後に評価とバグ修正の段階でも常にフィードバックすることで、ユーザーストーリーとテストケースの間の溝を埋めていきます。最終的には、「神様」であるテストケースにたどり着きます。

セッション内で提示した理想のアジャイルというゴールまでの道程は遠いですが、他のメンバを巻き込んでフィードバックループを広げるために、今の自分にできることを常に意識して、チームメンバの間に強い信頼関係を築けるように実践していきたいと思います。

テストケースが製品の詳細な振る舞いの仕様書になる(伊藤)

「ペアテスト設計」

ペアプロならぬペアテスト設計というのが面白いと感じました。

テストケースのレビューは行いますが、二人共同でテスト設計していくというのは実践してみたら知識の共有に役立つかなと思いますし、相乗効果でよりよいテスト設計が行えるかもしれないなと。

「フィードバックループの広がり」

最初 PO と QA が行っていた仕様レビューのフィードバックの流れが広がり、開発も巻き込みさらに様々な工程で実施されていったのが興味深いです。

会話しフィードバックしあうという文化(?)のようなものが形成されていったのではと思います。
アプレッソでも積極的に会話を行い、そういった流れや雰囲気を作っていきたいです。

「テストケースは神様」

フレーズも力強くて、一番印象に残りました。

フィードバックループを続けていくことで、最終的にテストケースが製品の詳細な振る舞いの仕様書になったといいます。テストケース = 仕様書という発想はありませんでした。
仕様書と呼べるということは、仕様を相当落とし込んでおり、開発や PO と綿密な連携が必要不可欠であることは想像に難くありません。ですが、そこまで落とし込めたならば、テストケースの不足や誤りを防ぐのに効果を発揮しそうです。

また、テストケースは一覧性があって仕様を読み取りやすいつくりになっているのではと想像します。
現状、我々が作成しているテストケースでは観点毎にシートが分かれており、フリーフォーマットで作るため、仕様を確認するには不向きなつくりになっています。
仕様書としても活用できるようなフォーマットで作成することを検討してもいいかもしれないと考えます。

品質を向上させるフェーズで QA としてどんなフィードバックができるか(金澤)

フィードバックループの成功例として、興味深く聴講しました。

「開発フェーズ (= 作りこむフェーズ)」 で開発・QA とも同時期に、要求仕様を検討することで、より精度の高い成果物になる。
その中で互いにフィードバックしあうことで得られた結果が仕様になり、その結果は「テストケース」としてまとめられ、仕様の神様となっている。

書くと簡単に感じられますが、まず要求仕様からテスト設計することの重要性を深く感じられました。
仕様書なしに「この機能はどうあるべきなのか、どう振る舞うべきなのか」についてのテストを考えることは旧来の QA に求められることが多くなかったからです。

講演では「結果としてテストケースが神様とされている」と刺激的におっしゃられていましたが、これは「仕様書を記載するより先にテストケースを作成」できていることの結果として面白いものと感じました。

また特徴的な表現として「開発プロセスが何であれ、システムテストフェーズでできることは変わらない」との言葉が印象に残りました。
「テストフェーズ (= 確認するフェーズ)」は品質をあくまで確認するフェーズであり、品質を向上させるフェーズで QA としてどんなフィードバックができるか、に注力しなければならないと感じました。

Agile Japan 2016 全体を通しての感想

最後に、Agile Japan 2016 全体を通しての感想を一つご紹介しておしまいにします。

まずは信頼関係を改善していくこと(金)

アプレッソの開発・QA では、現在、アジャイル手法の導入で大変盛り上がっています。
開発フェーズからQAメンバーを投入し、プロジェクト後半に発生するクリティカルな不具合を早期に見つけ、よりよい品質の製品をより早くお客様に提供しようとしています。

しかし、これまでの「開発フェーズの完了後に QA が本格スタートする」というスタイルから、「開発と QA が一緒にスタートする」アジャイル手法への変更で、理想的な製品が期限内にリリースできるか、漠然とした不安を持っていました。

QA はリリースに大きな責任を持っているため慎重に行動しないといけませんが、これまでの経験上、新しいプロセス導入を予行演習なしで本番に導入した場合には、とてもリスクがあると考えています。(もちろん成功するケースもまれにありましたが、ほとんどが失敗しています。)
短いイテレーション期間内に QA がどこまでどんなテストをするのか、具体的な方法を見聞きして、少しでも不安感を解消するために、今回、Agile Japan に参加することにしました。

今回のAgile Japanで最も良かったと感じたのは、信頼関係の改善を優先すべきということです。開発は開発なりのスタイルがあり、QAはQAなりのスタイルがあるのに、急に共同作業することでいろんな摩擦が起こる可能性は非常に高いと思います。どれだけよいプロセスを持っていても、この問題を解決しないと結局プロジェクトは残念な結果に終わるのではないでしょうか。アジャイルも数多いプロセスの中の一つにすぎません。結局、人がやるものです。

チームのメンバー全体が、共通の価値観を持って、楽しく働ける職場を作るのが最も重要だと思いました。
そして、メンバーの平準化も必要です。もちろん経歴が長いほど自己のナレッジも増えるため、経験が足りないメンバーよりはできることは当然ですが、経歴が足りないメンバーがより積極的に動ける雰囲気を作るのも大事です。

楽しく働ける職場を作るための手法として、ほとんどのセッションで話していたのが「情報の可視化」です。直感的に感じることが大切なので、デジタルではなくアナログで情報を可視化した方がよさそうです。
アプレッソ内でも付箋を積極的に活用するようになっていますが、プロジェクトの進捗以外にも個々の趣味趣向などに関する情報なども可視化して、メンバー間の距離感をできるだけなくすに力を注ぎたいと思います。

個人的に今回の Agile Japan で具体的なテスト方法よりは、プロジェクトに対する姿勢について学ぶことができました。(そもそも具体的なテスト方法を求めるのは現実的ではなかった気がします。当然ですが、会社ごと・製品ごとにテストの範囲や手法に差異があるため、何が正しいアジャイルテストの手法であるとは言い切れないと感じました。)

アプレッソにアジャイルのスタイルが定着するまで、色々な試行錯誤があると思いますが、前より品質がよく多様な機能を持つ製品を素早くリリースすることを想像するだけで、ドキドキしています!

やれる気がします

Agile Japan に参加して、それぞれのメンバーがそれぞれに色々なものを持ち帰りました。

新しいやり方を導入していくとき、今までのやり方を変えることは痛みをともなうので、「変えたくない」「なぜ変える必要があるのか」といった抵抗を受けがちです。
それだけをテーマにした本まで出ているくらいです。

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

  • 作者: Mary Lynn Manns,Linda Rising,川口恭伸,木村卓央,高江洲睦,高橋一貴,中込大祐,安井力,山口鉄平,角征典
  • 出版社/メーカー: 丸善出版
  • 発売日: 2014/01/30
  • メディア: 単行本(ソフトカバー)
  • この商品を含むブログ (16件) を見る

また、やる気があっても、やり方がわからず、うまくいかないこともあるでしょう。
あまりにもやり方がまずいと、「変えたのがそもそも間違いだった」ということになって、ただ元のやり方に戻ってしまうということも起こりかねません。

しかし、今回多くのメンバーで Agile Japan に参加したことで、「なぜやるのか」についても、「どうやってやるのか」についても、知識や考え方が組織に芽吹き、根付き始めている感じがします。
アジャイルな見積りと計画づくりを始め、フロア内のホワイトボードや壁に付箋が貼りだされ、今までになかったような対話が生まれ始めています。

やっていけそうです!

*1:「障がい者の雇用促進及び安定を図るため、特別な配慮を行っている子会社」のこと(セッション資料より)