IT基礎知識10選！町の電気屋さんの哲学を見習えば新人でもエンジニアと話せる

子供のころ、家に一台だけあったブラウン管テレビの調子が悪くなると、決まって母親が電話する先がありました。

そう、町の電気屋さんですな。電話一本で軽トラに乗ってすっ飛んできて、専門用語なんて一切使わずに「ああ、ここの接触が甘くなっとるだけやね」なんて言いながら、あっという間に直してくれる。

あの魔法使いのようなおじさんの姿、なんだか妙に記憶に残ってるんですよね。

で、大人になってIT業界の片隅で仕事をするようになって、ふと思ったんです。

僕ら非エンジニアが、エンジニアと話すときに本当に必要なスキルって、最新のIT用語を覚えることじゃなくて、あの町の電気屋さんの「話し方」なんじゃないか、と。

サーバー、API、クラウド…そんな横文字にビビる必要は全くない。

だって、それ全部、あなたの家にある家電に例えて説明できるんですもんね。

エンジニアは宇宙人じゃない、ただ使う“方言”が違うだけ

マーケターやディレクターといった非エンジニア職の人が、キャリアの初期でぶつかる大きな壁。

それが「エンジニアとのコミュニケーション」じゃないですかね。
会議で飛び交う「ここのAPIのレスポンスが…」「サーバーの負荷が…」なんて言葉を聞いて、頭が真っ白になる。

まるで自分だけ違う言語の国に放り込まれたような、あの疎外感。
僕も経験があるから、よーく分かります。

でもね、ちょっとだけ視点を変えてみてほしいんです。

彼らは、決して僕らを困らせようとして専門用語を使っているわけじゃない。
あれは彼らにとっての「日常語」であり、仲間内で話すときの「方言」みたいなものなんですよね。

青森出身の人が津軽弁で話すのが自然なように、エンジニアはエンジニアの言葉で話すのが一番効率的で正確だから、そうしているだけ。

問題は、僕らがその“方言”を、いきなり外国語や宇宙語のように捉えて、心を閉ざしてしまうことにあるのかもです。

町の電気屋さんは、家電という専門分野の“方言”を、僕ら素人にも分かる「標準語」に、それはそれは巧みに“通訳”してくれます。

僕らに必要なのは、IT用語を丸暗記することじゃなく、この「通訳スキル」のコツを掴むこと。それだけで、エンジニアとの会話はびっくりするほど楽になるってやつです。

なぜ「町の電気屋さん」が最強の通訳なのか？

じゃあ、なんで町の電気屋さんは、あんなに話が分かりやすいんでしょうか。

彼らの仕事ぶりをよーく観察してみると、そこには3つの鉄則があることに気づきました。

まず一つ目は、相手の知識レベルに完璧に合わせられること。

僕みたいな機械にちょっと詳しい客には、少し専門的な話を交えつつ。
一方で、うちの母親みたいなお客さんには「要は、テレビさんも疲れてたんですねぇ」くらいの、ふんわりした言葉を選ぶ。
このチューニング能力が絶妙なんですな。

二つ目は、難しいことを、必ず身近なものに例えるのがめちゃくちゃ上手いこと。

「この部品が、人間でいうと心臓みたいなもんでしてね」「この配線が神経で…」みたいに言われると、複雑な機械の構造も、なんだか自分の体のようにスッと理解できる。
専門知識を、相手の既知の世界に引き寄せてあげる優しさがあるんですよね。

そして三つ目が、常に「目的」からブレないこと。

電気屋さんのゴールは、あくまで「テレビがちゃんと映るようにすること」です。
だから、途中の過程で自分の知識をひけらかしたり、必要以上に難しい話をしたりしない。
「どうすればこの問題が解決するか」という本質だけを、最短距離で伝えてくれる。

これって、僕ら非エンジニアがエンジニアとプロジェクトを進める上で、見習うべき姿勢そのものだと思いませんか。

相手の理解度を想像し、難しいことは例え話で伝え、常にプロジェクトのゴールを見失わない。この3つを意識するだけで、コミュニケーションは劇的に変わるはずですもんね。

専門用語の丸暗記が、実は一番の遠回りなワケ

「エンジニアと話せるようになりたい！」と意気込む真面目な新人さんが、まず手をつけるのがIT用語辞典みたいな本を買って、単語を一生懸命暗記すること。

