Web Service QA Meeting June-2018 第一部

​🕘​ 議事録：Web Service QA Meeting June-2018

6 8, 2018

議題

───────────────────────────────────────────────────────

ディスカッション

「Web Service QA Meeting June-2018　第一部」をトゥギャりました。

雰囲気とかはTogetterで脳内補完してください。

ブロッコリーの記事も読んでください

カルバートのまとめ

───────────────────────────────────────────────────────

19:15 - 19:35

お題1「0からQAチームを立ち上げるまで」

パネリスト：鶴岡 洋子、山本 健

モデレータ：米山 允章

19:35 - 19:55

お題2「キャリアプランとビジョンについて」

パネリスト：柿崎 憲、山本 久仁朗、山本 健

モデレータ：米山 允章

19:55 - 20:15

お題3「テストの生産性について」

パネリスト：柿崎 憲、菅原 史晴、中野 直樹

モデレータ：小山 竜治

───────────────────────────────────────────────────────

お題１．０からQAチームを立ち上げるまで

モデレータ：米山さん

パネリスト：山本さん、鶴岡さん

山本さん：何もないところから、QAチームを立ち上げている。

鶴岡さん：今の会社ではQAが無かったので立ち上げた。

鶴岡：

入社時の状況は、社員数４０人いない程度。

何から着手したかというと、開発者の困りごと、改善点を見つけるというのをやっていた。

マネジメントする人には、QAという仕事はこういうものだよと示した。

会社全体には、かゆいところに手がとどくのがQAですと言っていた。

チケット単位でリリースしていたので、案件ごとにバラバラにリリースしていたのを、日にちを決めてまとめてリリースしたりした。

要求分析とかしていなかったので、上流から入っていったりした。

会議室も個室があるわけではなく、パーティションとかで区切られていただけなので、他の会議に割り込んだり、ドキュメントを整理したりしたりしていた。

山本：

QAに近い仕事は、社長が全部みていたけど、回らなくなったので、自分が呼ばれた。

既存のフローに入ることから始めた。だから、社長がやっているところに入って、一緒にやることから始めた。だんだんまわしていって。

文化がない状態なので、何をして欲しいのかというのを捉えて。

要求されることが多くて、調整したり、その要求に付いていったり、そこを気をつけていたり。

そういうところが苦労するところだったりする。

米山：ロードマップの話とかどうでしょう。

鶴岡：ロードマップなんか無かったです。

米山：自分で立ち上げられるのか、そういうのを聞きたいのかなと。

米山：立ち上げ時に意識すべきことは何？　最初の一人に求められるスキル

鶴岡：

QAとは何をする人なのかを、周りの人に知ってもらうことが大切。

ビジネスサイドの人と絡むので、コミュニケーションも必要。

QAの価値を知ってもらうようにしてもらうのがいいかな。

山本：

QAに対する意識がばらばら。

よいQAと仕事とした人ならいいのですが、QAに足を引っ張られると、QA来るなみたいになるので、

最初の３ヶ月とか、半年でQAの存在感をだしていく。

鶴岡：

QAの本来の仕事でなくても、困っているところを助けてあげる。

山本：

社長の仕事を手助けするために、プレスリリースとか書いていました。

米山：成長させるフェーズ。ローンチした後に入ると、それまでのスピード感が維持できないとか。

山本：

何も相談せずにスピードを落とすと、嫌がられるので。

これぐらい（期間が）必要ですみたいな感じで説明する。

米山：QAを増やすタイミング、二人目をどうとる？

鶴岡：

一人でテストが回らなくなったタイミング。

自分と真逆のタイプを選んだ。

米山：ストレスはなかった？

鶴岡：私は文系より。二人目は完全な理系を選んだので、助かっている。自動テストとか任せている。

山本：スキルとかばらして集めたほうがよい。態度のところは献身的にやってくれる人。

米山：立ち上げることが好きなんですね。立ち上げたら、次に行きたくならないですか？

山本：

転職芸人で話をしているんですけど、だいたい４年ぐらいで転職している。

最初に文化を創っていくんで、思い入れは違いますね。

鶴岡：

その分、勉強しなくちゃいけないので、大変ですし、でも、面白いし。

自分の理想のQAができますので。

