ジャーゴンからテクニカルタームへ〜開発者と円滑なコミュニケーションをするために〜

こんにちは。かにぱんのサブスクが欲しい。

会社でDirector's Growth Meetingというディレクターによるディレクター向けの発表会というものがあるのですが、こないだちょっとそこで発表してきました。今回はその内容を記事にしてみました。

想定読者

この記事が役に立ちそうな人は以下の方々です。

・webサービス/サイトの構築ディレクションを行なっている人
・webサービス/サイトを作ってもらっていて、それを非エンジニアの上部に報告しないといけない人
・営業窓口で顧客の要望をヒアリングして開発まで持ち帰る人

ざっくりいってしまうと、ご自身は非エンジニアだけどエンジニアにお願いしたり、質問したり、指示したりとコミュニケーションを取らねばならないポジションの方を想定しています。

日本語でおk

突然ですが上記の立場に当てはまる人、こんなシーンに遭遇したことはないでしょうか。

ケース1
大手クライアントの仕事を受注した。会社のホームページを回収し、うちが提供するCMSを利用したいのだそうだ。
みたところホームページもそんなに複雑な階層じゃない。あらかじめ提案したサイトマップには了承を得られたし、ワイヤーフレームも自社CMSのテンプレートを少しいじったくらいで良さそうだ。
しかし、どうも話を聞くうちに、ホームページはかなり前に知人の知人のweb作成会社に作ってもらったらしい。ドメインもその人にとってもらったという。誰が管理しているのか聞いてもわからない。
クライアントは「このURLってやつ？はそのままで、ホームページの中身だけ君んところのサービスを使えないかな」という。
あなたの隣でその話を聞いていたエンジニアはかぶりを振ってこういう。「DNSは管理しておられますか？AレコードをウチのIPアドレスに変更したらできるかもしれませんが…。あとwwwのサブドメインでもアクセスしたいなら、CNAMEも変えないと。あ、MXレコードはどこが設定されていますか？」
クライアントの顔をみると、眉毛がハの字になって助けを求めるような目でこちらを見ている。ごめん。私も何を言っているのかわからない。

ケース2
熱烈な営業の末に、大手物流ソリューション会社とのサービス協業が決まった。うちは小さなシステム会社でちょっとしたECの在庫管理システムを作っている。先方のサービスユーザーはなかなかの数なので、利用者増加も見込めるだろう。もちろんシステムの連携はマストだ。息巻いていると先方からドキュメントなるものが送られてきた。これを使えばシステム連携できるらしい。便利なものだとエンジニアに渡したら「これ在庫データAPI利用しなきゃいけないんですけど、どこでユーザに認可取るんですか？ユーザーの動きってどう想定してます？」
ふむ、認可？と言ったのか？と小首を傾げながら、「APIを利用したらデータ取れるから自動的に連携するしいいんじゃないの？」と私は返した。エンジニアは可哀想なものを見る目で私を見ている。

エンジニアと話したら、気がついたら5秒に1回は知らない単語が出てくる…。
都度聞くのもバツが悪いし、聞いたら聞いたで「はぁ、やっぱそこから説明しなきゃダメ？」という表情で子供電話相談室の研究者みたいな口調で諭してくる。
結果ディレクター側は「わかんないけど聞きにくい」、エンジニア側は「どこから説明していいのかわからない」と言ったディスコミュニケーションにつながるのである。

言葉の意味がわからない！？

このディスコミュニケーションは、一見するとエンジニアが使っている言葉の意味がわからないから起こっているように見える。
この何か意味を持って発言されているのに、その意味が全くチンプンカンプンなものをここで「ジャーゴン」と呼ぼう。（たいそうエンジニアさんには無礼であるが）
「ではこのジャーゴンの意味がわかったら、解決できるんじゃないか。そうだつどつどエンジニアに説明されずともわからないことは一個一個調べて潰していけばいいんだ！」
残念ながら、そうではない。例えば、ケース2のエンジニアが下記の通り説明してきたとする。

このAPIの利用にはOAuth2.0を利用してて、ユーザーに認証・認可が必要なのでそれは必ず組み込む必要があるんです。

なんのことかと思ってOAuthをググってみる。するとそこでてくるのは…

…？？
？？？？？？

リソースオーナー？認可サーバー？権限委譲用クレデンシャル？？
まじで何を説明しているのかわからない。というか余計わからなくなった。

そう、エンジニアさんが何を話しているのか分からない場合、ジャーゴンの意味がわからないのではない。その単語の後ろにある概念がわからないのだ。
日本語としては理解できてしまうが、意味はわからないという感覚。その感覚を持っているときは、だいたいこの事が起こっていることが多い。

わからないことがわかったら

では、そんなそもそも概念が分からないということがわかったらどうすればいいのか。残念ながら泥臭いが
①とにかくわからない事柄について複数の説明を読む・聞く
②抽象化する
この2つに尽きる。だが①の際、調べるうちにわからない単語がボコボコ湧き上がってくると思う。そんなときは、わからない単語をすべて調べたくなる衝動に駆られる時があるだろう（え、ないの？わたしはある）
だがここでもう一度OAuthについての説明を見てみよう。

きりがないよ！！！！なんだよだから権限委譲用クレデンシャルって！！！

そう、きりがないのである。そういうときは抽象化してみるのである。
まずは複数の説明を読む。知りたいことに関してできるだけ多くの説明を。そして自分の言葉で言い直してみたり、図を書いて説明をしてみる。いきなり総て理解するのでなく、自分でできる範囲で表現してみる。そうすると自ずと細かいところはともかく、自分の中でその事象の骨子を説明できるようになるはずだ。それだって立派な抽象化である。

そうすることで、概念さえ理解できれば細々とした単語など枝葉の言葉に迷わずに済むのである。

こうすることで、今までジャーゴンとして耳に入っていた言葉は、テクニカルターム（専門用語）として理解されるものになる。

一番確実なのは、覚えた概念をエンジニアさんと一緒に話しながら確認し、矯正してもらうことだ。相手にイチから説明させなくていいし、どんな粒度で自分が理解しているかを伝えることもできる。そのなかで、間違いがあれば正してもらうえばよい。
あとこれにはもう一つ重要な意味がある。「自分は技術側に歩み寄る姿勢がある」ということを見せることだ。コミュニケーションの態度は貯金である。「こいつは技術がわかるぞ」とまでは行かなくても、受け身の立場じゃないよ、という態度の積み重ねは今後のコミュニケーションの円滑さにもつながっていく。

まとめ

エンジニアとクライアントの橋渡しという立場上、それはときに技術的バイリンガルとして活躍しないといけない。
でも、あなたがエンジニアになる必要はないし、客先への説明をエンジニアに丸投げする必要もない。

①とにかくわからない事柄について複数の説明を読む・聞く
②抽象化する

あら簡単！訓練いらず時間いらず！とはいかないが、やればやるだけその分野に関する学習コストは二次関数的に下がるので、是非試してみてほしい。

苦悩多き橋渡し役の皆さんの円滑なコミュニケーションライフを願ってやまない。