ソフトウェアと言霊

この記事は [クラスター Advent Calendar 2020](https://qiita.com/advent-calendar/2020/cluster) の21日目です。
昨日は@kyokomiさんの [clusterのAndroidアプリ開発状況の紹介](https://qiita.com/kyokomi/items/67bf126ec0398bc81853) でした。

# はじめに
xyxです。今は正式にclusterのTech Leadをしています。去年はTLっぽい(参考資料: [新生clusterを支えるスプレッドシート技術](https://blog.cluster.mu/2019/12/22/new-cluster-project-spreadsheet/))だけでしたが、startupの1年は長くて短い…

変わったこととして、私自身が未経験な言語やフレームワークを使う開発に対しても、システム全体として「うまくいってる」状態にすることに責任を負うようになりました。

アプローチとして、レビュープロセスや採用のような組織論的な側面、諸々と調和のとれたアーキテクチャのような技術的側面、いろいろあります。組織とアーキテクチャを統合的に見てどう改善するかみたいな話はいろんな論が世の中にあって、私が新たに言えることはあまりないかな…と今は思っています。

それはそれとして、言葉の選択は、コードの可読性をはるかに超える影響を持つと感じていて、**言葉がソフトウェアを形作る**、ぐらい言ってもいいのでは？と常々思っています。

そういう、ちょっと感情的・無意識的な部分について、私の考えを書いてみます。

# 事例: outroom/inroom
@kyokomiさんの記事にもoutroom/inroomという言葉がありました。

clusterには古来よりroomという概念があります。サービスの表には現れない概念ですが、実装的には今でもかなり重要です。

roomとは、人が複数いてリアルタイムに同期されているひとつの場です。

* roomの外: 2D, 非リアルタイム通信, 複数コンテンツの一覧
* roomの中: 3D, リアルタイム通信, 単一コンテンツへの没入

と対称性があって、outroom/inroomという名付けは外・中の概念を直接表現した上で、その2つがサービスとして同等に重要であるという意思表明です。

例えば(Rec RoomやNeosVRのような) 3D空間が主体で、コンテンツ一覧はその中にある一要素、という見方をしていればこういう名前は付けません。

設計するための命名は「ユビキタス言語」として[ドメイン駆動設計](https://www.amazon.co.jp/dp/B00794TAUG)でも重要視されています。この本は、概念を統一しておくと便利ということを言いつつ、規模が大きくなったときにいつ諦めるべきか・諦めたときにどうするかというbounded contextの話が書かれているので私は好きです。

# 識別子の自然言語としての意味
コードに現れる言葉は、計算構造の特定箇所を指す識別子(identifier)であると同時に、人間の集団内で概念を指し示す記号表現([signifier](https://ja.wikipedia.org/wiki/%E3%82%B7%E3%83%8B%E3%83%95%E3%82%A3%E3%82%A2%E3%83%B3%E3%81%A8%E3%82%B7%E3%83%8B%E3%83%95%E3%82%A3%E3%82%A8))であるという点で特徴的です。

私は、自然言語としての意味というのを結構重視しています。なので、例えばclusterでavatarのことをcharacterと書く設計があったら、仮にそれが完全に機能する構造を持っていてもレビューで弾くと思います。

characterは英語的には「キャラクター」の意味も持ちつつ、「特性」(characteristics) 的な意味が強いので完全にずれているというわけではないですが、それならそれでtraitとかstyleみたいな語があります。そして、日本語での「キャラクター」はユーザー自身とは明確に異なる(フィクション上の)人格・存在、という語感が強いです。

2つの言語で正しい意味を持つような選択はちょっと難しい制約ではありますが、日本語主体の組織で英語を使う上では重要かなと思います。自然言語にはそのぐらいの柔軟性はあるし、概念の本質を強制的に2つの言語(文化)の観点から見てみるというのも悪くないな、という感覚があります。

こだわりすぎでは？と思う方もいるかも知れませんが、例えばroom / user / avatar の代わりに、game / player / character と命名されていた場合を考えてみましょう。

その中に「表情」の概念を投入しようとしたとき、

* 前者なら: emotion, expression、そのデータソースはface, input mapper
* 後者なら: emotion, animation、それを制御するのはstatus, hp, behavior

みたいな発想が出てきます。

自然言語には、ひとつの文中に書かれてて自然な(連想しやすい)言葉とそうではない言葉があります。構造に名前をつけるというのは、連想しにくい、距離の遠い概念はあんまり考えなくてもいいよ(場合によっては、考えてほしくない)という意思を表明した上で、新たな概念を生み出す行為です。

例えばiPhoneのfacial captureやってみよう、と思い至り、それが楽に実装できるコードの構造になっている確率は前者が採用されている組織・コードベースの方が有意に高いと思います。逆に後者なら、NPCに転用できるのでは？みたいなアイデアが自然に出てくるはずです。

# 新しい意味を注入する余地
ここまで、言葉は連想によって思考の方向性を誘導するという話をしてきました。逆に、世間的な意味が定まっていないことで、組織独自の意味を育てていける言葉もあります。

avatarというのも若干その気があります。語源がサンスクリット語([अवतार](https://en.wiktionary.org/wiki/avatar#Etymology))で馴染みがなくフィクションで少々使われている程度なので、まだ紐付いた意味が薄く、その「何となく分かるけどなんなんだろう」感は、バーチャル空間という新しい分野の中核概念として考えていくにはちょうどいい気がします。

意味の薄さとその効用が最も強く現れるのが造語です。

clusterには[2020/3/5に「ワールド」が新しく実装されました](https://blog.cluster.mu/2020/03/05/eventreport-cluster-conference-202003/)。同時に、イベントも単一ではなく複数roomを使うことでキャパシティを上げれるように内部の仕組みが変わっています。このとき、イベント・ワールドを包括する概念として、“ひとつのworldと複数のroomからなるもの”ということで、wrs (world room set)という言葉が生まれています。

[Creator KitのWorldGate](https://clustervr.gitbook.io/creatorkit/worldgate)で”WorldOrEventId”という若干謎の表現がありますが、これは内部的にはwrs IDと呼んでいるものを説明的に書いているからです。

この命名はかなり昔の実装に引っ張られているところがあって、たぶんスクラッチで実装すればこうはならない、という名前なんですが、折衷案としては結構気に入っています。

このとき感じていたのが、省略するという行為・その仕方にも強い力があるなーということです。たとえば、world room setと常に書いていれば、world room listもあるかもしれないし、roomsWithWorldもあるかもしれないし、という発想の余地があります。

ここにwrsとある種謎の名前をつけることで、「なにかわからないけど短いし重要っぽい概念」という印象を作って、好きな意味を付与していくことができます。省略形の利用が増えると徐々にもとの語列からは切り離されていって、wrsは”weakly related space”の略なんだよ、とか数年後に後付で言っている可能性もあります。

来年どう実装が変わっているべきかはまだわからないけど、存在はしているだろう、という概念に名前をつけることで、IDを振ることもできるようになるし、IDをkeyとして周りに別の物をくっつけることができます。白紙の意味はシステム上の責務が未定義なこととほぼ同義なので、ある種怪物(god class的な)になりやすいという危険はあります。

とはいえ、名前がある対象は後から議論することで定義を増やして閉じ込めることもできますし、あからさまに誤った命名によって、システム全体で命名が信用できない空気が割れ窓のようにどんどん広がっていくよりはるかに良いと思います。

# ソフトウェアと言霊
いくつか命名とその結果の例を見てきましたが、言葉はコードにも、設計文書にも、会話にも、頭の中にも浸透します。習慣化した言動は組織に長く残りますし、無意識での連想にも影響を与えます。

何かをつくるとき、影響範囲を考えて、範囲内に対しては図や文書や表を書いたり、何らかの体系的な方法で論理的整合性を調べる、ということをすると思いますが、そもそも影響範囲の考慮から漏れたものには意識的・系統的手法は無力です。

範囲の洗い出しに最も影響するのは連想だと思っていて、「思いもよらない」というのは、(2~3段階で)連想できないぐらい遠い、とほぼ同義だと思っています。

ましてや、なにかのrefactorをしていて50個のclassのmethodをIDEで再編してます、みたいなときは、それぞれ数秒ぐらいしか考えないかもしれません。このとき、1段階の連想で思いつかない影響範囲はコードがどうなっていようと考慮されません。テストの存在は単純なエラー防止と、解読を促すことで思考時間を稼ぐ効果はありますが、意味が忘れられたテストはいずれ切り捨てられます。

こうして、メンバーの誰も覚えていないけど、言葉が織りなす構造に合わせてコードが書き換わっていき、プロダクションのシステムの動作に反映される、という現象が発生します。

これは言霊っぽいな、と思います。言葉がシステムを生みだす。
clusterが創造力を加速した先、言葉に依らない概念共有によって限界を超えれると素敵ですね。

# おわりに
ほんとは計算の物理的システムとしての側面も絡めた話を書きたかったんですが、思ったより重い内容でまだ考えがまとまってないので、機運が高まったら別の形で公開します。

明日の記事は最近joinしてくれた、採用に強い人事の@AyukaTakayanagiさんによる「[アバター面接で表現されるクラスターらしさとダイバーシティの可能性について](https://note.com/a_takayanagi/n/n811fed5637ad)」です。