立ち上げちゃったので、抜けずらくなったというか。

参加者：１００人ぐらいの組織で新規にQAチームを立ち上げたい。

山本：

１００人規模になっているなら、QAの役割を担っている人がいるはず。

その人の仕事と一緒にやるのがよいのでは。

鶴岡：

怖いですね。この規模でいないとなると、課題がたくさんありそうです。

参加者：グローバル組織のQAチームについて

山本：

海外QAチームとかいたところもありました。玉虫色の解決。

QAは細かい範囲でいかないといけないので、グローバルはやりづらい。

グローバルで一つの基準は炎上するので、やめたほうがよい。

米山：立ち上げようとしている人へのアドバイスを。

鶴岡：こういう公の場では語れないので。

山本：リフレッシュ大切。

鶴岡：追い込みすぎないのが大切。

───────────────────────────────────────────────────────

お題２：キャリアプランとビジョンについて

モデレータ：米山

パネリスト：山本、くにお、柿崎

米山：QAマネージャまでのキャリアプランについて

山本：

位が上がっていくというのは現在は難しいのではないか。

いろいろなポジションを楽しめるほうがいいんじゃないのかなぁ。

柿崎：

CQOは浸透していないように見えますが、私はCQOみたいな立ち位置で仕事しています。

Web系にきたなら、キャリアパスとか関係ないでしょう。自分で作れよと。

いろいろ考えてみたんですけど、ステップアップしていくときって、人に対する影響範囲が広がっていくんですよね。

影響を及ぼす範囲が広がっていくんですけど、それはビジネス、マネジメントよりの話ですが、

QAエンジニアというからには、技術的にインパクトを与えるというのもあるんだろうなと。

マネジメント方面であれば、人数の多さで影響力が決まるけれども、技術的なインパクトもありかなと。

米山：今のキャリアを若いころからイメージできているか。

くにお：

若いころという話がでたので、最初の会社から、今７社目なんですけど。

僕は１～２年で会社変えているんですけど、若いころは同じ会社に長くいると思っていました。

山本：

もともと、別の業界にいましたので、美術系の学校にいました。

子供のころ、アセンブラで遊んでいたので（この業界に）

絵で食べられるとは思っていなかったんですけど。

今のキャリアは、ぜんぜん、想像していなかったですね。

柿崎：

いまのキャリアは想像していませんでした。２０代後半はちんぴらみたいで。

品質管理とか品質保証に関わったのは、SCEというところからテスターのキャリアを始めたんですけど。

そこからこの道に入っています。

（その後）Web系のテスターみたいなところにはいったり。

mixiに入ってから、いろいろな出会いがあって、

自由にやっていいんだという人たちがいて。

いまの自分をキャリアを創っているのは、出会いの中だなと。

計画的偶発性理論というのがあって、キャリアは偶然おきた結果なんだと。

今を大事にすべきという、好奇心をもって物事を取り組むとか。

この先、この分野に強い人に会いにいったり、

この場に来たというのもすごいな。

今後のキャリアプランとしては、マネジメントというところで、中小企業を自分で買って再建したいなと。

米山：キャリアパス、どんなふうにメンバーに見せたらいいか悩んでいる。

くにお：

無理はしない。個人の幸せが大切。

会社の仕事でストレスを感じたら、会社辞めるし。

楽しく思える現場が大切かなと。

スキルアップするにしても、自分が納得する場で仕事をする。

山本：

Webの世界は面白いので、やりたい放題。

美術の世界は制約ありすぎ。

柿崎：

Webの業界は、エンジニアになると、プログラミングでごりごりでキャリアを作れる。

でも、プログラミングによらないと、キャリアはふんわりする。Webディレクターもそう。

問題に対するテクニカルな解決方法を教えて、指導していくんですけど。

自分自ら、内発的な動機があれば、どんどんでてくる。

その段階は、内発的な動機と外発的な動機が切り替わるところがあるから。

一緒に悩むとか、俺ならこうするとか、真摯にテクニカルなところをみせる。

くにお：

（相談に）来る人には教えるけど、自分に来ない人には教えない。

効果が低いことはやらない。みんなを救う気はない。

米山：マネジメントに移ったときに困ったことは？

柿崎：

後から気づいたことが多い。マネジメントはまったく別のスキルセット。

