アジャイル開発に求められる品質改善活動を、ここでは「アジャイルQA」と呼んでいます。従来型のQAは網羅的、全体的なやり方ですが、アジャイル開発では短期間でのリリースが基本となるため、スコープを絞った局所的な方法をとらざるをえません。
この記事では、そんなアジャイルQAになるためのキャリアプランや、求められるスキルをスキルマップにまとめてみようと思います。ご自身のキャリア形成のヒントになれば幸いです。
アジャイルQAとは何か？
アジャイル開発において、「高い品質」とはなんでしょうか？
- 仕様通りできていること
- バグが少ないこと
- 期限内でリリースすること
- ・・・
ほかにも様々な観点はあるでしょうが、従来型の開発では、開発内容が契約で決まっていたりするので、上記の内容を満たせば「品質が高い」と言えます。特に「バグが少ない」はわかりやすい基準なので、ユーザが重要視することも多いはずです。
しかし、アジャイル開発では、契約というよりも成果で開発するため、「ソフトウェアによって顧客が実現したいことが達成できる」までがゴールになります。よって、仕様通りやバグが少ないのはあくまでベースライン（基準値）でしかなく、ベースラインを維持できてやっと、本来のゴールにチャレンジしなければなりません。
言われたものをちゃんと作っても、品質が高いわけではないのがアジャイル開発の難しいところです。
さらに難しいところは、ユーザのニーズが手によるようにわかっているビジネスやPOがいるならいいですが、そうでないなら、試行錯誤が続きます。ゴールに近づくために、さまざまなデータやフィードバックを得ながら、軌道修正を行い、真のゴールに近づいていきます。
うまくやれれば、ゴールに近づけますが、うまくやれないなら近づけません。もしかしたら、開発資金がなくなり、開発終了となる可能性もあります。
アジャイルQAは、上記のようなアジャイル開発に求められる品質を達成するための活動です。その活動をリードする人を指してもいますが、注意したいのは、最近のソフトウェア開発は、より複雑になってきており、開発に関わる活動もたくさんあります。よって、誰か特定の人に品質の責任をもたせるのが難しい場合もあります。よって、「活動をする人」ではなく「活動をリードする人」という表現にしています。
Caption: DevOpsのループではあらゆる活動でテストが必要になるため、全てを一人でやるのは難しい。参考：[翻訳] DevOpsにおける継続的テストとは何か？
アジャイルQAの「QA」は、いわゆる品質保証（Quality Assurance： QA）です。ただ、先にも書いたように、アジャイル開発では品質を保証するのが難しい。よって、チーム内での品質に対する合意形成とも言えるため、品質合意（Quality Agreement： QA）と表現することもできます。また、PMBOKでも品質保証という表現がManage Qualiry（品質のマネジメント）に変わっています。QAという言葉も、時代と共に意味合いが変わっていくのだと思います。
アジャイルQAのキャリアプラン
それではアジャイルQAのキャリアプランを考えてみましょう。ひとまずここではココでの名前をつけていますが、ご自身の現場に合わせて名前をつけてあげるといいでしょう。
アジャイルQAは、従来型のQAの上位キャリアではない点に注意してください。現場によっては、従来型プロセスのほうが適している場合もあります。プロセスも人も適材適所が当然ですので、アジャイルQAはアジャイルQAとして考えていく必要があります。ただ、従来型QAのキャリアやスキルは、アジャイルQAでも役立ちます。参考にできるところは取り入れてより発展させていくことができます。
テストエンジニア
アジャイルQAのキャリアのスタートは、「テストエンジニア」です。
テストエンジニアの役割と責任は以下になります。
- アジャイルチームで品質改善活動を行う
- アジャイルチーム内で適切で適量なテストが実行・運用されることに責任を持つ
品質改善活動の中心に「テスト」という行為があるはずなので、基本的なテスト設計から実行まではスキルとして身に付けなければなりません。エンジニアなので、エンジニアリング知識（テスト自動化など）を身につけるのも大切です。
未来ある新卒であれば、「まずはテスト実行」、「次にテスト設計」・・・というように、部分的に学んでいくこともあると思いますが、アジャイルチームでは基本的に一気通貫で作業ができるのが望ましいです。そうしなければ、「スプリント（固定の短い期間）の最後3日はテスト工程で、設計はAさん、実行はBさん・・・」というように、スプリントが工程で分かれてしまい、最後にまとめてテストする形になってしまいます。
テスト工程を最後にまとめると実行効率は良いですが、短期間で小さく開発しているのに、最後にまとめてテストをしていては、問題が起きたときのリカバリが難しくなります。アジャイル開発なのに、従来型のデメリットを引きずってしまう点に問題があります。
誰がテストを実行するかは、ここでは問題ではありません。スプリント内でテストが完了し、スピーディーにリリースまで持っていけるなら、手段はなんでもかまいません。
アジャイルQAを目指す企業の支援を行うときに、ロードマップを立てたりするのですが、「今、QA部がテストをしているから、アジャイルQAでもQA部がテストする」と考えるお客さまが多いです。それでも良いとは思いますが、現状を基準としてしまうと、本来あるべき姿に近づけなくなる可能性があります。人間はついついできることをやろうとしてしまうものですから。
よって、「誰が」や「何を」を考える前に「どうなりたいか？」を考えるといいでしょう。どうなりたいかに合わせて、やることとやることとやる人を考えるのです。
品質エンジニア
品質エンジニアはプロセス全体の品質をエンジニアリングの力で高められる存在です。アジャイルQAでは以下のような責務を定義できます。
- チームが合意する品質指標（例として速い開発スピード、バグの少ないコード、トラブルの起きないCI/CDなど）を達成するためのリードを行う
アジャイル開発では、様々な活動が行われますが、そのすべての活動を俯瞰的に見て、活動全体の品質を改善していくのが品質エンジニアの責務です。
そのためには、チームが合意している品質の指標を決める必要があります。残念ですが、従来型の指標（たとえば、バグ収束曲線など）は、アジャイル開発ではあまり役に立ちません。
よって、これまでビジネスが見てきたKPIやKGIといった指標や、エンジニアリング側ではDevOpsで注目されている4 Key Metricsなど、新しい指標を選択し、チームでその指標を追いかけていきます。
それぞれの活動で活躍する人はいるかも知れませんが、バラバラにがんばってもうまくいきません。たとえば、ある指標が向上して喜んでいたとしても、別の指標に影響が出て下がってしまったら、成功かどうかの判断が難しいはずです。
すべての活動において品質改善の活動ができなくても問題ありません。専門知識がなくても、専門知識を持った人たちをサポートすることはできます。また、専門知識があれば、その場所で改善の中心的な役割も果たせます。
品質エンジニアはその名の通り、テストという活動に閉じこもるのではなく、それ以外の活動にも積極的に関わっていく幅広い活動が求められます。
エンジニアリングマネージャ、スペシャリスト
テストエンジニア、品質エンジニアとキャリアを積んできたなら、エンジニアリングマネージャやスペシャリストへの道も切り開けます。
エンジニアリングマネージャは、テストエンジニアや品質エンジニアを支援するマネージャです。開発チームとは別で横断的な組織を指揮し、テストスキルの向上やテスト自動化など、横断的な関心にアプローチもできます。
開発チームが開発に集中できるように、彼らの手の届かない部分にコミットします。たとえば、採用はその中心になるでしょう。また、プロジェクトやプロダクトのリーダーとともにメンバーの評価も行い、メンバーのキャリア形成も支援していきます。
スペシャリストを目指すこともできます。その人にしかできないレベルのテスターを目指してもいいと思います。アジャイルQAと親和性の高い探索テストを極めるのもいいでしょう。マネジメントも一種の特別なスキルと言えます。
アジャイルQAのスキルマップと評価
最後に、アジャイルQAのスキルをまとめたスキルマップとそれを使った評価を考えてみます。IPAのITスキル標準の「ソフトウェアデベロップメント」のスキル領域と熟達度の中から、品質に関わりそうな内容を抜粋すると、「テスト技法」、「品質検査」があります。さらにスキル項目を調べてみると「品質保証と管理」には以下の項目があります。
- 品質マネジメント
- 品質保証と管理
- テスト計画／管理／評価
- パフォーマンス計画／管理／評価
アジャイル開発の場合だとそのまま使えない部分もありそうですが、参考にはなりそうです。これらをふまえて、スキルを洗い出してみましょう。かんたんにカテゴリに分けていますが、自分たちの現場に合わせて細かくカテゴライズしてもいいと思います。
それぞれのスキル項目を、テストエンジニア、品質エンジニアなどにマッピングもしておきます。スキルマップによって、自分のキャリアに必要なスキルを見つけられ、チャレンジできる形を作っていきます。
アジャイルQAのスキルマップ
| カテゴリ | スキル項目 | テストエンジニア | 品質エンジニア | エンジニアリングマネージャ | スペシャリスト |
| 基本 | アジャイル開発の理解 | ○ | ○ | ○ | ○ |
| 基本 | テスト技法の理解 | ○ | ○ | ○ | ○ |
| 基本 | ツールの活用（BTS、チケット管理理ステムなど） | ○ | ○ | ○ | ○ |
| テスト | テスト実行 | ○ | – | – | – |
| テスト | テスト設計 | ○ | – | – | – |
| テスト | テスト計画 | ○ | – | – | – |
| テスト | テスト実行管理 | ○ | – | – | – |
| 品質 | 品質指標の定義 | – | ○ | – | – |
| 品質 | 品質指標の改善計画 | – | ○ | – | – |
| 品質 | 品質指標の改善（開発） | – | ○ | – | – |
| 品質 | 品質指標の改善（開発以外） | – | ○ | – | – |
| 品質 | パフォーマンステスト | – | ○ | – | – |
| 管理 | テスト実行・バグ管理（チームレベル） | ○ | – | – | – |
| 管理 | テスト実行・バグ管理（プロダクトレベル） | – | ○ | – | – |
| 管理 | 障害対応（チームレベル） | ○ | – | – | – |
| 管理 | 障害対応（プロダクトレベル） | – | ○ | – | – |
| 管理 | 品質組織マネジメント | – | – | ○ | – |
| 専門 | 品質分析・評価 | – | – | ○ | – |
| 専門 | 人材マネジメント（育成・評価） | – | – | ○ | – |
| 専門 | 組織マネジメント（チームビルディング・採用） | – | – | ○ | – |
| 専門 | テスト自動化（UT、E2Eなど） | – | ○ | – | ○ |
| 専門 | プロセス自動化（CI/CD） | – | ○ | – | ○ |
| 専門 | 探索テスト | – | ○ | – | ○ |
| 専門 | テスト技法育成 | – | – | – | ○ |
| 専門 | テストエンジニアリング育成 | – | – | – | ○ |
| 専門 | スクラムマスター | – | – | – | ○ |
| 専門 | リリース後データ分析 | – | – | – | ○ |
| 専門 | カスタマーサクセス | – | – | – | ○ |
| 専門 | エバンジェリスト | – | – | – | ○ |
専門分野には、アジャイルQAが身につけるとよいスキルを追記しています。
たとえば、スクラムマスターは、開発チーム全体を俯瞰してみる役割なので、品質エンジニアの幅広い活動ととてもマッチします。
データ分析ができるなら、BIチームのようにリリース後データを用いてPOとバックログの議論ができるでしょう。顧客からの問い合わせをデータとして取り入れるなら、カスタマーサクセス的なスキルも身につきます。
広報的な活動ができるなら、エバンジェリストとしてカンファレンスにスピーカーとして参加してもいいでしょう。結果は採用の品質向上につながるはずです。
アジャイルQAの評価
評価軸は会社の基準に則ってまとめればいいと思いますが、大抵は以下のような習熟度で分かれていると思います。
- サポートを受けて実行できる
- ひとりで実行できる
- チームをリードしながら実行できる
- チームに教えられる
そして、スキル項目にこれを当てはめます。
| カテゴリ | スキル項目 | サポートが必要 | ひとりで実行可能 | リーダーシップの発揮 | 教育可能 |
| 基本 | アジャイル開発の理解 |
習熟度が上がると、左から右へとチェックがついていきます。細かく見るなら、それぞれにレベル（レベル1が一番低くレベル5が最高などの基準）をつけて、「ひとりで実行可能のレベル3」というふうに成長を計測していきます。
まとめ
ここで紹介したスキルマップや評価は、あくまで一例でしかありません。ただ、育成や評価のためには、こういった「地図」が必要です。
共通の地図を持ち、同じ地図を元に被評価者と評価者が認識を合わせることで、共通のゴールを意識できるようになり、チャレンジしたりそれをサポートしたりできる体制が整います。
