はじめに
この記事は、Leveragesアドベントカレンダー13日目の記事になります。
今回はポエミーな感じでお送りします。
弊社は営業からプロダクトをアウトプットするところまで、ほぼすべてを社内で行っているため、他職種のメンバーと話したり、議論をしたりする場面がかなり多いです。
なので他職種から信頼されている状態を作ることは仕事上割と重要で、エンジニアがやりたいことや、将来的に起きそうな、エンジニアしか理解していないことに割く工数を確保するためには「◯◯さんが言うならやっとくべきなんでしょう」と思われる状態を作るとスムーズです。
そのために、僕が他の職種の人と一緒に仕事をするときに心がけていることをまとめておこうかと思います。
あくまで僕がやっていることで、かつ、意識してやっているもの（普通にやれることではなく）であって、みんなやるべきということではありませんし、向き不向きもあると思います。ただ、誰かの何かの気付きになればいいかなと思って書いておきます。
あと、前提として、
何事もほどほどに!
の精神を持っていないと死んでしまうので、注意してください。
10分以内にできる仕事は最初に済ませる
日常的に信頼を高めるためには、なるべく早くレスポンスをし、簡単な作業はすぐさまやってしまうのがいいと思っています。信頼の積み重ねには、大小より数のほうが効果が強いと感じることが多いのと、ちょっとした仕事だからこそ、依頼した仕事がすぐに返ってくると、「この人に頼めばすぐにやってくれる」と認識され、まれにちょっと時間がかかりますよと言えば、「この人が時間がかかるというのだから、時間がかかるに違いない。なぜなら、いつもすぐにやってくれる人だからだ」と、理由を説明するまでもなく納得してくる確率があがります。
相手の技術的な知識量を知る
当然といえば当然のことですが、わかっていてもエンジニアは自分の知識をベースにした会話を展開しがちだと思っています。
なので相手の知識量を知ることは重要で、バージョン管理の概念がない人に、gitは便利だと説いても始まりません。そういう場合はexcelで共同編集して事故ったみたいな、相手が経験的に理解している話をするべきで、gitとsvnやcvsとの違いについての話をするべきではありません。これを見極めることは、相手を説得する上で重要です。
また、相手の知識量を知ることは、相手の興味の深さを知ることにもなると思っています。
つまり、相手の知識量が少ないということは、その人に技術的な価値の高さを説明しても効果が薄く、もっと直接的に利益になることを訴えるべきという判断ができます。
相手の意見が正しい、あるいは、自分が間違っていると仮定する
相手の意見の背景やプロセスを理解することは、相手に納得してもらう上では重要ですが、それを引き出すことは難しいです。僕の経験上では、そもそもしっかりそれをロジックに落とし込めている人はあまりいない印象です。
なので、相手の意見を一旦正しいものとして、自分自身がその意見を正しいと言うためには、どういうロジックが必要かを考えるようにしています。
たいていの場合は、相手の意見が正しいという結論を導き出すことができるロジックはいくつか見つかります。そうすると、相手が正しいと信じている根拠がある程度明確になり、自分の意見を通したい場合、ただ自分の正しさを押し付けるより、そのポイントを突いた説得をした方が相手は納得しますし、引っかかりがあった場合に、どこに相手が引っかかっているかがわかりやすくなります。また、意外と自分が思いもつかなかった考え方を知るきっかけにもなります。
自責で考える
僕が考えている自責とは、「私が悪いです」と認めるということではありません。
問題が発生したり、発生しそうな場面に気づいたら、「自分のせいでこの事象が発生したのだとしたら、どのタイミングで何をしていれば未然に防げただろう」と考えることです。
この繰り返しが、他のメンバーやリーダーが気づいていないリスクに気づくことができる下地になっていて、それをもとに事前に相談することで、「この人がいると安心感がある」と感じてもらうことにつながっていると考えています。
また、これを考えることは、何もしないよりも経験速度を遥かに高めてくれるので、自身の成長のためにも価値が高いはずです。
なんだかんだで10以上の案件、会社で仕事をしてきて、セクショナリズムによる殺伐とした空気も結構経験してきた身としては、それぞれの職種がお互いの仕事に関心を持って、歩み寄れる現場を作りたいものです。