QMファンネルを使ってQAキャリアイメージを描いてみる
アジャイル時代のQAマネージャー#2
これはウイングアーク Agile and DevOps Stories のAdvent Calendar 2021、2021年12月24日の投稿です。
2021年のアドベンドカレンダーも今日が最終日ですね。皆さん思い思いの記事を書いてくれて本当に感謝です！
さて、大トリとなる私の記事はQMファンネルを使ったQAキャリアの話を詳細に書いてみたいと思います。
目次
気付けばいっぱい書いてたので目次を作りました。
- QAファンネルじゃなくて、QM？
- QMファンネルとは？
- QAキャリアイメージ
- テスエンジニア
スプリットテストエンジニア（スプリットTE）
インプロセステストエンジニア（インプロセスTE）
テストエンジニアコーチ（TEコーチ）
テストエンジニアコンサルタント（TEコンサル） - パイプラインエンジニア
スプリットパイプラインエンジニア（スプリットPE）
インプロセスパイプラインエンジニア（インプロセスPE）
パイプラインエンジニアコーチ（PEコーチ）
パイプラインコンサルタント（PEコンサル） - QAエンジニア
スプリットQAエンジニア（スプリットQA）
インプロセスQAエンジニア（インプロセスQA）
QAエンジニアコーチ（QAコーチ）
QAエンジニアコンサルタント（QAコンサル） - プロモーター
- スペシャルティのバランスが重要
- ラインマネージャーとの違い
- ハイヤリング
QAファンネルじゃなくて、QM？
以前、JaSST Tokyo2021で「新しい品質保証のかたちを目指して
～君の心に「ファンネル」はあるか？～」というテーマで、SigSQAの一員として「QAファンネル振り返り術」の事例発表をしました。
SigSQAではQAファンネルをさらにブラッシュアップし、QMファンネルを作りました。このQMファンネルは「QAエンジニア」だけでなく、「テストエンジニア」や「パイプラインエンジニア」という3種類のスペシャリティと、「スプリット」「インプロセス」「コーチ」「コンサルタント」「プロモーター」という5種類のロールを定義して、合わせてQM（Quality Management）ファンネルとしています。
ここに至った経緯は西さんの説明を見た方がわかりやすいと思います。
QMファンネルとは？
上のスライドで説明されている通り、QAやテスターといっても考え方や役割は開発現場によってバラバラで、かといってどこかに明確に定義されているわけでもありません。そこでスペシャリティ（得意技）とロール（実業務への近さ）を2軸で整理したのがQMファンネルです。
Scrum Fest Osaka 2021で発表した西さんのスライドで、QMファンネルの概要がうまく説明されているので、そのまま貼ります。
QAキャリアイメージ
（前置きだけでおなか一杯になりそう…）
さて、この記事に書いた通り、私は今年の6月からSPQI部の部門長になり、さまざまなことに取り組んできました。その一環としてメンバー全員との1on1をしました。1on1を通してメンバーからのフィードバックで一番多いコメントが、「キャリアが明確にない」ことでした。
そこでちょうど良い機会なのでQMファンネルを使って、ウイングアーク版のQAキャリアイメージを描いてみようと思ったのが全てのきっかけです。
以下の表が通称、「QMファンネルを使ったQAキャリアイメージ2021年版」です。
注意1：あくまでウイングアーク内のQAに必要なキャリアイメージです。一般的ではないかもしれません。
注意2：まだまだ考慮不足はあるため、今後頻繁に変わる可能性があります。
前提
ここから一つずつ説明していきますが、先ずは前提としてスプリットとインプロセスの基本スキルセットを以下のように考えています。
- スプリットは基本的にニアショアやオフショア等の開発プロジェクトとは離れた別組織です（最近はリモートワーク時代によりニアショア/オフショアの概念が薄れてきてるように感じますが...一旦おいといて）。ここでは開発プロジェクトの現場から依頼されたタスクをこなします。基本知識として、JSTQBのFundationレベルやISO25000シリーズで定義されている品質特性の知識を持っていることが望ましいです。
- インプロセスは基本的に開発プロジェクトの中に入っているエンジニアです。そのため、製品アーキテクチャの理解や製品エンドユーザーの理解が必要になります。
それでは、上表の「TE」すなわちテストエンジアの各ロールから深掘りしていきましょう！
テストエンジニア
テストエンジニアはわかりやすいところで言うと、一般的に「テスター（テストする人）」です。テスト活動における、計画や戦略立案、設計、実装、実行、管理や品質分析等が対象になります。
スプリットテストエンジニア（スプリットTE）
スプリットTEは開発とは別組織で検証の実業務を行います。弊社の開発プロジェクトはほぼ内製化されていますが、一部のテストはニアショアやオフショアに依頼しています。依頼する内容はテストプロセスで言うところの、テスト実装やテスト実行が該当します。
インプロセステストエンジニア（インプロセスTE）
インプロセスTEは、開発プロジェクトの中で活躍するテストエンジニアです。開発エンジニアと一緒に、もしくは開発エンジニア自身が検証の実業務を行っているイメージです。検証の実業務はテストプロセスで言うところの、テスト分析、テスト設計、テスト実装、テスト実行等が該当します。
スプリットTEとインプロセスTEの「検証の実業務」の違いは、そこまで明確にしてはいませんが、要件や仕様からテスト分析をしてテスト設計するのはインプロセスTEで、そこからタスクを切り出してスプリットTEに依頼可能なテスト作業は任せています。作業のレベルによってスプリットTEに依頼できないテスト実装やテスト実行はインプロセスTEで行います。
また、インプロセスTEはJSTQBの用語を使用するとテストリーダーのようなスキルセットの持ち主で、特にリスクの管理やフィードバックを開発エンジニアやテストマネージャーに対して行えるような能力が理想です。
今秋入社したてのHiroyuki Itoさんが書いてくれた記事で、今までスプリットTEだったが、インプロセスTEのキャリアに挑戦する話は良かったですね。応援しています。
テストエンジニアコーチ（TEコーチ）
TEコーチは特定の開発プロジェクトの中にどっぷり張り付くのではなく、イメージ的には複数のプロジェクトを掛け持って、テストの技術移転や、品質文化をチームに浸透させるイメージになります。
JSTQBの用語を使用するとテストマネジメントが可能なスキルセットであり、テストプロジェクトの計画や戦略立案、コントロール、また品質分析をして改善施策が練られる人が理想です。
テストエンジニアコンサルタント（TEコンサル）
TEコンサルはTEコーチよりもさらに特定の開発プロジェクトに入っておらず、各開発組織を横串で連携し、テストの技術移転や、品質文化を組織に浸透させるイメージになります。
JSTQBの用語を使用するとテストアーキテクトが近い存在であり、組織に品質に対するガイダンスや戦略的指針を提供します。
弊社では最近OSSマネジメントの分野でTEコンサルを実施しました。
各プロダクトで使用するOSSは開発プロジェクト内でライセンス管理してはいるものの、全社的にマネジメントする必要があることが課題でした。そこでCTOにオーナーになってもらい、SQPI部のメンバーがリーダーとなって、各開発部門から代表するメンバーと共にOSSマネジメントチームを発足しました。OSSマネジメントチームではガイドラインを作成して、リスクや影響範囲の定義、ライセンス開示方針等の指針をまとめました。
パイプラインエンジニア
パイプラインエンジニアは簡単にいうと様々な自動化を行うエキスパートです。弊社では「QE（Quality Engineer）」や「インフラチーム」と呼ぶ現場もありますが、一般的にはSETやSREが該当します。
スプリットパイプラインエンジニア（スプリットPE）
スプリットPEは既に構築されたテスト自動化フレームワークを使って、E2EテストやAPIテストのコードを実装します。
イメージとしては既に用意されている自動テストツールがあり、決められたテストケースをリグレッションテストとして自動テストコードを実装をしていくようなイメージです。
最近のE2Eテストツールはローコード/ノーコードテストツールや、AI自動テストツールの台頭で、とりわけコーディング知識が無くてもE2E自動テストを組めるようになっています。
またAPIテストに関しても、開発プロジェクト内で使用している自動テストツールを引き継いで、機能やAPIの仕様がFixされていればスプリットPEにテストコードの実装は任せられます。
インプロセスパイプラインエンジニア（インプロセスPE）
一方でインプロセスPEはテスト自動化ソリューションの設計、開発、実装、メンテナンスをして、テスト自動化フレームワークをチーム全体で利用できる状態にするのが理想です。従ってスプリットPEが使用するテスト自動化フレームワークはインプロセスPEが構築したものになります。
ここでポイントになるのが開発プロジェクトの中で開発エンジニアと共に作っていく必要のある自動テストはインプロセスPEが実装します。
自動テストコードを実装していると、テスト容易性不足の気付きや、開発エンジニアの実装ロジックとエンドユーザーのUI操作からの仕様のズレ等、テストを組むことによって仕様変更が頻繁に発生する可能性があります。インプロセスPEは開発エンジニアと共に自動テストを実装していくイメージがあります。
ちょうどMasakazu Kichimaさんが書いてくれた記事で、FlutterモバイルアプリのE2Eテストを自動化するために頑張っている様子を共有してくれました。こういった取り組みがインプロセスPEのテスト自動化ソリューションの構築になると思います。
また、Watanabe Daisukeさんが書いてくれた記事では、テスト自動化をチームに導入することがアジャイルの成功体験になることを語っています。実際にどんなことを経験して成功体験になったかが、次回の記事になるようなので非常に楽しみですね！
パイプラインコーチ（PEコーチ）
PEコーチは、特定の開発プロジェクトの中ではなく、複数のプロジェクトを掛け持って、自動化やデジタル化を推進します。
基本的にテスト自動化の実装はスプリットPEやインプロセスPEが行います。PEコーチはどの部分を自動化することにより、開発プロジェクトの生産性が上がったり、安定的な運用を実現できるか等の、自動化するための戦略を考え、計画に落とし込みます。
また、テストを自動化するにつれ、テストの規模はどんどん膨れ上がります。膨大な量のテストをCI/CD環境でどうメンテナンスするかや、どうスケールしていくかといった戦略を立てたりします。
この辺は「Agile Testing Night #7 開発エンジニアとQAエンジニアが語る夜 Dr.Sum編」の動画で、Jenkinsを使って240時間かかっていた自動ビルドテストを50並列にすることにより、6時間弱まで速くした話が聞けます。
パイプラインコンサルタント（PEコンサル）
PEコンサルは各開発組織を横串で連携し、自動化やデジタル化を組織に浸透させるイメージになります。
個人的には、SREとして各開発プロジェクトの運用チームを支援して、自動化の横展開をすることが重要だと思っています。
例えばモニタリングや可観測性の観点から、システムを監視して分析できる自動化の仕組みを考えたり、SLIやSLOで定められた可用性の計測方法を考えたりと。システム運用における自動化やデジタル化に注力し、またそこでの知見を横展開し組織全体の自動化レベルの底上げにつなげられることが理想です。
（とは言え、実は理想ばかり語っており、この領域が実現できていないことは課題として認識しています。はい。）
QAエンジニア
最後にQAエンジニアです。（ここまで読んでくれている読者に感謝）
よくQAは「テストする人」とか「テスター」と呼ぶチームはあります。一方で、QAは「品質の門番」とか「基準の準拠」といった品質に対する厳しい人のイメージもあります。
QMファンネルではこういったQAに対する認識のズレがないように「みんなをよくする人」と言った定義をしています。かっこよく言うと「組織能力を高めるエキスパート」です。
それではさっそくいって見ましょう。
スプリットQAエンジニア（スプリットQA）
実はスプリットQAのイメージがありません。スプリットとは開発プロジェクトとは別組織と定義しているため、組織外から内部の組織能力を高めるイメージがないです...
（アイディアのある方は連絡待ってますw）
インプロセスQAエンジニア（インプロセスQA）
インプロセスQAは開発プロジェクトの中に入り、品質に対する実務や組織に対して品質能力の向上を担います。
例えばインプロセスTEやインプロセスPEと密に連携し、QCDに対して課題が見えてきたら、チーム内でファシリテーションをして、より良い方向に導いたりする能力が理想です。
reo arakiさんが書いてくれた記事で「マニュアルベーステスト」というテストタイプを実行後、マニュアルのライターとテストエンジニアが「ポジティブふりかえりをしたい」ということで、Kentaro Arakawaさんに入ってもらい、うまくファシリテートしてもらいました。
Kentaro Arakawaさんの動きとしてはQAコーチに近いのかもしれませんが、チーム内でファシリテートして、ポジティブにふりかえって、チームとして次の課題を見つけ出したという意味では、インプロセスQAとして非常に重要だと思います。
QAエンジニアコーチ（QAコーチ）
QAコーチはQAの技術移転やプロセス改善を開発プロジェクトに対してコーチングを行います。
例えば、開発プロジェクトの中に入っているインプロセスTEに品質マネジメントを教育や支援をしながら、インプロセスTEにテストマネジメントが可能なスキルを身に着けてもらい、TEコーチにキャリアアップしてもらうといた活動をします。
また、スクラムマスターのようなアプローチも行います。チームに寄り添い、メンタリング、コーチング、障害物の除去、ファシリテーションを行ってチームが自己組織化するようにします。POとも連携し、バックログの整理やストーリーの受け入れ条件を一緒に考えたりもします。
製品をリリースする際は、プロセス品質やプロダクト品質をレビューし、リリースに対してリスクや課題がないかをしっかりと監査したりもします。
Sakaguchi Yさんが書いてくれた記事で、リリースが頻繁になってきたことで権限委譲と意思決定の速さが今後重要な要素になってくる話は良かったですね。QAコーチとしてメンバーがリーダーシップを発揮してくれるようにコーチングしてくれていると思います。
また、Yuki Oharaさんが書いてくれた記事では、実際にSPQI部から開発の部門に組織異動し、開発プロジェクト内でコーチングしながら品質改善に集中する話を共有してくれました。心から応援しています！
（SPQI部にはQAコーチができるメンバーが多数いますので、色々な人が想像できて楽しいですw）
QAエンジニアコンサルタント（QAコンサル）
ウイングアーク１ｓｔでは「帳票・文書管理事業」と「データエンパワーメント事業」と大きく２つの事業があり、その中でも色々なプロダクト開発やサービスを立ち上げて事業展開しています。
QAコンサルは事業に対して、事業責任者（ステークホルダー）と密に連携して、品質の底上げに集中します。
例としては、品質に悩んでいるお客様先に出向き、品質分析の結果と改善計画を共有し、開発プロジェクトに落とし込んで、事業責任者も含んだ形で開発プロジェクトを推進していくような。
また事業の推進とリスクマネジメントを考慮して最低限の品質基準を策定し、関係者全員を巻き込んだ形で、ファシリテーション及びフィードバックを基に改善していくような。
（理想はあるのですが、なかなか難しい領域です）
プロモーター
QMファンネルは左図のように３Dのファンネル（漏斗）のような形をイメージしており、下に進むほど、領域は狭くなります。従って一番下のプロモーターの領域はテストエンジニアでありパイプラインエンジニアであり、QAエンジニアであり、各ロールの専門性を高めた、いわゆる業界の著名人を想像しています。
ですので、プロモーターの領域は正直分かりません。ただ、組織内も当然ながら、世の中に対しても品質文化を浸透するエキスパートだと信じています。
私もまだまだ至らない点はありますが、少なからずそう言ったキャリアを思い描いたりはします。現場で泥臭くテスト活動をしているテストエンジニアジアは多くいると思います。「エンジニアは幸せに働いて欲しい」という思いから、SigSQAというコミュニティに入ってモダンなQAを考えたり、JaSST新潟の実行委員をして新潟を盛り上げたり、スクラムフェス新潟という新しいイベントを企画したりしています。（スクラムフェス新潟に関してはまた追々ゆっくりと説明します）
ソフトウェア品質の歴史は長く、QAプロモーターとして世の中に貢献している著名人はたくさんいると思います。また、組織の中で現役で活躍するプロモーターもたくさんいると思います。そう言った人の話は今後もいっぱい聞きたいです。
スペシャリティのバランスが重要
ここまで、テストエンジニア（TE）、パイプラインエンジニア（PE）、QAエンジニア（QA）の各スペシャリティを説明しました。
「自分はテストもQAもやっているが、線引きする必要ある？」
と言った質問をいただきました。各スペシャリティの特性は説明しましたが、実は敢えて線引きをしたいわけではありません。重要なのはバランスだと思っています。
西さんのスライドでは車の両前輪と後輪の例えで表現しています。FR（後輪駆動）で、前輪が操舵輪で後輪が駆動輪をイメージしており、前輪の両輪がTEとPEで、後輪がQAです。要は3つのスペシャリティのバランスが悪いとうまく進まないことを車の例えで表現しています。
キャリアを考える上で自分の得意不得意はありますが、開発プロジェクトの中ではテスト活動におけるバランスを考え、「自分はどのスペシャリティを発揮すべきか」に集中することがポイントになります。そのため、時にはTEでもありQAでもあるし、時には開発エンジニアでありPEである必要があると思います。開発プロジェクトの中でQMファンネルを使って、そういったスペシャリティやロールの話を共通言語としてチームメンバー全員で話せるようになると良いですね。
ラインマネージャーとの違い
よくテストマネージャーとラインマネージャーを混同する現場があります。またこのQMファンネルを説明すると、コーチ、コンサルタント、プロモーターは組織の管理職なのでは？と質問されます。
組織内のマネージメントのキャリアと、エンジニアとしてのQAキャリアは別物と考えています。QAのキャリアが長いため、組織の中で出世してライン上のマネージャーになる人は多いと思いますが、役割が違うため敢えて別物と定義しています。
特に弊社の技術系人事制度では「マネジメント職群」と「プロフェショナル職群」を分けており、一般的なラインマネージャーはマネジメント職群が相応します。今回のQMファンネルを使ったQAキャリアイメージはQAに特化したプロフェッショナル職群に相応しているため、例えばTEコーチを「テストマネジメント可能な人」と定義づけた場合に、組織をマネジメントすべきか？と言うと、そんなことはありません。また、ラインマネージャーがテストマネジメントをしなければいけないかと言うと、そうもなりません。（たまたまTEコーチで管理職を兼務している人が多いと思いますが、考え方として別と言うことになります）
とはいえ、ではラインマネージャーはいったい何をするのか？と気になる人は多いと思います。実は正直な話、私にはまだわかりません（部門長がそんなこと言っていいのか？）。ただ、一応これに関しても定義しております。が、ここで紹介するとまた長くなりそうなので、次回以降の記事で紹介したいと思います。
（アジャイル時代のQAマネージャーとは何か？まだまだ道のりは長そう）
ハイヤリング
なんだかんだで1番伝えたいのは実は「ハイヤリングしてます！」ってことかも？
ここまで読んでくれた方はウイングアークのQAが何を考え、どこに重きを置いてるか？なんとなくわかっていただけたかと思います。
このような感じでやってますので（何を？）興味ある人、もう少し話を聞いてみたい人、一緒に働きたいと思った人！は気軽に連絡をください。先ずはカジュアル面談をしましょう。
また、最近は人事部のメンバーと協力し合い、インターンシップにも力を入れています。「あなたの知らないQAエンジニアの世界」というタイトルで2月にインターン受け入れを行う予定です。QMファンネルについても熱く語りたいと思いますので、興味のある学生は奮ってご参加ください。
