こんにちは。HumanCrestの津久井です。
梅雨も明けて、本格的に暑くなりそうですね。
真夏になると毎年思います。
はやく冬がこないかなぁっと!
※真冬は真冬で、夏が来ないかなぁっと思っているわけですがw
今回は受け取り方と届け方について、僕なりに気をつけていることを書かせて頂きます。
内容的にはQAエンジニアなりたての人に読んでもらえたら嬉しいですね!
ではさっそく。。。
とある僕の先輩は言いました!
「情報をアウトプットすればするほど、不思議と新たな情報が集まってくるもの」
これはまさにその通りで、情報を自分の中だけにとどめていた時より、社内のSNSなどで情報をアウトプットしてからのほうが、意見や補足情報含め、多くの情報に触れられるようになりました。
さらに、他の先輩は言いました!
「アウトプットが無いということは、単純にインプットが足りないからだ!」
これまたその通りで、何も手元になければ、アウトプットなど出来るはずが無いですよね。
上記に紹介した私の先輩方の御言葉はごもっともで、間違いなく自分の中の血肉になっています。
しかし、今回私が書きたい事は、上記に述べた内容とは少し異なります。
受け取り方と届け方について、特に最近考えさせられることが多いこともあり、今回Quesブログのお題にしようと思いました。
QAエンジニアというお仕事ですが、
情報を受け取りに行くこと(インプット)と、収集したことを届けること(アウトプット)が、
非常に多い役割のお仕事だと僕は思っています。
必要な情報の見極め、部署・部門問わず、必要な情報を取りに行くことが出来なければお仕事が出来ないといっても過言ではないかと!
しかも、収集した情報を基に、Test仕様書やCaseなどを作成したり、何らかのドキュメントとしてまとめたりしなければなりません。
なんだかQAエンジニアは、常に走り回っているイメージです。
だからこそ、情報を受け取ること(インプット)と、そこから必要な物を届けること(アウトプット)の速度が非常に重要になります。
“スッと頭に入れて、サッと伝える”
こんな感じです。
私はこの”スッ”と”サッ”をずっと追い求めていますが、ちょっと忙しくなるとなかなか上手くいかなくなるので、
まだまだ修行が足りないですね。。。
■”スッと頭に入れて、サッと伝える”
揃っている資料の数や、コミュニケーションの取り方などは現場ごとに、それぞれやり方があると思います。
それこそ仕様書たるものなど存在せず、開発者の頭の中にしか情報が無いことだってあるでしょう。
そんな時、開発者の頭の中にアクセス出来ればいいのですが、今の時代ではまだそれは出来ませんw
なので、言葉や文章を使って、欲しい情報を得るしかありません。
しかし、技術的な内容がわからない場合、会話がかみ合わないことも。。。
極力無駄を無くすためにも、“何”がしたくて、”どんな”情報が欲しいのかを明確にしましょう。
目的を相手に伝えることが出来れば、必要な情報がサッと出てくるかも知れませんし、
自分自身が知り得たいことなので、結構スッと頭に入ります。
もちろんわからない言葉などは後々、調べることは必要です。(あたりまえか…)
ちなみに「〇〇に書いてあるよ!」っと言われたらすぐに確認しましょう!
〇〇に書いてあるのかっと安心して、確認を後回しにしても何も良いことはありません!
もしかしたら、書いてはあっても、理解できないかもしれませんのでw
ここで僕の反省した小話をひとつ。。。
インフラ関係の知識が乏しい私は、インフラ関連のことを開発者に質問する際、
何がわからないかわからない状態で質問しに行ってしまったことがあり、必要以上に時間をかけてしまいました。
忙しいからといって、事前に下調べを怠って質問しにいくと、かえって時間がかかってしまい、
結果的に誰も幸せになれないことを身をもって痛感。
質問するということは、相手の時間を奪う行為でもあることを理解したうえで質問するように心がけています。
さて、せっかく知り得たい情報が頭に入ったなら、次はサッと伝えましょう!!
具体的にはドキュメントやメールなど、基本的には文章と図にすることになるはずです。
同じQAメンバーにシェアしたり、報告書を作成したり、伝えなければならない状況はいろいろとあると思います。
ここで大切なのは、伝えたいことが何なのかを強調すること。
文章の書き方とか、プレゼンに関するなんチャラみたいな本を読めば大体似たようなことが書いてあると思うので、ここではあまり深くは書きませんが、
ダラダラとした内容になっていたり、情報を詰め込みすぎていたりすると、
結構別口で説明が必要になることが多いように思います。
また、100点満点の資料を時間をかけて作成するよりも、良くても80点くらいの出来で出してしまったほうが、
時間も短縮でき、何より修正が必要になった場合のことを考えると効率的です。
重要なのはたたき台レベルのものが短時間で作成出来るかどうかだと思っています。
■最後に
QAが情報をあちこちからかき集め、その上でアウトプットをすることで、
開発の効率も向上し、情報の伝達漏れなども少なくなり、それが品質の向上につながることもあると思います。
品質を担保するには、テストという行為だけではなく、開発時に散乱してしまった重要な情報を集約することも重要だと思っています。
人それぞれスタイルがあると思いますが、僕はしばらく走り回る感じで行きたいと思います。