（クライアントとの会話では）テクニカルジャーゴンはやめよう
はじめに
ぺんぎん（@jitepengin）です。
システム開発の現場では、専門用語（テクニカルジャーゴン）が飛び交います。
エンジニア同士の会話であれば問題ないのですが、クライアントやビジネス側と話すときにもつい使ってしまい、よくわからないというコメントをもらったり、後から伝わっていなかったという経験はありませんか？
本記事では、テクニカルジャーゴンについてまとめてみます。
ちなみにこれは自戒も込めた記事です。
わたしの記事もLAPRASのAIレビューで専門用語が多くわかりづらいと評価されます。
また、妻にも専門用語が多すぎてわからないと言われることが多々あります…
テクニカルジャーゴンとは
テクニカルジャーゴンとは、特定の分野（技術、学術、業界など）で使われる専門用語のことで、その分野に詳しくない人には理解できない言葉を指します。
ITの分野でもビジネス側やクライアントには初見の言葉や、聞いたことがあってもよくわからない言葉が多くあると思います。
例えば、「冪等性」と言われても普段使わない人には理解できないのかなと思います。
なぜテクニカルジャーゴンを使わない方がいいのか？
言語ギャップがプロジェクトのリスクになる
技術が難しいのではなく、「違う言語を話している」こと自体がリスクとなります。
例えば、下記のようなリスクが考えられます。
- 意思決定が遅れる
- 認識齟齬が生まれる
- 説明コストが増える
- クライアント側が遠慮して（理解を諦めて）質問しなくなる
- その結果、後工程で手戻りが発生する
特にクラウドやデータ基盤の話は概念も抽象度も高いため、専門用語をそのまま使うと誤解が起きやすい領域です。
ちなみに「ドメイン駆動設計をはじめよう」の中でも、同じ言葉で話すことの重要性が述べられています。
技術者の正確性が裏目に出る
わたしもそうですが、専門分野であればあるほど、正確だったり事細かに説明したいという意識が出ることはないでしょうか？
そういった場面では専門用語を多用しがちだと思います。
しかし、クライアントが知りたいのは概念の正しさや技術の正確性ではなく、その議題が自分たちのビジネスの何に関わるのかであることが多いです。
その期待値のズレがいつしか大きな問題となることがあります。
よくあるテクニカルジャーゴンと言い換えのイメージ
以下はよく出てくる用語例です。
言い換えはあくまで一例なので、クライアントの理解度や専門性に合わせて調整してください。
| テクニカルジャーゴン | 相手の受け取り方 | 言い換え |
|---|---|---|
| 冪等性 | 難しい | 何回実行しても結果が変わらない仕組み |
| レプリケーション | イメージしづらい | データを複数の場所にコピーしておく安全策 |
| Icebergのメタデータ更新 | 概念が複雑 | テーブルの管理情報をまとめ直す作業 |
| ACID | 説明が抽象的 | データが壊れないようにするためのルール |
| APIのスロットリング | ニュアンスが伝わらない | 短時間で大量にアクセスされないようにする仕組み |
このように置き換えることで理解しやすくなると思います。
なぜ技術者（過去のわたし）はテクニカルジャーゴンを使ってしまうのか？
相手の理解度や専門性を考慮していない
説明する相手の立場や知識レベルをあまり意識せず、自分が理解している前提で話を進めてしまうことが多い。
社内会話の癖がそのまま出る
開発チーム内での会話が専門用語になるため、そのままクライアントにも使ってしまう。
これも相手目線に立つことが不足していると起きがちです。
とっさに言い換えるのは意識しないと難しい
比喩や例えで説明するというのは、案外難しいです。
意識しないと専門用語を使ってしまうことも多いので、ここは意識するしかないです。
正確に言わなければ誤解されるという思い込み
実際には、クライアントは専門用語を多用した正確な用語より自分の理解できる言葉を求めていることが多いです。
クライアントとの会話で気をつけるポイント
相手の専門性や理解度を推し測る
プレゼンや説明の反応をみながら、相手の理解度や専門性を推し測り、言葉を調整することが重要です。
資料をそのまま説明する必要はなく、相手によって言葉を変えることも求められます。
あくまでも相手を意識することが前提です。
専門用語は最初に定義してから使う
一つ上の内容と被る部分がありますが、一度「こういう意味です」と説明すれば、その後は用語を使っても問題ないと思います。
まずは「共通言語」を作ることが重要です。
置き換えて説明する
- DWH → データを貯めておく倉庫
- データフロー → データの流れ、社内のワークフローに似たようなもの
- メタデータ → データに関する情報、本でいうところの著者や出版社
- 監査ログ → 誰が何をやったか記録するもの、監視カメラや入退室記録のようなもの
といった具合に、置き換えるのもいいかもしれません。
なぜ必要なのかから説明する
人は目的が分からないと絶対に集中できません。
例：
Icebergのコンパクションが必要です。 → 小さなファイルが増えると処理が遅くなるので、整理してひとまとめにします。
テクニカルジャーゴンとはずれますが、目的があると理解がしやすく、納得感が得られやすいです。
一文を短くする
説明が複雑なときほど、一文が長くなりがちです。
「一文一メッセージ」を意識するだけで伝わり方が変わることが多いです。
プレゼン資料でも「1スライド1メッセージ」を意識するのも重要です。
同じ言葉を使う（相手と目線を合わせる）とうまくいくことも多い
実際のプロジェクトでも、
- 意思決定が早くなった
- クライアント側の理解が深まり、後続の議論が進めやすくなった
- お互いのストレスが減った
ということが何度もありました。
特に近年の高度化したシステム開発では、伝わる説明ができるかがプロジェクト成功の分水嶺と言っても過言ではないと思います！
技術力より翻訳力が必要な場面も多い
テクニカルジャーゴンを避けるのは、技術者のアイデンティティを損なう行為ではありません。
むしろ、
- 相手の立場に立つ
- 説明の目的を理解する
- 難しいことを簡単に伝える
という、高度なスキルを使う行為です。
そしてこれは、上流工程だけではなく、プロジェクトマネジメントや新人育成など様々な場面で必要となる能力でもあります。
つまり「技術力 × 翻訳力 = 物事をうまく進める力」です！
まとめ
今回は自戒をこめて、テクニカルジャーゴンについての考えをまとめました。
わたしもそうですが、技術が好きであればあるほど、専門用語を多用しがちだと思います。
しかし、プロジェクトを円滑に進めるには、相手を意識した「同じ言葉」を使うことが重要になります。
この記事が、クライアントや家族とのコミュニケーションを見直すきっかけになれば幸いです。
Discussion