Rakuten Commerce QA Night#1 のこと
2019/04/24。仕事終わりに二子玉川まで行き、こちらに参加させてもらった。
Automation Testing for Leisure Service
エンジニア時代のテスト自動化の（苦い）経験をふまえ、QAとして心がけたことを発表されていた。うまくいかなかった→ではどうすれば？という思考の流れがよくわかり、とても参考になった。
- 気をつけたこと。自動化のスコープ、目的の明確化、保守・運用設計。
- テストのマトリクスをつくって自動化しない部分の明記、CI条件などを共有。
- チームにあったツール選定を心がけた。
ここからは質疑での話。
- ツールはある程度絞ってメンバーにさわってもらい選定。Ranorexを利用している。
- チーム立ち上げから自動かまでは、数日かからず。
- Jenkinsは3分くらいで終わるジョブが150ほど。
- プロセスはウォーターフォールっぽくやっている。
Test Automation at Rakuten Travel
Testcase generationの部分、graphmlを知らなかったのでどういう理屈でテストケースが生成されるのかちょっとついていけなかった…。
Rakuten QA group and Automation team
ISTQB（JSTQB）によってQAの共通言語を得ることができる。って手元のメモに書いてあったけど、この時の自分は何を思っていたのか。
Rakuten QA Group Introduction & Best Practices
WebエンジニアからQAになった方のお話。 3つの視点でベストプラクティスを紹介されていた。
可視化 Visualization
- JIRA Kanban＋ホワイトボード
- 日々の朝礼
文書化 Documentation
- 機能・サービス関係図
- テスト観点表
- テスト実施ルール
- 英語で書く
- Prj終了時に1, 2日かけて分析しながらノウハウを残す
- ノウハウは整理、更新をしてアクセスしてもらえるようにする
コミュニケーション Communication
- 「しっかりテストする」とは
- テストはバグがあることの証明。ないことの証明はできない。
- Shift left（上流工程から関わる）。開発部門へイチャモンをつけるのではなく情報提供するような立場で接する。貢献する。
- 開発とQAの違い。QAはたとえばデート前にチャック空いているよ、を行ってあげる人。QAの仕事をバグ出しとしてしまうと開発部門との関係が良くなっていかない。
- QAの仕事は手抜きできてしまいやすいからこそ、日頃の声かけが信頼関係につながっていく。
思ったこと
- QAの果たすべき役割、目的を明確にして仕事に臨んでいることがよくわかった。
- Shift left。かっこいい言い方なので使っていこう。ちなみにQAの工数でやるんだろうか。開発チームに取り込まれてなあなあにならないよう距離感大事かもしれない。ノウハウを提供する立場、というのはほどよい距離感な気がする。
- 楽天の社会的な影響力も増してきているなかで、各サービスにおけるスピード／品質へのバランスも変化してきているよう。
- 英語のプレゼン聞けるのすんごい貴重。ありがたいです。
- 英語の聞き取りはまあまあできたけど、ほんと聞くだけになってしまった。聞きながらあれこれ考えたりできない。
- 日本語ネイティブの人の話す英語プレゼンも聞きたい。
Cookpad TechConf 2019 のこと
イベント
メモ
クックパッドが目指す、これからのデザインとプロダクトのあり方
- BTCモデル
- Business、Technology、Creativeはつなぐものではなく重なり合っているのでは
- Figma
- 全員でデザインを作り上げる時代
生鮮ECクックパッドマート - サービスの立ち上げから拡大に向けて
- Google venture の Design sprintの手法を利用
- ２〜５日といった短期間でチームでソリューションを検証
- 難しい課題ほど向いている
- ストーリーボードをつくりプロダクト体験全体を検証
料理の学習体験をデザインする
- 多くの人が求めていることは「手元にあるものでぱぱっと」であるとわかった
- 発想力
- 必要十分のレベルを定義（五法の表）
- 料理を素材、味付け、調理法に分解すると発展する
- 具現化力
- 切る、下ごしらえといった工程は共通している
- ひとつひとつは小さく覚えやすい
- 上記の仮説をカードをつくって検証した
新規サービス開発を加速させる技術とデザイン
- Figmaが便利。Sketch, abstract, zeplin, …から乗り換え
- LottieでJSONからアニメーションを実現
- エンジニアの負担をふやすことなく、デザイナー側で実装まで完結できる
- デザインデータのReactcomponent化
- Doczを利用してコンポーネント仕様書を作成
Challenges for Global Service from a Perspective of SRE 2nd season
- 71カ国、26言語での展開
- 9400万人の月間ユーザー
- 日本のサービスとグローバルサービスは別
- 開発拠点はUKのブリストル。100名程度のエンジニア
- Conway’s law
- Partial release in production → Feature toggle
レシピを解析する！Machine Readable Recipe（MRR: 機械可読なレシピ）の開発
Re:silience から始めるカオスエンジニアリング生活
- envoyを使って Fault Injection testingを実施
- Known Unknownsを潰していく取り組みからはじめている
基調講演
- 「毎日の料理を楽しみにする」
- からだは食べたものでできている
- 頭でわかっていても、実感している人は少ない
- 妊娠、子育てを通じて食べ物への意識を向けざるを得なくなる
- 世界で健康な人を増やす
- 食卓をうむことで豊かな時間をすごす
- 食の工業化による環境問題への対抗
- 地産地消の促進
- よりよい社会をつくっていくこと
- 食と料理にまつわる社会課題マップ
- 料理を楽しみにする
- 楽しいことは自発的に継続されていく
- 「毎日の」の意味
- 必要にせまられて仕方なくやっている人が多い
- 問い：料理を楽しみにするものは何か？
- よい食材が手に入ると楽しみになる（Komerco, Cookpad mart）
- スキルが身につくと楽しみになる（TV、たべドリ、Do（教室））
- Cookpadの取り組みに反してゴールは年々遠ざかっていっている
参加してみて
- どのサービスにおいても仮説・検証マインドが根付いている。
- 問題の設定がうまい。ので、解決に注力できるんだろうなと。自分のとこだと問題がモヤモヤしていて時間は過ぎるわ不安感は残るわという場面多い気がする…
- 実際のところはわからないけど、自分の仕事と会社のミッション、社会課題がリンクして実感できていそうでシンプルにいーなー。
- 懇親会すごい豪華。ごちそうさまでした。
- iOSエンジニアの方、ユーザ系のSIでデータ分析されている方などから苦労話、前向きな話を聞けて学びが多かった。
DeNA QA Night #2 のこと
イベント
資料
http://jasst.jp/symposium/jasst17tokyo/pdf/A7.pdf
メモ
品質管理部について
- システム本部 QC第一グループ
- 180名程度
- 新規案件
- 運用案件
- LQA（言語QA）
- 内製チーム（アルバイト）
ゲームQAの上流工程での品質改善について（山本さん）
概要
- 不具合多発で開発、QA共にコストが増加
- 並行開発だったためリソース不足、成果物のセルフレビュー不足
- QAメンバーが開発に入って検証開始前に成果物レビューを実施
- 一定の効果を得た
背景
- 運用中のアプリ
- 実際の暦と連動するのでリリースをずらすことは難しい
- 開発はひとり
- コピペ対応で作業していることが多かったので、書き換え漏れのバグが多発
施策紹介
- インクリメンタルにできたものからQA側がレビューしていった
- 早期指摘で開発に学習を促した＆手戻り負担軽減
- 開発の負荷を分散
結果
- 約4人日の工数削減
疑問（業界違うからか初歩的なことがいろいろわからん）
- もともとレビューって誰がやるもんだったんだろ？開発ひとりなんじゃ？
- レビューって言っているのはテストのこと？
- スプレッドシートをアップすることは開発なのか？定型の運用作業に聞こえる。
- 整合性チェックについて仕組み化していこう、みたいな話は出なかったのかな？
自分のとこだとどうだろう
- 前行程の品質が悪くて結合テストが一向に進まないのはよくある。
- 結合テスト前に受入テストを実施
- 開発中であれば中間品質検査をして品質の良し悪しの要因を探る。たとえば、人依存なのか機能の難易度なのかとか。
パネルディスカッションオープニング（西さん）
我々はどこに向かえばよいのか？
- ちょっと昔と同じQAをすると概ね失敗する
- クソCHAPDコントロール（！）
- 昔からのよい考え方を変化・進化させる
自組織のQAを進化させよう
- 優れた組織イニシアティブの創出や醸成
- 経営TOPは品質についてなんと言っているか？
- 品質向上は成果物の質、組織能力、人間らしさを高めていくこと
- 品質保証はみんなが品質向上へ意識を向けるような仕組みづくり、文化を作ること
- 品質保証戦略のデザインと着実な積み重ね
- サービスやチームのコンテキストや成長の過程に合わせて品質向上施策をデザインする
- みんなが嬉しくなる品質マネジメントシステムの構築
- 組織構造、評価制度、組織的振り返り、ツールや環境の構築・整備などを行う
まとめ
- 品質保証は組織を賢くするためにあらゆることをするクリエイティブな組織
パネルディスカッション本編（河野さん、奈良さん、西さん）
- 品質管理手法
- 考え方は知っておいた方がよい。統計を使おうとしてもソフトウェア現場では役立たない。
- コンサルにだまされないようにするために知っておいた方が良い。
- 品質管理図
- バーンダウンチャートは使えない状況もある
- なんにせよテストがどんな状況にあるかを答えられる仕組みは必要
- V&V
- 工程とあてはめて自動化できているところ、これからするところなどを整理する
- SWETが次に何をやるべきかに関わってくる
- 探針・信頼度成長モデル
- コンサルにだまされないようにするために知っておいた方が良い。
- いまのコンテキストだとテスト期間が短すぎて統計処理とあわない
- 規模（LOC、FP）ベースの品質マネジメント
- メトリクス（GQM）、品質特性
- 数字の一人歩き、QMSおじさんは無意味
- 何を把握したくて何を測定するのかというデザインは意味がある
- Web界隈では数字ベースの話が少ない気がしているので意味のある数字は必要。
- GQMは難しいが重要
- 品質保証は開発者よりも頭を使う必要がある
- 何のために数字とっているのか？に答えられないことが多い
- そういった指摘自体もらえる機会が少ないのかもしれない
- ソフトウェア工学
質問
- クソCHAPDコントロールをやめたい
- 小さいチームでこっそりやっていく。隣のチームへ広めていく。
- 技術のわかる人が役員にいるかどうかもカギ。
- 自分がコンロール聞かない場面でも仲間をつくりながら取り組んだ経験は転職でかなり有利
- 勉強会は複数人で参加すると持ち帰って実現しやすい
- ひとりで始めてまわりに押し付けず注目を集める。過去に夢破れたいちいち文句言ってくる人が協力してくれる。
- ここのストーリーの妙な具体性すごかったな…
- 小野さんのこの話を思い出した。
SIについて私が思ったこと。そしてSIerにおけるモダン開発について : 小野和俊のブログ
「『いいな』と思えるやり方を広めて、成功して、そのやり方のファンが増えて、ファンがまたインフルエンサーとなり別のファンを増やして、結果的に会社全体が良くなっていく。」
- 次の時代のQAが身につけるべきスキルとは
- 提供しているサービスが何を実現したいのか、どういった社会問題を解決しないといけないのかを考えないといけない。
- 開発者よりも先取りして変化を察知して、どうQAするのかを考えておく。
- 自社でしか通用しない技術・知識は役に立たない。どこでも通用する技術を身につける必要がある。
