ぱと隊長日誌

ブログ運用もエンジニアとしての生き方も模索中

「常識」が常識とは限らない

常識とはその人のこれまでの経験の積み重ねから生み出されるものです。人はみな異なる経験を積んでいます。よって、各自が持っている常識は多少なりともズレているものです。「常識」の一言で片づけず、お互いの思う常識を理解し合うことが大切です。

本屋の本棚の下の引き出しをお客さまが勝手に開けたことを店員が咎め、トラブルに発展した話を聞きました。この話を聞いた時、思い出したことがあります。

雨の日になるとデパートの入口には傘袋が設置されたりします。

長い間、私には傘袋を使う理由が分かりませんでした。というのも、当時の自分にとって傘袋は「雨に濡れた傘が自分の服にあたって濡らすのを防ぐもの」という認識でいたからです。どうせ雨で服が濡れているのだし、傘袋は使わなくてもいいや、と思っていました。

そして、傘袋を設置する台には「お使いください」のようなメッセージはあれど、なぜ使うべきかの説明はありませんでした。傘袋を使う理由が「常識」だったからでしょう。

そんなある日、メッセージボード付の傘袋の台を見かけました。そこには「他のお客さまの服に傘があたって濡らさないように傘袋をお使いください」と書いてありました。そこで初めて、傘袋を使うことが他のお客さまへの配慮につながることに気づかされました。自分の「常識」とお店が求めている「常識」のズレに気が付くことができたのです。

本屋の話に戻ります。

本屋で探している本が本棚に見つからないとき、店員に声をかけると店員は本棚を探し、次に引き出しを開けて探すことがあります。もしかしたら、お客さまはそんな経験を繰り返し、本棚の下の引き出しは本棚の続きでしかない(お客さまにとっての「常識」)、そう思ったのかもしれません。そうであれば、探している本が本棚に見当たらなければ自分で引き出しを開けて探す気持ちは理解できます。

一方で店員にとって本棚の引き出しは勝手に開けられては困る場所だったのでしょう(店員にとっての「常識」)。店員の常識に反する行動をしたお客さまを見て、店員は思わず声を荒げてしまったのかもしれません。

もし、ここで自分の持っている「常識」と相手の持っている「常識」が違うかもしれないことを双方が思い浮かべていたら、結末が変わっていたかもしれません。

もしかしたら、本棚の引き出しに格納されている本は単なる在庫ではなく、まだ発売日前の本であったり、在庫に登録されていない本なのかもしれません。そうだとして、店員がお客さまへ声を荒げて叱る前に一言でもその説明があったなら。お互いの「常識」のズレがなくなり、丸く収まったかもしれません。

「常識」とはその人のこれまでの経験の積み重ねから生まれます。この「常識」がお互いにズレていることはありうることだし、お互いに理解し合う努力をしなければなりません。ましてや「非常識」と切って捨ててはいけません。

当たり前、常識、当然、と言いたいこともあります。でも、常識は人によって異なります。そして、常識のズレはわかり合えることもあります。自分にとっての常識を説明し、相手の常識を理解しようとする姿勢が必要なのではないでしょうか。

データベースはレコード・フィールドではなく、行・列と表現すべき

概要

Joe Celko はデータベースにおいて、行 (row)・列 (column) という用語を使うべきであり、レコード (record)・フィールド (field) という表現は適切でないと主張しています。これは論理的存在と物理的存在を分けるべきとの考えからです。

はじめに

先日、Twitterにて奥野さん(@nippondanji)と私(@pato_taityo)の間でこんなやり取りがありました。

【奥野さん】

DB業界に飛び込んだ当初は、何の疑いもなく「レコード」という用語を使ってしまっていたんだけど、後からこれはRDBでは使うべきではないと思うようになった。はっきり言って誤用。RDBerは「行」という用語をきっちり使うべき。同様にフィールドではなく列(カラム)を使うべき。

https://twitter.com/nippondanji/status/1103218605511008256

【私】

無知で申し訳ないのですが、「レコード」という用語を使うべきでは無い、という理由を教えていただけないでしょうか…?ググってみたものの行き当たれず。また、英語表記であれば何とすべきでしょうか?

https://twitter.com/pato_taityo/status/1103226485123346432

【奥野さん】

SQLにそのような用語はないからです。行(row)、列(column)を使いましょう。

https://twitter.com/nippondanji/status/1103226704573587457

