チームで自信を持つためにチームでアウトプットに触れて対話する機会を増やす/explore-output-and-dialogue

私たちのチームは自分たちの作る製品に漠然とした不安を抱いていました。その不安を可視化してみると、自分たちのアウトプットに感じている課題と向き合いきれていないことに気づきました。そこでチームのさまざまなアウトプットにチームみんなで触れて、個々人の感じてることを対話する機会を増やしてみると、以前より自信を持った製品リリースができるようになりました。その過程と具体的な取り組みについて紹介します。

Transcript

1. チームで自信を持つために アウトプットに触れて 対話する機会を増やす 1 1
2. はじめに 2 2
3. 意見が一致しても 最終的に目指すものが ずれていることがある みんな品質向上を目的にしているけど 個々人の品質のイメージは微妙に異なる　とか 3 3
4. 意見が相違しても 最終的に目指すものが 同じこともある 不具合やストーリーの優先度で意見が割れてるけど 顧客に満足してほしい気持ちは同じ　とか 4 4
5. アウトプットに触れて チームみんなで対話すると 5 5
6. 最終的に目指すものを すり合わせやすくなる それを共通認識にできる 6 6
7. 協力しやすくなって 問題をさばきやすくなる 7 7
8. そして チームで自信を持てる 8 8
9. 今日はそんな気づきを得る きっかけとなった チームの話をします 9 9
10. 自己紹介 名前: 赤﨑 光(@pikazakipika) 所属: 株式会社カオナビ 職業: QA 10 10
11. チーム紹介 PO エンジニア デザイナー QA 11 11
12. 目次 1. 以前感じていた不安 2. 解決策の模索 3. 手ごたえ 4. 拡張 5. 気づきの言語化 12 12
13. 目次 1. 以前感じていた不安 2. 解決策の模索 3. 手ごたえ 4. 拡張 5. 気づきの言語化 13 13
14. 以前感じていた不安 作った機能に不安がある チーム内の価値観の差に不安がある 14 14
15. 作った機能に不安がある 15 15
16. お客様に満足してもらえるか そもそも使ってもらえるのか インシデントが発生し、かえって迷惑をかけないか 16 16
17. 現にインシデントが起きたり 自分で触っていて わかりづらいと 感じることがある 17 17
18. もしかして 18 18
19. 問題がいっぱい潜んでる..？ とくに過去に作った機能 19 19
20. まぁでも 20 20
21. 受入基準通りに作っているし テストしてるし たぶん大丈夫なはず.. 21 21
22. なんとなく不安だから テストする場面が散見された 特にリリース前 22 22
23. 他にも チーム内の価値観の差に 不安がある 23 23
24. 24 24
25. 25 25
26. えっ!! 不具合なのに 直さない..!? 26 26
27. もしかして 27 27
28. チームの価値観と 自分の価値観が 根本的にズレてる..? 28 28
29. まぁでも 29 29
30. チームの理解してる価値 の方が大事だから これでいいはず.. 30 30
31. チームの中で 「これでいい」の基準の差が 埋まらず、意見が割れたまま になる場面が散見された 31 31
32. 不安なことが まあまあ多いぞ... 32 32
33. 今は大丈夫かもしれないけど この先も本当に大丈夫？ 33 33
34. 確信は持てないけど まずそう... 34 34
35. 目次 1. 以前感じていた不安 2. 解決策の模索 3. 手ごたえ 4. 拡張 5. 気づきの言語化 35 35
36. 36 36
37. 懸念があたってると 決まったわけじゃない 37 37
38. 懸念があってるか試してみた 38 38
39. 1つ目のトライ 製品を触る時間を増やす 39 39
40. QAが毎日1時間 すでにテスト完了済みの チケットを古いものから順に 受入基準通りか確かめる 40 40
41. inspired by 忍者式テスト 参考: 「テストからはじめよ」〜忍者式テスト20年の実践 から〜 41 41
42. 名付けて手裏剣テスト 42 42
43. コストをかけすぎかも？ 43 43
44. とりあえずやってみよう 何も出なければやめればいい 44 44
45. 普段のテストで見落とした 不具合やリグレッションが 週に1個くらい見つかった 45 45
46. ユーザーが使いづらい なんなら使えない 可能性も見つかった 46 46
47. その通りだった... 47 47
48. でも繰り返せば繰り返すほど これだけ触ってれば大丈夫! という自信に繋がっていった 48 48
49. 気づきがたくさん出て チームで懸念やあるべき姿に ついて話す機会が増えた 49 49
50. 2つ目のトライ チームの考えを聞く 50 50
51. QAはよく集まって 対話していた 51 51
52. 例えば 手裏剣テスト テスト設計 52 52
53. なんでそれを テストしようと思ったの？ 53 53
54. それをテストしようと考えた理由 そう考えるに至った過去の経験 そのときに感じた感情、など 54 54
55. 予期できない価値観の差を 感じる機会はほとんどない 55 55
56. そんな経験から 56 56
57. チームの価値観は チームに向き合わないと 確かめられない 57 57
58. （再掲）2つ目のトライ チームの考えを聞く 58 58
59. ストーリーの見積もりに 参戦してみた 59 59
60. ストーリーの見積もりでは 受入基準などを見て 不安なことや作るものの イメージが話されていた 60 60
61. QAも同席していたが 議論や見積もりには 参加してなかった 61 61
62. QA目線での不安や懸念を コメントする頻度を 少しずつ増やしてみた 62 62
63. ​この機能で利用者ができるようになることは何か この機能を実装したときに起きそうな不具合は何か こういう導線にしたのはどういう意図があったのか ここも確かめた方がいいと思うがイメージ合うか 63 63
64. 始めは緊張しながらだった 64 64
65. でも意外と 65 65
66. 「たしかに..考慮できてない!」 みたいな声があった 66 66
67. 「こう作るから、安心して」 逆に安心することもあった 67 67
68. 意外とQAの不安は QA以外のメンバーも感じてる ことが多い 68 68
69. 他にも エンジニアはよく モブプロしていた 69 69
70. モブプロに潜入してみた 怒られたらやめよう 70 70
71. 潜入したはいいが 言葉が理解できない 71 71
72. 頻出ワードを拾って どういう意味か聞いてみた 72 72
73. 意外と教えてくれた 今はバリデーションを実装してる ここにテストコードを実装してる など、なんなら画面共有して教えてくれた 73 73
74. UnitTestの テストケースは これでいい？ テストについて質問されることもあった 74 74
75. 価値観はずれてなさそう 75 75
76. ただわからないものを わからないと受け止める姿勢 に差があった 76 76
77. 目次 1. 以前感じていた不安 2. 解決策の模索 3. 手ごたえ 4. 拡張 5. 気づきの言語化 77 77
78. 3つのトライを通じて 少なくとも 自分の不安は減ってきた 78 78
79. 不安はアウトプットに触れ みんなと対話する中で 解消されていった 79 79
80. ①アウトプットに触れる ②みんなで対話する に可能性を感じた 80 80
81. ①アウトプットに触れる？ 81 81
82. アウトプット なんでも。リリースした製品に限らず その途中過程で生じたドキュメントなども対象 82 82
83. アウトプットに触れる 動くものを動かしてみる ドキュメントを読んでみる ドキュメントを書いてみる 動画を見てみる 83 83
84. ②みんなで対話する？ 84 84
85. チームのみんなと 対話するイメージ 85 85
86. PO エンジニア デザイナー QA 86 86
87. チームのみんな 87 87
88. ここでいう対話はお互いの意 見や考えを交換するイメージ 88 88
89. AさんがBさんにフィードバックして BさんがAさんに「承知しました」と言うもの よりは AさんがBさんに「こう考えてるけどどう思う？」と聞いて BさんがAさんに「私はこう考えてる」を伝える 89 89
90. 意見以外の 背景や前提も 90 90
91. ①アウトプットに触れる ②みんなで対話する これをチームのみんなでできれば チームのみんなで自信を持てるようになるかも 91 91
92. 目次 1. 以前感じていた不安 2. 解決策の模索 3. 手ごたえ 4. 拡張 5. 気づきの言語化 92 92
93. アウトプットに触れ みんなで対話する機会を 作ってみた 93 93
94. 1. アウトプットができたときに話す 2. アウトプットを一緒に作る 94 94
95. ①アウトプットができたとき に話す 95 95
96. ユーザーストーリー 受入基準 着手前にチームの代表で眺める時間を作って、 その機能で提供したい価値、差別的要因は何か ​その機能で利用者ができるようになることは何か​​ 96 96
97. コード モブプロに参加して、 頻出ワードを起点に何を実装しているのか あのテストコードがないけどなぜか 性能効率性の懸念はないか​​​​ 97 97
98. テスト環境 チームのみんなで触ってみようと招待して 想定される利用シナリオを達成できるか 過去に検出した不具合の周辺に他の不具合がないか キーボードのみ or 読み上げ音声に従って操作できるか 98 98
99. 気づきや対話が少ないときも。 99 99
100. クイズ形式にする シチュエーションを乗せる 100 100
101. 例: 想定される利用シナリオを達成できるか 101 101
102. 102 102
103. 103 103
104. さらにシチュエーションを追加 104 104
105. 105 105
106. 106 106
107. 107 107
108. 問い合わせ 利用者から問い合わせの中で、 頻繁に問い合わせのあるペインを体感する 体感してみて難しかったことについて話す 108 108
109. ②アウトプットを一緒に作る 109 109
110. テストを一緒に設計する テストしたいことを考えよう！ 何をテストする？ 実装的にはどんなふうに確かめれば安心かな？ このテストは自動と手動どっちが向いてそう？ 110 110
111. テストコードを一緒に書く テストコード一緒に書いてみませんか？ 普段どんなテストを書いている？ このテストで確かめたいことって何？ 111 111
112. 理想の品質候補を一緒に作る みんなが製品に期待する品質をすり合わせませんか？ そもそもみんなのイメージしてる品質って何？ 製品に期待する品質の候補を5つ挙げるなら何？ 112 112
113. 参考：ソフトウェアテストをカイゼンする50のアイデア 113 113
114. みんなのイメージしてる品質を 書き出したもの 114 114
115. チームの作る製品に期待する 品質の候補リスト 115 115
116. 目次 1. 以前感じていた不安 2. 解決策の模索 3. 手ごたえ 4. 拡張 5. 気づきの言語化 116 116
117. チームに起きた変化 なんとなく不安だからテストする、が減っていった リリース前のリグレッションテストのタスク 本番環境へのデプロイ時のリグレッションテスト いいか悪いかの議論で、利用者視点でどう？と問い合う ことが増えていった 117 117
118. チームのみんなで アウトプットを触って 対話するメリット 118 118
119. メリット1 アウトプットに込めた思い 作った先で期待していること が見えてくる 119 119
120. アウトプットそのものへ フィードバックできなくても 120 120
121. 目指す先が見えると それぞれの専門分野の視点で 解決策を提示しやすくなる 121 121
122. その結果、チームとして問題 に対しての解決策が増える 122 122
123. メリット2 早めに問題を 検出しやすくなる 123 123
124. テストコードの不足に 気づきやすくなる 一緒にテストコードを実装して どこにテストコードがあって どこを見ればどのテストかわかるようになったから 124 124
125. 受入基準を達成しても 問題が解消できないことに 気づきやすくなる 問い合わせのきっかけになった利用者のペインを チームのみんなで一緒に体感したから 125 125
126. メリット3 フラストレーションが減っ て、尊敬の気持ちが増える 126 126
127. 自分はやってるけど あの人がやってないこと 対話しなくても見えるかもしれない 127 127
128. 対話すると 128 128
129. 自分はやってないけど あの人はやってること が見えてくる 129 129
130. この人そんなことまで 気にかけてたんだ..!! 130 130
131. それぞれがそれぞれの 大事にしている価値観を 持って製品に関わっている 131 131
132. お互い様 を実感しやすくなる なんなら尊敬できたりする 132 132
133. 理屈として理解するより 対話して、なんなら ぶつかった方が納得できる 133 133
134. 対話機会が増えれば増えるほ ど、尊敬チャンスが増える 134 134
135. あらためて 135 135
136. アウトプットに触れて チームみんなで対話すると 136 136
137. 協力しやすくなる 137 137
138. 問題が小さいうちに気づいて さばける問題の種類が増える 138 138
139. それが チームの自信につながる 139 139
140. この資料を叩きに 意見交換できると うれしいです！ 140 140