気持ちは痛いほど分かりますが、ハッキリ言って、これは一番の遠回りかもです。
なぜなら、言葉というものは、それ単体で存在しているわけじゃなく、必ず「文脈」の中で生きているからです。

例えば、「サーバー」という単語の意味を「Webサイトのデータなどを置いておくコンピュータのこと」と完璧に覚えても、会議でエンジニアが「今回はサーバーサイドで処理を…」と言ったときに、その意味を正しく理解できるとは限らない。

なぜ、今その話が出てきたのか。
それが、プロジェクト全体の中でどんな意味を持つのか。
その背景や関係性が見えていないと、単語の意味を知っていても、会話には参加できないんです。

町の電気屋さんが、いきなり客に「こちらのコンデンサの静電容量がですね…」なんて話をしないのと同じです。
そんな数字だけ言われても、客は「はあ…」としか言えない。

そうじゃなくて、「この部品が電気を溜めておくダムみたいな役割なんですけど、そのダムに穴が開いちゃってるんですよ」と言ってくれるから、僕らは納得できる。

必要なのは、単語の暗記じゃない。

その言葉が持つ「役割」や、他の言葉との「関係性」を、自分なりにイメージできるようになること。
そのための最強の武器が、「身近なものへの例え話」ってわけですな。

家電の仕組みで理解するITの世界観

さあ、ここからはいよいよ実践編です。

ITの世界を、一つの「大きな家」だと想像してみてください。
いきなり「データベースが…」とか「APIが…」とか言われても、どこに何があるのか分からず迷子になってしまいます。

まずは、家全体の地図を頭に入れるのが大事。

この「大きな家」には、リビングやキッチン、寝室といった、いろんな「部屋」があります。
この一つ一つの部屋が、いわゆる「Webサイト」や「アプリケーション」だと思ってください。

そして、それぞれの部屋には、テレビや冷蔵庫、エアコンといった「家電」が置かれていますよね。
これが、Webサイトを構成する様々な「機能」にあたります。

この家全体に電気を供給し、家電を動かしている大元の仕組みこそが、「ITインフラ」と呼ばれるものです。
どうです？

こう考えると、なんだかITの世界が自分の家のように感じてきませんか？
このイメージを頭に置いた上で、まずは家の大黒柱とも言える、いくつかの重要な概念を、電気屋さんと一緒に見ていきましょう。

「サーバー」は、家の大元にあるブレーカーみたいなもん

エンジニアとの会話で、絶対に出てくる言葉ナンバーワンが「サーバー」です。
サーバーが落ちた、サーバーが重い、サーバーを増強する…。

このサーバーって、一体何者なんでしょうか。
これは、あなたの家にある「配電盤のブレーカー」を想像してもらうのが一番分かりやすいです。

ブレーカーは、電力会社から送られてきた電気を家全体に分配し、管理している大元ですよね。

もし、このブレーカーが落ちたらどうなりますか？
リビングのテレビも、キッチンの冷蔵庫も、寝室の電気も、家中の家電が全部一斉に使えなくなってしまいます。
サーバーも、これと全く同じ。

Webサイトの文章や画像、顧客情報といった、ありとあらゆるデータを保管し、ユーザーからの要求に応じてそれらのデータを取り出したり、処理したりする、まさに「大元」のコンピュータなんです。

だから、「サーバーが落ちた」というのは、「家のブレーカーが落ちて、全館停電になった」という非常事態。

「サーバーが重い」というのは、「一度に電子レンジとドライヤーとエアコンを使ったら、ブレーカーが落ちそうになって照明がチカチカしてる」ような状態。

このイメージがあれば、「サーバーって、とにかく超大事な心臓部なんだな」という感覚が掴めるはずです。

「データベース」は、家族みんなが使う大きな冷蔵庫

サーバーとセットでよく登場するのが「データベース（DB）」という言葉。

これも、家のキッチンにある「冷蔵庫」に例えると、めちゃくちゃ分かりやすいんですな。

冷蔵庫の中には、何が入っていますか？

肉、魚、野菜、卵、牛乳、ジュース…。
いろんな種類の食材（データ）が、それぞれ適切な場所に整理されて保管されていますよね。
卵はドアポケット、野菜は野菜室、といった具合に。

そして、お母さんが「今夜はカレーにしよう」と思ったら、冷蔵庫からジャガイモと人参とタマネギと肉を、的確に取り出していきます。

データベースの役割も、まさにこれ。

