https://tech-blog.monotaro.com/entry/2025/03/13/090000

もしあなたが様々なシステムの品質保証を担ってきた QA エンジニアとして、QA 組織がない・QA エンジニアがいない会社に「入りたい」と思いますか？

もしあなたがエンジニアリングマネージャーとして、QA 組織がない・QA エンジニアがいない中 CTO から「QA エンジニアを採用・オファーするか？（面倒を見れるか？QA 領域で活動していく覚悟はあるか？）」と言われて「はい」と答えますか？

もしどちらも「Yes」となり、1年後にどうなったと思いますか？

はじめに

こんにちは。
プラットフォームエンジニアリング部門 DevSecOps グループの伊藤です。
DevSecOps グループでは、各エンジニア組織に対して、主に SRE、オブザーバビリティ、CI/CD、プロダクトセキュリティの領域で支援を行っています。

今回は、QA 領域の組織を立ち上げる過程の話をお伝えします。

特に、社内で新しい領域を導入・推進されている方、QAや品質保証に従事されている方、テストプロセスについて興味を持っている方々にお届けできればと思います。
（また、QA 領域の人員募集も行っており、下記求人一覧となります。）

QA領域の組織を立ち上げたい発端

※ (2025/03/14 15:30) 「売上は2023年度実績で2,542億円」を「売上は2024年度実績で2,881億円（前年比＋13.5%）」に修正

従来、モノタロウには QA エンジニアというロールは存在せず、開発エンジニアがテストも行う体制でした。
（世間一般的に QA エンジニアの役割とは成果物が仕様通りに動作すること、ユーザーの要求を満たすこと等を担保することでしょうか。）

しかし、2022年頃に EC サイト（ https://www.monotaro.com/ ）の開発・運用を担う EC システムエンジニアリング部門内で、DX 改善の一環として E2E テストの改善を約1年かけて行いました。
（Robot Framework から Playwright への移行を支援することで、不安定なテスト（Flaky Test）がほぼ無くなりました。）

また、当部門でテストに関するアンケートを行ったところ、以下の課題が浮かび上がりました。

テスト仕様書の書き方のルールがないため、テスト仕様書の再利用が困難になっている。
開発エンジニアが手動テストの実施に一定の工数を費やしている。

一方で、ビジネスも組織も成長し続けており（売上は2024年度実績で2,881億円（前年比＋13.5%）、エンジニアは正社員で200名を超えています）、全てのエンジニア組織の開発生産性や信頼性の担保・向上に貢献する部門として、プラットフォームエンジニアリング部門が2024年1月に設立されました。

それに伴い、QA・品質保証もその対象領域の一つとして扱うこととなりました。

…と言うと他人事のように聞こえますが、私自身ここ数年「DevSecOps エンジニアとしての開発生産性の向上」に取り組んでおり、大規模な障害が度々発生するといったことはないものの（その面の品質は一定担保できている）、上述の通り開発エンジニアのテストに関する開発者体験（Developer Experience）が他の項目と比べて良くないと考えていました。
（なお、ユニットテストといったソフトウェア面は、研修・実践により一定の成果が得られていると思っています。）

また、開発エンジニアにはよりプロダクト開発に専念、例えばテストに関する改善や広く言えば運用・保守に関する負荷の緩和をしたい想いもありました。

一方で、同時期に長年当部門でテスターとして従事してきたメンバーが正式に参画することになり、QA エンジニアとして QA・品質保証の担保・改善を期待し、一緒に活動していくこととなりました。

QA領域の活動の方向・方針を考える

2024年前半は他の施策を優先しており、その間は QA 立ち上げチーム（マネージャー（私）、リーダー（QA・品質保証に関する知識・知見がある）、QA エンジニア）の3名が週1回のペースで議論を重ねていました。

例えば、以下の点について考えました。

前述の EC システムエンジニアリング部門のアンケート結果から何ができるか
世間一般的な QA・品質保証の考えから何ができるか

また、リーダーを中心に QA・品質保証に関する学習を企画し、チームで実施することで理解を深めていきました。