テクニックを使って、チームを率いていた人が、マネジメントに移ってつぶれていくのをたくさんみてきた。

マネジメントって、顔をみたくない奴と面談しなくちゃいけないし、何か仕事をやらせないといけないし、モチベーションを上げるとかわかんねぇよとか。

山本：

部下の評価をできる権限をもらうように。

権限ないのに仕切れとか、信頼関係ががたがたになるので。

───────────────────────────────────────────────────────

お題３：テストの生産性

モデレータ：こやまん

パネリスト：なおくん、柿崎、菅原

こやまん：

Webの世界で、スピードを落とさず、テストの品質も落とさないにはどうすればよいのか。

Webの場合は、テストやろうとしても、プロセス重くなるし、やること増えるし、足引っ張るなといわれる。

でも、スピード感の中でテストをやろうとしている。

テストの価値をどうやって証明しているのか、

合意を取ろうとしている工夫とか、

テストの質とかを保つために工夫しているのではないかということをパネリストに聴こうと思います。

なおくん：

障害件数、本番環境の障害件数は測っている。

我々のQAチームはテストを丸受けしていない。テストは開発者がやっている。

不足する部分をQAチームがやっている。

技術の指導とかやっている。

本番障害件数と、自動テストが要件を満たしているかどうか、要件カバレッジをとっている。

自動テストが壊れていない状態で動き続けているかどうかをみている。

基本的に動いているかどうか。

以前は金額とか、工数とかに換算していたけど、今はやっていない。一時的にはやっていた。

ビジネスアウトカム。

ビジネスアウトカムで評価されると儲かるプロダクトに関わっていたいになる。

生産性指標は誰のためのものか？

経営者と自分たちの共通の価値観。

我々全員にとって、ビジネスアウトカムは遠いなあと。

金額は直接みていない。

腹落ち感が無い。

柿崎：

お金。プロダクトの比率をとっている。

単体でどれくらい使っているからいいかどうかではなくて、

プロダクトのコンディションがどうなのかをお金でみている。

ゲームのテストをやっていたんだけど、売上に対してどのくらいインパクトがあるのか。

欠陥の検出率は大切。

本番と自分たちが見つけたものの比率。

テストのメトリクスとかは、ユニットテストの網羅率とか、いろいろなメトリクスをとっている。

後からメトリクスをどのように解釈するのかが大切。

信頼度成長曲線を使って経営陣に説明したりしている。

売上が落ちたとき、品質が悪くて、メンテ祭りになったりしていたときに、僕はこの会社に入っていったので、

お金で、テストの価値というのを示している。

変化を、メトリクスをたくさんとっている。

こやまん：売上に対して、テストの貢献度合いは？

柿崎：

純粋に僕がガバナンスを効かせたら、リリースしたら即やばい、メンテだなんだという状態だったけど、収まった。

後は、新規リリースのものは、リリース直後にこういうのがきますと信頼度成長曲線で説明した。

超重要なバグは取れていますよとか、そういうコミュニケーションの結果とか。

バグの重要度とか、リスクとかが埋め込まれないようにしていた。

リスクの度合いとかは取っていた。

１日に２０件ぐらいバグがでているなかで。

軽量なメトリクスを継続的にとるのが大切。

あるとき跳ね上がるときがあって、チームにいってどうしたっていうコミュニケーションをとっている。

菅原：

３つのプロダクトがある。日米英。

オートメーションQAチーム。日ごろ、End２Endのコードを書いている。

生産性を測るというのは特にやっていなくて、

いまのところ、何かを図るというのは行っていない。

何かを入力するとか、そもそも何かを入力する行為が生産性を落としているわけで。

要するにですね。マネージャのための仕事が一番嫌い。

こやまん：自分たちがやっているのが正解だって言っていない？　対外的に説明はどうするの？

菅原：あんまり考えていない。

柿崎：

ダメだししたいんだけど。

お客様に価値を提供する取り組みをしているんじゃないか。

テストの生産性をテストだけでみちゃいけない。プロダクトのライフサイクル全体でみるべきだと。

お客様にささる機能は何かと、半年間の中で、施策を取り組めるというのは指標なはずで．．．

こやまん：

熱くなってきたところで、第二部に。