ECサイトで言えば、顧客の名前や住所、購入履歴といった大切な情報（食材）を、決められたルールに従って、きちんと整理整頓して保管しておく場所なんです。

そして、「Aさんが買った商品を一覧で表示して」という要求が来たら、膨大なデータの中から、Aさんの購入履歴だけを正確に、かつ素早く取り出してあげる。

もし冷蔵庫の中がぐちゃぐちゃで、どこに何があるか分からなかったら、料理の効率は最悪ですよね。
データベースの設計が悪いと、Webサイトの表示が遅くなったり、欲しい情報がなかなか出てこなかったりする。

「DBの設計が大事」とエンジニアが言うのは、「美味しい料理を作るには、まず冷蔵庫の整理整頓からでしょ！」と言っているのと同じことなんです。

町の電気屋さんに学ぶIT基礎知識10選【新人マーケター・ディレクター必見】

さて、家の全体像が見えてきたところで、ここからはさらに具体的に、様々な「家電」や「配線」にあたるIT用語を10個、一気に見ていきましょう。

一つ一つ、町の電気屋さんの名調子で解説していきますんで、リラックスしてついてきてください。

これを読み終わる頃には、あなたも立派な「IT通訳」の見習いになっているはずです。

1. API (Application Programming Interface)

これは何か

異なるソフトウェアやサービス同士が、お互いに情報をやり取りするための「接続口」や「窓口」のことですな。
これがあるおかげで、全く別の会社が作ったサービスを、自分のサービスの一部みたいに連携させることができるんです。

電気屋さんの例え話

これはもう、家電の「コンセント」そのものだと思ってください。
日本の家庭にあるコンセントは、全部同じ形（Aタイプ）ですよね。

だから、パナソニックのテレビも、日立の掃除機も、どこのメーカーの製品だろうと、あの穴に差し込めば電気が使える。

APIも同じで、「この形のプラグ（リクエスト）を差してくれたら、こういう電気（データ）を流しますよ」という共通のルールが決まっているんです。

だから、自社のWebサイトに、Googleマップの地図を表示させたり、ぐるなびのレストラン情報を載せたりできる。

あれは、Googleやぐるなびが用意してくれた「API」という名のコンセントに、自分のサイトを繋がせてもらっている状態なんですね。

エンジニアとの会話でこう使う

エンジニアが「ここの天気予報は、気象庁のAPIを叩いて情報を取得してます」と言ったとします。

そしたら、あなたはこう返せばOKです。
「なるほど！気象庁が用意してくれた専用のコンセントに繋いで、天気データっていう電気をもらってる感じなんですね！」

これで、エンジニアは「お、この人、分かってるな」と思ってくれるはずです。

2. OS (Operating System)

これは何か

パソコンのWindowsやMac、スマホのiOSやAndroidといった、全てのソフトウェアが動くための土台となる「基本ソフトウェア」のことです。

これがなきゃ、パソコンもスマホもただの箱ですな。

電気屋さんの例え話

これは、テレビについてる「リモコンの基本的なボタン」みたいなもんです。

リモコンには、「電源を入れる」「チャンネルを変える」「音量を調整する」といった、テレビを操作するための最低限の機能がありますよね。

OSの役割も、まさにこれ。
「ファイルを保存する」「文字を入力する」「画面に表示する」といった、コンピュータの基本的な操作を全部引き受けてくれているんです。

WordやExcelといった個別のアプリ（リモコンの録画ボタンみたいな応用機能）は、このOSという土台の上で初めて動くことができる。

だから、OSのバージョンが古いと、最新のアプリが動かなくなったりするわけです。

エンジニアとの会話でこう使う

エンジニアが「このアプリ、次期OSのベータ版だとクラッシュするんですよね…」と悩んでいたら。
「あ、テレビのモデルチェンジでリモコンの基本設計が変わっちゃって、今までの録画ボタンが効かなくなった、みたいな感じですか？大変ですね…」と返してみましょう。

その共感の姿勢が、チームの潤滑油になるんです。

3. クラウド (Cloud Computing)

これは何か

ソフトウェアやデータを自分のパソコン（ローカル）に保存するのではなく、インターネット上にあるサーバー（クラウド）に置いて、必要な時にどこからでもアクセスして利用する使い方です。

Google DriveやDropboxなんかが、身近な例ですな。

電気屋さんの例え話

