エンジニアのための心地よい関係性を築く言葉選び
はじめに
QAであれ、開発エンジニアであれ、ビジネスで開発プロジェクトに携わっている以上は人とのコミュニケーションを避けて通ることはできませんよね。
とはいえ、中には「なるべく人と関わり合いになりたくないからエンジニアをしているんだ！」という方もいるかもしれません。
ということで、そんなエンジニアの皆さんのために、「良いコミュニケーションのためのポイントはコーディングにも通用する」というスタンスで、
コミュニケーションのための大事なポイントをコーディングや開発プロセスに例えながら紹介したいと思います！
…あ、わたくし、SHIFTのいしいと申します。SHIFTはソフトウェアの品質保証の会社なんですが、今回はコミュニケーション品質の向上を目指して筆を執ってみることにしました。よろしくお願いします。
トピック
今回のトピックは以下の3つです。
相手に何かを変えてほしい時は一般論や正論の押し付けより主観的な意見交換をしよう
「XXするの止めてください」ではなく「〇〇してください」と言おう
意見を言うときには自分の立場を事前に宣言しよう
相手に何かを変えてほしい時は一般論や正論の押し付けより主観的な意見交換をしよう
人はつい自分の主張が正当なものであることを示したいがために、「普通は～」「他の人はみんな～」「常識として～」「～～という本では～～と書いてあった」などという表現を使いがちです。
もちろん、べき論や一般論を確認したいという場合もありますから、
このような多数派の意見をご紹介することも時にはあるでしょう。
しかしながら多くの場合、その一般論を実践できない背景には、様々に複雑で複合的な政治的事情というものがあるものです。そういう事情に対して何の配慮も示さずに訳知り顔で、上から目線で一般論を押し付けられて気持ちよく受け入れられる人がどれほどいるものでしょうか？
時間制約のある中、不慣れな開発フレームワークを使って頑張ってコードをGitに上げて、プルリク出したのに、コードレビュアーから「リーダブルコードにも書いてあるかと思いますが、この表現はアンチパターンです。お手数ですが、こちらの表現に変えてもらえませんか」なんて言われたら…。
正論だから言い返せないけど、「お前は間違えている」と言われているみたいで気持ちがしょげくりかえりますよね。（そんなときのための静的解析、Lintツール。機械に言われるのもムカつくけど、人に言われるより100倍マシです）
「ここのコードですが、今後の保守性を考えてどうしてもこっちの表現で統一したいと思っています。お手数ですが、こちらの表現に変えてもらえませんか」だと、面倒だけど、協力してあげようかなって思えますよね。
おでんを一緒に買いに行って恋人友達が「大根はおでんの具ランキング1位なんだよ？入れないとかありえなくない？」って言い始めたらなんかムカつきますけど「おでんの大根メッチャ好きなんだよね！入れてもいい？」って言われたら、全然いいよ！ってなりますよね。
何かを人にお願いするときや指摘をするとき、否定してはいけないとはよく言われますが、一般論の押し付けが相手の否定につながることに気付いている人は実は多くないのではないでしょうか。あるいは分かっていても、つい自分の主張を押し通そうとして多数派や権威の力を借りてしまいがちではないでしょうか。
意外と難しいプラクティスですが、プライベートでも非常に効果的なスキルになるはずです。ぜひ練習してモノにしてみてください！（わたしも練習中です。わかってるんですけどね…むずかしいよね…）
「XXするのやめてください」ではなく「〇〇してください」と言おう
「XXするのやめてください」ってなかなか角の立つ表現ですよね。みなさんはどのように言い換えをしますか？
ちなみにネットで「やめてください 言い換え」で検索したら、「ご遠慮ください」とか「クッション言葉を使おう」とか出てきました。
もちろん。もちろん。そういうのも大事です。特にクッション言葉は相手への共感を示すにあたってすごく便利な表現技法です。ほんの少し共感を示してもらうだけで、人は自分のことを理解してもらえていると思えて安心できるものです。超大事。でもね、そうじゃなくてだね。「やめてください」という否定表現の時点でもうあんまりイケてないんですよね。。。
コーディングでもそうですよね。if文の条件文にはなるべく否定形ではなく肯定形を使うべきだし、bool値の変数名も否定形は避けるべきです。リーダブルコードにも書いてありました
なぜかと言えば、否定形は分かりづらいんです。まず否定形の文章を読み解くには肯定文を理解してそれを反転する必要があります。そして意味が広い。
boolean isNotOden = false; // おでんではないフラグがfalse
if(!isNotOden){ // おでんではないフラグがTrueではないならば
I.eat.oden; // わたしはおでんを食べる
}
…地獄ですね
boolean isOden = True; // おでんであるフラグがTrue
if(isOden){ // おでんであるフラグがTrueならば
I.eat.oden; // わたしはおでんを食べる
}
…圧倒的にわかりやすい！（まあこれは極端すぎる例ですが）
これだけでも否定形の恐ろしさは十分に伝わりそうですが、他の例も見てみましょう。
「これはモチ巾着です」はモチ巾着以外の何物でもないですが、「これはモチ巾着ではありません」はまずモチ巾着を想像して、モチ巾着以外とは何かを想像しなければなりません。がんもどき、さつまあげ、いやまさか・・・たこやき？・・・正解が全然わからないですよね。
「デスクでの食事はご遠慮ください」だと外で食べてこいということなのか、食堂があったりするのか、臭いのしないものなら実はOKな可能性も…？あるかもわかりませんよね。「食堂をご利用ください」「デスクでの食事は12～13時の間のみ可能です」ならするべきことが分かりやすいです。
もちろん、この場合はデスク以外での食事は基本的にOKということだと思われますので、「デスクでの食事はご遠慮ください」は間違った表現ではないものと思われますが、あわせて食堂の場所や外食できる場所の案内があったらとても親切ですよね。
ということで、選択の幅があることを示すために否定形の表現を使う場合でも、あわせて肯定文での選択肢の例示や提案があると分かりやすくて素敵かと思われます。
意見を言うときには自分の立場を事前に宣言しよう
※立場というのは、同意、部分同意、反対、質問などの立場のこと
コーディングする時には、これから書くものがメソッドであるのか変数であるのか、データ型は何かなどをあらかじめ宣言しますよね。
口頭で何かを議論するときも同様で、これから何を言うのか、それが賛成意見なのか反対意見なのか、もうちょっと深掘りしたいから質問をしようとしているのか、あらかじめ宣言をしましょう。そうすると聞き手の負担がぐっと減ります。
聞き手側が「この人は何を言おうとしているんだろう？」とあれこれ想像を巡らせて頭をガンガンに働かせていると、聞き手側はリソース不足になり、優しい笑顔や声音を作るプロセスを強制終了しています。これは悪意があるからではなく、リソース不足によるメモリ解放が行われるからにすぎません。
しかしながら話し手側はこれにより変なことを言ってないはずなのに、「自分の発言が歓迎されていない」と感じてしまうことになります。誰にとっても不幸でしかないので、是非とも最初の立場表明を忘れず議論するようにしましょう。
いやいや、開発言語の中には動的型付け言語もあるじゃないか。
メリットがあるから存在しているんだろう？という意見もあるかもしれません。そうですね。動的型付け言語にもメリットがあって、「とりあえず書き始める」という点では非常に優れています。
話慣れていない人は「まず言葉を発することに慣れる」ことを目的に宣言なしの動的型付け言語的スピーキングから始めるのもいいでしょう。ただしこの場合は相手の反応をいちいち気にしてはいけません。自分の言いたいことが言えたかどうか？だけを評価対象にし、一通り言えたらそれは100点満点として処理してしまいましょう。
なお、議論の時の事前宣言の有無によるメリデメは動的型付け、静的型付け言語のそれと同じです。チーム開発する以上は静的型付け言語的な事前宣言付きの会話に少しずつでも良いのでシフトしていけるとよいですね。
また類型のよくあるアンチパターンが、
Aさんの「わたしはXだとおもいます」という発言に対して、
Bさんが「わたしはYだと思います」と言ってしまうケースですね。
もう少し具体化してみましょうか。
議題：今日のおでんの具
A「わたしは大根と白滝とちくわがあれば十分です」
B「わたしはたまごとモチ巾着とはんぺんが食べたいですね」
A「大根はおでんのだし汁を吸って一番おでんらしい味がするし、あの味の染み出す感じが最高でしょう。外せません。」
B「たまごの濃厚な味わいや黄身と白身の食感の違い、おでんの汁と黄身を混ぜて食べる味変を楽しめないおでんはおでんと言えるのでしょうか」
…Bさんが賛成・反対を宣言しなかったので、Aさんは全否定されたと思って、自身の意見の補強を始めてしまいました。それに対してBさんも、
自分の話を無視されたと思って自身の話の補強を始めてしまっています。
これでは話が収集つかなそうですね。コーディングで言うと値の受け渡しを行わない二つのメソッドを順繰り呼び出しているような感じでしょうか。
Bさんの会話を宣言型に変えてみましょう
A「わたしは大根と白滝とちくわがあれば十分です」
B「大根最高ですよね。そこは同意です。私も外せないと思います。あとはわたしはたまごと持ち巾着とはんぺんが食べたいですね」
A「同志よ。大根を共有できてうれしいです。たまご、忘れてました。私もたまご食べたいですね。その二つは確定として、残りの具材をどうするか検討していきましょうか」
B「そうですね。まずはあっても良いものと、ない方が良さそうなものを振り分けましょうか」
…これは話がうまく進みそうですね。Bさんが部分同意というかたちで自身の方針を示してくれたので、Aさんも安心して相手の意見に同意しつつ話を次に進めようとしてくれています。
ひょっとするとこの後はんぺんを巡った血みどろの戦いが繰り広げられるかもしれませんが、これならずいぶん早く話が進みそうです。
このように、意見を言うときには前の話を受けて、自分がどこまで同意、理解しているのか、それに対して自分がどういう立場なのか、きちんと明示することで、相手の思考の負荷を下げるとともに心理的な安心感を与えることができます。
（"前の話を受けて"宣言するのは、コーディングにおける宣言とは違うのではないかと思ったそこのあなた。気のせいです。見逃してください）
ところで、全否定の場合は事前宣言してもしなくても一緒では？と思った方がいらっしゃるかもしれません。その通りだと思います。
ただ、ほとんどのケースで全否定的な意見を言うことはまずないと思います。相手も同じ人間で、ある程度のロジックをもって話しているので、部分的にでも同意できる部分があるはずです。
もし全くの全否定になりそうな場合は何か見落としている前提条件があるかもしれません。いきなり否定の立場を表明して自分の意見を伝えるのではなく、相手の意見をもう少し深掘るような質問をしてみるとよいかもしれませんね。
おわりに
コーディングや開発に例えてお話しするつもりが、なぜかおでん比率が上がってしまったような気もしますが、たぶん気のせいでしょう。
ひょっとすると、おでんの具のように様々な人達で開発チームは構成されていて、良い出汁を作るのは良い人間関係を作るようなもので、ちょうど良い温度調節という名のコミュニケーションスキルが必要不可欠…なんていう関係性があるのかもしれませんね。…別に上手くないですね。すみません。
おでんは美味いですが。すみません。
さて。上で書いたことは決して簡単なことではなく、私もついアンチパターンをかましてしまうことがよくあります。ですが身につければ、ビジネスでもプライベートでも一生モノのスキルになるようなものばかりではないでしょうか。
ばっちり身につけて素敵な大人になれるよう、お互い頑張っていきましょう！ここまでお読みいただきありがとうございました！
★
★★
★★★
….★★★★★….
★明日も新しい記事に出会えます★
★★SHIFTアドベンドカレンダー2022★★
執筆者プロフィール：石井一成
業界経験6年ぐらい。
そろそろ若手は苦しいけれど、ベテランというにはまだまだ遠い経験値。
SHIFTでは、UNIT～GUIテストの自動化アーキテクトを主に担当しているが、効率化、品質向上の文脈ならチームビルドでもプロセス改善でも何でもやる人。
ジムで筋トレ＆増量活動を始めた結果、運動不足（筋トレだけでは運動量が足りない）で、お腹がポッコリしてきたので、リングフィットも始めた。健康はQOLの向上にだいじ。
お問合せはお気軽に
https://service.shiftinc.jp/contact/
SHIFTについて（コーポレートサイト）
https://www.shiftinc.jp/
SHIFTのサービスについて（サービスサイト）
https://service.shiftinc.jp/
SHIFTの導入事例
https://service.shiftinc.jp/case/
お役立ち資料はこちら
https://service.shiftinc.jp/resources/
SHIFTの採用情報はこちら
https://recruit.shiftinc.jp/career/