エンジニア対非エンジニアのコミュニケーション問題を解決する方法

目次

• コミュニケーションスタイルのグローバル標準とは
• グローバル標準のコミュニケーションを難しくする3つのハードル
• ビジネス上に合理的なコミュニケーション。それはスピードに直結する
• コミュニケーションスタイルの壁である文化を乗り越える

Sprocketには、お客さんの要件を聞いてシナリオ作成などを担当する非エンジニアの「プロデューサー」と、その要件をプロダクトに落としこむ「エンジニア」がいます。

エンジニア側は、要件やリクエストはどんどんぶつけてきてほしい、と思っているのにも関わらず、非エンジニアのプロデューサー側は、ストレートなリクエストは出しにくくて、つい気を使ってしまう、という課題があります。

これを解決するためにSprocketが取り入れているのが、コミュニケーションスタイルのグローバル標準です。

そしてこれは、エンジニアと非エンジニアのコミュニケーションだけでなく、上司と部下のとのコミュニケーション、部署をまたがったコミュニケーションでも適用できます。

コミュニケーションスタイルのグローバル標準とは

グローバル標準と言いつつ、そういっていいかどうかはわからないのですが、USスタイルかもしれませんし、USの中でも一部の人たちに限られるのかもしれませんが、一応こういう呼び方をします。

まず、そのコミュニケーションスタイルについて説明しましょう。

1. （相手の都合は特に考えずに）まずリクエストを出す
2. リクエストを受けた側は自分の都合でリクエストを処理する
3. リクエストをしたのに動いてくれないなどがあればリクエストを出した側が頑張って動いてもらえるように考えて行動する

これがグローバル標準のコミュニケーションスタイルです。

相手の都合を考えずにリクエストを出していいが、相手も相手の都合で動くのでリクエストが通るかどうかはまた別の問題、ということです。

僕がこのスタイルを採用することになった背景として、過去にシリコンバレーのスタートアップのBadgevill社とのコミュニケーションの体験があります。彼らとのやりとりを通した気付きは以下の記事に詳しいです。

アメリカ企業との交渉に求められるのは「Creativity」。相手を動かすためのコミュニケーション

グローバル標準のコミュニケーションを難しくする3つのハードル

ここで、日本的なコミュニケーションスタイルとの違いでいくつかのハードルが現実にはあります。

1. リクエストを出すということに対してのハードル

これは日本人として理解できるところは当然僕にもあります。相手に要求を出すということはちょっとしたブレーキがかかります。「このタイミングでこんなこと言って空気読んでないんじゃないか」「失礼に当たらないか」「迷惑をかけてしまうんじゃないか」といった配慮をしてしまうためです。

でも、こういう配慮はSprocket社においてははっきり言って全く不要です。

それは次に説明する2. の前提が成立しているためです。ただ、そのことによるハードルがあります。

2. リクエストを受けたら断りにくいというハードル

日本人は親切なので、リクエストを受けたら基本的にそれに応えなきゃいけないという前提で物事をつい考えます。逆に、こういう前提があるので1. のハードルが上がることになります。

こちらもSprocket社においては無用の配慮で、来たリクエストは自分の都合（自分勝手ではなく、自分が抱えているタスクの優先順位を考慮した上で）に応じて対処するようにしています。

Badgevill社では、優先度が低いリクエストとなればかなりの期間放置されることもしばしばありました。それくらいでも、極端な話、OKです。

3. リクエストを出したら聞いてくれているだろうという前提があるがゆえに、相手を動かすべく頑張るという動きを取らないというハードル

3つ目のハードルは実は結構厄介です。

「なんで送ったのにメール見てないの」とか「反応がないんだよなあ」と周囲にコミュニケーションの不満をこぼしたたこと、あるいは不満を聞いたことがある人も多いでしょう。

しかし、これはかなり日本人特有のスタイルだと思いますが、相手はこちらの話しかけに対して何か答えること（しかも可能な限り素早く！）を当然のこととして期待していたり、もっと言えばそうしないことに対して不満や怒りを覚えてしまうという事が結構あると思います。

「相手の都合」より先に、リクエストには従うべきと暗黙の了解になっている（と本人が思っている）「規範」に則らないことに対して、ある種の正義感からの怒りを覚えるという行動スタイルです。

これはグローバル標準からするとかなりイレギュラーだと思いますし、Sprocket社においてもこういう怒りはNGにしています。