そんな中で「テストプロセス」が一つのキーワードとして出てきました。
皆様は「テストプロセスとは？」と言われて、何をイメージするでしょうか。

せっかくなので、MonoChat（Slack 経由で GPT-4o を利用できる社内ボット）に聞いてみました。

また、QA エンジニアが作成した『テストプロセスの概要』からの一枚となります。

このことから、「テスト仕様書の作成と実行に関する課題の改善ができるのでは？」や「テストプロセスの考えをもとに各テストフェーズの観点・方法を揃えることで、それができるのでは？」と考えるようになりました。

他に考えたこととしては、

テストデータ管理の改善（例：テストユーザーの作成を簡単にできるようにする）
- DORA | Capabilities: Test Data Management
大規模等の特定プロジェクトに QA・品質保証担当として参画

がありましたが、前者はエンジニアリングが必要となること、後者はモノタロウではドメイン（例：配送）別開発の方が多くスケールしやすいことや新しい取り組みで小さく試したいことから、後回しとすることにしました。

CTOとの議論（1回目）

そんな中、2024年6月に CTO に QA 領域の活動（テストプロセスの導入・実践）を提案しましたが、議論する過程で取り組みとして不十分であるとの結論が出ました。

あくまで QA・品質保証の一般論の説明にとどまり、

何が課題で、何を解決したいのか？
QA・品質保証の活動がモノタロウのビジネス・システムにどのような価値を生み出すのか？

といった CTO の観点での問いに対して十分に答えられませんでした。

さらに、データやエビデンスも不十分とのフィードバックを受け、PoC（Proof of Concept 概念実証）の必要性を感じました。

私は「べき論で言えば提案は正しいだろう」と考えていたのでショックでしたが、上記の通り意思決定に必要な材料、次アクションといったヒントを CTO から貰えたので、次の提案に向けてさらに進めることとしました。
（念のためですが、もしこの時点で提案が採用されていたら、目的や価値が不明瞭なまま進行していたと思われ、今振り返ると CTO には本当に感謝しています。）

テストプロセスの学習と実践

ということで、机上の議論にとどまらず、テストプロセスの実践の PoC の計画・実施に取り掛かりました。

具体的には、以下のやったことに対してそれぞれ以下の成果が得られました。

QA エンジニアの給与・賞与評価のための個人目標の一つに JSTQB (Foundation Level) 資格の取得を組み込み、PoC の実行能力を獲得
1. QA エンジニアが JSTQB (FL) に合格しました 🎉
品質の向上に課題感を持つ開発チームリーダーとの議論を通して、PoC 先として巻き込み
1. QA・品質保証の価値探索・仮説検証が一定できた。
2. 「課題感が大きいこと」と「その解決に向けてモチベーションがあること」があると、PoC が行いやすいという知見が得られた。
B-Testing 風間裕也さん (X: @nihonbuson) のテストコンサルタントとしての参画
1. 風間さんに特定チームに対してテストプロセス研修を実施していただく。
  1. その後、実際の案件で開発エンジニアと QA エンジニアが協業でテストプロセスを実践し、週1回、風間さんと成果物や困りごとを相談・議論する。
    1. 例えば「◯◯はデシジョンテーブルを用いて項目・パターンを洗い出しましょう」といった開発エンジニア・QA エンジニア間で共通の認識・言葉ができ、テストプロセスの実践がより進めやすくなった。
2. 風間さんと QA 領域の組織の立ち上げについて議論やアドバイスをしていただく。
継続的な QA チームの世間一般的な QA・品質保証の考えの学習
1. 共有・議論・学習を通して、QA チームの価値観の醸成、方向・方針のすり合わせにつながった。
  1. 例えば、品質を加速させるために、テスターを増やす前から考えるべきQMファンネルの話（3D版） | PPT を元に各役割・やることを議論し、定義できた。

そうして実際の案件の中で、

手戻り率が削減できる（例：従来ではリリース後に発覚した不具合がテスト分析フェーズで発見できる）
テスト技法の獲得・実践により、テスト設計・実装の質・スピードが向上できる（例：テスト仕様書の項目の質は変わらずに数を平均◯%削減できる）

