https://www.youtube.com/watch?v=dn_JOu8PPJM&feature=youtu.be
今回も引き続き Swift API Design Guidelines の命名規則を題材に扱いますけれど、今日はその中でも「専門用語」の扱いに着目したガイドラインを眺めていくことにしますね。
人の何かと特別な言葉に代えて表現したくなる性格の中で、それがもたらす効能と弊害に意識を向けて適切に扱える場面を見定めていく。簡単でそれほど特別な話ではないですけれど、自分的にとても関心を寄せてるガイドラインです。
—————————————————————————————— 熊谷さんのやさしい Swift 勉強会 #17
00:00 開始 00:36 前回の self. 省略の話 01:10 前回の increment の話 02:45 専門用語について 06:06 専門用語とは 07:25 難しい用語は慎重に使う 08:59 専門用語が障壁となる場面 10:08 専門用語を使う場面 14:10 専門用語を使うときの注意 15:40 厳密であれば良いともいえない場面も 16:56 ハッシュ 18:21 ぱくスタ 23:58 専門用語を訳して不都合が出た事例 27:14 専門用語を使うときの難しさ 27:37 Swift におけるハッシュの実装 31:19 ハッシュテーブルと衝突 33:40 ハッシュ値は一意ではない 34:31 Hashable と Equatable の関係 36:28 置かれている世界で適切なものを描く 38:51 計算量 41:29 略語は使用しない 42:42 MBP 43:46 msg 44:13 各言語にみる用語の選び方 46:15 I/O 48:45 既存の文化は大切に 49:39 Array 50:49 sin 関数 52:32 通用する世界を見極めて専門用語を使う 54:19 次回の展望 ——————————————————————————————
Transcription & Summarize : 熊谷さんのやさしい Swift 勉強会 #17
前回はセルフの省略の話と、インクリメントの話をしましたね。OJチャンネルでもお話しした内容ですが、いくつか新しい情報を共有したいと思います。
まず、セルフドットについてです。セルフを明示的に書くことは、Swiftではあまり必要ないと言われています。基本的に、セルフドットを書かないことが多いですね。これについて、個人的にはそのように理解しました。
次に、インクリメントの名前の付け方についてです。インクリメントよりもインクリーズの方が適しているのではないかという話も出ましたが、Swiftプログラミング言語の中で「インクリメント」というメソッドが使用されているため、この用語に馴染みがあるようです。また、歴史的にもZ80というアセンブリ言語や、C++のプラスプラス演算子などで使用されています。こういった経緯からインクリメントという用語が現在も使われているのです。このあたりについては、今日のガイドラインでも触れる予定です。
では、本題にいきましょう。今日は、Swift APIデザインガイドラインの続きで、専門用語の取り扱いについて話します。これは個人的にとても興味深い部分です。例えば、薬の効能を理屈で説明するよりも、薬品名を挙げた方が説得力が増すといった話を聞いたことがあります。タウリン何ミリグラム配合とか、トラネキサム酸が何とか、ですね。しかし、個人的にはこういった専門用語はあまり馴染みがなく、伝わりにくいと感じることがあります。
ミーティングを「mtg」と略すことさえ、難しく感じることもあります。しかし、こういった部分を上手にガイドラインとして制定されていることに関心があります。ガイドラインの制定については、ネットやツイッターでも何々な現象に名前を付けたいなどの話題がありますが、個人的にはそのままの表現でも良いのではと思うことも多いです。
では、Swift APIデザインガイドラインに戻りましょう。専門用語についてです。専門用語とは、特定の分野や職業において、精密で専門的な意味を持つ語句のことを指します。これを基に、Swiftで専門用語をどう扱うべきかがガイドラインで示されています。専門用語は単語もしくは長いフレーズの形を取りますが、いずれも特定の分野で専門的な意味を持つものとされています。 それで、基本的に大事なポイントとして、一般的な言葉で意味が通じるのならば、わざわざ難しい用語は使わない方がいいというガイドラインが示されています。例えば「スキン」という言葉で肌を表現する場合、わざわざもっと科学的な生物学用語的な「エピダーミス」（上皮）という言葉を使う必要はありません。「スキン」で通じるならそれで十分です。
逆に、生物学に詳しい人がいたら補足して欲しいのですが、「エピダーミス」という言葉は上皮などの意味も持っているようです。だから、もし上皮と下皮を精密に区別して表現する必要がある場合には、「エピダーミス」という用語が適しているかもしれません。しかし、単純に「肌」を意味する場合には、「スキン」で十分です。専門用語を使うと、その専門分野の人には具体的な意味が伝わる一方で、逆に他の分野の人にとっては意味が通じなくなってしまうことがあります。よって、難しい専門用語を使わずに、簡単な言葉で表現することが推奨されます。
専門用語を使うべきかどうかは、精密に表現する必要があるかどうかに依ります。例えば、専門用語が役立つのは、共通認識としてすぐにイメージできるものがある場合です。最近のiPhone機能の話で言うと、「ステータスバー」と言われたら、iPhoneの一番上のバーの部分がすぐに思い浮かべることができます。他にも「コントロールセンター」という用語も、下から上にスライドして出てくるウィンドウよりも具体的で分かりやすいです。
専門用語は共通認識があれば便利で、適切な場面では使うべきです。しかし、突発的に出てくると困ることもあります。例えば、私はあまりラーメンに詳しくなくて、「ジロー」と言われてもピンと来なかったことがあります。他にも、共通認識がない場合、専門用語を使うのは避けたほうが無難です。
一方で、自動車の運転免許などでは「クリープ現象」などの専門用語が共通認識としてあります。このように、専門用語を使うべき場面ではしっかり使うべきです。ただし、自分の常識が他人の非常識にならないように、自分だけの常識なのか、皆の共通認識なのかを考えて専門用語を使い分けましょうというガイドラインです。
実際に専門用語を使う場合、その意味を正確に理解して使うことが重要です。誤解を招くような使い方をすると、専門家が見ると違うと否定されたり、意図が正しく伝わらなかったりします。例えば、さっきの「エピダーミス」の話のように、誤った使い方をすると、専門家が見た時に起こり得る問題を避けるためにも注意が必要です。
オブジェクト思考という言葉も、原則に基づいていないとオブジェクト思考とは言えないという話になることがあります。例えば、Objective-Cはメッセージパッシング方式ですが、C++やSwiftは仮想テーブルを使う方法でメッセージパッシングと異なる方式を取ります。これにより、オブジェクト思考と言っても、それぞれの方法に違いが生じます。
同様に「ハッシュ」は、ある値を表すユニークな値ではありませんが、専門用語として使う際にはその定義をちゃんと理解して使うことが重要です。 ハッシュ値っていう言葉が一般的になっていますけど、ある値が一意じゃないとどう説明したらいいんでしょうか。ハッシュテーブルなどでよく使われますが、検索を効率的に行うための仕組みですよね。ある値のハッシュ値を取り、そのハッシュ値ごとにテーブルを整理して値をグループ化して保存するという感じです。もう少し具体的にプレイグラウンドで実践すると分かりやすいかもしれませんね。
質問してもいいですか？専門用語を日本語で実装して命名するときに悩むことが多いんです。具体的には、例えばパクパクスタディ制度（略してパクスタ）というのがあります。アプリ内でパクスタに関する変数がたくさん出てきたら、pakuSta...という変数名にするか、LunchSupport...のように英語の単語に訳して使うか、それともそのままカタカナ表記で使うか迷うんですよ。パクスタをそのまま使うと、知っている人には伝わりやすいですが、知らない人には分かりません。
一方、英語に訳す場合、訳し方に揺れが出ることがあります。例えば、パクスタはランチをサポートする制度ですが、目的としては勉強会を盛り上げる制度でもあります。だから「勉強会支援制度」と訳す人もいるかもしれないですね。変数名がぶれることもありますし、無理にローマ字に訳すとダサく感じることも多いです。
はい、例えばどういう感じになるのでしょうか。私が現在の職場に関わることになったとき、パクスタという言葉を初めて聞いたときは何のことかさっぱり分かりませんでした。でも、「パクスタ」という制度の詳細を把握すると、その用語が通じやすくなってきました。
例えば勉強会という構造体を作り、その中にパクスタ対応かどうかを示す情報を持たせるとします。社内で共通認識として「パクスタ」という言葉が浸透している場合は、isPakuStaといったプロパティを持たせても問題ないです。
外部の人にも分かりやすくする場合は、列挙型を作り、その中にcase pakuStaを用意して、勉強会構造体の中でその情報を管理する手段もあります。applyPakuStaといったメソッドを設けて、そのプロパティを列挙型として持たせることで、「パクスタ」という一つの制度があることが伝わります。
このように段階的に専門用語に導いていくことも一つの手段ですね。ただのアイデアですので、必ずしも正解ではないかもしれませんが、参考になればと思います。
ちょっと補足しますね。ある知り合いの実例ですが、専門用語を無理に一般的な英語に直したところ、別の機能追加の際に問題が発生しました。新しい機能が元の英語の翻訳と似ているが微妙に違っており、そのため区別がつかなくなりました。このように、無理にパクスタを「ランチサポート」と訳してしまうと、別のランチ支援制度が出てきたときに混乱する可能性があります。
やはり「パクスタ」という言葉のほうがしっかり位置づけされ、制度の名前自体が変わらない限り安心かもしれません。名前が変わればリファクタリングすればいいだけですしね。
今の話は、日本語の専門用語を英語にする際に一般的な言葉に直してしまうと専門用語の性質が失われてしまう点についても納得です。ありがとうございました。 固有名詞についてお話ししていますが、確かにガイドラインには固有名詞という言葉自体は出てきませんでしたね。専門用語と固有名詞は確かに違うもので、似たようなものに見えますけれども、異なるものです。ありがとうございます。次からはその点を意識できそうです。このスライドの理解が深まったという点では良かったですし、次に考える際には適当に考えずにする指針が立ったと思います。私自身も道しるべ的なものができたように思います。ありがとうございました。
それではプレイグラウンドについてお話ししましょう。専門用語を使う際に、意外と意味を曲げずに使うことが難しいという話を踏まえて、次のお話をします。例えばハッシュについてです。Swiftの中のハッシュというのは非常に面白いものです。
ハッシュ値は1位ではないことはよく知られています。この特徴を持つSwiftのハッシュを少し紹介してみたいと思います。例えばキーを文字列で作ることがよくありますが、このキーのハッシュ値は整数型で取得できます。そして、その整数型のハッシュ値を使って管理するのがハッシュテーブルの基本的な考え方です。ディクショナリー型もそうです。ディクショナリー型はキーとバリューを持つ構造で、そのキーがハッシャブルである必要があります。ハッシュ値は被ることがあります。たとえば、文字列は無限に存在しますが、64ビット整数で表現できるハッシュ値は有限ですから、必ずどこかでハッシュ値が被ることになります。
このハッシュの重複をどう処理するかがハッシュテーブルの鍵です。Swiftではハッシャブルに準拠しているキーとバリューを使いますが、それだけではなく、SwiftのハッシャブルはEquatableにも準拠しています。これが非常に興味深いポイントです。通常、ハッシャブルというのは一致性まで語ることはないのですが、Swiftでは一致性も保証しています。
具体例として、Swiftでdata1 == data2が成り立つのは非常に重要なポイントです。通常、ハッシャブルは一致性まで保証しないので==が使えるわけではありません。しかし、SwiftではハッシャブルがEquatableに準拠しているために一致性が保証されています。AppleのSwift言語開発者にその理由を聞いたところ、プログラムの表現上、こうするのが妥当だという回答を得ました。これはSwiftの面白い特徴の一つであり、非常に興味深いと感じました。 だから、この専門用語を使うときに、その確立している意味を曲げずに使うと言っておきながら、標準ライブラリではハッシャブルの意味を曲げているんですよ。だから意外と、間違っているかと言われたら間違っている気も自分はしないですね。じゃあ、ハッシャブルじゃない別の言葉を使った方がいいのかとも言えない気がします。「アイデンティフィアブル」だっけ？そういう感じでもいいかなとも思わなくもないですが、意外とこのあたりも難しいですね。
でも基本的に、それがちゃんと意味を厳密に表現しているかというのは、一応ガイドラインとして大事にしておくところです。あとは、そのガイドラインを踏まえた上で現実的にどうなのかというところも多分考えていく必要があるんでしょうね、きっと。
あと、コメントの方で計算量についてお話が上がっていて面白いところなんですけど、そのあたりが先日何かの勉強会でちょうどあったんですよね、計算量のお話。そのアウトプット用のチャンネル、スラックにありますよね。あそこに資料が上がっているので、何の勉強会だったかちょっと忘れちゃいましたが、後で自分のノートにも書いておきますね。
計算量の中にもいろいろあって、例えば配列の計算量がO(1)とO(n)が違うのか、というような面白い話があるんです。コメントでいただいたように、「ソーシャルアウトプットシェア」にスライドが上がっているので、よかったら見てみてください。
自分がハッシャブルを紹介してしまったがために、この自分のスライドを語るのが非常に難しくなってしまいました。専門用語は意味に厳格であることが大事だと言っている割には、説得力がなくてですね…。でも、気持ちは通じているかな。専門用語は原則として意味に厳格にし、その上で現実に即したものを選んでいくのがいいんじゃないでしょうか。特に誤解を招かせないことと、専門用語を知っている人にびっくりさせないことが大切です。
Swiftのガイドラインの中では、専門用語の他にも略語についても、専門用語と同じように扱うべきだと言っています。略語は略語として通じやすいところもありますが、それが通じる相手というのはそれを知っている人だけで、知らない人にとっては何なのかわからない。意味を知るためには、その略語が何なのかをたどっていく必要があり、負担が増えてしまうことがあります。
例えば、コメントでいただいていた「メッセージ」と「MSG」のように、メッセージと略さずに書いた方がわかりやすい場合があります。例として「MVP」や「MacBook Pro」などがありますが、特に前者は略してしまうとわかりにくくなる場合があります。
また、C言語の標準ライブラリであるstdio.hのような専門用語は、知っている人には通じても知らない人にはわかりにくいものです。シャープインクルード<stdio.h>やシャープインクルード<iostream>など、STDやCアウトは直感的ではないかもしれません。こういったものは、スタンダードIOやコンソールアウトなど、わかりやすい言葉で表記するのが望ましいでしょう。
わかりやすい言葉があるなら、積極的にそちらを使うべきです。意味の誤解を招かないように、専門用語と略語も慎重に使う必要があります。次のスライドに移りますが、このような注意点を踏まえて見ていきましょう。 ここもやっぱり、そのドメインっていうのかな。そのコード、今プログラムの話だからコードにしていいですね。で、コードの話で、そのコードがどういった人に触れていくのかっていうところを考えたときに、I/OがいいのかこっちのI/Oがいいのか、インプットアウトプットがいいのか。ここに専門用語とそうじゃない一般用語との差が見え隠れするかと思います。
この今分けた8行目のI/Oって書くと、コンピューティングにおけるI/Oなんですよ。インプットアウトプット、何かに書き込んでデータをインプットして、データをアウトプットするバス。そのバスが電子回路だったりメモリだったり、メモリ回路だったりといろいろあるんですけど、とにかくデータ通信で使うI/Oですよね。これをインプットアウトプットって表現すると、出ていくもの入っていくものの、もっと漠然とした雰囲気がすごい出てる気がします。ここでね、ちゃんとコンピューティングのI/Oとして言いたいのか、データ入出力のことを言いたいのかっていうのが、どっちが適切かっていうのが見えてくる気がします。
個人的にスタンダードI/Oを表現するときには、スタンダードインプットアウトプットより、スタンダードI/Oのほうが自分の中のイメージにぴったりするかな。そのあたりは、使う場面によって変わってくると思います。既存の文化っていうものを大事にしようっていうルールもあるんですよ。いくら専門用語をわかりやすい言葉を使おうという話であっても、既存の文化でそれが一般的に浸透している場合には、その用語を使うことで調べやすくなる、意味が通りやすくなる。専門家にとっては既に認識している知識の中から「ああ、それだな」と出てきて、その扱い方とかいろいろイメージが膨らむ。スタック(stack)とかキュー(queue)とか配列(array)とか、そういったものがそうですね。
初心者にとっても、配列(array)って言葉を聞いて「配列って何だ」と思って、たとえばGoogleとかで検索をしたとすると、ズバリ出てくるんですよね。学習コストがかかりにくいってのもありますし、配列(array)で出てきた具体的な情報と専門家がイメージする配列(array)、要はソフトウェア工学でイメージする配列(array)が完全に一致するわけです。そういうふうになるので、配列(array)でよくリスト(list)と話を聞くことがありますが、配列(array)って言うけど、それはリスト(list)を表現しているものだよねという話を聞いたりしますけど、リスト(list)で調べたときに出てくるものと、配列(array)で調べたときに出てくるものというのが、配列(array)っていうのが一般的に浸透しているようであれば、そちらのほうが勝るということですね。
サイン(sin)という関数もそうで、英語で書くと、SINEと表記します。でも、数学とか数学から発展してきた応用数学のコンピューターとかでは、3文字でsinでサインと表現するのが一般常識として浸透しています。ここを正確に表現しようねという意味で、SINEとわざわざ今更書くよりは、浸透しているsinを使ったほうがみんなが平和にいくとか。そのサインというよりもっと平たい言葉で「バーティカルポジションオンユニットサークル」「オリジンオブエンドオブラディウスウィズアングル」、よくわかんないですね。その「ユニットサークル」、単位円のバーティカルポジション、縦軸Y軸、単位円の縦軸の角度に応じて変わっていくのがサインですけど、正弦波、正弦関数波、そういった表現をするよりもズバッとサイン(sin)と言ったほうがわかるわけです。
さっきのパクスタ（パクスタックのこと）なんかもこの部類かもしれないですね。ゆめみにとってはパクスタがすでに広く浸透しているっていう感じなんですかね。外部の人が関与するドメインになったときには、そのあたりを補足していったほうがいいかなという感覚ですね。専門用語って、そういう感じで使う、それが通用する世界をちゃんと見極めて、その通用する世界であれば使っていくという感じです。
他にも、今日の冒頭でお話ししたインクリメント(increment)も、このあたりになるかもしれないですね。ソフトウェア工学的にインクリメント(increment)っていう言葉は、値を増加させるという意味で常識的な用語になっているっぽくて、それを使っていくほうが妥当でしょうと考えることもできます。この文化を大切にというのを考慮するとき。でも、その文化って時代とともに失われていくのもあるじゃないですか。そう考えると、もしかすると今時の価値観だったら、前回どなたかが挙げてくれたインクリメント(increment)よりもインクリース(increase)のほうが自然に感じる、それも選んでいくのも全然ありな気がします。Appleがインクリメント(increment)を使ったからといって、それが正解というわけじゃないんでね。だから、前回みたいに「インクリース(increase)っていうのが良さそうだな」という発想もとても大事にしたいことだなと、このスライドを見て感じました。
じゃあ、これでちょうどいい時間になりましたので、今日の勉強会はこれで終わりにしようと思います。次回は、またもうちょっと一般的な、全般的な証言、そのあたりのガイドラインを引き続き見ていこうかなと思います。はい、それでは、ありがとうございました。お疲れ様でした。