昔のテレビ番組の録画方法を思い出してください。

自分の家に「ビデオデッキ」と「ビデオテープ」を置いて、せっせと録画してましたよね。
これが、自社でサーバーを持つ「オンプレミス」という考え方です。

でも今はどうでしょう？

NetflixやHuluみたいな「動画配信サービス」に月額料金を払えば、膨大な映画やドラマをいつでも好きな時に見られます。
これが「クラウド」です。

自分でビデオデッキ（サーバー）を管理・維持する手間やコストをかけなくても、その道のプロが管理してくれている巨大な倉庫から、必要な分だけサービスを借りてくる。

この身軽さと便利さが、クラウドの最大のメリットなんですよね。

エンジニアとの会話でこう使う

「うちのサービスも、サーバーをオンプレからクラウドに移行するらしいですよ」という話を聞いたら。

「おお、ついに自前のビデオデッキを手放して、Netflixを契約するんですね！メンテナンスも楽になるし、見られる映画（使える機能）も増えそうですね！」と返せば、話が弾むこと間違いなしです。

4. フロントエンドとバックエンド

これは何か

Webサービスやアプリを開発するときに、ユーザーが直接見たり触ったりする「表側の部分（フロントエンド）」と、ユーザーからは見えない裏側でデータの処理や保存を行っている「裏側の部分（バックエンド）」を分けて考えることです。

電気屋さんの例え話

これは、家庭用の「エアコン」を想像してください。

僕らが部屋の中で直接操作するのは、壁にかかっているエアコンの本体ですよね。風量を変えたり、温度を設定したり。
これが「フロントエンド」です。

でも、実際に部屋の暖かい空気を吸い込んで、冷たい空気に変えている心臓部は、家の外に置いてある無骨な「室外機」です。
これが「バックエンド」。

僕らは室外機の存在を意識しませんが、あれが動いてくれなきゃ、部屋は一向に涼しくならない。

Webサービスも同じで、見た目がキレイなだけじゃダメで、裏側でしっかり仕事をしてくれるバックエンドがいて初めて、快適なサービスが提供できるんですな。

エンジニアとの会話でこう使う

「今、フロントエンドの改修タスクが立て込んでまして…」とエンジニアが言っていたら。
「見た目の部分の工事ですね！室外機（バックエンド）はそのままに、部屋の中のエアコン本体だけ最新のデザインにする、みたいなイメージですか？」と聞いてみましょう。

的確な例えに、エンジニアもきっと頷いてくれます。

5. IPアドレス (Internet Protocol Address)

これは何か

インターネットに接続されているパソコンやスマホ、サーバーといった、全ての機器に割り振られている、重複しない固有の番号のことです。

ネット上の「住所」にあたります。

電気屋さんの例え話

これはもう、例えも何もなく、まんま「住所」ですな。

町の電気屋さんが「テレビの修理をお願いします」と頼まれたとき、お客さんの住所が分からなければ、家まで伺うことができませんよね。
インターネットの世界も同じです。

あなたがスマホでWebサイトを見ようとするとき、あなたのスマホからWebサイトのデータが置いてあるサーバーに対して「このページの情報ください」とリクエストを送ります。

そして、サーバーはそのリクエストに応えて、あなたのスマホに情報を送り返してくれる。

この一連のやり取りができるのは、お互いのIPアドレス、つまり「住所」が分かっているからなんです。

「〒100-8968 東京都千代田区永田町1-7-1の国会議事堂さんへ、〇〇の情報をください。返信は、〒150-0041 東京都渋谷区神南2-2-1の私までお願いします」みたいな手紙のやり取りが、ネットの世界では一瞬で行われているイメージです。

エンジニアとの会話でこう使う

「不正アクセス元を特定したら、海外のIPアドレスでした」という報告があったら。

「犯人の住所が海外だってことが分かったんですね！すぐにその住所からのアクセスをブロックしましょう！」と返せば、危機感を共有できます。

6. ドメインとDNS (Domain Name System)

これは何か

「157.7.188.88」のような数字の羅列であるIPアドレスは、人間には覚えにくいですよね。

そこで、「yahoo.co.jp」のような、人間が覚えやすい文字列とIPアドレスを紐付ける仕組みがあります。

この「yahoo.co.jp」の部分を「ドメイン」、そしてその紐付け（翻訳）を行ってくれるシステムを「DNS」と呼びます。

電気屋さんの例え話

