この連載では、ソフトウェア開発のQAエンジニアとして働き始めた皆様に向けて、私の実体験をもとに「こんなことを知っておけばよかった」という、ちょっとした気づきを共有します。
一緒にソフトウェア開発のQAエンジニアとしての充実したエンジニアライフを築くためのヒントを探っていきましょう。
＜QAエンジニアのスタートガイド 記事一覧＞※クリックで開きます
ソフトウェア開発は、一般的に、多くの専門家からなるチームによって行なわれます。
また、ソフトウェア開発は創造的であり、高度で知的な作業が伴うため、チームワークや人間性への配慮は、生産性や品質を含むさまざまな結果に影響を与えます。
チームワークや人間性への配慮に重要なファクターとなるのは「ソフトスキル」です。
ソフトスキルはQAエンジニアにとっても、より一層重要になります。
QAエンジニアの仕事で特に重要なのは「情報提供」であると考えます。そして、伝え方やマインド次第でチームを守ることもできますし、壊すこともできてしまいます。
本記事ではQAエンジニアにとって重要なソフトスキルについて解説します。
チームで働く
チームの一員として働くということ
QAは多くの場合、1人で価値を届けることはできません。テストを始めとして、誰かが作ったものに対してQAとして貢献することが一般的なありかたではないでしょうか。
つまり、QAはチームを必要としています。
ここで紹介したい品質モデルがあります。JIS X 25010:2013では、利用時の品質の他にも外部特徴・内部特徴・プロセス品質という考え方で整理しています。
利用時の品質にフォーカスするQAは多いと思いますが、プロセス品質もまた重要だと私は考えています。
プロセス品質を大事にしてこそ、良いプロダクトが作れるという考えを私は支持しています。
ソフトウェア開発において、「プロセス」は、ただ単に仕事の受け渡しだけではなく、人のモチベーションやコミュニケーションも含めて考えたほうがよいでしょう。
QAはタスクの受け渡しをするのでなく、チームの一員としてオーナーシップを持ち、プロセス品質にも着目して活動をすることが大切だと考えています。
チームでソフトウェア開発をすることに言及している記事は多くありますが、私は「チーム・ジャーニー」という本をおすすめします。
■チーム・ジャーニー：TEAM JOURNEY 〜ゼロの状態から最強のチームをつくりあげるまで〜（市谷 聡啓 著／翔泳社）
弱さを抱擁できることがQAの強みである
ソフトウェアテストでは、ソフトウェアの故障を見つけたり、欠陥を指摘するということがあると思います。
だからといって、QAは喜びすぎたり、ましてや開発者を非難するような振る舞いをしていてはいけないと思っています。
昔、「こんな悪いコードを書いたのは誰だ」や「なんでこんなバグを作るんだ」というような発言をするQAに出会ったことがあります。
私はそれを大変残念だと思いました。
QAは、プロダクトを通じてプロセスの課題や人の弱点を垣間見ることがあります。
だからこそ、QAは優しい存在になる必要があります。
QAは、礼儀正しく、接しやすく、そして何よりメンバーの弱さを受容するような態度が必要だと思っています。
もちろん、チーム開発にとってそういう行動が好ましいという側面があります。
それだけでなく、これらはQAの倫理として守るべきものではないでしょうか。
欠陥を探して故障を見つけるということは大事なことです。
一方で、そういった立場を使って優位に立とうとしたり、人を貶めるようなことは決してしてはいけません。
弱さを抱擁できることこそが、QAの強さであると私は考えています。
「弱さを抱擁する」というフレーズについては西康晴先生の以下の動画から引用しています。
この動画はQAエンジニアにとってあるべき姿について深い洞察が得られるので、ぜひご覧いただきたいです。
コミュニケーションの方法
コミュニケーションの方法としてさまざまありますが、QAのあるべき姿が試される場面として、3つ紹介します。
ミーティング
ミーティングはチーム開発においては避けられない活動であり、とても重要です。
ミーティングの効果、生産性の議論はエンジニアリングの分野に限らず活発的です。
ここでは、QAの専門性を発揮できる参加の方法を提案したいです。
「俯瞰的に見る」ということ、「目的志向に立ち返る」ということです。
テスト設計をしていて、抽象と具体を行き来することは少なくないと思います。
QAはミーティングのなかで、「どういう議論をしているのか」「何を話しているのか」を俯瞰で見て、時に抽象でまとめ、時に具体によって前に進めることができます。
あるいは、ミーティングの中で目的を見失ってしまうことがあるかもしれません。
そのなかでもQAは、専門性である「目的志向」で、「目的は何なのか」という問いを立てることができます。
ミーティングを通して、チームのプロセス品質を良くしていくことも、QAとして重要な役割だと考えています。
バグチケット
バグチケットを通して開発者にフィードバックすることがよくあると思います。
そのなかでも重要なことは、事実を正確に書く、そして礼儀正しく書くということです。
バグチケットは開発者を批難する手段ではありません。バグチケットはあくまで事実を提示して、チームにとってより良い意思決定を促すために使うものです。
レビュー
レビューでもQAの専門性が発揮されると考えます。
レビューはソフトウェア開発でも重要な役割を持っています。一方、体系的に導入している組織は少ないのではないかと考えています。
レビューはリーディング技法などがある一方で、コミュニケーションもまた重要です。
たとえばJSTQB FLでは、レビューのミーティングについて、体系的な解説がされています。
レビューのプロフェッショナルとして、必要に応じて体系化された技術を実装していくことが、QAには求められていると考えます。
コミュニケーションで大切にしてほしいHRT
コミュニケーションは会話や発信であると捉えている人は多いと思います。
一方で、私は自分自身のマインドもまた重要だと思います。
ここでは「Team Geek」という書籍で紹介されている、HRTという考え方を紹介します。
■Team Geek（Brian W. Fitzpatrick、Ben Collins-Sussman 著、角 征典 訳／O’Reilly Japan）
HRTとは、Humility（謙虚さ）、Respect（尊敬）、Trust（信頼）の3つの単語の頭文字を取ったものです。ソーシャルスキルの三本柱であり、人間関係を円滑にするだけでなく、健全な対話とコラボレーションの基盤になると考えられています。
Humility（謙虚）
自分の考えは、絶対に正しいわけではなく、自分自身もまた欠点を抱えていることを理解することです。同時に常に自分を改善していくことも大切です。
他者に対して謙虚であることも重要ですが、一方で自分に対して謙虚であることも重要です。
例えば、「自分の成果物は完璧な状態で見せなければならない」と思っていれば、それは自分自身を完璧だと思いたいことの裏返しであり、謙虚さを失っていると言えます。
時には不完全な成果物を見せることも必要だと知ることが大切です。自分は完全無欠ではないということを理解して、自分の成果物もまた不完全であることを受容することが必要なのです。
Respect（尊敬）
一緒に働く人の人格や能力を尊重し、心から思いやることです。相手は「開発者さん」といった役割ではなく、人格のある人間であることを認識することでもあります。
特にQAは批判を行うことがあります。
そうした中で成果に対する建設的な批判と性格に対する攻撃的な批難を区別して理解する必要があります。
建設的な批判は、心から他人を思いやり、成果を改善してほしいと願っていないと生まれません。そして、そこに尊敬が含まれていることが重要なのです。
Trust（信頼）
自分以外の人は有能であり、正しいことをすると信頼することです。
チームのメンバーはそれぞれ何かしらの専門家であり、自分とチームに対して恩恵をもたらしてくれていると心から信頼しましょう。
これは批判を受ける際にも重要となります。
仕事の中で批判されているのは成果物であり、自分自身ではないということを理解することが大切です。
また、批判する対象は作成者ではなく成果物であるべきということを肝に銘じておく必要があると考えます。
おわりに
優れたQAエンジニアは、技術的なスキルだけでなく、コミュニケーション能力も高いものです。
チームの一員としての自覚を持ち、HRT（謙虚さ、尊敬、信頼）を念頭に置いて行動することで、QAエンジニアはチームに貢献し、プロジェクトを成功に導くことができます。
コミュニケーション能力は、一朝一夕で身につくものではありませんが、意識して継続的に努力することで、より良いチームとより良い製品を作ることができると信じています。
