スペシャルインタビューvol.3
QAエンジニアはパートナーであり
重要な存在だと考えている
QA部門のリーダーとして
QAの業務全般とマネジメントに従事
開発のパートナーとも言えるQAエンジニアの業務内容や立ち位置は?
我々開発チームは製品を作る部門であるため、どうしても開発者視点で製品を見てしまいます。それをQAエンジニアがユーザー視点で厳しく製品を見て、品質を担保してくれる。本当にありがたいですね。
開発エンジニアとQAエンジニアは基本的に対等な立場にあるべきだと思っています。開発チームの力が強くなると、ユーザビリティの良くない製品ができたとしてもなかなか意見しづらいです。QAチームの力が強くなりすぎると、技術面よりもユーザーの使い勝手ばかりが重視されてしまい、製品のバランスが悪くなってしまいます。
そういう点では、弊社の開発チームとQAチームは双方の意見を交換しながら製品を作り上げていくので、その結果が製品のクオリティに反映されていると感じます。
「技術や性能を重視した独創的な発想」と「ユーザーにとっての使いやすさ」。それらが合わさったものが製品の価値だと思うんです。それが開発エンジニアとQAエンジニアの役割で、お互いの強みと弱みを補い合う関係ですね。
私自身は開発経験が豊富というわけではないので、プログラミング技術を持つ方たちは素晴らしいと思っています。とは言いつつ、そういう人たちが作ったものに対して厳しい視点を持たなければいけないし、逆に開発者の意図もくみ取らなければいけないのは、この仕事の難しいところですね。
QAエンジニアの方々は日々、製品の品質を俯瞰して見てくれているので、その経験は開発者にとって重要です。開発者が「すごくいいものを作った!」と思っていても、QAエンジニアからのフィード・バックによって我々が気づく視点は非常に多いんです。
自分たちの製品を俯瞰して見られるように、他社の製品と比較するなどして常に意識していますね。やはり自社製品ゆえに、どうしても「自分たちの製品が一番だ」と思って見てしまうところはあるので、第三者的な目で見るように心がけています。自分たちではわかりやすいと思っていても、ユーザーにとっては複雑なものだったということがよくありますからね。
ユーザーからの取扱説明書に関する問い合わせを見ると、自分たちの視点はまだまだだと気づくことがありますね。
マニュアル修正やユーザーからの問い合わせ対応におけるQAエンジニアの介在価値とは?
以前、マニュアルの見直しを提案してもらったことがありますね。
製品の次期バージョンの検証作業に備えて、現行バージョンのマニュアルを閲覧していたんです。そうしたらインストールの手順内容が、特定の環境のユーザー向けになっていたことに気づきました。
一般的な環境のユーザーに向けた手順も記載がないと、間違ってインストールされたり、そのまま使用されたりすることが想像できたんです。そのため全てのユーザーに適用できる内容に書き換えてもらうよう手配しました。
あと、ユーザーからの問い合わせ対応でもQAエンジニアの存在は大きいですよ。
弊社ではユーザーの不具合に対する問い合わせはまずサポートチームが窓口になりますが、技術面の細かい問題はQAチームが解決してくれます。
技術面に関する問い合わせのすべてを開発チームが請け負っていたら、開発業務が止まってしまいますからね。QAチームのメンバーは技術的な知見も備えているため、そこで吸収してもらえるのは本当に助かります。
もちろんその中でも開発チームが対応しなければいけないケースはありますが、まずQAチームで障害状況を精査したうえで情報をもらえるほうがスピーディに対応できますから。
サポートチームに来た問い合わせは、QAチームでも独自調査をして精査し、優先順位の高い重篤な問題と判断したものは毎週行われる開発チームとの定例会議で共有します。「こういう問い合わせが来ていますが、これを解消するにはどのくらい時間がかかりますか?」「そもそも改修はできますか?」といった感じですね。
悔しいですが、自分たちは完璧だと思っていても、ユーザーからの問い合わせは必ず来ます。それが単純に不具合なのか、使い勝手が悪いのかは調査をしなければいけません。お褒めの言葉以外の問い合わせが来るということは、まだ我々の製品が完璧ではないということ。
その解消手段はいくら考えても尽きないことが難しくもあり、面白いところですね。
まだまだ自分に与えられているミッションは多く、それを1個1個解決していくのは楽しいですね。
イーブンな関係だからこそ実現できる本質的な提案
開発チームにとっては改修時にQAエンジニアのありがたみを特に感じます。ちょうど1年くらい前、大きな改修が入ったんですよね。その時は、通常の検証フェーズよりももう少しブレイクダウンした細かいフェーズでテストしないか、と提案をしていただいたことが印象に残っています。確か定例会議で話し合って、大改修の後は対処が難しい場合があるので、そのほうが早い段階で課題を見つけ出せてリスクを下げられる、という話でしたね。
そうですね。Logstorage8で一部のGUI仕様が大幅に変更されたため、改修規模が大きくなりました。改修規模が大きい場合、リリース直前に製品を検証すると問題発生した時の手戻りなどに大幅な時間が取られます。また、その後の再検証で納期が遅れることがあるため、開発フェーズを通常より細分化して検証を行うのが妥当と判断しました。
この作業のおかげで多くの問題点を早めに見つけることができて、不具合を早急に改修できました。QAチームと定例会議で話し合うことで、QAエンジニアに開発過程を見守ってもらい、「当初考えていたような検証期間だとリスキーじゃないか」とか、冷静な判断をしてもらえて本当に助かっています。
我々が目指したい品質保証は、単に仕様通りに動作しているかをチェックすることではありません。「我々のユーザーが使いやすいと思っていただけるかどうか」「想定された利用シーンで機能する仕様になっているか」「矛盾していたり、一貫性に欠けたりする箇所がないか」など、開発者の目線だけではカバーしきれない部分をクリアしてこそだと思っています。
これだけ高い品質が担保されているからこそ、Logstorageは「長くお客様から選ばれる製品」につながっているのだと思っています。
多くの人はQAエンジニアって「テスター」や「バグ・ハンター」と捉えていると思うんです。もちろん、テストで不具合を見つけることも仕事のひとつですが、それはあくまで一部でしかないです。
私が考えるQAエンジニアは、「ものづくりに携わる全ステークホルダーのハブ役」だと思っています。開発視点とユーザー視点を持ちつつ、常に全体最適を追究していかなければならないポジションです。
「製品機能の利便性」と「ユーザビリティ」、「品質検証コスト」などを総合的に踏まえ、状況により変化する優先順位を勘案しつつ、臨機応変にアクションする必要があります。
こう言うと難しく聞こえてしまいますが、私はこの仕事にやりがいと誇りを感じています。技術を核として、幅広い業務に携わることができるQAエンジニアの魅力を、もっと色々な人に知ってもらいたいなと思いますね。
そもそもQAとは「Quality Assurance」の頭文字を取った略称で、日本語では「品質保証」となります。QAエンジニアの仕事は多岐にわたりますが、主に「ユーザー問合せ調査」「不具合原因分析、検証作業対策やワークアラウンド策定」「出荷前動作検証」「ユーザビリティ検証」「検証の見直しと改善」があります。
これらは一見、関連性のない業務に見えますが、すべてつながっています。まず、「ユーザー問合せ調査」「不具合原因分析、検証作業対策やワークアラウンド策定」により、ユーザーにとって使いづらいポイントや、不具合が多発しそうなポイントを洗い出し、「出荷前動作検証」「ユーザビリティ検証」の項目に追加していきます。検証結果から導き出された内容を実行することで、ユーザーからの問い合わせを削減し、新たな「ユーザー問合せ調査」に活かしていきます。こうした「検証の見直しと改善」を繰り返していくことで、ユーザビリティと品質を向上させていくサイクルができあがります。
QAエンジニアはGUIベース(画面上の操作)の検証よりCUIベース(コマンドライン上の操作)の検証が多いため、専門的な知識が必要ですね。