これも住所の例えの続きです。

あなたは、親しい友人の家の住所を、番地まで完璧に暗記していますか？ 多分していないですよね。

その代わり、「佐藤さんち」とか「鈴木くんの家」みたいに、名前（愛称）で覚えているはずです。
この「佐藤さんち」が「ドメイン」です。

そして、いざ佐藤さんちに遊びに行こうとなったとき、「そういえば、佐藤さんちの住所ってどこだっけ？」とスマホの連絡先アプリで調べますよね。

この、「佐藤さんち」という名前と「東京都〇〇区△△1-2-3」という住所を結びつけてくれる「電話帳（連絡先アプリ）」の役割を果たしているのが「DNS」なんです。

僕らがブラウザに「yahoo.co.jp」と入力すると、インターネット上の巨大な電話帳であるDNSサーバーが、「ああ、yahoo.co.jpさんの住所は157.7.188.88ですね」と教えてくれる。だから、僕らはヤフーのサイトにたどり着けるってわけです。

エンジニアとの会話でこう使う

「新しいサービスのドメイン名、何にしましょうか？」という議題が出たら。

「お客さんが覚えやすくて、愛着が湧くような『愛称』がいいですね！インターネットの電話帳に載る、大事な名前ですもんね」と発言すれば、建設的な議論ができるはずです。

7. SSL/TLS (Secure Sockets Layer / Transport Layer Security)

これは何か

インターネット上でデータをやり取りする際に、その内容を暗号化して、第三者による盗み見や改ざんを防ぐための仕組みです。

WebサイトのURLが「http://」ではなく「https://」で始まっていれば、この仕組みが導入されている証拠です。

電気屋さんの例え話

電気屋さんが家の中で配線工事をするとき、銅線がむき出しのままの電線を壁の中に這わせたりはしませんよね。
必ず、感電しないようにゴムなどの絶縁体でしっかりと覆われた「被覆（ひふく）電線」を使います。SSL/TLSによる暗号化は、まさにこの「電線の被覆」と同じ役割です。

インターネット上を流れるデータ（電気）を、暗号化という頑丈なカバーで覆ってあげる。
そうすることで、もし途中で悪い奴が通信を盗み見（電線を素手で触る）しようとしても、中身がぐちゃぐちゃの暗号化されたデータなので意味が分からず、情報を盗むことができない（感電しない）というわけです。

個人情報やクレジットカード情報を扱うサイトでは、この「配線カバー」が絶対に必要不可欠なんですな。

エンジニアとの会話でこう使う

「このページ、SSL化が漏れてて、ブラウザから警告が出ちゃいますね」という指摘があったら。

「うわっ、配線がむき出しで『危険！』って言われてる状態ですね！お客さんが不安になるのですぐに対応しましょう！」と、ことの重大さを理解した上で即座に行動を促せます。

8. キャッシュ (Cache)

これは何か

一度アクセスしたWebサイトの画像などのデータを、パソコンやスマホ、あるいはサーバー側に一時的に保存しておく技術のことです。

これにより、次に同じページにアクセスしたときの表示速度を高速化することができます。

電気屋さんの例え話

腕のいい町の電気屋さんは、お得意様から修理の電話がかかってくると、「ああ、佐藤さんちですね。前回は確か、エアコンのフィルターを掃除しましたよね」と、過去の作業内容を覚えているものです。

そのために、お客さんごとに修理内容をメモした「作業日報」や「顧客台帳」みたいなものを持っているかもしれません。

キャッシュは、まさにこの「一度やった作業のメモ」なんです。

Webサイトを表示するとき、毎回律儀にサーバーまで全てのデータを取りに行っていると時間がかかります。

そこで、「このロゴ画像はさっきも表示したな」「このCSSファイルは昨日と同じだ」といった、頻繁に使うデータを自分のパソコンの中に一時的にメモしておくんです。

そうすれば、次回からはそのメモを見るだけで済むので、いちいち大元のサーバーに聞きに行かなくても、ページを素早く表示できる。そういう仕組みですな。

エンジニアとの会話でこう使う

「画像を更新したはずなのに、古い画像のまま表示されちゃうんです…」という相談をされたら。

「ああ、ブラウザが持ってる古い作業メモ（キャッシュ）を見ちゃってるのかもですね！一度そのメモを破り捨てて（キャッシュクリアして）、もう一度見てもらえませんか？」と提案できます。