相手が動いてくれないのは相手に都合があるからで、自分の都合に従ってもらうためには自分で頑張るのが筋だよね、というのがSprocket社のスタイルです。

ビジネス上に合理的なコミュニケーション。それはスピードに直結する

この3つ、ベースにあるのは主に深田個人がこれまでにUSの人たちとのコミュニケーションで学んだスタイルですので、実際にはグローバル標準的なものではないかもしれませんが、ただビジネス上の合理性があると思っているので、Sprocket社ではこの方針を採用しています。

なぜ合理的かと言えば、
「ビジネスとしてのスピードが早い」
これにつきます。

1. 配慮しない分早い

相手の都合に配慮する、というのはビジネス上はほとんど意味を持ちません。だってみんな仕事上の成果を出すためにコミュニケーションを取るんですから。配慮してスピードが遅れることに本来何の意味もないのです。

むしろ、要件を自分の都合でどんどん伝えていくことで、まず相手のことを考えなくていいということでスピードが早まります。

相手側も断っていい前提なので、別にどんなリクエストが来ようと気にしませんし、自分にできることだったり、優先することに合理性があるとなれば優先します。

「合理性」の基準はビジネスとしての成果、みんなが目指しているゴールに近づくかという点にあるので、「配慮」すべきは本来そこにあります。

2. 合理性をベースとする分早い

リクエストする側は、合理性があると思っているからリクエストをしているわけですから、それを相手に納得してもらうために頑張る（説明する）のも当然ということになります。

ここも結構重要で、「なぜ早めるべきなのか」をリクエストする側はちゃんと考えないといけないわけですね。これを考えること自体がリクエストの重要性を自分なりに認識することにもつながります。

3. リクエスト内容をちゃんとまとめるので早い

「配慮しない」「配慮されない」場合、リクエストを受けてもらうためには、どんなリクエストなのかを明確にしないといけないですし、ぼんやり言っても相手が汲み取ってくれるだろうという期待をしてはいけません。

要望が曖昧のまま進めようとしても進みませんし、往々にして日本人的コミュニケーションでは言っている本人も何を具体的にリクエストしたいのかわかっていないときがあります。

これははっきりいってリクエストする側の怠慢だと思います。相手に動いてもらうためには例えば「期日を具体的に設定する」「可能な限り要求内容を具体的にして受け取り手に推測やくみ取りの負担を減らす」といった工夫が必要になります。

ストレートに物事が進むというのはビジネス上は極めて便利で、シリコンバレーのスタートアップの動きが早いのはこういうところにも大きな要因があるなというのは僕の実感として大きいですし、であればぜひSprocketでも取り入れたいと思っています。

コミュニケーションスタイルの壁である文化を乗り越える

グローバル標準のコミュニケーションスタイルが難しい背景として、価値観の違いが大きいと推測しています。

相手の都合に対しての2つの考え方をイメージしてみてください。

• 基本的に自分の都合は自分の都合、相手の都合は相手の都合、と切り分けて物事を考える
• 基本的に自分の都合で相手の都合は変えられる（変えてもらう）と考える

前者がここでいうグローバル標準、後者が日本的スタイルということになります。

これは一言で言うと、個人をどれだけ尊重する発想があるかということなんだろうと思っています。つまり、相手を尊重していれば、相手にも相手の都合があるわけだからこちらの話を聞くべきだとかメールは読むべきだとかレスを返すべきだというのはそもそも発想として出てきません。

日本だと個人の尊重という観点よりも和の尊重という観点のほうが強いんだろうと思います。なので「汲み取り力」が基本的に高いし、汲み取ってもらえるのを前提でコミュニケーションすることになるので、自然に中身が相手の推察を要する内容になりがちです。

僕はこれはビジネス上はマイナス要因だと思います。推察が違っていたりすると手戻りになりますから。

ところで、「リクエストを出すということに対してのハードル」について、リクエストをするということが相手に文句を言っているように感じるという声を何度か聞いたことがあります。なので言いにくいという。

同様に「リクエストを受けたら断りにくいというハードル」の派生で、リクエストされたということは文句を言われたということとして受け取るということもよくあるように思います。

デフォルトで相手の意図を汲もうとするのは日本人の特性かと思いますが、ややもすると存在しない意図を読み取ってしまってネガティブに考えすぎるということも実際は起こっている気がします。

さて、これはSprocket社内のコミュニケーションスタイルの考え方ですが、エンジニア、非エンジニアのコミュニケーションに課題がある会社はチームは、こんなやり方もあるのだということで、参考にしていただければと思います。