今回は、第5回の「営業」の回に続き、再び「幕間」として、技術とは少し異なる、しかしQAエンジニアにとっては避けて通れないテーマについてお話しします。
そのテーマとは、「品質」です。
QAエンジニアと名乗る以上、「品質」という言葉は常に私たちの隣にあります。
私はこの言葉をなんとなく分かった気で使っていました。
そして、(今となっては幸いなことに)あるタイミングで、この言葉を明確に言語化する必要に迫られました。
その過程で出会ったのが、TQMという品質マネジメントに関わる包括的な方法論です。
私自身、TQMの専門家と呼べるほど成熟しているわけではありません。しかし、この考え方に触れたことが、私が「品質」をどう捉え、それをどう自分のキャリアの土台とするかに、決定的な影響を与えました。
今回は、このTQMという概念を通じて、私がどのように「品質」という言葉に向き合ってきたかをお話しします。
記事一覧：技術を土台にして自分なりのQAエンジニアを組み立てる -あるQAの場合
“品質”という言葉を使うことの畏れ多さ
「品質」という言葉は開発現場でよく使われます。
一方で、「品質はなんもわからん」と口にするベテランのエンジニアや品質保証の専門家も多く見受けられます。
QAエンジニアとして「品質」という言葉を意識し始めた頃、私自身はこう思っていました。
「“品質”という言葉を軽々しく使ってしまうことは失礼に当たるし、本質を理解していないことになる」
今振り返ると、自分の虚栄心からそう思い込んでいたのかもしれません。
今でも「品質」という言葉を使う時には、多くの人が思い悩みながらも言語化を避けてきた恐ろしさ、そして先人達への畏れ多さを感じずにはいられません。
それでも、あえてその「魂」の部分に向き合い、自分なりに腹落ちさせるプロセスを経たことは、私のQAエンジニアとしてのスタンスを大きく変えるきっかけとなりました。
QAエンジニアという職能の捉え直し
現在の日本のソフトウェア開発現場において、『QAエンジニア』といえば、『テストをする人』や『テストの専門性を持っている人』を指しているのが実情です。私自身もその一人です。
しかし、TQMにおける「品質保証」という視点から捉え直すと、QAエンジニアの職能はもっと大きな範囲に広がるのではないか、と考えられるようになりました。
「顧客との間で明示的に約束しようがしまいが,徹底的に満足させてやろうとすること」
『マネジメントシステムに魂を入れる』p.54
TQMでの「品質保証」について学んだのはこの書籍ではないですが、私がこういった捉え方と出会ったとき、私はこの上なく自由さを感じました。私のQAとしての活動に、文字通り魂が宿ったと感じました。
そして、この目的を達成するためには、いわゆる「テスト」という活動だけでは不十分だと私は考えています。
私がSqriptsなどのプロフィールで、単なる「QAエンジニア」ではなく、あえて「テストに専門性を持つQAエンジニア」と書いているのには、実はそうした背景があります。
私はあくまで、「テストの専門性」を土台（強み）として持っているQAエンジニアに過ぎないと考えています。そう考えれば、世の中にはもっと多様な土台を持つQAエンジニアがいて良いはずだと思うのです。
- プロダクトマネジメントに専門性を持つQAエンジニア
- SREに専門性を持つQAエンジニア
- カスタマーサクセスやマーケティングに専門性を持つQAエンジニア
どのようなバックグラウンドであれ、「品質」という目的のためにその専門性を発揮するのであれば、それは胸を張って「QAエンジニア」と名乗ってよいのではないか。
TQMの思想に触れる中で、私はそう確信するようになりました。
品質保証を広義に捉えることの危うさ
「品質保証」をこういった広義に捉えることはある種の危うさをはらんでいます。
それは「品質保証の責務を押し付けられた」あるいは「QAが品質保証を放棄した」と捉えられることです。
現実との差分として、そういった捉え方をするのは自然なことだと思います。
だからこそ私は今まで語ってきたさまざまな専門性と接続して、建設的に、そして納得感を持ってチームに実装していく必要があると感じています。
専門性の組み合わせ
「品質」という概念を深掘りしたことによって、他の専門性との結びつきもより強固になりました。
スクラムマスター（アジャイル）との組み合わせ
「品質」という言葉の本質を捉えようとすると、「アジャイル」という概念がより鮮明に理解できるようになりました。
例えば「アジャイルソフトウェア開発宣言」で語られている価値観は、驚くほどTQMの思想と合致しています。 品質を単なる「仕様通りであるか（品質特性）」だけで理解するのではなく、「顧客にとっての価値」や「提供側としての在り方」という本質的なところから考えることなどです。
スクラムやアジャイルの実践は、単なるフレームワークの導入ではなく、「本質的な価値提供のために、我々はどう行動すべきか」という問いをより強固なものとします。品質への深い理解は、アジャイルなチームビルディングを行う上での強力な土台になると考えるのです。
テストマネジメントと品質マネジメント
かつての私は、「テストマネジメント」と「品質マネジメント」をほぼ同一のものとして捉えていました。しかし今は、これらを明確に区別して考えています。
品質マネジメントという全体の中に、テストマネジメントが位置づけられる。
この視点を持つと、テストの役割がより柔軟に見えてきます。 品質を作り込むために、テストはどうあるべきか。
そう考えると、典型的には「シフトレフト」の必要性にまず気付けると思います。
あるいは、「シフトライト」や「運用でカバーする」という判断、さらには「オブザーバビリティ」を高めることや、マーケティングの視点からのフィードバックが必要になるかもしれません。
「テスト」という枠組みを超えて、様々なステークホルダーと「品質」を共通言語に会話ができるようになる。これが、品質マネジメントの視点を持つ最大のメリットだと感じています。
実務において、「品質」を脇に置くことも考える
正直なところ、実務の現場において、「品質とは何か？」といった哲学的な議論を頻繁に持ち出すべきではないと私は考えています。
定義論争は時に不毛なものになりえます。
特にQAエンジニアの実務において、個人の胸の内に留めておくということもチームを健全に前に進めるためには必要になるでしょう。
私自身、哲学的な議論が大好きです。
一方で 「私たちはどういった世界を実現したいのか」、 「そのために、お客様やステークホルダーにどういう状態になってほしいのか」、そういったことを建設的に議論するほうが、プロジェクト、あるいは世界は前に進むことも多いでしょう。
大切なことは「顧客満足のために在りたいスタンスを取り続けられること」だと思っています。
そしてその議論の中で使われる言葉は、必ずしも「品質」という言葉でなくても構わないと思っています。
「品質」という言葉を使ってしまうと、今まで「品質」という言葉をつかってこなかったチームにとってマウントを取られた気分になりえます。
実際に私は「QAエンジニアとして品質について理解している」そういった気持ちでいたことがあります。
そんな時に、別の言葉で表現したり、脇に置いて前向きに対話していくことで、私は「いきいきとした」チームになっていく姿をたくさん見てきました。
そして、それこそが品質を扱う私の働き方の醍醐味だと思うようになったのです。
それでも品質を言語化すること
最後まで読んでいただきありがとうございます。
本稿を読まれた皆様は、「QAエンジニア」を名乗っている、あるいは目指しているのではないでしょうか。
皆さんのアイデンティティの核である「品質」、あるいは「品質保証」について、一度じっくりと考え、自分なりの言葉で向き合ってみてはいかがでしょうか。
ここであえて、私なりに品質について一言で表しましょう。「誰かがハッピーになること」です。
「品質」。
畏れ多い言葉です。
しかし、そこから逃げずに自分なりの答えを持てた時、それは「自分はなぜここにいるのか」「自分の専門性はどこで活かせるのか」という、QAエンジニアとしての揺るぎない土台になると、私は信じています。
参考文献
- 書籍『マネジメントシステムに魂を入れる』／飯塚悦功（著）、公益財団法人日本適合性認定協会（編集）日科技連出版社、2023年
- やまずん、QAとしての自分の考えを表明するためのポジションペーパーhttps://55ymzn.com/me/positioning_paper_of_qa/
