とあるQAエンジニアの劣等感を意識した生存戦略

この記事は カオナビ Advent Calendar 2023 (シリーズ1) 18日目です。

https://qiita.com/advent-calendar/2023/kaonavi


## はじめに

QAエンジニアのfenecrg1218です。
最近は [Playwright](https://playwright.dev/ "Playwright") を勉強中です。

前回に引き続き、賑やかしのポエム枠として参加してみます！

:::note info
忙しい人向けの要約

* ないものねだり、他者と比較して落ち込むのはほどほどに。
* 前向きに考えて、自分の武器で闘い小さな成功体験を積み重ねていきましょう！
* （QAの話題はおまけ程度です。）


といった記事になります。
:::


## 記事を書こうと思った経緯

社内/社外、職種は問わず、若手の方々の悩みをよく見聞きします。

1. 改善提案の意見が却下される
2. やりたいことが出来ない
3. 正しく伝わらない

自己肯定感が低く、劣等感の固まりみたいな私も同じような経験があり、未だに悩むことばかりです。様々な方々に支えられながら失敗から学び、私なりの対応策が身に付いてきたので少しでも参考になれば！　と考えました。


## 劣等感と向き合う

まずは自分自身の強みと弱みを知り、武器を選びます。

私はQA/QC職でソフトウェアテストにおよそ15年携わってきました。カオナビでは4年近く勤めています。業務を通じて、ある程度は他者と自分自身が見えてきました。

### ポジティブ

* 「 **ホスピタリティが高いですね！** 」とよく褒められる
    * 自分の武器となる
* 「こんなバグによく気付きましたね！」と褒められる
    *  **探索的テスト** が自分の武器となる
* 業務で困っている人がいれば率先して解決に向けて働きかける
    * 人から感謝されることが多い
        * **人脈、信頼関係、実績の蓄積** が自分の武器となる 
* 他者と比較して情報蓄積、テストツールやテスト自動化に詳しい
    * **他者へ布教して仲間を増やせること** が自分の武器となる

### ネガティブ

* あの人のコミュ力、トーク力には絶対に勝てない
    * 【具体例】自分は手を動かさず、他人を動かすことに長けている
    * 【具体例】人たらしである
        * 苦手分野で血の滲むような改善努力をしても、 **<font color="red">出来る人の当たり前に追いつくだけ、勝つことは出来ない</font>** 
        * （病むぐらいならば無理をしない）
* 目的達成に向けて非情になることが出来ない
    * 空気を読む、他者の事情を汲む、協調性を重視する傾向があるため
* エンジニアほどの技術力があるわけではない
    * 努力は続けているが、業務で即戦力となる技術力があるわけではない
    * エンジニア適性があるわけではない（あるならば、エンジニアをやっていますｗ）
* 身体的、精神的なもの
    * 誰しも何かしらは抱えながら生きている

### ネガティブをポジティブへ

* エンジニア業務やソースコードを多少は理解しているので、**<font color="DeepSkyBlue">QA/QC活動でホスピタリティを活かすことができる！</font>** 
* 「テストツールやテスト自動化」方面で **<font color="DeepSkyBlue">QA/QC、エンジニア間の橋渡し役</font>** になれる！
* ネガティブだからこそ、 **<font color="DeepSkyBlue">他者の悩みに寄り添い、協力することができる！</font>** 

---
上記で選んだ武器を携えて、冒頭1～3の悩みに向き合っていきます。

## 1. 改善提案の意見が却下される

却下される理由が幾つか考えられます。

* （事業として）今はまだその時ではない
* （管理者目線として）今はまだその時ではない
* （過去の背景や経緯を考慮した結果）今はまだその時ではない
* 関係構築が出来ていない
* 日々の仕事振りや実績で説得力に欠けている
* チームメンバーの相性やスキルを最大限に生かすための決断をしている

頭ごなしにただ否定されたとネガティブにならず、冷静になり俯瞰すると見えてくるものがあるはずです。分析するときは **新QC七つ道具でお馴染みのKJ法** がオススメです！

https://www.forestpub.co.jp/author/dokushozaru/lp/mondaikaiketsu/


人脈、信頼関係、実績の蓄積が不十分であれば、まずはそこから改善していくとよさそうです。 **他人の言うことは聞かないが、仲間の意見ならば耳を傾けて協力してくれるかもしれません！** （某ゲーム作品の受け売りですｗ）

「同じことを言ったのに自分は却下されて、あの人は採用された、悔しい！」と思ったときは、下記の書籍を読んでみてください。私はこれで腑に落ちました。

https://www.diamond.co.jp/book/9784478116692.html

## 2. やりたいことが出来ない

弊社では「 [相互選択関係](https://www.dodadsj.com/content/20200629_kaonavi/ "企業は成長機会を提供し、働く人は企業の価値を高める。企業と人は互いに選び合う関係へ | d's JOURNAL（dsj）- 理想の人事へ") 」を採用しています。様々な事情で事業としての優先順位がつけられていき、人によっては納得できない場面が多々あるかと思います。

* 他に出来る人がいない
* 後任が育つまでフォローしてほしい
* 炎上したので助けてくれ

納得できない、面倒なので断る。転職する。個人の自由です。ただ、弊社に限らずどこかの会社に所属して会社員として働くこととは、そういうことも含めた上での選択ではないでしょうか。「困ったときは助け合い」はお互い様であり、会社で働くことの最大のメリットだと私は考えます。

逆に捉えれば、ピンチはチャンスです。 **人脈、信頼関係、実績の蓄積チャンスとして引き受けることをオススメします！　頑張っていればちゃんと見て評価してくれる方々はいらっしゃるはずなので、腐らず、縁の下の力持ちとして実績を積んでいきましょう！** 

:::note warn
※1.　仮に評価されなかったとしても、得られた技術や経験、実績は無駄にはならず、今後の人生でいつか役に立つはずです！

※2.　勿論、どうしても無理なものは断っていいと思います。私も1つだけ丁重に断った記憶がありますが、 ~~（時には面倒くさいなと思いながらも）~~ 殆ど引き受けて実績を出し続けて、最近になり自分がやりたいことが出来るようになりましたｗ　また、案件を手伝うことで知り合いが増えた結果、テスト自動化で困ったときに相談しやすくなりました！
:::


## 3. 正しく伝わらない

例えばですが、テキストベースで説明しても理解してもらえず、口頭だと理解してもらえる、図解すると理解してもらえる場合があります。また、言葉の解釈が一致せず正しく伝わらない/理解できない場合があります。

個人特有、状況など様々な原因があります。 **相手が悪いと考えず自分事として捉えて、他者に寄り添い尊重する行動を心掛けていきましょう。** 信頼関係の構築が出来れば、相手によって伝え方を変えていくことができるはず！

下記はご参考まで。

https://note.com/sugo_ron/n/na8d0916b1f55

https://www.cogtem.com/

https://www.ny-academy.com/teacher-blog/?p=4272

https://www.kaonavi.jp/dictionary/keicho/

https://www.kaonavi.jp/dictionary/communication_cost/

### リモートワークでの問題の場合

下記の書籍を一読すると取っ掛かりを掴めるかもしれません。

https://www.shoeisha.co.jp/book/detail/9784798183916

個人的には下記の辺りが素敵だなと思います！
（一部を抜粋して引用いたします。）

> * 成果の行動基準
>     * 「同意しない、コミットする、同意しない」
> * 多様性、包括性、帰属意識の行動基準
>     * 「小さな攻撃性を受け入れる」
> * 心理的安全性を生み出す7つの方法
>     * 黄金律を破る（自分がしてほしいことではなく、他人に合わせたスタイルで対応する）
> * 心理的安全性を維持しながらフィードバックする方法
>     * 日常的にポジティブなフィードバック、人間味のあるコミュニケーションを行って良い関係性を構築しておくこと
>     * 相手を良くしたい心情を乗せてコミュニケーションをすること

:::note info
「同意しない、コミットする、同意しない」の補足

> * [GitLabハンドブック原文](https://jp-handbook-gitlab.tech4u.dev/handbook/teamops/everyone-contributes/#disagree-commit-and-disagree "GitLabハンドブック原文")
>     * Disagree, commit, and disagree
> * [GitLabハンドブック日本語版](https://jp-handbook-gitlab.tech4u.dev/handbook/values/#disagree-commit-and-disagree "GitLabハンドブック日本語版")
>     * 異論を言う、でもコミットする、その後に異論を言う

書籍とハンドブックそれぞれに目を通して自分なりに解釈したところ、
下記のような考え方のようです。

* 対立を避けたり周りに同調をするため、同意した振りをやめる
* 何も言っても意味がないと諦めて意思決定を委ねず、言うべきことは言う
* 各自が意見を述べた後、DRI(直接責任者:Directive Responsible Individual)が客観的な視点で公正に判断して、結論が出たらその決定を尊重して取り組む



:::

## 今後の立ち位置を考える

QA界隈で話題のQMファンネルで自分を照らし合わせると、
目指すべきところは「TEコーチ寄りのPEコーチ」なのでしょうか。

私が苦手とする「トーク力」が武器の人は「QAプロモーター」がよさそうですね！

https://speakerdeck.com/gen519/qmhuannerutoqakiyaria

## おわりに

ネガティブな誰かの役に立ったら幸いですｗ

お読みいただきありがとうございました！
明日のカオナビ Advent Calendarもお楽しみにです！！

https://corp.kaonavi.jp/recruit/recruitment/