ちょうどこの記事を仕上げようとしていた時に X で次のポストを見かけました。
この動画のコメントらしいです。
悲しいけど珍しいことではありません。
我々エンジニアも仕事によっては言葉のすれ違いで大きな損害を出しかねません。
この記事では誤って使われがちな言葉とともに、誤用やすれ違いによるトラブルを避けるための考え方を紹介します。
TL;DR
- 言葉を正しく扱うには次のことを普段から心がけるといい。
- 知らない言葉に遭遇したら意味を調べる。
- 知っている言葉と知っている言葉がつながってできた言葉の意味を類推せず調べる。
- ある文脈において意味を知っている言葉でも異なる文脈であれば意味を調べる。
- 必要十分な意味を持つ言葉を使う。
- 曖昧な言葉の意味は確認する。
- 自分が使う場合には厳密に、他人が誤用する場合には寛容でありたい。
前置き
僕の言葉の定義に対する思想などを最初に書きます。興味のない方はとばしてください。
そもそも僕は何者か
大学院の数学専攻出身です。
数学ほど言葉の定義に厳密な学問は無いと思いますが、そのおかげもあって学生時代に嫌と言うほど言葉の定義の重要性を知ったので言葉の定義に対しては人一倍敏感です。
どうしてこの記事を書いたか
言葉の定義の重要さを伝えたくて書きました。
言葉の定義を軽視する人は軽視している自覚すらなく、本人も他人も困らせていることが多いように思います。
たまに熱心なのになぜかトラブルを生じさせてしまう方がいますが非常にもったいないです。その原因の1つは言葉の定義の軽視にあると僕は考えています。
心当たりのある方はこの記事の心がけだけでも読んで実践すれば改善できるかもしれません。そういった方やそういった方に悩まされている方の助けになれば幸いです。
僕自身の言葉に定義に対する態度
僕は大前提として、言葉を扱うときはある程度ロバストネス原則に従うべきだと考えています。
ロバストネス原則とは「貴方が自分ですることに関しては厳密に、貴方が他人から受けることに関しては寛容に」という原則のことです。より正確な態度としては、自分自身は正しい意味で言葉を使いつつ、他人が扱う言葉には誤りが含んでいることを前提とすべきだと考えています。
自分がなるべく正しく使うのは当然として、他人は間違った言葉を使う前提とします。他人が誤った言葉を使うことはコントロールできないため、できるだけ相手の意図する意味を確認するなどして言葉の定義を誤っていても正確なコミュニケーションに修正できるように心がけます。
言葉を正確に扱うための心がけと具体例
僕が日頃から心がけていることと、それに対応するデータエンジニアリングの言葉の具体例を紹介します。
なお具体例は少ないのでこれも加えてほしいというのがあればコメント下さい。
初めて見た単語の意味を調べる
当たり前ですが初めて見た単語は調べます。ただし単に辞書を引くような調べ方をするのではなく、複数の情報源を参照すると良いでしょう。
試しに「データリネージ」という単語について調べます。データリネージはここ数年でよく聞くようになりました。
初めて見た単語はとりあえず Web 検索して信頼性が高そうなページをいくつか見ます。
とりあえず検索してみました。
いくつか見てみます。
利用されるデータがどこで登録され、どのシステムを経由し、なおかつどのように加工されて眼前に至っているのか、源泉から現在地点までのデータの変遷のこと
DWH（データウェアハウス）へ統合されたそれぞれのデータについて
- いつ、どこで、どのように取得されたデータなのか
- どのようなETLを経たデータなのか
- どのような分析にかけられるデータなのか
これらの情報を明確にし、データが取得されてからETLを経て分析にかけられるまでの流れ（これをデータパイプラインといいます）を適切に管理するという考え方です。
データ・リネージュは、一定期間のデータの流れを追跡するプロセスで、データがどこから発生し、どのように変化したか、およびデータ・パイプライン内のデータの最終的な宛先を明確に把握できるようにします。 データ・リネージュ・ツールは、あらゆるETLまたはELTプロセス中に適用されるソース情報とデータ変換を含むデータ・ライフサイクル全体にわたってデータを記録します。
データリネージは DataPlex の機能で、システム内でのデータの移動（データの送信元、データの通過先、データに適用される変換）を追跡できます。
Google Cloud の場合はサービスの機能としてデータリネージというものが存在しているということですね。
こんな感じで複数の情報源で調べたことでデータリネージについてのイメージが掴めたと思います。
また Google Cloud のように特定の機能を指すこともあることがわかり、Google Cloud の文脈においては意味が異なるかもしれないと想定することもできます。
データリネージに関しては定義がどこも似通っているため調べるのはこの程度で良いかと思います。
さらにデータリネージの概念を詳しく理解したければ次のようなことをすると理解が深まります。
- メリットなども合わせて調べる
- 関連する用語を調べる。
- 例えば調べたときにデータカタログという単語も出てきたので合わせて調べる。
- データリネージを搭載しているサービスを試しに動かしてみてどんな記録が見れるのか確認する。
小学生のとき、先生が知らない単語は辞書で調べろと言っていましたが、大人になっても大事なことだと最近気づきました。
辞書を引くだけなら小学生でもできますが、大人なら複数の信頼できる情報源を参照しつつ、手を動かすところまでやりたいところです。
言葉の組み合わせから類推しない
知っている単語と知っている単語が合わさったものは知らない単語になるかもしれません。
冒頭の動画でもでてた「黙殺」は無視するという意味ですが、字面だけ見ると「黙って殺す」というふうに見えます。いい大人なら意味を知っているはずですが勘違いしている人がいてもなんら不思議ではありません。
大人になっていろんな単語を身に着けていると、ついつい類推できる気になってしまいますが、組み合わさったときに全然違う意味になってしまうことは全く珍しくありません。
あくまで知らない単語として意味を調べ直したほうが良いです。
具体例
母数
正：分布を決定づけるパラメータのこと
誤：母集団の総数のこと
母数は統計用語です。
どちらかというとデータサイエンスの領域ですが、分析寄りのデータエンジニアであれば知っておいたほうがいいでしょう。
人が使っている分には文脈で（というかほぼ母集団の総数という意味で使われているところしか見たことがないので）意味はわかりますが、自分が使うときに母集団の総数という意味で使っていると統計を勉強していないと思われてしまいます。
Data Architecture
Data Architecture は複数の解釈があります。一例として以下のものがあります。
| 引用元 | 定義 |
|---|---|
| Deciphering Data Architectures | データアーキテクチャとは、情報システム内のデータの全体的な設計と編成を指す。 |
| DMBOK | 企業のデータニーズを明確にし、ニーズに合うマスターとなる青写真を設計し、維持し、データ統合を手引き、データ資産をコントロールし、ビジネス戦略に合わせてデータへの投資を行う |
| IBM | データ・アーキテクチャーは、データの収集から、変換、配布、利用にいたるまでの管理の方法を示します。 データ・アーキテクチャーはデータの青写真と、データがストレージ・システムをどのように動いていくかを設定します。 |
Data Architecture に限らず Data なんちゃらという言葉は本当に解釈が多いです。
Deciphering Data Architectures は Data Architecture 以外の言葉にも言及しており、 次のようなことが書いてあります。
data mesh, data warehouse, data lakehouse などの用語を飛び交っているようだが、10 人に data mesh とは何かと尋ねると、11 通りの異なる答えが得られる。
これらの用語は字面から類推するに留まらず複数の解釈を調べたほうがいいでしょう。
サービスを提供する人と使う人、ビジネス側とシステム側など立場によって言葉の捉え方が変わります。調べるときは立場を考慮すると整理しやすくなるかもしれません。
初めての文脈であれば言葉の定義を調べ直す
慣れ親しんだ言葉でも文脈が異なれば意味が変わることがあります。
例えば三重県では「しあさって」とは4日後のことを指して使われることがあるそうです。
また岡山では「はよしね」は早くしろという意味だそうです。
このようなケースは回避するのがやや難しく、違和感に気付いて初めて正しい定義を理解することになることも珍しくありません。
具体例
BigQuery のマルチリージョン
マルチリージョンと聞いて思い浮かべるのはリージョン間でレプリケーションされて高可用性を実現するような仕組みではないでしょうか。
ではここで BigQuery のマルチリージョンを見てみましょう。
BigQuery のロケーション-マルチリージョン
上記の公式ドキュメントには次の記述があります。
注: マルチリージョン ロケーションを選択しても複数リージョン間のレプリケーションやリージョン冗長性は提供されないため、リージョン停止の場合にデータセットの可用性が向上することはありません。データは地理的位置内の単一のリージョンに保存されます。
BigQuery のマルチリージョンはより大きな割り当てを期待するものであり、可用性向上につながるものではないことに注意が必要です。
Airflow の start_date
DAG の実行タイミングを設定しようとするとき、 start_date と schedule_interval を設定します。
字面を見る限り、直感的には start_date に設定した日時に最初に実行され、 schedule_interval に設定した間隔が経過するごとに DAG が実行されます。
が、実際には start_date に設定した日時以降の直近の schedule_interval が完了した時点が初めての実行タイミングになります。
何言ってるんだこいつと思った方はぜひ調べてください。
本番環境で初回実行されなかった、みたいな事例が発生しうる恐い仕様だと思いました。
こういった例もあるので字面で判断せずにドキュメントを読んで言葉の意味を調べたいものです。
必要十分な範囲の言葉を使用する
例えば git のコミットメッセージで [fix] 不具合の修正 のようにコミット種別を冒頭につけることがあると思います。
このとき、何らかの変更を加えたということで [change] を使うと言葉の定義が広すぎてあまり意味がありません。
もっと細かいニュアンスのある言葉を使うことでよりほかの人が commit の内容を理解しやすくなります。一例としては次のようになります。
- fix
- 修正。間違ったものから正しいものへの変更
- tweak
- 微調整。わずかな誤りや悪い部分がある状態からから望ましい状態への変更
- delete
- 削除。もともと存在したものが無くなるように変更
それではデータエンジニア向けの例を見てみます。
具体例
Data Driven
データに基づいて意思決定する場合に Data Driven を使うのは間違ってはいませんが、Data Informed を使ったほうがよりふさわしいケースを多く見ます。
Data Driven という言葉を使った場合はデータが主体の意思決定という意味に解釈されやすくなります。
人間の判断を主体とし、データも使った意思決定をする場合は Data Informed を使用して区別したほうが言葉の範囲が狭まり伝わりやすくなります。
言葉の意味を確認する
他人が複数の解釈ができる言葉を使ってきた場合や間違った使い方をしている疑いがあるときは意味を確認して意味を特定します。
管理職の方は特にメンバーの使った言葉の意味の確認は日常的にやっているのではないでしょうか。
例えばタスクの進捗を聞いたときに「順調です」と言われた場合に、掘り下げて聞くと全然順調ではなかったという経験のある方もいるでしょう。
確認を怠ると前提が覆って痛い目に遭う可能性があり、心がけの中でも特に重要です。
具体例
テーブルの列名や description
列名や description と実際のデータが乖離していることは本当によくあります。
最初はよく定義できていたけどデータが徐々に拡張されるにつれてズレていくなどの事情がありそうです。
列名だけを見てこういうデータが入っているんだなと想像せずに、実際に中身を見てみるなどの細かい対応が必須です。
あとがき
余談1 言葉の定義を大事にするとトラブルを防げる
僕が言葉の定義を厳密に扱うよう心がけるようになったのは大学院生の頃からです。
数学のセミナー中に指導教官にボコボコにされ続けた結果、言葉の定義に気をつけるようになりました。
言葉の定義を正確に扱えなければ正確な知識を積み重ねていくことができないことを、学生時代に嫌と言うほど痛感しました。
大学院までいってなかったら言葉の定義の重要性を理解できず、苦労していた可能性があると考えると恐ろしいです。
言葉の定義を大事にしない人は苦労している印象を受けます。しかも当人は自覚がないままにです。
X で文章の意味を汲むことができずに難癖コメントをつけるような人を「文字が読めても文章が読めない」などと揶揄する表現があり、そのような人は相当に苦労していると思います。これも突き詰めれば言葉の定義の確認の積み重ねができていないために起きてしまうと考えています。
この記事を読む人の中にそのようは人はいないと思いますが、仕事でつい定義がフワフワな言葉を使ってしまったり、逆に使われてしまったときに正確な意味を探りにいかなくて後から困ってしまう経験をしたことくらい誰でもあるのではないでしょうか。
言葉の定義に気をつけることで、不毛なトラブルを防ぐことに繋がります。
余談2 言葉を誤用しても指摘されない
社会人になってからは言葉の誤用に関する指摘を受けることはほとんどなくなりました。
日頃から注意しているおかげもあるでしょうが、わざわざ間違いを指摘してくれる人が滅多にいないのが大きいのだと思います。僕自身も自分に害がない限りはめんどくさくて指摘しませんしね。
めんどくさくて指摘しないのは自然な発想です。
言葉の定義を軽視する人ほど知識の積み重ねが浅いため言葉が通じにくくなり、間違いを指摘してもめんどくさいと思われた上に伝わらない可能性が高いです。言葉の定義の重要性についてはなおさら伝わりません。だから指摘しません。
これは恐ろしいことで、自分が間違っていても誰も指摘してくれない可能性が高いです。この記事に書いたような心構えで日頃から気をつけていく必要があります。
そのうえで僕は身近なところでまずそうな誤用を見つけたときはめんどくさい人だと思われるリスクをとってでもなるべく指摘しています。誤用に対する指摘が起きない環境に自分の身を置くことのほうがまずいと考えているからです。
記事の冒頭に自分が使う場合には厳密に、他人が誤用する場合には寛容でありたいと書きましたが、別に誤用されても怒らないし、だめな人だとも思わないです。だれでも定義を間違ってしまうことはあります。
この考え方が広まれば指摘することも指摘されることも自然になって世の中良くなるんじゃないかなーと思ってます。
最後に
偉そうに記事を書きましたが、僕自身も定義を間違えたり調べきれないことがあります。
日々新しい言葉が生まれる現代においては定義を調べ続けるのは大変ですが、言葉を正しく扱うにはひたすら調べ続けるしかありません。
この記事で言葉の定義の重要性が少しでも伝われば幸いです。