といった見込みや、価値探索・仮説検証が一定程度の定量的なデータとして得られました。

CTOとの議論（2回目）

上記の PoCをもって2024年9月に CTO へ2回目の提案をしましたが、議論する過程で取り組みとしてまだ不十分であるとの結論が出ました。

確かにモノタロウのシステムの品質向上の見込みについては一定の理解を得られたものの、開発生産性との関連が十分に考慮されていませんでした。
というのも、事業やエンジニア組織の現状・今後、そして Mission / Vision / Value との紐付けが十分にできていなかったからです。

モノタロウでは「資材調達ネットワークを変革する」という企業理念のもと、安定的に素早く施策・機能を提供していくこと、エンジニア組織においては「質とスピードの両立」が一つのキーワードとして掲げられています。

ということで、次のお題である「QA・品質保証が開発生産性にどうつながるか？」の問いに対して、さらに別の価値探索・仮説検証を行うことで何が課題で、どんな価値を見出せるのか？をまとめていくこととしました。
（と冷静に書いていますが、生まれも育ちも開発エンジニアの私は当初「テストプロセスの導入・実践が開発生産性にどうつなげられるか？」に悩みました。）

付随して高品質と高スピードを両立させるソフトウェアQA/Software QA that Supports Agility and Quality - Speaker Deck のように、事業側からの QA への期待は事業によって異なることも学びました。

テストプロセスの課題・価値探索と仮説検証

ということで、さらに別のチームで PoC を行い、工数やリードタイムといった「質とスピード」の“スピード”部分の価値探索・仮説検証も行いました。

一方、2つのチームの PoC から以下のテストプロセスを浸透させる際の課題が浮かび上がりました。

（当たり前ですが）テストプロセスに関する知識・知見をチーム内で揃えるための研修やワークが必要である
（これも当たり前ですが）テストプロセスを実践すると、短期的には工数やリードタイムが増える
テストプロセスを効果的に実践するためには、理想的には着手前に要求・仕様が明確になっていることが望ましい

そこで、特に3つ目の課題を QA チーム内で議論する中で、「QA・品質保証がより良いプロダクト開発につなげられるのでは？」という仮説が生まれてきました。

システム開発・プロダクト開発におけるQA

ここまで「システム開発における QA」としてテストプロセスを考えてきました。その過程で、仕様やテストプロセスに関するドキュメント・成果物の標準化・ナレッジ化にも貢献できるのではないかと考えるようになりました。
インプロセス QA（開発組織に常駐しながら QA の実業務と品質文化を担う）として参画することで、例えばテスト仕様書の項目の洗い出し・取捨選択の観点・方法の標準化に加えてテンプレート化することで、品質は担保しつつ工数は削減できる見込みができました。
また例えばユースケース図・状態遷移図等の UML の作成、テスト仕様書の項目の取捨選択時に判断理由を記載することで仕様がよりわかりやすくなり、属人性の低減やドキュメントの再利用につながる見込みもできました。

上記はすなわち「仕様を明確にすること・ブラッシュアップすること」でもあり、それはプロダクト開発において重要な要素の一つだと思われます。

加えて、「要求を明確にすること・ブラッシュアップすること」にも貢献できる余地があるのではないかとも考え始めています。

「要求を定義する能力」は、プロダクト開発や SLO 等の考え方やフレームワークにどれだけ従っているか、また組織・職種間の状況（例：PdM、スクラムマスター、開発エンジニア、QA エンジニアがそれぞれどのような役割や進め方をしているか）によって、成熟度レベルのようなものが存在するように感じています。

それに対して具体的には、以下の記事のようにして QA エンジニアがプロダクト開発をより良くするためのサポートが一定できるのではないかと、現在さらなる仮説検証・価値探索を進めています。
バグゼロに陥らないためのQA活動 - 弥生開発者ブログ

例えば、以下のアイディアとなります。

