タイトル未定

品質や趣味について語りたいブログ

悲観的意見の伝え方

 

qiita.com

1日目の記事です。

すでに投稿時点で日付が過ぎています。まぁ、こまけぇこたぁいいんだよ。

まだネタが不足しているので、twitterやpeingからコメントやDMなどいただけると幸いです。

 

 頂いたお題

twitterにて頂きました。ありがとうございます。

「QAの悲観的思考をポジティブ思考であるべきマネージャーや開発者にどう伝えるのがプロジェクトにとってベストなのか?とかどうでしょうか。」

技術といえば技術なようで、マインドといわれればマインドのような。

ソフトスキルのお題です。

 

悲観的な考え

JSTQBのFLシラバスでもテスト担当者のマインドセットとして悲観的な考えが挙げられています。

1.5.2 テスト担当者と開発担当者のマインドセット

(中略)

テスト担当者のマインドセットには、好奇心、プロとしての悲観的な考え批判的な視点、細部まで見逃さ ない注意力、良好で建設的なコミュニケーションと関係を保つモチベーションが必要となる。

(引用元 : http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018.J03.pdf)

 

テストをする上で「こうなってほしくない」「こんなことが起こるかもしれない」と自分達のプロダクトやサービス、プロジェクト進行についてリスクを考えることは大切な要素です。

しかし、「仕様と異なる動作がありました」「エラーが発生しました」であれば伝えやすいですが、「この仕様で問題ないですか」「エラー起きないですか」とは聞きにくいこともあります。

 

伝え方の工夫

自分の中で工夫をしているといいますが、気をつけていることは次の四点です。

  • 決めつけない
  • 理由を説明する
  • 理由をきく
  • 解決策も提案する

 

決めつけない

リスクを考えること自体は正しいことです。

しかし、「絶対に〇〇」と決めつけてはいけません

 

「この仕様、絶対に問題がある」

「ユーザーにとって、このUIは絶対に良くない」

少なくとも一度はこのように感じたこともあると思います。事実、自分はそう思ってしまうことが今でもあります。

 

しかし、その仕様も誰かが考えて作ったものです。

もちろん、入念に考えた上でも考慮が漏れることはあるかもしれませんが、頭ごなしに否定されては修正時のパフォーマンスにも影響しかねません。

法的にルールが決まっているために見栄えや使い勝手が悪いこともあり得ますし、色々なリスクを考えた上で複雑になってしまっているのかもしれません。

 

理由を説明する

懸念を伝えるのであれば、理由も添えるようにしてます

当然といえば当然に思えますが、暗黙的に「わかるだろう」と思ってしまい理由を伝えていないこともあるかと思います。

 

なぜそう思ったのか。どうしてそれが問題なのか。

それらの情報があることで、そのリスクをどう扱うかの判断がしやすくなります

ものづくりの人がものづくりになるべく専念できるよう、渡せる情報はしっかり渡します。

 

また、理由を伝えることで他の誰かがそこから派生して新たなリスクを見つけられるかもしれません。

見えていなかったところでリスクヘッジされていた、ということもありえます。

 

理由をきく

一方的に伝えるだけでなく、理由をききます。

仕様は〇〇となっているが、どんな理由・意図があってそうなっているのか。

 

例えば設計上、そのような対応を取る必要があるのかもしれません。

「本当はそう実装したくないけれど、そうせざるを得ない」ということがそこから汲み取れます。

設計に問題がある箇所をこれで把握できました

その情報は今後のテストでも活かせますし、リファクタリングなど改善を進める上で問題箇所として挙げられるようになります。

 

例えば法務部門に相談したら、そう表示しないとダメだと指摘されたのかもしれません。

自分の知らなかった法的に必要な対応があったことを知ることができます。

こちらも以後の観点として使うことができます。

 

といった具合に、自分の知らなかった知識や観点、設計や環境による影響を知ることができます

 

解決策も提案する

「問題じゃないですか」と懸念だけを投げられるとどうなるでしょう。

1件2件ならまだ良いですが、それが何件も続くとなると「またかよ...」と精神的にも苦痛でしょう。

本来の作業を中断して対応を考える必要もありますし、正解のない問題も多々あります。

 

協力してプロジェクトを進め、良いプロダクト・サービスをつくることが目的であるはずです。

自分の担当、専門じゃないからと無関心ではなく、「自分はこう思っている」と伝えることが大事です。

 

イデアを提案しなければ、自分の思ったとおりの修正がされないことのほうが多いでしょう。

そうなると、また「問題があります」と報告することになるかもしれません。

また、自分の思っている解決策が問題をはらんでいる可能性も十分にあります。

 

 

 

最終的に良いプロダクトを目指すのであれば、
相手(チーム)を尊重し、背景の理解に努め、必要な情報や自分の考えを出し惜しみせず率直に伝えることが重要だと思います。

 

 

(追記)まとめ

twitterにて「一言でまとめると?」と問いを頂き、自分ではうまくまとめられなかったのですが良いアンサーをいただけたのでこちらにも引用にて掲載します。

 

自分が最初に一言でまとめた言葉は、「“悲観的な考え”は否定的であってはいけない」です。

悲観的であることと否定的であることは等価ではありませんし、

(よほどの意思表示でなければ) 否定的に伝えることにポジティブな効果はないため、否定的であることを否定しようとしています。

 

その後まとめて頂いた言葉が次のtweetになります。

 こうして反応をいただけるだけで本当にありがたいです。

(それなりにエゴサもしていますので、反応をしていただけると喜びます。)