こんにちは！TECH Street編集部です！
今回は３社のQAエンジニアが集まり、実際の実務で得た知見や、課題、改善策などを共有しあうQAエンジニア勉強会の様子をレポートいたします。
登壇者はこの方々！
くぼぴーさん
吉次洋毅さん／パーソルキャリア株式会社
谷平 純一さん／株式会社セゾン情報システムズ
早速くぼぴーさんの発表からご紹介いたします！
プロジェクトにQAが参加するとどうなるか
くぼぴー：今回はQAが初期から参加して一緒に開発するという経験が社内で一度もなかったところに、私が初めてQAエンジニアとしてプロジェクトに参加したときのことをお話いたします。そして、その際に起こったことや、改善できる点を共有したいと思います。
プロジェクトの流れ
プロジェクトの期間は３〜４か月程度で流れは以下の通りです。
①キックオフ
②仕様検討
③実装
④検証
⑤本番リリース
プロジェクトはアジャイル的な進め方ではありますが、スクラム開発の手法ではありません。
①キックオフ
プロジェクトの大まかな仕様や目標を決めます。QAとしては、必要な最低限の機能や回避すべきリスクについて質問し、提案することでリスクを洗い出していました。また、QAが率先してプロジェクトを盛り上げ、心理的安全性を高めるために、積極的に意見を出す雰囲気作りも重要だと考えています。
②仕様検討
③実装
実装の方針やセキュリティ、懸念事項などを検討し、解決していきます。QAとしては関連する部署（SREチーム/CSチーム）と連携し、問題点を洗い出し、具体的な例を示してエッジケースを考慮しました。また、仕様ドキュメントをQAチームで作成・メンテナンスできるようにしました。
仕様検討と実装の段階で、ヘルプページも同時に考えました。CSチームと協力して草案を作成し、運用イメージを共有しました。ヘルプページにはユーザーが迷わないために必要な情報や使いやすい画面設計などを反映し、単体テストやコードのレビューもQAができる限り行いました。
コードの品質はバグの発生率や開発速度、問題解決の予測精度に影響するという研究結果もあります。そのため、QAエンジニアとして私たちは品質管理に重点を置きました。開発者との密なコミュニケーションを図り、共通の目標と基準を確立しました。また、テスト自動化やコードレビュープロセスの改善にも取り組み、品質向上に貢献しました。
④検証
⑤本番リリース
検証は、テスト計画の策定、テストケースの作成、実施、結果の分析などを行いました。バグの早期発見と修正、品質の向上を目指し、テストカバレッジを高めるために努力しました。本番リリース前には総合的なシステムテストを実施し、問題のない状態でのリリースを確認しました。
本番リリースに向けてシステムテストを実装します。特に問題になるのは「本番環境で動かない！」となることなので、本番に近い環境を用意してもらいデプロイして動作確認を全員で行いました。
”全員”とは開発メンバーはもちろんのこと、QA/SRE/CS/PRチームなどを巻き込んで機能自体のバグと同時に機能の認識齟齬、実装ミスなどがないかを確認していきました。
今回はサーバーサイドのリリースをしたうえでフロントエンドのリリースを行えば良いだけだったため、フィーチャーフラグ的にリリースを行うことができました。またリリースフローを整備していたので適切に機能リリースと、平常リリースを分けてリリース作業を行うことができました。
QAが参加して良かったこと
ここからは実際に私がプロジェクトへジョインして良かった部分をお伝えします。
・過去データの洗い出し/テストケース作成ができたこと
過去データを利用して新たなデータを作成する機能であったために、クレンジングされていないデータではバグが発生する可能性がありました。例えば5年前のレコードでは入っているが、今は使っていないデータなど可能性は多岐にわたり、人間が認識できるレベルを超えていました。そのためデータに規則性があったので、あるパターンを元に過去数万件のデータをマスクして取り出してテスト検証用データとしました。
・ドキュメント作成
これまではドキュメントを作成しながらプロジェクトを進行したことがなく、チームが解散したあとどこの持ち物かわからない、かつドキュメントも残っていないという課題があったのでドキュメントを格納できる場所を用意して、出てきた案や懸念点などをそこに集積できるようにしました。
あらゆる場所にフロー情報が発散される（Slackなど）と、認識齟齬が発生するのですが「結局、それどうなった？」は格段に減ったと思います。時系列にまとめていたので、それも良かったのではないでしょうか。
・デイリースクラム/随時検証
検証は一気に行わず、できるところから進めていき最終的にリグレッションテストをおこなっていました。これにより「何ができて何ができないか」が日毎に明確になっていき、スケジュールに遅延が起こりそうといった見えない危険に気がつくことができました。
・実例マッピング/他部署連携
実例マッピングでは具体的なユーザーストーリーを作成して問題点を検討することが出来、新機能を構築するための許容条件の判断（=受け入れ条件）に役立ちます。
他部署を集めて実例マッピングを行うことで「これだけはできないと本当にまずい」ということが共有できて実装後に巻き戻ることがありませんでした。
また実際に運用するであろうCSチームの理解を早期に得られたことが非常に大きな功績でした。
・ストッパーになれた
随時検証していく中で、このままではまずいのではないだろうかとアラートを素早く投げることができました。具体的にはここまで機能を検証しきれていないので、スケジュールを後ろ倒ししてほしい、というアラートを全体に投げることができました。結果としてスケジュールは遅延することになりましたが、障害レベルの不具合が起きずにリリースすることが出来ました。
やれば良かったこと
やれば良かったこととしては3つあります。
・スクラム開発
初期からスクラムイベントの実施、またスプリントゴールを設定して何が出来て、何ができないかを週ごとに明確にしておくなど重要だと感じました。というのも検証段階で何を検証したらよいかパッと見分けがつかないからです。それぞれの認識に齟齬があると「えっこれってできてると思っていた」となると最悪でした。
・動くものを素早く検証する
機能を単一で動かせるような実装をした後に負荷検証を行ったインフラ環境と統合して確認できるといいなと感じました。一気通貫で作りたくなる気持ちはわかるのですが、まずは単一で動くものを用意して、アジャイル的にステークホルダーへ見せていくというのが大事なのだと思いました。
・単体テストケースを設計する
単体テストケースは完全に開発メンバーにお任せし、レビューを行っていたのですが、一部確認できなかったり設計自体にきちんと意見を言えたり出来なかったと反省しています。
コードリーディングスキルと、単体テストの技術が必要なので、そのあたりもQAとしてはきちんと身につけていなければいけないと感じました。
まとめ
プロジェクト進行を横断して見られて、すべての時間軸で存在できるQAならではの動き方はもっとあるな、という反省の多いプロジェクトでした
QAエンジニアはプロジェクトのオーナーになるつもりで、イニシアチブをもって進行役ができるともっといいだろうなと思います。
また一部分だけアクターとして見るのではなくQAとして俯瞰して見ることが、QAエンジニアの役割として求められていると思います。
続いてパーソルキャリア 吉次さんの発表を紹介いたします！
QAエンジニア組織立ち上げはじめの一歩
吉次：今回は私がQAエンジニア組織の立ち上げを行った時のことをお話したいと思います。
QAエンジニア組織立ち上げの経緯
まず立ち上げの経緯をお話します。
パーソルキャリアでは事業企画や開発は順調に進行していましたが、1〜2年ほどサービスを運用する中で品質面の課題がだんだん浮き彫りになってきました。
具体的にどのような状態かというと・・
リリース後のバグ検出頻度が増えていましたが、ドキュメンテーションをする文化が根付いていなかったり、経緯がブラックボックスになっていたりと、意思決定の理由が分からないため、システムに変更を加えることの難易度が高くなっていました。
また、テストベンダーに協力していただき、リリース前にまとめてQAを行っていましたが、テスト仕様書のレビュー負荷が高いなどの課題もありました。
そこで、私たちはまずは現有のリソースを活用し、取り組むことができる改善策を考えることにしました。
取り組みのご紹介
取り組みの一部をご紹介します。
品質課題のヒアリングと改善施策の作成
まずは各プロダクトの開発リーダーに品質課題をヒアリングし、組織として解決するべき課題を明確化しました。
品質と言っても色々なところに問題が隠れています。そこで「仕様」「実装」「テスト」と大きく3つにわけてそれぞれの工程で課題と改善策を整理してみました。
テストマネージャーの半常駐体制の整備
洗い出した中で仕様書のメンテナンスとリリース前のQAテスト実行の両方をスムーズに進めるために、私たちは「仕様」と「テスト」の部分を重点的に取り組むことにしました。しかし、社内に必要なリソースがなかったため、外部のテストベンダーと連携するためのテストマネージャー体制の構築を行いました。
テストベンダとテストマネージャー体制
会議への参加や仕様書のメンテナンスなどを日常的に行い、スムーズにテストに移行し質の高いテストを実施する体制を整えるために、テストマネージャーを配置しました。この取り組みは成功したと感じています。
テストマネージャーの存在により、仕様を正確に把握し、それに基づいてテストケースを作成することが担保されました。
さらに、日々の会議で仕様について話し合っている際にも、テストエンジニアの観点から貴重な指摘をいただくことができました。テストマネージャーが開発プロセスに日常的に関与することで、問題が発生しそうな箇所を事前に洗い出してもらったり、問題を解決しておくための活動につながりました。
アプリケーションエンジニアに対する、品質知識のインストール
基礎知識のインストールと意識の醸成を狙いQA輪読会の実施を行いました。
題材としては基本的な内容が網羅的に掲載されているJSTQBのFoundation Levelシラバスを活用しました。
＜輪読会のTIPS＞
改善前は１章ごとに＜予習＞→＜資料作成＞→＜輪読会＞というサイクルで実施していました。しかし、予習をしても理解できない。予習の時間が十分に取れないことも出てくるかと思います。その結果、輪読会の内容が薄くなってしまうこともあるため、参加者が「予習」を行った上で「疑問点」「議論したいこと」を事前にピックアップするようにしました。発表者はそれに対して回答する形で資料を準備します。
このように「予習」と「事前準備」を厚くして、やり方を変えるだけで、輪読会の内容を濃くすることができるのでおすすめです。
QA組織の立ち上げポイントまとめ
私が思うQA組織の立ち上げポイントはこのあたりだと思います。
・ヒアリングによる品質課題の明確化
初めに、関係者とのコミュニケーションや情報収集を通じて品質に関する課題を明確化します。ユーザーの要求や期待、現行の品質管理の課題などを把握しましょう。
・現実的なアプローチの模索
明らかになった品質課題に対して、現実的かつ効果的な解決策を模索します。技術的な改善、プロセスの見直し、ツールやフレームワークの導入など、具体的なアクションプランを策定しましょう。
現実的なアプローチを見つけるためには下記3つに分けて一つ一つ着手していくと良いと思います。
①新しく人を採用すればできること
②テストベンダーとの協業を行えばできること
③既存の組織メンバーでできること
・既存メンバーの巻き込みと組織活動の引き上げ
QA組織を立ち上げるためには、既存のメンバーを組織活動に巻き込み、その意識とスキルを高めることが重要です。教育やトレーニングの提供、情報共有やコラボレーションの機会の創出など、組織全体の活動に参加してもらいましょう。
今後の展望（採用と組織デザイン）
結果的にQAエンジニアの採用ができましたが、採用に至るまで結構苦戦しました。
一人目のQAエンジニア採用のため、当初は組織作り、エンジニアリング、マネジメントなどの考えられるスキルを全て採用要件に含んでしまったために、中々マッチする人と出会えませんでした。
そこで採用要件の分解をしっかり行い、現実的な落とし所を見極め、既存メンバーも協力しながら進めていくべきと感じました。
今回はQAエンジニアとしての発表ではなく、QAエンジニアがいない環境でどういった組織を作っていくかという話が中心でしたが、ご紹介させていただきました。
続いてセゾン情報システムズ 谷平さんの発表を紹介いたします！
QA/テストエンジニアとして10年ちょいやってきて変わらなかったもの、変わったもの
谷平：今回は弊社のプロダクトの中でも今日はDataSpider Servistaをメインにテストに対する考え方やスタンスは共通して共有できるものをお話しできればと思います。
特に今回は2016年に上長が書いたブログの内容を振り返り、当時の状況と現在の状況の変わったもの変わらないものを考え、ソフトウェアでは何が大事なんだろうかと考える一助になれば幸いです。
DataSpider Servistaの開発フェーズ
QAでは新機能の開発は加えず、発見した不具合を修正することに主眼が置かれます。
そうした中で、上長のブログにはQAチームが大切にしていることは以下の５つのことが書かれていました。
・ユーザー視点を担う
・テスターでなくプロダクト開発者である
・開発との関係は対等
・答えは自分でみつける
・やる理由/やらない理由を考える
これらのワードを、振り返りながら考えていきます。
ユーザー視点を担う
QAはプロダクトのファーストユーザーであり、ユーザの代弁者として行動する必要があります。
そのためにはプロダクトの「当たり前を疑う」姿勢が重要です。さらに、様々な制約を認識しながらも、ユーザーが満足できる仕様であり、必要な品質基準を満たしているかを確認し、使い勝手の良し悪しを評価する必要があります。テスト経験が豊富になると、つい「こんなものだろう」と前提を持って開発やテストを行ってしまいがちですが、本当にお客様にとって使いやすいのかを常に疑問視し、開発やテストを行う必要があります。
また、ブログが公開されてから7年が経過し、今ではユーザー視点を持つ存在はQAに限定されなくなりましたが、QAは基本的な立場として「ユーザーの側」に立ち、ユーザーの視点から正論を述べることが重要です。ただし、ユーザーになりきることは容易ではないため、ユーザー視点を持つためのいくつかの方法を以下に示します。
ユーザーになりきるため、そしてユーザーの意見や考えをつかむ手法として営業同行や展示会の説明員があげられます。HULFTでも過去に実施していました。しかしジョブ型雇用といわれる時代になり、これらの方法は手放しで勧められるものではなくなりました。非常に役立つ手法ではあるものの、本来の仕事ではないため強制はできないので賛同が得られる場合にしておいたほうがよさそうです。
テスターではなくプロダクト開発者／開発との関係は対等
テストとはプロダクトをよくするための活動です。現状の品質状態を明らかにして、対等な立場で遠慮なく意見をぶつけ合うことが価値あるプロダクト作りには必要です。ただ当時は「テスター」の地位が低かった背景もあり、ブログが書かれた当時は必要な心掛けが必要だったのだと思われます。
テスターだけでは品質が良くならないので、開発と一緒に製品をより良くしていかなければなりません
では、対等にどのようにチームに貢献すべきか？これは「役に立つ」という意識が重要だと思っています。
ステークホルダー間の通訳とは、プロダクトオーナーや営業などいろいろなポジションの方が参加して機能について議論することがありますが、話が噛み合っていないときに通訳してあげるという役割もQAはできるのではと考えています。
敢えて自分が無知になり｢よく分からなかったけど…こういうことですよね？｣と、回答を引き出してあげるという方法もあり、そこから会話が引き出されることもあります。
答えは自分で見つける
これは「仕様は降ってこない」という考えが根底にあります。
『いやいや、それは無茶ぶり』と思うかもしれませんが、”待ちではなく攻めの姿勢”は間違っていないと思います。出来上がる前から開発者と議論して仕様を良くする/不具合の芽をつぶすことはQAの役割として重要です。現在は「一緒に考える」というスタンスでQAだけでなく開発、フェーズで製品仕様を検討したり、スプリントレビューというかたちで出来上がったものを実際に確認したり「考える」タイミングは前倒しになっています。早いタイミングでQAも関わるという姿勢でいきましょう！
やる理由・やらない理由を考える
様々なことに対して「やる理由」を見つけることは出来ても「やらない理由」を見つけて実際”やらないこと”は勇気がいることだと思います。
「やらない」ことはコストが無尽蔵で時間が無制限であれば考える必要がありませんが、現実はそうではありません。
・変更したコードの影響範囲
・不具合の過去事例
・「ヤバい」機能に対する変更かどうか
・「不安を覚えるところがあるか」の確認
上記項目に注視しながら「やる」「やらない」をＱＡエンジニアは見極めることが重要です。
過去を振り返ってみて…
今回過去を振り返ってみた印象は「おおむね大きく変わっているものではない」ということです。
ただ7年前と比べて会話する/合意する範囲が広まっています。
ステークホルダーと会話して合意を取っていくことで、｢思っていたのと違う｣｢お客様のためにならない｣といった確率がどんどん下がっていきます。なのでQAエンジニアはプロジェクトに携わるメンバーをはじめとしたステークホルダーと積極的に会話していきましょう！
質問コーナー
くぼぴーさん
QAエンジニアの人がどういった方法（書籍や資格）で技術を磨いているのか興味があります。
スクラムフェスや、QA勉強会にとにかく参加したり、SQuBOKを読んだりしています。また、QA界隈で人気になってそうな本はとりあえず買ってます
QAチームメンバーのモチベーションの維持や向上で取り組んでいることとかあれば。
褒めちぎる！！！
自動テストが増えできた場合の複雑性への対処方法 スクラムで要件が変わったときの自動テストの変更方法(愚直に直していくのかなど)
変更容易な形にあらかじめ作ったりします。（具体的なケースは先に作らずにヒアリングしながら同時に進めるなど
QAチームのあるべ姿をどう考えているか教えて頂きたい
品質について考えることを、社内全体に浸透させることです。リードではなく協力していくことです。
開発エンジニアからQAエンジニアを目指そうとする人におすすめの研修（有償）はありますでしょうか？
Jasstとスクラムフェス新潟はおすすめです！
くぼぴーさんが一番QAエンジニアとして苦戦したこと（開発組織としての課題）はありましたか？
品質が軽視されているわけではないが、品質以外に重きを持たれていることが多い。そのため、QAエンジニアが「ここ出来てませんよ」と苦言を呈さなければいけないことがある。そういう時は心が苦しいです。。
一気に検証をするのではなく、少しづつ進めていったのはなぜですか？
一気に進めてしまうと大変な事故が起きた時に、手戻りが大量に発生してしまう。コミュニケーション量（レスポンス）も多くなってしまう。ちょっとずつの方が修正もしやすいし、コミュニケーション量もカットできる。
開発エンジニアとQAエンジニアが並走し、随時検証をしていく中で、開発エンジニアからの反発はありませんでしたか？ 例えば、どうせ、めんどくさいこと言うだろうな？みたいな空気感。 もし、そんな空気感があれば、払しょくするためにどんな工夫をされていましたか？
自分の中で「まためんどくさいこと言ってしまう」と被害妄想してしまうので、気持ちわかります！「ここがおかしいと思うので、一緒にみてもらえませんか？」など当たりをつけて、明るく、志気を下げない方法で話かけるようにしています。
社内ドキュメントもnoteだったりして
流石にそれはないですｗ
各noteのリンク先も今見たい...！笑、あと、おすすめツールとか推しツールとかありますか？参考までに聞いてみたい
QA関係ならMablです！GIHOZ（ぎほーず）。あと、note。
ステークホルダーとの齟齬の一番の対策は何でしょう？QAエンジニア視点でアドバイスあればぜひ
情報共有を細かくせずに一気に出してしまうから、齟齬が生まれてしまう。人間なので、一気にドンと渡すと見落としが発生してしまう。「ここがこのような結果になった」を少しずつ認識していくのが大切。スクラム的な考えです。
実例マッピングについてもう少し詳しく教えていただきたいです！
"broccoliさん"という方の情報を参照してください
吉次さん
QA組織の立ち上げは吉次さんが起案したボトムアップで生まれた話なのでしょうか。
ボトムアップです。マネージャー層に相談したところ、同じくQA組織があったほうが良いという意識があったので、すんなり進みました。
せっかくですので吉次さまからもおすすめ＆推しツール聞きたいです
実はQAエンジニアではないのですが、これから使いたいなーと思ってるのはAutifyです。
組織立ち上げまでどのくらいの期間で実施されたのでしょうか。
1人チームで活動し始めたのは2年くらい前です。
QAエンジニア（リーダーレベル）の1人目を採用するまでにはなんだかんだ1年以上かかりました。
テストベースをインプットした後の、テスト側の負荷が減ったのかを知りたいです。
テストベースの質と量が高まったことで、テスト設計・実行する際のテスト担当者も「動かしてみてよくわからないから聞く」みたいなコミュニケーション負荷は減っていると認識しています。
仕様書（ドキュメント）を作るカルチャーを作るのってめちゃめちゃ大変ですよね。。。 自分もうっかり「後で作ろう→そのまま放置」になってしまったことがある。。
ドキュメントは資産、メンテナンスは資産運用と捉えています。
丁寧に作ってしっかり運用すれば将来的に複利で効いてきますし、将来の自分を助けてくれると思ってめんどくさいと思ったときも頑張るようにしています。
品質課題のところでルールの整備というのはどんなルールで作られたのでしょうか？
施策はあるけど具体的なルールの策定はこれから、という状況です。
少しズレますが、品質ガイドラインの作成を行って、基本的な用語などについて目線が合う環境作りを進めています。
パーソルさんくらいだとQA部署の体制は大きそうですね、関連企業との連携なんてありますか？パーソル○○とか多いイメージなので
内製のQA部隊はまだできたばかりで、「QAの部署」は名目上は現状存在していません。
「QAエンジニアが在籍している部署がある」という位置づけです。これからしっかり活動を拡大してグループや部の格にあげていきたいと思っています。
グループ会社については品質面に関してはあまりなく、開発のアウトソース的なところで関わることが現状は多いです。
QA輪読会すてきすぎる、これはどれくらい集まりますか？
5〜6人集めてJSTQBシラバスの1〜6章を輪読するのを1セットとして、運用しています。
大体1人1章担当するイメージです。
QA輪読会は参加できますか？
現状、社内での活動となります。すみません。
将来的に社外のコミュニティにもアプローチして実施するのは可能性としてはあるかも知れません。
「仕様書を作成・メンテナンスできる状態を作る」「一定レベルで仕様理解が担保されるプロセス、ルールの整備」というのは具体的にどのようなことをされましたか？同じような課題を今抱えていて困っています
「仕様書の作成・メンテ」は、当事者意識をもって、ドキュメントを更新・参照する（頻繁に参照されるものはキチンと更新されるという仮説）。
私のいるプロジェクトでは、仕様書は（1）単一の施策についての仕様書と（2）機能単位での仕様書を作っています。
（1）は、その施策が終われば基本的に見ません（過去の経緯など確認する場合などは見ます）。テスト、リリースが完了したタイミングで（1）の内容を（2）に統合する流れにしています。
その統合の作業をテストマネージャの責務として定めています。
「プロセス、ルールの整備」はこれからです。スクラムの中で仕様の読み合わせなどはしていく必要があると思っています。
テストベンダーさんから来ていただいたテストマネージャーの方々はどのタイミングでチームを抜けますか？
基本、抜けないです。開発が続く限りは併走してもらいます。
パーソルさんのQAエンジニアに応募したいのですが、どこからできますか？
1人目を採用後、これから諸々組織づくりの方針をまとめていっている最中なので、直近はQAエンジニアメンバーの採用は停止しているのですが、
カジュアル面談を受け付けておりますので、「話を聞きに行く」をからコンタクトいただければと思います。
カジュアル面談後、ご興味ありましたらキャリア登録というものを案内致しますので
採用活動を再開した場合にお声掛けさせていただければと思います。
ロードマップについて、質問です。将来ビジネスで必要なシステムは開発エンジニアが作る様に思うのですが、将来システムとリンクしたQA視点でロードマップというと具体的にはどの様な事を描くのでしょうか？
ご質問の意図を正確に解釈できていかもしれないのですが、
QA組織としてのロードマップは「プロダクトや会社に対して提供する価値はなにか」という観点でゴールを定めてそこに向けてどういうステップを踏んでいくかを考えています。
例えば、「特定の部署に閉じず、全社的にプロダクト向上やプロセス改善に寄与することで、自社が提供する顧客価値・ビジネス価値を最大化する」というところをゴールとして定め、ゴールに近づくために、足元の課題をクリアしながらどのように役割を広げ、組織を大きくしていくかをデザインしていくプロセスだと考えています。
将来的にQAの内製化などは考えられておりますでしょうか？
完全に内製化することは現状考えていません。
少数精鋭の内製メンバーで社としての品質課題をコントロールしつつ、テストベンダさんとうまく協業しながらQAチームとして出せる価値を大きくしていくことを考えています。
採用されたQAエンジニアの方のキャリアパス相談や評価フィードバックなどはどなたが行っておりますでしょうか？弊社では適切にQAエンジニアを評価できる知識・経験を持つ方がおらず目線のズレなどが生まれてしまっておりまして…
直近はこれまでの品質向上の活動をリードしてきた吉次（アプリケーションのエンジニアです）が実施する予定です。
個人の目標設定や評価についても今後中長期的に取り組んでいく課題で、組織的に整備していきたいと考えています。
（解決策を提供できずすみません）
テストベンダーの選定方法について知見やアドバイスをお願いします！
社内に良い実績がある会社さんがあればまずそれを検討しますが、
現状の課題や今後想定される動きに対してフィットするソリューションを持っているかがポイントだと考えています。
その後は予算との兼ね合いになってくると思います。
1人目のQAエンジニアとして採用されました。品質課題を明確にするタスクに着手していますが、その明確化のために最初に何をすれば良いか悩んでいます。吉次さんは限りあるリソースの中で、品質向上のためにどのような取り組みやヒアリングを実施しましたか？また、「仕様」「実装」「テスト」の改善に取り組むにあたって、どれを一番重要視しましたか？
自分自身が開発に携わって、課題がある状態で「みんなも同じような悩みあるよね？」というところからスタートし、ある程度開発現場との今日考えられやすい環境だったので質問者様と状況が異なるとは思いますが、個人的な考えを回答致します。
品質に関わる活動に限った話ではなく、新しい環境に身を投じたときにはまず組織やプロダクトを理解することと、周囲からの信頼を獲得することが重要なので
まずはコミュニケーションをとって関係性を作るのと、些細なことでも品質関係なくてもいいので組織内に転がっている困りごとを解決するところから始めるのが良いと思います。
（ある程度周囲との関係性ができて信頼が得られると、情報が集まりやすくなったり協力的な人が増えて効率が上がり、同じ工数でもできることが増えていきます）
具体的な品質課題については、シフトレフトの考え方に基づいて挙げられている3つの中だと「仕様」の部分を最重要視していました。
後工程全てに効いてくる部分なので、まずは仕様の部分にアプローチしていくのが成果に繋がりやすいと考えています。
谷平さん
QAがユーザー目線に立って検証をすることはどうしても仕様書のレビューやホワイトボックステストなどとは両立しない部分があるかと思うのですが、ハルフトさんのQAはどちらを重視しておりますでしょうか？
立場をわけています。開発者がホワイトボックステスト。QAがブラックボックステストを担当しています。単体テストの作り方がわからない、など相談することはあるが、基本的には役割分担している。中身を知らず、動いた内容を見て、ユーザー目線での意見を言えるようにしている。レビューもそのスタンス。
弊社はQAをプロダクトをよくするための活動とはおもっていなくQA=単なるテスターと思われがちです。なにか上部へ説得するには何かアイデアはありますか？
弊社がQAチームを作った経緯。痛い目にあった経験がある。客先に納品しにいったら、インストーラーが起動しないなどが起こって、痛い目にあったのでQAチームが発足した。必要性を社内で意識づける。基本的に品質を優先するなら、テストは大切です。
QAがユーザー目線に立って検証をすることはどうしても仕様書のレビューやホワイトボックステストなどとは両立しない部分があるかと思うのですが、ハルフトさんのQAはどちらを重視しておりますでしょうか？
立場をわけています。開発者がホワイトボックステスト。QAがブラックボックステストを担当しています。単体テストの作り方がわからない、など相談することはあるが、基本的には役割分担している。中身を知らず、動いた内容を見て、ユーザー目線での意見を言えるようにしている。レビューもそのスタンス。
次回のイベントレポートもお楽しみに♪