テストベースフェーズのテンプレートは2024年2月時点では以下となりますが、要求定義フェーズで一部流用することで、要求を効率よく整理できる
テキストベースだけではなく、例えば要求を持つ人と対面ベースで確認、録画・録音で要求を伝えてもらうことで、コンテキスト量を増やしていく

CTOとの議論（3回目）

ということで、2024年12月に CTO へ3回目の提案を行い、採用（今後テストプロセスの導入・実践をさらに拡大していくこと）となりました。実質的に半年ほどでここまで進められたのは、リーダーや QA エンジニア、PoC 先、風間さんのご協力が大きかったです。

前述の通り、品質だけでなく中長期的な開発生産性やプロダクト開発への貢献のストーリーを描けたことも良かったと考えています。
（逆を言えば、単にテストプロセスの導入・実践だけだと尻すぼみ、得られる価値を失う可能性があったかも知れません。）

また、別のマネージャーのアドバイスでビジネス書を意識して読むようにしたのですが、特にD・カーネギーの『人を動かす』や『道は開ける』は、組織や人を動かす際の提案の方法において大いに参考になりました。
例えば、一般論ではなく自社にとっての課題・問題設定を示し、解決方法を提示し、価値を深掘りすることが重要だと学びました。

加えて、以前の上司から「一番良い提案は承認・決裁者がただ頷くだけ」と教わっていたのですが、そういった提案の方法やロジックが良いとも改めて痛感しました。

今後

短期的には、「テストプロセスの知識・知見のベースを揃える」と「テストプロセスの標準化（ドキュメント化や観点などの暗黙知の明示化）」を行い、品質とスピードを担保・改善できる状態を拡大していきたいと考えています。

また、中長期的には「より良いプロダクト開発に貢献する」ことをテーマに、要求や品質といったより根本的な部分に進んでいければと目論んでいます。

ここで言う”短期的な品質”は変更障害率、手戻り率といった指標を考えていますが、”中長期な品質”は応答速度といった非機能要件、ひいては例えば「◯◯は△△にした方がユーザーの叶えたいことがより実現できる」といった要求や品質自体への貢献までできればと目論んでいます。

例えば、各基幹系システムでより良い要求定義とするためには業務側と開発側の適切なコニュニケーションが大事かと思いますが、その理論と方法論を QA が用意ないしサポートできるのでは？と考えています。
言い換えれば、事業のコアとなる基幹系システムに対してプロダクト開発の考えを適用し、上記をさらにドライブさせるというミッションを QA が担っていけるのでは？とも考えています。

TDD はテストを中心にソフトウェアのフィードバックループをもたらすとしたら、QA は要求・仕様を中心にプロダクトに対してフィードバックループをもたらすことができると思っています。

本文の冒頭の”もしも話”について、一年前、もし QA エンジニアのTさん・エンジニアリングマネージャーの私のどちらかが「No」と言っていたら、ここまでの話は存在しない IF ストーリーになっていたかも知れません。
しかし、様々な方のフィードバックやご協力により、最近 PoC 先で「従来ではリリース後に障害として発覚したバグをテスト分析（設計・開発）中に見つけられた」「最初はテストプロセスの導入・実践に負荷がかかるが、慣れると負荷は下がり価値をより感じられる」といった非常に嬉しい声を貰うことも増えています。

ということで、これから本格的に QA 組織の活動を行っていくにあたって、QA リードや QA エンジニアの仲間を増やしていきたいと思っています。これまでの通り、QA・品質保証のスキル・経験をもとにテストプロセスの導入・実践・改善を行い、結果的に品質やひいてはプロダクト開発に貢献していくことは、大変ながらもやりがいの多い仕事だと考えています。

「大変ながらもやりがいの多い仕事」とは、「トップダウンでバグゼロとか言われた通りの品質を担保する」ではなく「品質とは？開発生産性とは？プロダクト開発とは？」を自ら問い続けていくからだと思っています。

ぜひカジュアル面談でお気軽に QA・品質保証についての談義や採用応募をいただけると嬉しいです。

「Let's enjoy QA!!!」

careers.monotaro.com

hrmos.co