このやり取りをきっかけに用語 (row, column, record, field) の違いを調べることにしました。

奥野さんからは参考書籍として以下の2冊をお勧めされました。

SQL and Relational Theory: How to Write Accurate SQL Code

SQL and Relational Theory: How to Write Accurate SQL Code

  • 作者:Date, C. J.
  • 発売日: 2015/11/16
  • メディア: ペーパーバック

上記2冊の本は手持ちになかったのですが、「プログラマのためのSQL 第4版」(以下、「プログラマのためのSQL」)でも今回のテーマに関する記述がありました。

プログラマのためのSQL 第4版

プログラマのためのSQL 第4版

そこで今回は「プログラマのためのSQL」をベースに考察を進めることにしました。

Joe Celko による行と列の定義

Joe Celko は「プログラマのためのSQL」の著者です。

Joe Celko はこんな言葉を残しています。

Columns are not fields. Rows are not records. Tables are not files,

Joe Celko - Wikipedia

まさに今回のテーマそのものの言葉です。

この Joe Celko が「プログラマのためのSQL」で行と列をどのように定義したのかを確認します。

行 (row) はレコードではない。レコードはアプリケーションが読み込むことで初めて意味を持つ。レコードはシーケンシャルで、最初、最後、次、その前といった順序が意味を持つ。行はいかなる物理的な順序も持たない(ORDER BY はカーソルにおける句であって、SQLの一部ではない)。
プログラマのためのSQL 第4版 1. データベース VS ファイルシステム

行はレコードではない。レコードはそれを読み込むアプリケーションプログラムの中で定義される。行はデータベーススキーマの中で定義されるのであって、それが意味を持つためにプログラムを必要としない。フィールドの名前は、アプリケーションのREAD文やINPUT文の中で定義されるのに対し、行はデータベーススキーマの中で名付けられる。同様に、READ文におけるフィールド名の物理的順序は絶対である(READ a, b, c は、READ c, a, b ではない。しかし、SELECT a, b, c は SELECT c, a, b と同じデータである)。
プログラマのためのSQL 第4版 1.3 行 VS レコード

列 (column) はフィールドではない。フィールドはそれを読み込むアプリケーションから意味を得る。またアプリケーションによっては複数の意味を持つことがある。フィールドはレコードの中で順序づけられており、データ型も制約もデフォルト値も持っていない。すなわち、列とフィールドの違いは、前者が能動的データであるのに対し、後者は受動的データである、という点が大きな違いである!
プログラマのためのSQL 第4版 1. データベース VS ファイルシステム

データベースは能動的にすべてのデータの正しさを保つように動く。そのための道具は、トリガー、制約、そして宣言整合性制約である。
プログラマのためのSQL 第4版 1.4 列 VS フィールド

この定義の意味をCSVファイルとテーブルを例に確認します。

CSVファイル

100, 10

◆ テーブル

値段 数量
100 10

READ a, b がCSVファイルの1列目を変数a、2列目を変数bに格納する命令であったとします。

引数の順序の異なるREAD文でCSVファイルを読み込んだときの結果を示します。

READ命令 値段 数量
READ 値段, 数量 100 10
READ 数量, 値段 10 100

READ の引数の順序とCSVファイルのフィールドの順序は対応しています。よって、引数の順序が変われば、その値が意味することも変わってきます。

これに対し、以下の2つのクエリの結果は変わりません。
SELECT 値段, 数量 FROM テーブル
SELECT 数量, 値段 FROM テーブル
プログラムで列番号を指定して値を取得すれば、2つのクエリの間で結果が変わると思うかもしれません。ですが、列番号は物理的な順序を意識しています。属性(例では値段・数量)を指定すれば順序を意識する必要はありません。つまり、結果が変わらないといえます。

では、CSVファイルにヘッダをつければフィールドではなく列として扱えるのでしょうか?

値段, 数量
100, 10

これは依然としてフィールドです。なぜなら、ヘッダも含めてその意味するところはアプリケーションによって決まるからです。アプリケーションがヘッダを参考に値を読むことも、ヘッダを無視して値を読むことも可能です。

また、このCSVファイルを表計算ソフトに読み込むのか、テキストエディタで読み込むのかによってもファイルの意味するところが変わります。表計算ソフトであれば表データとして扱うでしょうし、テキストエディタであれば単なるテキストとして扱うでしょう。

このようにアプリケーションが意味を決めるという点で受動的データであり、フィールドといえます。

