日本語「開発生産性の3階層」で考えるQAエンジニアの事業貢献
こんにちは。MagicPodでエバンジェリストをしているYoshiki Itoです。
先日、株式会社ベリサーブ・株式会社MagicPod共催のオンラインセミナー「テスト自動化とQAの事業貢献～3社で語る攻めの品質創造とは～」にて、LINEヤフーコミュニケーションズ野原さん・広瀬さん、ベリサーブ髙田さん・長橋さんと一緒に「QAの事業貢献」についてパネルディスカッションをしてきました。
【オンラインセミナー】テスト自動化とQAの事業貢献～3社で語る攻めの品質創造とは～
当日は時間の制約もあって話しきれなかった内容がいくつかありました。本記事では当日話しきれなかった部分——「QAの事業貢献を、開発生産性という軸でどう整理するか」——について、私なりの考えをまとめてみたいと思います。
そもそも「事業貢献」とはどういうことか
「QAの事業貢献」やこれに類するトピックについて、最近よく聞くようになったと感じています。とくに「QAエンジニアとしてこの先どう生き残るか」といった文脈において、単純に日々目の前のテストやQA活動を行うだけではなく、それがどう事業にとってメリットをもたらしているのか説明できるようにならねば、というQA側の内発的なモチベーションから来ていることが多そうです。 私自身も経験がありますが、例えば一人目のQAエンジニアやQA組織のリーダー・マネージャーとして体制強化や組織を拡大していこうと考えたときなどは、QAによる事業貢献の説明が求められることが多いでしょう。
「事業貢献」をごく単純に捉えると、「売上や利益の向上に寄与すること」と言えます。ただ、QAの業務が直接的に売上や利益の向上につながる、という説明はしづらい部分が多いです。バグを減らすことで機会損失を防ぐ、リリーススピードを上げることで競争優位に寄与する——こうしたロジックは成り立ちますが、「QAがこれをやったから売上がこれだけ上がった」と言い切れる場面というのは、多くはないでしょう。今回のイベントで「QAの事業貢献とは何か」というテーマのディスカッションが成り立つのも、ある意味ではその説明しづらさゆえ、という面もあると思います。
そこで、QAによる事業貢献を考えるうえでのヒントとして「開発生産性」という切り口を用いて、「直接的な売上・利益への貢献よりも、開発組織における開発生産性の向上を通じて、結果として事業に貢献する」というロジックを組み立てるのはどうか、と思いつきました。
ただし、「事業貢献」を考えるための切り口として用いる「開発生産性」という単語自体も、まだふわっとした部分が残ります。「開発生産性を上げましょう」という話をしていると、エンジニアと経営層で全く違う話をしているように見えることもあります。
そこで本記事では、広木大地氏が提唱する開発生産性の3階層を用いて、「QAが開発生産性の向上に貢献するとはどういうことか」を整理し、そこからもとの問いである「事業貢献」まで考えをつなげていきたいと思います。
目次
開発生産性を3階層で整理する
広木大地氏のQiita記事「開発生産性について議論する前に知っておきたいこと」では、開発生産性を3つの層で捉える考え方が紹介されています。
開発生産性について議論する前に知っておきたいこと より
レベル1：仕事量の生産性
「その仕事の価値や売上貢献などはいったん置いておいて、作業量としてどの程度の仕事をこなすことができたのかを評価する生産性」と定義されています。コード量・PR数・ストーリーポイントのベロシティなど、開発チームが日常的に見ている数字がここに当たります。
一開発者やエンジニアリングチームが改善しやすい層で、DORA Metricsに代表されるようなDevOps指標もここに含まれます。エンジニアが「生産性の話」と聞いてまず思い浮かべるのは、この層が中心になります。
レベル2：期待付加価値の生産性
「仕事量だけではなく個々の施策がどの程度プロダクトにとって価値があることなのかを踏まえて評価」する生産性です。リリース前の「期待」段階で評価するため、実際の成果が出る前に計測できます。プロダクト開発組織全体のアウトプットを評価する際に使われます。
言い換えるならば、「ユーザーに価値を届けられそうな仕事を、どれだけ生産できているか」という視点です。
レベル3：実現付加価値の生産性
「売上やKPIなどの実際のサービスに対しての貢献を評価するときに用いる」生産性です。経営層が見ている数字がここに当たります。多くの場合、遅行指標になるため、開発チームだけでなく、CS・セールス・マーケティングなど事業全体の活動が影響します。
QAはこの3階層のどこに貢献できるのか
この3階層に基づいて、QAエンジニアが開発生産性を向上させることについて考えていきましょう。
主に2つのポイントがあります。
- 仕事量の生産性を高める
- 仕事量の生産から期待付加価値の生産への「変換効率」を高める
仕事量の生産性を高める
QAが仕事量の生産性に貢献できる点として、上流からの参加とテスト自動化の2つがまずは思いつきます。
1つ目の上流からの参加について。私自身もQAエンジニアとして「上流からQAが参加したほうがいいですよ」とよくお伝えして、できるだけ早期に関われるようにしていました。
要件・仕様の段階からQAが関与することで、仕様の誤りや認識のずれを早期に発見できる、と言われています。（もちろんドメイン知識やQA自身の能力・スキルに依存する部分もあります。）
開発が進んでからバグを見つけるよりも、仕様段階で修正する方がコストは圧倒的に低いため、手戻りを減らす・未然に防ぐという意味で、開発チームの仕事量の生産性を高めることにつながります。
2つ目のテスト自動化については、開発者へのフィードバックのタイミングを早め、頻度を高めることが仕事量の生産性向上につながると考えられます。基本的な理屈は上記の「上流からの参加」に似ています。問題の特定を早め、コーディングなど開発者にとっての「仕事」を妨げる要素を減らせる可能性があります。
ただし、この「仕事量の生産性の向上」という観点では、QAの貢献よりも生成AIによるコード生成の方が、インパクトははるかに大きい可能性があります。コードを書く速度などは生成AIによって劇的に向上しているため、QAが上流参加やテスト自動化を通じて仕事量の生産性に貢献できる度合い以上に、生成AIによる効果のほうが大きいかもしれません。
仕事量の生産から期待付加価値の生産への「変換効率」を高める
仕事量の生産性が上がったとして、それが必ずしも「ユーザーに届く価値」の増加につながるとは限りません。たとえば、開発チームが本番環境のバグ対応・障害対応・再発防止対応に時間を割いた場合。この間に書いたコード自体も仕事にあたります。しかし、ユーザーに対しての価値提供に時間を割いた、期待付加価値を高めた、とは言い難いでしょう。本当であれば、機能追加や使い勝手の向上など期待付加価値を高める部分に対して時間を使うほうが望ましいですよね。
たとえばQAが未然にバグを検出し、本番リリース前に修正ができれば、障害対応という「仕事量の生産性に計上されるが期待付加価値には寄与しないコスト」を減らせます。つまり、同じ仕事量で、より多くの期待付加価値の生産に充てられるよう、変換効率を高めることができるわけです。このように考えると、QAが期待付加価値の生産性向上に間接的に寄与した、とも言えるのではないでしょうか。
ほかにも、ATDD（受け入れテスト駆動開発）やユーザーストーリーマッピングといったプラクティスは、「ユーザーが本当に求めている価値」を起点に開発活動を定義します。QAがこうしたプラクティスに関与することは、仕事量の生産が「期待付加価値に向かっている」ことを担保する役割を果たします。
まとめると、QAが変換効率を高める手段は大きく2つです。
- ATDD・ユーザーストーリーマッピングなどで、価値と直結した活動の割合を高める
- バグの予防で修正コストを減らし、期待付加価値を生まない仕事を削減する
この整理から見えてくること
3階層モデルの切り口からQAの事業貢献を整理してみると、いくつかのことが見えてきます。
まず、「QAが事業貢献する」と言うとき、私たちはどの層の話をしているのかを意識する必要があるということです。仕事量の生産性を上げる話と、変換効率を上げる話と、実現付加価値の生産性を上げる話では、必要なアプローチがまったく異なります。
次に、生成AIが進化する中で、QAが注力すべきポイントは「変換効率」の方向にシフトしていくかもしれない、という考え方です。仕事量の生産性向上にAIがより大きく貢献するようになるにつれ、「たくさん作ること」よりも「よりユーザーへの価値につながりそうな機能追加や改善を行うこと」「価値に向かっていない活動を減らすこと」の相対的な重要性が上がっていく。QAが担うべき役割は、その方向にあるのではないかと考えています。
おわりに
今回のパネルディスカッションは、普段なかなか深く話せない「QAの事業貢献」という切り口で議論ができた貴重な機会でした。ご一緒したLINEヤフーコミュニケーションズさん、ベリサーブさん、ありがとうございました。
本記事は「これが正解」という話ではなく、私自身が考えたことをもとに「問いのきっかけ」として書きました。QAエンジニアとして、あるいはQAチームと関わる開発者・マネージャーの方が、QAの事業貢献について考える際の材料になれば幸いです。
