日本最大級のソフトウェアテストのイベントJaSST '21 Tokyoが3/15(月)～16(火)に行われたので行ってきました！
こちらは1日目のセッションメモまとめです！
目次
- 基調講演 "Being Agile about Architecture"
- 「アジャイル・DevOps時代のテストと品質保証 輝く未来を抱きしめて！技術やツールが変えてしまうこと、変えられないこと」
- 「カスタマーサポートエンジニアの品質貢献」
- 「テストプロセス改善のお悩み相談室 リターンズ ～テストプロセス改善技術の導入で悩んでいる皆さん、悩みを共有しませんか？～」
基調講演 "Being Agile about Architecture"
Joseph W. Yoder 氏（Refactory CEO）
Agileのアーキテクチャ
Agile
- 常に短いループでフィードバックをもらう
- テスラなどのハードウェア企業でも使われてる
- 常に学習して自らを振り返る
Agile/Leanの価値
- 継続的な改善、改善を投入していく
- 価値があるから練習する
パターンとは？
- パターンはGood Practice
- 既知のテクニック、ソリューションを再利用できるかも
→繰り返してきちんとできるようになったら普通のプラクティスになる
- プロジェクトの一番初めに考えるべき、ずっと考え続ける必要もある
価値はプラクティスを推進する。価値は人によって異なる
＜プロジェクトのはじめに考えること＞
- 巨人の肩に乗る：どのようなフレームワークやDBを使うかなど、これまでのリファレンスを基にする
- 自分たちで追加でやる必要のある事を明確にする(信頼性、性能などなど)
- どこが一番問題があるのかに従って計画する
- 最終責任地点
- アーキテクチャのロードマップを作成する際に品質を一緒に考える（例：モバイルのセキュリティはいつ考える？な（）
- アーキテクチャそのものを検証する（アーキテクチャの進化の方向、品質にも影響を与える）
- テストアーキテクチャを構築する（プロジェクト中でも時々戻って考えたり確認したりする必要あり）
- 最大責任点を計画する
＜プロジェクト中に考えること＞
- バックログを作成して優先度を考える（色分けして考えると便利）
- 重要な品質が見えるようにする
- アーキテクチャのトリガーを設定しておく（測定しておいてフィードバックする）
- アーキテクチャのスパイク*1を設定しておく
- どのフレームワークがうまくいくか分からないとき、実験してどれがよいか意思決定するするタイミングを決定しておく？小規模な実験をたくさんやることを予め計画に入れておく
- 大きな泥団子（技術的負債）ができてしまうかも。できてしまうと後から綺麗にするのが難しい
- 見えないものは改善できない
- 横断的に可視化する
- 立場（開発者、マネージャー）によって見たいものが異なる
- 技術的な判断はビジネスの価値を踏まえて下すべき
- 継続的なインスペクション
- 効率的な運用に適用される自動化は、効率を倍増させる。非効率的な運用に適用される自動化は、非効率性を倍増させる by ビル・ゲイツ
- アーキテクチャを再評価し続ける
- ★イノベーションのためにはちょっと止まる時間も必要（この時間もプロセスに入れておく）
- 新しいことを考えたり、好きなことを試してみたりする時間
- 速さと生産性はイコールではない
質疑応答
Q. ユーザビリティはどのように可視化するか？
A. ユーザビリティのラボなどがあれば、キーストロークやユーザの視線などのログをとって追跡することもある。シナリオを構築して実験しフィードバックを得る。難しいが数字に落とし込むことは可能。
Q. 進化性の定義と測定する方法があれば教えてほしい
A. ビルドからリリースまでどのくらいかかったかを記録して比較する
Q. SREについてどのくらい優先度を与えるべきか？
A. 対象の製品によって異なる。人の命にかかわるものでは信頼性の優先度が高い。
Q. 技術的負債の対応はどのようにする？
A. ビジネス上のインパクトをきちんと見せるべき（例：負債がたまるとDelivery Speedが下がる）。ビジネス、エンジニア、QAみんなで対応する
Q. 技術的負債やアーキテクチャレビューをどの頻度でやるか？
A. 日常的に行う
感想
プロジェクトのはじめからプロセスに入れておくべきことや、進行中に絶えずやり続けることまで網羅されていて勉強になりました。勉強不足でいくつか用語とかが分からないところがあったので、twitterで補足いただいた方々に大分助けられながらの聴講でした。まだまだ勉強が足りない。
終盤の「よいアーキテクチャが高くつくと思うなら、悪いアーキテクチャを試してみなさい」がツボでした。根幹になるところは時間かけて考えないといけないところなんですけど、最初の方には見えてないこともあってなかなか難しいと思ってます。それもあっての「立ち止まる時間もプロセスにいれておく」なんでしょうね。よく抜けてしまうところなので、実験の時間を入れておくのは意識します。
（この講演は時間を置いた後にもう一度見たい。Yoderさんの別の講演動画でも見てみようかな）
「アジャイル・DevOps時代のテストと品質保証 輝く未来を抱きしめて！技術やツールが変えてしまうこと、変えられないこと」
藤原 大 氏（mabl Japan）
発表資料：アジャイル・DevOps時代のテストと品質保証 - 輝く未来を抱きしめて！技術やツールが変えてしまうこと、変えられないこと / Tech and Tool for Testing and Quality Assurance in Agile and DevOps Era - Speaker Deck
- 顧客が本当に欲しいのは結果
- 自動化できるものを自動化（自動化できないものもある）
- マニュアルテストの自動化はアンチパターンになりがち
- 技術の恩恵を受ける 例：パイプライン実行
- 品質保証をビジネス全体の活動にする
- QAチームを作るのではなく、活動に（QAチームがすべてをやるのは不可能）
「カスタマーサポートエンジニアの品質貢献」
登壇された方々（敬称略）
モデレータ：
城風 智（KIOXIA）
パネリスト：
加藤 敏之（LINE Fukuoka）
齋藤 由佳（Autify）
田向 祐介（ヴェルク）
山田 恭平（日本マイクロソフト）
Q. カスタマーサポートとコールセンターは違うの？
A.
- コールセンターがマニュアルに沿ってお答えするというイメージなら違う。お客さんの困りごとを解決するのが仕事。最終的には安心感とか好印象を持ってもらいたい。QAにもお客さんがどこでつまづいているのかという観点を得るのに、カスタマーサポートを行ってもらいたい
- お客様とのコミュニケーション「どういう状況で何に困られてるのか？」
- 顧客の困っていることをいかに引き出すのか、がポイント。「〇〇機能がほしい」と言われたときに、それが欲しい理由をきちんと聞けること。
- 問い合わせ対応時に、過程を言語化してお伝えすることも大事。（問合せしてくださった方も、さらに先のエンドユーザーさんに調査に時間をもらうことを納得いただく必要があったりする）
Q. カスタマーサポートエンジニアがソフトウェアの品質に貢献していると思う瞬間
A.
- ユーザーの温度感（ここつまづきやすそうだな、みたいなこと）を開発者にフィードバックする→該当部分の問い合わせが減り、サービスとしての品質向上につながる
- 開発に伝えた後もフォロー
Q. カスタマーサポートにとっての成功とは？
A.
- お客様が口コミで評判を広げてくださること（例：「問合せしたらすごくよく対応してくれた」）
- サポートがいいからここの製品を使おうと思ってもらえること
- お客さんにファンになってもらうこと。お客さんがテストを効率化できることにどれだけ貢献できたか
- 違和感を拾って聞いてみたところ、問合せのあった事象の手前に問題があった（サービスの仕様を誤解していて間違った使い方をしていた）話を聞いて解決につなげられた
- 「お客さんの声がもともとベクトルが間違ってることがあって、それに対して真摯に対応してはいけないパターン」
- 問い合わせをいただいた時点で、サポートを頼ってでもサービスを使いたいと思っていただいている
Q. 品質という視点でサポートチームから開発、QAにお願いしたいことは？
A.
- 仕様や画面の変なところに事前に気づけるくらいの引き出しを持ってほしい
- お客さんのことを考えた回答が欲しい。事実だけではなく、提案とかもあると嬉しい。ユーザのことを想像する力を持ってほしい
- 調査時点で、どういう状況で何に時間がかかるのかを開発からCSに共有してもらえると、いいサイクルになる（海外だと時差があるので特に）
質疑応答
Q. サポートチーム内でどのようにナレッジを共有しているか
A.
- 問合せ、回答、注意事項のDBを作っている。問い合わせ時にはそこを見て対応。マニュアルは敢えて作らない
- 社内FAQを用意している。対応時に感じたことや注意点も記載
Q. サイレントカスタマー対策は何かしているか？
A.
- サイレントカスタマー（不満は持ってるけど声を上げない顧客）は問い合わせないので、SNSなどを確認している
Q. 開発とサポート担当で期待が違う場合調整はどうしているか？
A.
- 顧客からの不具合レポートを開発とサポートでレビューしていく。
- 既存のお客さんが使いやすくなるような改善と、サービスの進化方向のバランス
Q. お客様とのコミュニケーション面で技術支援以外で工夫していることは？
A.
- 共感する力をあげていく。
感想
私自身はQAですが、カスタマーサポートの問い合わせにも時々目を通すので楽しみにしていたセッションでした。ユーザーが本当は何に困ってるのかを聞きだしたり、問い合わせ対応時に対応状況を相手にお伝えしておくなど、確かにそうだなと思う共感ポイントがいくつかあって楽しく聞けました！
「テストプロセス改善のお悩み相談室 リターンズ ～テストプロセス改善技術の導入で悩んでいる皆さん、悩みを共有しませんか？～」
登壇された方々（敬称略）
モデレータ：
田井 康平（ノハナ）
モデレータ補助：
雨宮 寿幸（ベリサーブ）
パネリスト：
上田 卓（ソーバル）
大段 智広（豆蔵）
山﨑 崇（ベリサーブ）
参考資料：
http://aster.or.jp/business/testprocess_sg/pdf/ASTER_TPIGuide_v1.0.0.pdf
お悩み1
テレワークに移行してからコミュニケーションが減ってしまい、仕様の理解不足や認識齟齬が発生している
テレワークに移行して生産性が下がってしまった
お答え1
特性要因図を使って要因を洗い出す
→TPI NEXTとテストプロセス関連の要因を紐づける
TPI NEXTのチェックリストと要因を合わせてテーラリングしてみる
お悩み2
システムテストを行っているが、テストケースは秘伝のたれ状態で何をテストしているか分からない。改善したいが周りが話を聞いてくれない
お答え2
- 可能性1：硬直化したお役所仕事パターン
- 対処：仲間を作る、自分が偉くなる
- 可能性2：独善的な改善パターン（社外活動のハシカ）
- 対処：相手の立場の関心事で語る、自分のやりたいことと組織の関心事を整合させる
改善を回す際に、全体観をもって客観しできているか
- 提案内容は相手の関心事に沿った文脈か
- 組織やプロジェクトの制約や前提を考慮しているか
- 相手に寄り添うマインドになっているか
- やりたいことではなく、やることによる価値を伝えられているか
ビジネスゴール⇔ITゴール⇔BDTPI
お悩み3
組み込み業界で結合、統合テストの自動化で書く工程、製品ごとにプロセスがバラバラで無駄が多いと感じている。組織全体でプロセスを作りたい
TPI NEXTは読んだけどよくわかっていない
お答え3
各工程、各プロセスでどんなテストをやっているのか可視化
1. プロジェクトプロファイル
2. 問題の絞り込み
3. アセスメント実施
4. 問題の検証
フィッシュボーン図で問題を整理し、アセスメントモデルを使って視野を広げるのが良さそう
質疑応答
Q. 「プロセス改善前に現場を可視化しようというと「工数かさ増ししているのでは？」 と言われる問題」
A. 怒る/喧嘩するところ。可視化して問題を特定する前に着手すると結果的に苦しむことになる
Q. 社外活動のハシカにかからないようにするには？
A. 正直難しい。かかってしまったら、周りの反応とかからいち早く気付くようにする
Q. テスト改善というとすぐ「テスト自動化」と言われる。それ以前の問題が山積みの場合の説得は？
A. 開発全体で改善するべきところはないか、自動化以前の問題はないか、モデルを使って示す。
イケてないテストを自動化してもイケてないテストが高速化されるだけ。
上位層の説得にアセスメントモデルは便利
感想
どれもあり得そうなお悩みで、お答えも納得しながら聞けました。質疑応答に上がってきたお悩みもこれまたリアルでよかったです。カスタマーサポートのお話でも「本当は何に困ってるのか」を聞くのが大事という話が出ていて、本当の問題は何かを可視化するのがどこの過程でも同じなんだなと思いました。それだけ難しいということですよね。
*1:この文脈でのスパイクって何だろうとつぶやいたら スクラムにおける技術的スパイクの進め方 | Ryuzee.comを教えていただきました