議論

用語を区別する必要はあるのか?

行とレコードを同一視している記事が多くあります。また、私たちは会話でもこれらの用語を区別することなく用いています。それだけ頻繁に区別なく用いられるこれらの用語を区別する必要はあるのでしょうか?

私はあると考えています。なぜなら、理論を議論する際に定義のあいまいさが解釈の妨げとなるからです。これは勉強会で議論する際に痛感したことでした。題材とした本の用語の定義が明確になっておらず、議論の度にまずはそこでの用語の使い方から議論が始まることになったのです。

用語の定義は議論する際だけに気を付ければよいものではありません。普段から意識しなければ急に切り替えられるものではありませんし、アウトプットも混在したものになります。いざ正しい定義で扱おうとしたときに混乱することになるでしょう。

用語の定義は妥当なのか?

今回参考にした用語の定義は Joe Celko の主張ともいえます。データベースの用語として行 (row) とレコードが混在して用いられているこの状況で、用語の定義は果たして妥当といえるのでしょうか?

この疑問に対するヒントを以下のQ&Aから見つけることができます。
terminology - What is the difference between a "record" and a "row" in SQL Server? - Database Administrators Stack Exchange

このQ&Aで回答者の Aaron Bertrand は以下の回答をしています。

In any case, say what you will about the guy's online character, but he wrote the standard, and the fact that such an authority dictates that there is a distinction should tell you something.

terminology - What is the difference between a "record" and a "row" in SQL Server? - Database Administrators Stack Exchange

Joe Celko は ANSI/ISO SQL 標準化委員会の委員を務めてきました。その彼が用語を区別して用いるべきだと主張しています。

また、回答者の Phil は回答の中で、SQL標準(ドラフト版のようですが)に record より row という単語のほうが多く登場していること、テーブルの説明に row という用語が繰り返し登場していることを挙げています。

このほか、PostgreSQLのマニュアルでも "row" という用語を用いてSQL言語の概念を説明をしています。

Each table is a named collection of rows. Each row of a given table has the same set of named columns, and each column is of a specific data type. Whereas columns have a fixed order in each row, it is important to remember that SQL does not guarantee the order of the rows within the table in any way (although they can be explicitly sorted for display).

PostgreSQL: Documentation: 11: 2.2. Concepts

これらを用語の定義の妥当性とするには根拠が弱いです。ですが、無視できない事実でもあります。

まとめ

行とレコードを区別することなく用いられている現状を踏まえると、データベースの用語として行 (row)・列 (column) を用いるべきという主張にコンセンサスが取れているとはいいがたいです。

ですが、私は論理的存在と物理的存在を用語として明確に分離すべきと考えています。なぜなら、それらは異なる存在だからです。そして、データベースの用語として Joe Celko は行 (row)・列 (column) を提案しました。

あいまいな定義は議論の妨げとなります。より適切な用語を選択するべきという観点から、データベースにおいては用語として行 (row)・列 (column) を積極的に利用すべきではないでしょうか。

デブサミ2019「【15-B-2】メンバーの成長とチャレンジのためにエンジニアリングマネージャーとして大切にしたこと」聴講メモ

はじめに

Developers Summit 2019 (Developers Summit 2019)
【15-B-2】メンバーの成長とチャレンジのためにエンジニアリングマネージャーとして大切にしたこと
スピーカー:山本 学 [ヤフー]
の聴講メモです。

メモは口頭説明を中心にまとめています。資料を併せてご参照ください。

Twitterのつぶやきがtogetterでまとめられています。併せてご参照ください。
デブサミ2019【15-B-2】メンバーの成長とチャレンジのためにエンジニアリングマネージャーとして大切にしたこと #devsumiB - Togetter

【参考】としている個所は私が挿入しています(補足や参考資料など)。登壇者の講演内容ではありませんので、その旨ご了承ください。

まず伝えたいこと

マネジメントの定義「組織の為に組織の人たちをいきいきとさせ高度な成果を上げる」はドラッカーの言葉を引用した。

そもそも

小さい頃のブロック遊びが楽しかったように、モノ作りは根源的に楽しいこと。だからエンジニアリングは楽しいといえる。

マネジメントに対する印象

マネジメントへの興味がまだ薄そうな周囲の若者にマネジメントへの印象を聞いてみた。

この中で「体制側」と出てくるが、これはプレイヤーには決定事項のみが伝えられ、マネジメント側が全て決めている。その間には越えられない一線がある。ということらしい。