原因の切り分けに貢献できる、デキる新人だと思われますよ。

9. UIとUX (User Interface / User Experience)

これは何か

UIは「ユーザーインターフェース」の略で、ユーザーが製品やサービスと接する部分、つまり見た目や操作性のことです。

一方、UXは「ユーザーエクスペリエンス」の略で、その製品やサービスを通じてユーザーが得る「体験」や「感情」全体のことを指します。

電気屋さんの例え話

またまた「エアコンのリモコン」の登場です。
リモコンに並んでいるボタンの形や大きさ、文字のフォント、液晶画面のデザイン。これが「UI」です。

一方で、「このリモコン、ボタンが大きくて押しやすいから、おじいちゃんでも迷わずに使えて嬉しいな」とか、「ボタンの配置が直感的で、説明書を読まなくてもすぐに操作できた！快適だ！」といった、リモコンを使ったことで得られた感情や満足感。
これが「UX」です。

つまり、優れたUIは、優れたUXを生み出すための「手段」であって、「目的」ではないんですな。

どんなに見た目がカッコいいリモコンでも、ボタンが小さすぎて押しにくかったら、UXは最悪ですよね。
「使いやすさ」や「心地よさ」といった、人の心に寄り添う視点がUXでは重要になります。

エンジニアとの会話でこう使う

「このアプリ、UIは洗練されてるけど、UXは最悪だよね」という会話が聞こえてきたら。
「リモコンのデザインはApple製品みたいに美しいけど、肝心のボタンが押しにくくてイライラする、みたいな感じですね…。見た目だけじゃダメなんだな…」と呟けば、あなたも議論の仲間入りです。

10. バージョン管理 (Git/GitHub)

これは何か

プログラムのソースコードやデザインファイルなど、コンピュータで扱うファイルの変更履歴を記録・管理するための仕組みです。

「いつ」「誰が」「どの部分を」「どのように変更したか」を全て記録してくれるので、いつでも過去の状態に戻したり、複数人での共同作業をスムーズに進めたりできます。

そのための代表的なツールが「Git（ギット）」で、Gitの仕組みをWeb上で利用しやすくしたサービスが「GitHub（ギットハブ）」です。

電気屋さんの例え話

すごく複雑な配線工事を、複数の電気屋さんがチームで担当する場面を想像してください。
誰がどの配線を担当したのか、いつどの部品を交換したのか、記録がなかったら大混乱ですよね。

そこで、工事全体の「作業工程記録簿」を用意します。
「4月1日、田中がリビングのコンセントを増設」「4月2日、鈴木がキッチンの配線を修正」といった具合に、全ての作業履歴を記録していく。

バージョン管理は、この「完璧な作業記録簿」だと思ってください。

もし、「鈴木が昨日やった修正のせいで、なぜかリビングの電気がつかなくなったぞ！」というトラブルが起きても、この記録簿を見れば、すぐに昨日の状態に戻すことができます。

また、田中さんと鈴木さんが同時に別の場所を工事していても、後で記録簿を一つにまとめることで、お互いの作業内容がゴチャゴチャになるのを防げるんです。

エンジニアとの会話でこう使う

「そのファイル、Gitで管理してるんで、万が一のことがあっても大丈夫ですよ」とエンジニアが言っていたら。
「おお、完璧な作業記録簿があるから、いつでも元に戻せるんですね！安心して大胆な修正をお願いできます！」と返しましょう。

エンジニアは、安心して作業を進めることができるはずです。

どうでしたかね。

ITの世界の言葉たちも、こうして僕らの暮らしの中にあるモノに例えてみると、急に親しみが湧いてきませんか？
もちろん、今日紹介したのは膨大なIT知識のほんの入り口に過ぎません。

でも、大事なのは全ての用語をマスターすることじゃないんです。

大事なのは、分からない言葉が出てきたときに、「これは、うちの家でいうと何に例えられるだろう？」と考えてみる、その思考の“癖”をつけること。

その癖こそが、未知の言葉への恐怖心を取り除き、エンジニアとの対話を楽しむための、最強の武器になるんです。だからこそ、次にあなたがエンジニアとの会議で知らない言葉に出会ったら、チャンスだと思ってください。

「すみません、その〇〇って、何かに例えるとどういう感じですか？」
その素直な一言が、あなたとエンジニアの間の壁を壊し、プロジェクトを成功に導く、魔法の言葉になるかもですな。