NPO法人ソフトウェアテスト技術振興協会 イベント報告-JaSST'21 Niigata
HOME > 活動報告 > イベント報告 > JaSST'21 Niigata
2021年7月16日(金) 於 オンライン開催
11回目となるJaSST新潟はオンラインで開催された。
定刻を待っていると、開始10分前に実行委員長の伊藤氏と基調講演の永田氏によるフリートークが和やかに始まり、その雰囲気のまま開始となった。
実行委員長の伊藤氏によるオープニングセッションでは、スポンサーと参加者への感謝を述べた後、今回のシンポジウムは近年言われている「One team」「Whole-Teamアプローチ」「サイロの排除」といったキーワードから、「品質向上のためのチームワーク」をテーマにしたとの説明があった。
また、新潟の魅力として、90もの酒蔵を持ち、ラーメン王国であること、また自然の豊かさといった紹介があり、オンラインながら新潟に思いを馳せつつ本編が開始された。
基調講演のアジェンダは以下の通りである。
アジャイルについて、事実や本質よりも誤解との戦いがあったという。
永田氏自身も表面的な抵抗があったが、わかっている人に出会い、理解を深めていったとのことだった。
その中で試したプラクティスは以下のものである。
ドキュメントに欠陥を埋めないために行う。
短い時間でレビューし、ドキュメント品質を作りこむアプローチである。
インクリメンタルなレビューを行うことで書き手が学び、レビュアーの質も向上していく。
アジャイルには学ぶ回数がWFと異なり、改善する機会が多いという特長がある。
評価を頻繁に行うことで"学び"があり、顧客が求める価値にたどりつく。
この"学び"がポイントであるとした。
探索的分析と欠陥モデルを作る2つのフィードバックループをイテレーティブに繰り返し、真の要因を導き出す。
モデルを成長させ、学びながら分析する。
DevとQAの情報のコラボレーションにより、品質を作りこむ活動である。
アジャイルには価値という言葉が頻繁に使われるが、価値の対価はどう決まるか。
時計の例(機能だけでは1000円で十分だが高価な時計が売れている事実)から「我々では本当の品質はわからない」と述べた。
そのため、お客様にどんどんデリバリーしフィードバックを得る必要がある。
これがCI/CD(継続的インテグレーション/継続的デリバリー)であり、開発と分離していた昔との違いになっている。
新しい価値のアイデアであり、仮説の立証ができること、但し、顧客からの信頼・期待ができていることが前提となる。
永田氏はこの定義を、"顧客価値を製品、サービスに組み込むしくみ及び活動のこと"とした。
バリューストリームに品質を組込みながら、皆が関わる、Whole Teamで品質保証するということである。
QAは品質のビッグピクチャの観点を持ちながら、バランスよくそれをサポートするロールである。
また、QAに求められているものは、ソフトウェア品質に特化した多様性である。
アジャイルにおけるプロセスではインタラクションが重要。
プロセスをしていることの管理、ではなく、その中身と質が重要と述べた。
要求毎にプロセスは同じもので良いのか、と疑問を持ち、最適なプロセスをチームが設計する。
上記は、目の前にあるバックログに対してWhole Teamで品質の組込みを上流で行うプロセスであり、これが品質への自信となる。
開発で使うためのドキュメントについて、アジャイル・モデリングの分類"Keeps"と"Temps"を、アジャイル・ドキュメントにおいて適用する。
仕様書はKeepsに分類され、標準ドキュメントとして品質の楔となるため、しっかりとメンテナンスする。
メンテナンスは開発する前から行い、スコープを小さく習慣化し、コードと同期を取りながら進める。
アジャイル・クオリティ・モデルのプロトタイプの紹介があった。
モデルにおいてアジャイルQAとチームが重なる部分はOODA(ウーダ)プロセスで考える。
品質のビッグピクチャ(全体像)の観点を持つ。
目の前のバックログに対する諸々の活動に加えて、ビッグピクチャを考える。
ビッグピクチャは会社方針と品質ビジョンの整合性を取り、開発計画毎に変わることを留意する。
アジャイルQAが持つ品質の仮説は、現場で有効なのか、オープンに問題を議論してもいい。
偉い人が言うことが本当にそうなのか考える。
現場から学ぶことも多い。
永田氏は最後に「アジャイル・クオリティ、わくわくしませんか？」と、濃密な90分の講演を締め括った。
繰り返し発された「学び」というキーワードが非常に印象に残る講演だった。
永田氏自身が貪欲な学びの姿勢を持っていることも伝わり、大きな刺激となった。
昨今聞かれるSDGs(持続可能な開発目標)は、ソフトウェア開発においてもビジネスモデルの変化に伴い、持続可能な開発が求められている。
その変化に対するSustainable Quality(持続可能な品質)とは何か、事例を交えて紹介する内容となった。
サブスクリプションへの変化などにより、サービスの継続性が求められるようになった。
サービスが連携して動くようになり、サービスの構成が複雑化している。
上記の、継続性×複雑性により見えてきたのは様々な課題であり、QAが難しい時代と言えるのではないか。
アジャイル開発に移行するまでのQAは横断的にビッグテストをしていたが、プロジェクト毎にQAメンバーを固定するようになり、開発チーム以外のメンバーも巻き込む必要が出てきた。
スプリントレビューにおけるデモには関係者が全員参加する、そうした"お祭り感"も大事と述べた。
基本はSlackで行い、やり取りが2往復続くとGoogle Meetに繋ぐといった、適切なツールの選択を考える。
データを取って監視してアクションに繋げる。
エンジニアは数字でモチベーションを持ちやすい。
Seleniumで実装した事例の紹介があった。
QA主体で始めたが、E2Eに失敗した際の注意喚起をしている内に、エンジニアも一緒にやるようになった。
リリース前の性能テストをQA/Dev/SREの三位一体でやっているが、どこまでやるかが難しい。
不用意な更新によりパフォーマンスが劣化する。
更新の際はTech Leadのレビューを通してもらうようにする。
変更内容によってはテストをしてから更新する。
サポート期限を把握する。
テスト設計でいかにバグを潰すか。
テスト設計レビューはOne Teamで行う。
QAの指摘の仕方(による開発の受け取り方)に配慮する。
リリース時に見送った不具合については、リリース後に2スプリント内で対応する。
ユーザが気付く前に直す(夏休みの宿題と同じ「言われる前にやる」)。
直さない不具合の対応として、ユーザはバグだと思う可能性があるものはサポートへ連携し、なぜ直さなかったかの情報を提供する。
ユーザのペインを知る。 営業の生の声を聞く。
継続的に品質を担保するには、リリース後が大事であり、サービスに関係する全ての人達の協力が必要と締め括った。
事例発表ということで、持続可能な品質作りへの実践的なアプローチを聴くことができた。
起こり得る問題を予測し先手先手の対応を取っている点、モチベーションやコミュニケーションでの配慮など１つ１つのアプローチに繊細さを感じた。
アプリチームを見るインプロセスQAとして、プロセスの問題の解決に取り組み学んだことをTips形式で話す内容となった。
プロセスの見える化としてPFDを用いたが情報量が多く、反応が鈍かった。
しかし、重要そうな成果物を見つけることができた。
渡邊氏が感じていたテスト計画へのモヤモヤや情報量の多さを、ビジネスインパクトから優先順位を付ける形で情報量を最小限に抑え、自身の納得感のいくものにしたことで、スムーズな合意を取ることができた。
ロールに縛られず金の羽を探すことが、プロジェクトのゴールに少しでも近づくならばやるべきである。
お互いの会社の働き方を尊重する。
同期レビューの難しさを、マインドマップツールによる非同期レビューにすることが事例ではマッチした。
既存にやり方に囚われてはいけない。
いつかは飛び込まなければいけない、勇気が必要。
飛び込む際の文章力は大事である。
振り返りの結果から、チームが明日から動いてもらうため、半日で終わるよう、アクションアイテムの情報量を小さくする以下の提案を行った。
銀の弾丸はあるとした、但し撃つ前はわからないが、撃った後に拾う(振り返ると)ことで分かる。
撃たないことが一番ダメで、分析×回数で、銀の弾丸になる。
撃つ相手を分析し、撃つ回数を増やすと銀弾になる、また撃ち方を変えることも必要と述べた。
最後に、本発表のTipsを弾丸の回数の１つに使って欲しい、と締めた。
QAコーチとしてアウェーな環境の中での苦労が見えてくる実践事例の紹介だった。
渡邊氏の既定の概念に捉われない柔軟さと、相手へのリスペクトが常に感じられ、それが成功に繋がっているのではないかと感じた。
実行委員長の伊藤氏は「感無量」と述べたが、筆者も濃密な時間を過ごし、同じ思いであった。
最後に「来年こそはオンサイトで交流を深めて、新潟を楽しんでほしい」と締め括った
Whole Team／One Teamとして、立場の異なるメンバーをリスペクトし、コミュニケーションを取りながら、思考停止に陥らずベストプラクティスを模索し続ける、といったことが講演に共通して語られていたと思う。
テーマである「品質向上のためのチームワーク」以上に多くの気付きや学びがあり、非常に有益な時間だった。
記：堀川 透陽 （JaSST関西 実行委員）