【第5回】コミュニケーションが鍵を握る｜QAエンジニアのスタートガイド

この連載では、ソフトウェア開発のQAエンジニアとして働き始めた皆様に向けて、私の実体験をもとに「こんなことを知っておけばよかった」という、ちょっとした気づきを共有します。
一緒にソフトウェア開発のQAエンジニアとしての充実したエンジニアライフを築くためのヒントを探っていきましょう。

＜QAエンジニアのスタートガイド記事一覧＞※クリックで開きます

ソフトウェア開発は、一般的に、多くの専門家からなるチームによって行なわれます。

また、ソフトウェア開発は創造的であり、高度で知的な作業が伴うため、チームワークや人間性への配慮は、生産性や品質を含むさまざまな結果に影響を与えます。

チームワークや人間性への配慮に重要なファクターとなるのは「ソフトスキル」です。

ソフトスキルはQAエンジニアにとっても、より一層重要になります。

QAエンジニアの仕事で特に重要なのは「情報提供」であると考えます。そして、伝え方やマインド次第でチームを守ることもできますし、壊すこともできてしまいます。

本記事ではQAエンジニアにとって重要なソフトスキルについて解説します。

チームで働く

QAは多くの場合、1人で価値を届けることはできません。テストを始めとして、誰かが作ったものに対してQAとして貢献することが一般的なありかたではないでしょうか。

つまり、QAはチームを必要としています。

ここで紹介したい品質モデルがあります。JIS X 25010:2013では、利用時の品質の他にも外部特徴・内部特徴・プロセス品質という考え方で整理しています。

利用時の品質にフォーカスするQAは多いと思いますが、プロセス品質もまた重要だと私は考えています。

プロセス品質を大事にしてこそ、良いプロダクトが作れるという考えを私は支持しています。

ソフトウェア開発において、「プロセス」は、ただ単に仕事の受け渡しだけではなく、人のモチベーションやコミュニケーションも含めて考えたほうがよいでしょう。

QAはタスクの受け渡しをするのでなく、チームの一員としてオーナーシップを持ち、プロセス品質にも着目して活動をすることが大切だと考えています。

チームでソフトウェア開発をすることに言及している記事は多くありますが、私は「チーム・ジャーニー」という本をおすすめします。

ソフトウェアテストでは、ソフトウェアの故障を見つけたり、欠陥を指摘するということがあると思います。

だからといって、QAは喜びすぎたり、ましてや開発者を非難するような振る舞いをしていてはいけないと思っています。

昔、「こんな悪いコードを書いたのは誰だ」や「なんでこんなバグを作るんだ」というような発言をするQAに出会ったことがあります。

私はそれを大変残念だと思いました。

QAは、プロダクトを通じてプロセスの課題や人の弱点を垣間見ることがあります。

だからこそ、QAは優しい存在になる必要があります。

QAは、礼儀正しく、接しやすく、そして何よりメンバーの弱さを受容するような態度が必要だと思っています。

もちろん、チーム開発にとってそういう行動が好ましいという側面があります。

それだけでなく、これらはQAの倫理として守るべきものではないでしょうか。

欠陥を探して故障を見つけるということは大事なことです。

一方で、そういった立場を使って優位に立とうとしたり、人を貶めるようなことは決してしてはいけません。

弱さを抱擁できることこそが、QAの強さであると私は考えています。

「弱さを抱擁する」というフレーズについては西康晴先生の以下の動画から引用しています。

この動画はQAエンジニアにとってあるべき姿について深い洞察が得られるので、ぜひご覧いただきたいです。

コミュニケーションの方法としてさまざまありますが、QAのあるべき姿が試される場面として、3つ紹介します。

ミーティングはチーム開発においては避けられない活動であり、とても重要です。

ミーティングの効果、生産性の議論はエンジニアリングの分野に限らず活発的です。

続きを読むにはログインが必要です。
ご利用は無料ですので、ぜひご登録ください。