おことわり
- 最初から参加することが出来なかった＆携帯でメモしていたため、発言者や発言内容が合っていない可能性があります。
- ご了承下さい。
お題1
- テストマネージャは何が重要なのか
小山「知ること ※ただし制約の中で」
- そして知らせることも重要
佐々木
- 調整の方法は？
小山
- 知りたいことって何か？というスコープマネジメントする。ヒアリングをする。
- 事前にネゴっておく。
佐々木
- 明日リリース判定でダメだよというときは？
小山
- これだけリスクがあるのでオススメしませんと言う
- 信頼して貰っているのが大切
中野「チームの柱…ではなく、テストの答えを持つこと。」
- 第三者的視点で見れること。
佐々木
- こんなん教科書に載せられない。「リファレンスとか」とはなんなのか
湯本「ブレない心。対等に渡り合う精神力。メンバーがやっていることが正しいと信じること」
- テストが最後の砦になりがちな所なので、元々と変わってくる。それで残業が増えたり…。
- そこで変わってくるのはおかしいと言い張ることが大事。
佐々木
- もっと具体的な話が聞きたい
長谷川「説得する材料はどんなものがあるか」
- いつ何を聞かれても、テストプロダクト状況を説明できる
- メンバーにはテストに集中させて、常に説明できること
湯本
- アカウンタビリティーとか言われるところ
佐々木
- どうやってその説明する材料を集めるんだろう？
長谷川
- テストの状況をなんでも、というが、その中で何が大切だと思うか？
- テストの何%とか本当に聞きたいんですか？
経営層なのか開発陣で説明する内容は異なる。
- テストリソースの話なのか、テストしないことのリスクの話なのか？
最終的には経営層がジャッジするので、出荷をどうしても止めるということはない
お題2
- テストメンバーに今回のテストの1週間頑張らなくちゃいけないとき、どういう説明をするのか？
- だいたいステークホルダー側の話になりがちだが、現場の人にどのように伝えるのか？
小山「ゴールの話」
- ゴールを達成するために困ったことが無いか
- 人って目的とかゴールとか分からないまま進みがち。
佐々木
- スケジュールだけでなく、内容を把握して説明している
湯本「なにをどこまでやれば終わるか。可視化、残テスト数、バグ数…」
- 朝礼とかでやることを全部話して、目標達成したら喜び、達成していなければ残業したりする。
- その可視化の情報に嘘を含めないようにお願いする
小山
- メンバー信用してないじゃないですかー
湯本
- 基本的には信用してるよ。それでも間違えることがあるから
佐々木
- 計画通りで、ではなく優先順位をつけて朝会でやるって重要なこと
神田「I message ヘルプミー」
- 緊急事態が発生したときは何をすべきか、やりたいことを伝えて、みんなで考えていく
佐々木
- みんなに嫌われずにいることは大事
- 黙ってやるのではなく、共有することが必要
長谷川「平鍋さんから聞いた話『スコアボード』」
- 9回2アウトの時に、みんなが走れますか？
- ステークホルダーもテストメンバーも同じ状況を理解して走り出せますか？
佐々木
- 進捗とかがエクセルにまとめられて「ここに置いてあるから見てね」と言ってませんか？
- かんばん方式とかみたいに、見える場所にあることが重要
お題3
- テストマネージャーはテストプロジェクトを成功を導くたまにあらゆる活動を実施する。
- そのためにテストプロジェクトを成功に導く秘訣を話しやがれ。当然その理由も説明しやがれ
- テスト計画ではここを注意しようとか、テスト実施時にはここを注意しようとか。
中野「逆算のイメージ。」
- 自分の中で計画もそうだが、実際のリリース日から逆算してイメージとの乖離を照らし合わせる
- 数値だけ見てると多分違っている。メンバーの疲労度とか
佐々木
- 自分だけ？チームメンバー全体が持てているか？
中野
- 共有はするが、自分が一番見えているはず。詳細までは共有してない。
佐々木
- スケジュールを立てる時は足し算して期間が無いから頑張って圧縮しがち。
- そうではなく、引き算をできると、要素を理解しているはず。答えから引いていく。
中野
- 答えから引いてくるとは？
佐々木
- 全体で40とか見えていないと逆算出来ないですよね？
- 積み重ねて終わりではなく、工程が結果に繋がるが、結果を見えてないといけない。
小山「完全性。※データの整合性」
- テストの成功ってなんだ？と悩んだが、5Wをしっかり残すことが成功だと思っている。
佐々木
- 現状の品質を知りたいという場合もあるが、出荷できる状態を示すことが必要
小山
- データが残ってないとやり直しになっちゃうので、ちゃんと残しましょうということ。
佐々木
- 一番最初から考えておかないと、説明は出来ないですよね。残っているデータから状況を管理しておく。
- そして、すぐに戻って管理しておくのが重要。
長谷川「テスト実行に入ったら自分達が主役。バクが直らないなら直せるようにしてあげる。」
- これをさせてもらえる伝達をする
湯本
- テストを終わらせるには最終的には開発者が直して動くようにならないといけない
佐々木
- 検出率はよく出されたりするが、修正率は出していますか？そこで修正率が高い人は能力が高い。
- これをマネージャーがリードしてあげる。重箱の隅をつつくと、開発者が「もういいよ」とモチベが下がる。
- どれぐらいバグがあるか求められたらいっぱい出すが、そうでない限りは、その方法はしない。
湯本「計画時と実行時で秘訣が異なる」
- 計画時①…必要なものの調整。特に自分達で出来ないこと。
- 環境とか。
- 他社とのネゴシエーションとか。
- 貰ってくるデータとか。
- 計画時②…ゴールの握り。
- 品質的なゴールとか。
- 実行時①…正直になる。
- 実行時②…バグの修正を停滞させない。
- 実行時③…他テストレベルのと調整。
- 「これだけ品質が悪かったら単体テストをやるべきでしょ？」とか
佐々木
- なんかまともな回答ですね。
- 他のところも見なくてはいけない。
- 正直になることだけでなく、嘘をつかなくちゃいけないような環境を作らない。
- 「オンスケです」と嘘を付いていると、8割ぐらい終わってからダメだとなる。
神田「臨機応変、ブレないゴール。」
- 計画時点でゴールを握るが、基本的には線通りに行かない。
湯本
- WBS通りにはだいたい行かない。
神田
- その時の臨機応変に合わせて小さなゴールを決めたりする。
お題4
- テストマネージャーは日頃から研鑽しているはず。
- 後輩のお手本になるためにどんな努力をしているのか話しやがれ。
小山「とりあえずやってみる。※興味を持って楽しむ」
- とりあえずやることが大事
佐々木
- やってみるのは重要。
- メンバーに働きかけるだけでなく、自分でもやる。
- 失敗したからダメだではなく、その経験を使ってフォローしてあげる。
神田「社外→社内」
- 10年前にjasstを知って、全国回った時は、それをすぐに実践したりしている。
長谷川「JSTQBシラバスを読んで自分のものにする。」
- ラーニングオブジェクトを読む。オプションが変わっていく。
- 自分の実力を知る。
中野「開発を学ぶ。」
- WEB系は組み込み系と違って分かりやすいので、学ぶことが大事。
- なんとなく経験で工数を増やそうか、ではなく、実際に学ぶ。
佐々木
- テストって開発をどれだけ知っているの？とかはこれだけで1テーマになる話題
湯本「テストの知識は必要。（JSTQBのTM）」
- 大事なのは、良いエッセンスを自分のところに適用させる。
- 多くの人と協同で仕事をする訓練をする（WBSのような上っ面の部分だけではなく。）
- テストマネージャーに限ったことではないが、いつも考えてトレーニングにするとか。
実行委員からのフィードバック
- 神田さんへ…組み込み系をやっているので共感できる
- 湯本さんへ…とにかくすごい。多くの人を動かしている
- 小山さんへ…私もMなんだな。みなさんも是非やってほしい
- 中野さんへ…逆算するイメージが出来てないことに気づいた
- 長谷川さんへ…コメントを断言できているのがすごい。
MVP
- スコアボードの話がMVP。
状況を全員に伝えることの大切さを感じた。
今の状況を共有する、嘘をつかずに言う。
うわべだけの共有になってないか気をつける。
打ち合わせをやっていても中身が無ければ意味がない。