このアンケート結果を受けて、発表の内容を変えることにした。当初はhow-toを中心に資料をまとめていたが、それよりもまずはこのマイナスな印象を払拭することにした。

パフォーマンスの方程式 Robbins (2001)

チームのパフォーマンス=
チームが本来持つ生産性
+プロセスゲイン(協働作業によるシナジー効果・適材適所の役割分担)
+プロセスロス(協働作業による負のシナジー効果・コミュニケーションコスト)

この方程式からチームのパフォーマンスは個人の能力以外にも影響を受けていることが分かる。

また、プレイヤーとマネジメントでは成果の出しどころが違う。

  • プレイヤーの成果の出しどころ
    • チームが本来持つ生産性
  • マネジメントの成果の出しどころ
    • プロセスゲイン
    • プロセスロス

Ep2.はじめてのピープルマネジメント

評価の際はする側とされる側で組織の評価制度のすり合わせから始めた方が良い。面談をしていると、この認識のズレていることが意外と多い。

達成感を感じる瞬間/成長を感じる瞬間

マネジメントの達成感は対象がチームなのでちょっと感じにくいところはある。

だが、(自分の成長だけでなく)メンバーの成長も感じられることをふまえると、もしかするとメンバーよりも達成感を感じやすい面もあるかもしれない。

成長の支援

個人を成長させることができれば、チームとしての生産性も上がる。

なにを/どう学べばいいか分からない

ティーチングが有効。エンジニアリングマネージャーとして、組織での評価や市場価値を上げるために何を学ぶと良いかを教える。これにはエンジニアとしてのバックグラウンドが活きてくるはず。

学ばざるを得ない状況を作る。このままではいけない、周囲に迷惑をかける、という思いがあると動く。
ただ、危機感で動くと初速は出るが、その勢いを継続させるにはポジティブな体験が必要となる。例えば、仕事に活きたとかリスクを回避できたとか。

学んでいるはずだが成長の実感が無い

同じプロジェクトに長く従事していると成長を感じられなくなる。これにはコーチングが有効となる。

1on1で仕事から学んだ経験やメタ知識を掘り出してあげる。

エンジニアがアウトプットしやすい環境づくり

オープンな勉強会を会社主催で開催することで、広くフィードバックを得られるようにしている。

楽しくマネジメントを続けるためには

自己犠牲をしない。例えば、自分が行きたいイベントに参加するチャンスを安易に他の方に譲ってしまうこと。これは自分のモチベーションに影響してしまうので、やってはいけない。

楽しさにフォーカスを当てることでマネジメントを避ける人を減らしたい。

Ask The Speaker

セッション後、登壇者に質問してみました。

Q1.
本人の方向性と組織が望む方向性にずれがあるときどうするか?

A1.
1on1で話し合う時は日を分ける。今週は個人目標、来週は組織目標のように。これをまとめて話し合うことはしない。
個人目標と組織目標の方向性にずれがある場合、個人目標は給与などへ反映できないことを説明する。

Q2.
私にとってマネジメントは個人のリーダーシップを最大限引き出すことだと思っているが、山本さんはどのように考えられているか?

A2.
全員がリーダーシップをとれるわけではない。エンジニアを風林火山に分類した方がいたが、その人に適した役割をアサインすることが重要なのではないだろうか。
【参考】
風林火山の分類は小野和俊さんが提唱されたものだと思われます。下記の記事を参照ください。
プログラマー風林火山 : 小野和俊のブログ
リーダーシップについては私と山本さんの間で定義が違ったかもしれません。この点についてすり合わせたうえでお話ししてみたかったです。

所感

私はマネジメントが楽しいものだと思っています。私の場合、マネジメントする対象が小さく、気持ちよく働けるメンバーに恵まれたからという状況ではありますが、今回の発表には共感するポイントがいくつもありました。

まとめの「自己犠牲をしない」という言葉は心に響きました。というのも、仕事があまりに忙しく、周囲に迷惑をかけたくないという思いから、今回のデブサミ参加は見送ろうかと直前まで悩んでいたからです。でも、メンバーの「行くべきです。(迷惑をかけたくないからと)諦めたらだめです。」という言葉に背中を押され、今回参加することができました。今はメンバーへの感謝とともに、「自己犠牲をしない」という言葉の重みを感じています。

チーム全員が活き活きと活躍できる場をこれからも作っていきます。