C-7 テストの完了をゴールにしない！～仮説検証を繰り返し、開発・QA・ユーザーが交流しながら開発することで見えてくる理想の姿～

デブサミでメモしたことをつらつら書いていきます。

こんな経験ありませんか？
　機能開発したけど、本当にユーザーの解決したいことにつながっているか分からない

機能開発の時にアウトプットを意識しがち
　アウトカムを意識するべき

本発表でお伝えしたいこと
　・「一般的なテストの完了＝ゴール」ではないことを実感してもらう
　・テストの側面から、アウトカムの獲得を試みる
　・テスト活動に用いた、アウトカムに繋がる事例を紹介する
　・QAも含めた開発チーム全体でステークスホルダー（特にパートナー）と向き合って開発を続けてきた事例を紹介する

テスト完了をゴールにしないとは？
　テストはフェーズじゃなくて、アクティビティである

アウトカムに繋げるためのテスト活動とは？
　・継続的テストモデルの考え方を用いる
　　コード実装後にテストするだけでなく、設計段階からテスト活動を行う（シフトレフトテスト）
　・コード実装後、デプロイ前にテストするだけでなく、デプロイやリリースした以降にもテスト活動を行う（シフトライトテスト）

シフトレフトテスト
　TDDやDDDよりも前の話
　PlanやBranch時点でのテスト

スリーアミーゴスの考えを用いる

修正後の受け入れ基準
　とあるメソッドが注文締切時間前に呼ばれているので対応する
　QAが「アプリの振る舞いで言うとどれ？」と、3つの立場の人が集まると問題の本質に気づくことがしやすい
　メソッドだけの修正では内容がわからないので、何をもってタスク完了なのかはっきりするようになった

シフトレフトの活動を行うと良いこと
　早い段階で行うべきことがハッキリしていると、バグが混入されづらくなり、追加コストが不要になる
　・バグチケットの起票コスト
　・開発内容を思い出すコスト
　・修正するコスト
　・もう一度テストするコスト
　・関連部分にデグレードが無いか確認するコスト
　・起票したバグチケットを完了にするコスト

シフトライトテスト
　リリース後にあるテスト

今回の事例の対象
　・注文変更の締切時間の前の場合、パッキング画面に「完了」ボタンを押した時にエラーにする。かつ、エラー表示した後前画面に戻る。
　・注文変更の締切時間の前の場合、パッキング画面で「完了」ボタンを押さなくても15秒後にエラーを返す。かつ、エラーを表示した後前画面に戻る。

　疑問点
　・注文の締切時間の前に対象画面を開く頻度はどれくらい？
　疑問点の検討
　・15秒に1回エラーを表示している
　・対象画面を開く頻度が高いと、業務の妨げになる
　・どれくらいの頻度で開いているか見当もつかない
　ログを仕込んだ状態で1回リリース
　・ログを仕込むだけの差分でリリースする
　・リリース後に、そのログがどれだけ出たのか調べる
　　ログが頻発する
　　　今回の修正を入れると業務の妨げになる
　　ログが頻発しない
　　　今回の修正を入れる価値がある
　効果が高ければ差分リリース
　　ログを仕込んだ場所に今回の修正を入れる

計画的にログを仕込み、効果が高そうか確認する

進め方の注意

　・闇雲にログを仕込まない
　　ログがいっぱい出てくるね、どうしようってなっちゃう
　　わからないから指標を決めるためにログで吐いて結果を見る
　　その前段階から検討して試す
　・適用範囲を絞る
　　Feature Flag（Toggle）による適用範囲の指定
　　特定の対象に絞って適用した場合に有効
　　段階的リリースによる適用範囲の制限
　　少数の適用範囲で試したい場合に有効（カナリアリリース）
　　ABテストによるランダムな適用
　　現行と改善案のどちらが優れているか統計的に調べたい場合に有効
　ABテストとFeature Flagやカナリアリリースは混ぜないほうがいい
　ABテストは統計的に取りたいから他を混ぜると効果がぼやける

実際のオペレーションの様子を観察する
　最適なオペレーションを実現するために、プロダクトがどうあるべきか認識することが重要
　プロダクトで解決しないことも含めて認識

現場リサーチという取り組み
　いわゆるフィールド調査やユーザーインタビューをミックスした形式

現場リサーチの様子

現場リサーチで見えてくるもの
　運用でカバーしている点
　　・アプリでは解決が難しいものも含む
　　・プロダクトの仕様やプロダクトに残るI/Oのデータだけみても、極めて断片的な理解・情報にしかならない
　　・現場の工夫でシステムじゃ見えない運用でカバーしている場合がある
　リサーチした店舗特有の課題点
　　・同じパートナーであっても、店舗によって課題は異なる
　　・店舗特有の課題は無理に解決しない
　自分たちが開発した機能がどのように使われているか
　見つけた気づきを次のアイデアの源泉、開発に繋げる

現場リサーチで気づいた例

現場リサーチで得られた知見を活かす

現場リサーチで得られる副次的な効果
　よりアウトカムが意識できるようになる
　・一般的にお客様からくるお問い合わせのほとんどは、現状のアプリで不便だと認識している点
　・以下の点はお問い合せからは分からない
　　お客様が便利だと感じている点
　　お客様が暗黙的に不便だと感じている点
　問い合わせは来ないけど、不便だと感じてる場合がある
　
　実際の使われ方を見ることで、よりリリースに意識が向く
　・「機能を作って終わり！」と鳴らなくなる
　・「どうすればいかに早く、いかに効果的にリリースできるか」を考えるようになる
　実際の使われ方を見ることで、価値を提供できてないとかがわかる

ユーザーと協力して、実際にオペレーションが問題なく進行できるか確認する
　分割リリース
　　1回目
　　　実店舗に開発したアプリを持ち込んで、自社社員が擬似的にピッキングを試した
　　　問題なくオペレーションが進行するかの確度を高めた
　　　大事な観点は業務遂行性
　　2回目
　　　スタッフ研修に同席した
　　　パートナーが運用を問題なく進行できるかの確度を高めた
　　　機能理解・オンボーディングにかかるコストを確認した
　　　大事な観点は業務遂行性・習得性・運用操作性
　　　　フローが回るのか
　　　　多少の計算ミスなどは目を瞑ってもらう
　　3回目
　　　正式リリース
　　　実店舗で実際に活用いただく
　　　大事な観点は業務遂行性・習得性・運用操作性・機能正確性

分割リリースのよかったこと
　パートナーのフィードバックを貰いながら調整できた
　パートナーの機能理解度が高い状態でリリースできた
　　新機能に対してビックリしない
　「オペレーションを効率的かつ確実に行う」というお届け領域の特徴を損なわないようにできた
　リリースから数ヶ月経過しているが、この機能に関する障害発生0件！　お問合せも数件！
新機能に対してびっくりしない状態（理解度が高い状態）でリリースすることが大事

重視した品質について
　品質特性や狩野モデルなどから単に引用する形ではない
　・今回は議論した上で当てはめてみた結果
　・議論せずに単に引用だけすると、それっぽく聞こえるけど何も表現できていないものになってしまうかも
　「当たり前品質って重要だよね！」
　　何がプロダクトにとって「当たり前」なのか？
　経営チームも含めた自分たちで品質を定義する
　　最も大きなGapは「保守性」であるという結論になった
　　「保守性」を更に深掘りしたら「運用自律性」や「システム運用効率性」、「テスト容易性」などの独自のキーワードが浮かんだ
　独自の用語で品質をキャッチアップしていくこと自体が品質に向き合う第一歩で重要なことと気づけた