ふにゃっとしない名前の付け方 〜哲学で茹で上げる、コシのあるソフトウェア設計〜

Transcript

1. ふにゃっとしない 名前の付け方 〜哲学で茹で上げる、コシのあるソフトウェア設計〜 PHPカンファレンス香川2026 あくしも @akshimo
2. • このスライドはネット上に公開しています • forteeのトーク画面からご覧ください • 公開しているものと投影するものは一部内容が異なります この資料について
3. • ウィトゲンシュタインという哲学者の考え方に触れてもらう • パキッとした答えを出すものではない ◦ むしろ命名の際に立ち止まって一度悩んで欲しい • 哲学がベースの話なのでどうしても抽象的にはなります ◦ 最後にちょっとだけ実践的な話もします 今日の目的
4. • エンジニアリングの結論としては、初〜中級者向けのもの • ベテランエンジニアにとって目新しい結論ではない（と思う） • 切り口は聞いたことないと思うのでその辺りも楽しんでほしい 今日の内容 一般教養としても楽しい内容になれ ばと思います
5. • 哲学の話→ソフトウェア設計への応用という構成にしてます • あくまでもソフトウェア設計の話が主目的です ◦ 目的を果たせる範囲で簡略化かつ表面的な説明をします ◦ “都合よく”解釈してる部分があります ◦ 哲学をプラグマティックに”悪用”しています 構成
6. • 哲学のDr.を持ってる人間が話してるわけではありません ◦ 誤りや不備が含まれる可能性があります ▪ 是非フィードバックをください ◦ 「大学1~2年生の小僧がなんか言っとるわ」くらいで聞いて下さい • 「これが唯一の答えだ」という主張ではありません ◦ 「哲学をヒントに考えてみたけどどうだろう？」という内容です 注意事項
7. 参考書籍 ※推薦書籍ではない
8. • Eric Evans『ドメイン駆動設計』 • Vlad Khononov『ドメイン駆動設計をはじめよう』 • Robert C. Martin『Clean Code』 • 増田 亨『現場で役立つシステム設計の原則』 • 石川 宗寿『読みやすいコードのガイドライン』 • Dustin Boswell, Trevor Foucher『リーダブルコード』
9. • ウィトゲンシュタイン著、野矢茂樹訳『論理哲学論考』.岩波文庫 • ウィトゲンシュタイン著、鬼界彰夫訳『哲学探究』.講談社 • 飯田 隆『ウィトゲンシュタイン』 • 古田 徹也『ウィトゲンシュタイン「論理哲学論考」の基本』
10. • 永井 均『ウィトゲンシュタイン入門』 • 橋爪 大三郎『言語ゲームの練習問題』 • 橋爪 大三郎『はじめての言語ゲーム』 • 中村 晃『ウィトゲンシュタイン、最初の一歩』 • 中村 晃『ウィトゲンシュタイン「哲学探究」入門』
11. • 鈴木 俊貴『僕には鳥の言葉がわかる』 • 石田 英敬『記号論講義』 • 内田 樹『寝ながら学べる構造主義』 • ガイ・ドイッチャー『言語が違えば、世界も違って見えるわけ』 • 佐藤 信夫『レトリック感覚』 • 町田 健『ソシュールと言語学』 • 服部 裕幸『言語哲学入門』
12. • オーストリア出身の哲学者 • 1889年~1931年 • ラッセルのもとで学ぶ • 前期: 『論理哲学論考』 • 後期: 『哲学探究』 ルートヴィヒ・ウィトゲンシュタイン
13. 論理哲学論考
14. 1. 世界は成立していることがらの総体である。 2. 成立していることがら、すなわち事実とは、諸事実の成立である。 3. 事実の論理像が思考である。 4. 思考とは有意味な命題である。 5. 命題は要素命題の真理関数である。（要素命題は自分自身の真理関数であ る。） 6. 真理関数の一般的な形式はこうである。　　　　　　これは命題の一般形式であ る。 7. 語りえぬものについては、沈黙せねばならない。 8. ウィトゲンシュタイン著、野矢茂樹訳『論理哲学論考』
15. 世界ってよくわからんな 世界を言語でマッピングできるんじゃない？ そしたら哲学の問題全部解決したわ
16. 現実のコトだけを直接思考するのは難しい 世界
17. 直接は難しいので模型で考えてみる 模型 世界
18. “マッピング”して実際の世界の模型をこしらえる 模型 世界 マッピング
19. “マッピング”には写真や楽譜などがある 模型 世界 マッピング
20. 最強の“マッピング”は言語である！ 「昨日うどんを 食べたphperが 存在する」 模型 世界 マッピング
21. 「昨日うどんを 食べたphperが 存在する」 世界 マッピング 同じ構造 模型 “マッピング”した場合、実物と同じ構造となる
22. ？ 世界 マッピング 同じ構造 模型 コトバを知らないと言語の模型を作るのは難しい
23. 「昨日うどんを 食べたphperが 存在する」 世界 コトバ マッピング 同じ構造 事柄 事柄 模型 コトバ
24. • 実際の世界からコトバを使ってマッピングする • コトバの理解が不十分だとマッピングが難しい • 世界と模型は同じ構造でなければならない • 模型は世界の事柄をマッピングしている ◦ マッピングは完全なコピーではない ソフトウェア設計への応用
25. 「昨日うどんを 食べたphperが 存在する」 世界 マッピング 同じ構造 模型
26. 「昨日うどんを 食べたphperが 存在する」 ドメイン マッピング 同じ構造 モデル
27. 商品 商品モデル ・在庫数 ・値段 ドメイン マッピング 同じ構造 モデル “マッピング”は”モデリング”と呼んでもいい
28. 商品 商品モデル ・在庫数 ・値段 ドメイン マッピング 同じ構造 モデル “マッピング”した際に不要なものは抜け落ちる 例：材質、生産工場
29. 商品 商品モデル ・在庫数 ・値段 ドメイン マッピング 同じ構造 モデル “マッピング”しても、同じ構造、同じコトバを使わなければ ならない！
30. うどん うどんモデル ・材料？ ・作り方とか？ ドメイン マッピング 同じ構造 モデル コトバを知らないと、モデルを作るのは難しい！
31. ドメインをマッピングができてないと class Account { public float $balance; } class AccountService { public function reduceBalance(Account $account, float $amount): void { if ($account->balance < $amount) { throw new Exception("残高不足です"); } $account->balance -= $amount; } }
32. ドメインをマッピングができてないと class Account { public float $balance; } class AccountService { public function reduceBalance(Account $account, float $amount): void { if ($account->balance < $amount) { throw new Exception("残高不足です"); } $account->balance -= $amount; } } ドメインと違う構造
33. class Account { public float $balance; } class AccountService { public function reduceBalance(Account $account, float $amount): void { if ($account->balance < $amount) { throw new Exception("残高不足です"); } $account->balance -= $amount; } } ドメインをマッピングができてないと ドメインと違うコトバ
34. ドメインをマッピングができてないと class Account { public float $balance; } class AccountService { public function reduceBalance(Account $account, float $amount): void { if ($account->balance < $amount) { throw new Exception("残高不足です"); } $account->balance -= $amount; } } 知識のマッピング漏れ
35. ドメインをマッピングができてないと class Account { public float $balance; } class AccountService { public function reduceBalance(Account $account, float $amount): void { if ($account->balance < $amount) { throw new Exception("残高不足です"); } $account->balance -= $amount; } } 分散する知識
36. • 「口座」「残高」「出金」「残高は0以上」という構造・コトバ • 世界（ドメイン）をモデリングし、そのままコードに落とし込む 世界（ドメイン）に一致させる
37. そのままコードに落とし込む class Account { public function __construct(private float $balance) { // 不変条件 if ($balance < 0) throw new DomainException("残高がマイナスです"); } public function withdraw(float $amount): Account { if ($amount <= 0) throw new InvalidArgumentException("金額が正しくありません"); if ($this->balance < $amount) throw new DomainException("残高不足です"); $this->balance -= $amount; } }
38. そのままコードに落とし込む class Account { public function __construct(private float $balance) { // 不変条件 if ($balance < 0) throw new DomainException("残高がマイナスです"); } public function withdraw(float $amount): Account { if ($amount <= 0) throw new InvalidArgumentException("金額が正しくありません"); if ($this->balance < $amount) throw new DomainException("残高不足です"); $this->balance -= $amount; } } ドメインと同じコトバ
39. そのままコードに落とし込む class Account { public function __construct(private float $balance) { // 不変条件 if ($balance < 0) throw new DomainException("残高がマイナスです"); } public function withdraw(float $amount): Account { if ($amount <= 0) throw new InvalidArgumentException("金額が正しくありません"); if ($this->balance < $amount) throw new DomainException("残高不足です"); $this->balance -= $amount; } } ドメインと同じ構造
40. そのままコードに落とし込む class Account { public function __construct(private float $balance) { // 不変条件 if ($balance < 0) throw new DomainException("残高がマイナスです"); } public function withdraw(float $amount): Account { if ($amount <= 0) throw new InvalidArgumentException("金額が正しくありません"); if ($this->balance < $amount) throw new DomainException("残高不足です"); $this->balance -= $amount; } } 口座のルールは口座にマッピング
41. チームでモデルは常に良くしていく
42. ソフトウェアを書き始める時、我々は対象を十分に理解しているわけでは ない。（中略） 高度に生産的なチームは、自分たちの知識を意識的に育てて、継続的学 習（Kerievsky 2003）を実践する。 Eric Evans『ドメイン駆動設計』 p.16
43. • ドメインの構造や名前に必然性はあるのか？ • 同じ言葉を違う部署の人が違う意味で使ってることはないか？ いくつかの疑問
44. コトバの境界線
45. モノが先にある モノに名前をつけるのが命名である
46. アダムの前に野の獣が連れて来られます。それを見て、アダムは「じゃ、 これは牛、これは馬、これは犬」というふうに名前をつけてゆきます。 まず「もの」があり、ただ名前がついていないだけなので、人間がこちらの 都合で、あとからいろいろ名前をつけること、それがことばの働きである、 というのが『創世記』に語られている言語観です。（中略） しかし、この言語観は、いささか問題のある前提に立っています。それ は、「名づけられる前からすでにものはあった」という前提です。 内田 樹『寝ながら学べる構造主義』
47. 命名（対象）が先にあるのか？ 命名（対象）は必然なのか？ こういうときは 極端な例を見てみるのも良い手
48. シジュウカラ語 “蛇”を指す語とそれ以外の敵を指す語が 違う （蛇は「ジャージャー」それ以外の敵がきて 警戒を促す場合は「ピーツピ」） 蛇とそれ以外で境界を引いており、シジュ ウカラの言語の世界にカラスは存在しな い
49. • 古代ギリシャの詩人 • 現代の感覚だと「色彩表現がおかしい」「色彩の語彙が少ない」 ◦ 葡萄酒色の海 ◦ 緑色の蜂蜜 ホメロスの詩
50. • ホメロス以外にも様々な言語で色彩表現がおかしい例が見つかった • 色彩の語彙を獲得する順番にある程度共通している ◦ 白/黒 → 赤 → 緑/黄 → 青 → … 色覚表現の変化
51. 赤 ホペ 命名するモノが先にあるなら 緑 ププ
52. 赤 ホペ 実際はこうだった 緑
53. 色の名前に必然的な境界線はない
54. 日本語も例外ではない
55. 「エディプス」とは、図式的に言えば、子どもが言語を使用するようになる ことと、母親との癒着を父親によって断ち切られること、この二つを意味し ています。（中略） 「父」は子どもと母との癒着に「否」を告げ、同時に子どもに対して、ものに は「名」があること（あるいは「人間の世界には、名を持つものだけが存在 し、名を持たぬものは存在しない」ということを」）を教え、言語記号と象徴 の扱い方を教えるのです。 内田 樹『寝ながら学べる構造主義』 p.187
56. • 色の境界は言語によって恣意的 ◦ 虹の色の数も違う • フランス語では蛾と蝶は同じ単語 • イヌイット語では雪を区別する語が多い • 家族表現は言語によって違う（英語で”兄”を言うには？） 命名に必然性はない
57. ソフトウェア設計に応用するなら ユーザー 会員 ゲスト 購入者 出品者 どこに境界を引くことも可能！
58. ソフトウェア設計に応用するなら ユーザー 会員 ゲスト 購入者 出品者 「ユーザー」に「出品者」「購入者」の知識を 入れたら所謂「神クラス」になる危険がある
59. 命名に必然性はないなら、 どう世界（ドメイン）に 境界を引けば良いのか？
60. 経済性の原理
61. シジュウカラ語も 色彩の名前がつく順番も 合理性があった
62. マルチネは、コトバには意味を伝達する機能があることを前提としなが ら、コトバを支配する原理として「経済性」があると主張しました。経済性と は、コトバのしくみは人間ができるだけ労力を使わなくてすむように、効率 的に出来上がっているという性質のことを言います。 町田 健『ソシュールと言語学』 p.140
63. • 現場ではある程度合理的なコトバが使われているはずである • 倉庫担当者は「受注の明細の商品を確認し棚から拾い上げ箱に入れてい く作業」とは言わず、「ピッキング」と言うはず • だが、担当者ごとにコトバの使い方が違ったりする場合もある • ソフトウェア設計の視点から見て適切なのかという問題もある コトバには経済性がある
64. 言語ゲーム
65. 　「言語ゲーム」という概念 第 １節の例について考えてみれば、語の意味に関する一般的な概念と いうものが、どれだけ言語の働きをもやで覆い、事柄をはっきり見えなくし ているかを、おそらく人は感じるだろう。─言語に関わる諸現象を、語の目 的と働きがはっきりと見渡せるような原初的な言語の使用に即して探究 すれば、霧は晴れる。 子供は話すことを学ぶ際に、こうした原初的な形の言葉を用いる。その場 合、言葉を教えることは、説明ではなく訓練である。 ウィトゲンシュタイン『哲学探究』 p.20
66. • コトバの意味は訓練により獲得する • コトバは言語ゲームの中で使って初めて意味を持つ • 同じコトバでも言語ゲームが異なれば意味が異なることがある 私が思った言語ゲームのエッセンス
67. • ひや？あつ？汁は？ • 太さは？ • グルテンフリーで作られたうどんはうどんではないのか？ “うどん”を定義できるか？
68. うどん 「コレはうどんだ」使い 方を学習する
69. うどん 「コレもうどんだ」使い 方を学習する
70. うどん 「コレもうどんだ」使い 方を学習する
71. うどん “うどん”を使える ようになった、かも？
72. • うどん原理主義派はグルテンフリーのうどんは「うどんではない」と言うか もしれない • どちらが正解というわけではなく、言語ゲームが違う • コトバは言語ゲームの中で初めて意味を持つ 言語ゲームは集団や状況によって違う
73. “横断歩道”は道路を横断するためのもの
74. 子供の遊びにおいては”白いところ以外はマグマ”
75. • 横断歩道は（多くの大人にとっては）歩行者が道路を横断するためのもの • 子供の遊びでは安全地帯（白いところ以外はマグマ！）になる • 同じモノを見ていても、子供は子供の世界（ドメイン）を作っている 子供の言語ゲーム
76. 仮にライオンが話すことができたとしても、我々に は、ライオンが理解できないだろう。 ウィトゲンシュタイン『哲学探究』 p.407
77. 事業における言語ゲーム 注文とは顧客との成約。 約束した金額を期日までに決済してもら う必要がある。 注文とは顧客へ荷物を発送する単位。 注文された商品を確認し配送方法を決 定したのち期日までに発送する必要が ある。 営業部署 配送部署
78. 事業における言語ゲーム 成約日時 決済金額 決済方法 支払い期限 発送日時 発送期限 重量 配送方法 営業部署 配送部署
79. “全部入り”のモデルを作ると 注文モデル • 成約日時 • 発送日時 • 発送期限 • 重量 • 配送方法 • 決済金額 • 決済方法 • 支払い期限 このモデルの関心は何...？
80. 言語ゲームで境界を引く 営業の言語ゲーム 倉庫の言語ゲーム 注文モデル • 成約日時 • 決済金額 • 決済方法 • 支払い期限 注文モデル • 発送日時 • 発送期限 • 重量 • 配送方法 同じ名前のモデルでも、 異なるモデルにする！
81. モデルや境界は改善し続ける
82. “青信号”は本当に緑？
83. 1. “青信号”という名前が広がる（戦前頃？） 2. 「名前と違うじゃん！」という指摘が広がる（1970年代） リネームか振る舞いの変更か
84. 1. “青信号”という名前が広がる（戦前頃？） 2. 「名前と違うじゃん！」という指摘が広がる（1970年代） リネームか振る舞いの変更か 選択肢は2つ 1. 名前を変える=緑信号にする 2.実体を変える=信号を青色にする
85. 1. “青信号”という名前が広がる（戦前頃？） 2. 「名前と違うじゃん！」という指摘が広がる（1970年代） 3. 世界的な規格で進め信号に緑色以外を使うことはできない リネームか振る舞いの変更か
86. 1. “青信号”という名前が広がる（戦前頃？） 2. 「名前と違うじゃん！」という指摘が広がる（1970年代） 3. 世界的な規格で進め信号に緑色以外を使うことはできない 4. 規格上で許される範囲ギリギリで青色に近づけた！ リネームか振る舞いの変更か
87. 1. “青信号”という名前が広がる（戦前頃？） 2. 「名前と違うじゃん！」という指摘が広がる（1970年代） 3. 世界的な規格で進め信号に緑色以外を使うことはできない 4. 規格上で許される範囲ギリギリで青色に近づけた！ リネームか振る舞いの変更か リネームというリファクタではなく、 実体（振る舞い）の変更を選択した！
88. 1. “青信号”という名前が広がる（戦前頃？） 2. 「名前と違うじゃん！」という指摘が広がる（1970年代） 3. 世界的な規格で進め信号に緑色以外を使うことはできない 4. 規格上で許される範囲ギリギリで青色に近づけた！ リネームか振る舞いの変更か リネームはそれだけ痛みを伴うこともある リネームは可能だが、最初の命名に手を抜いてはいけない
89. ここまでのまとめ
90. • ドメインと同じ構造・同じコトバを使うモデル/コードを作る • 技術レイヤーだけで考えない • 何も考えずにドメインの構造をそのまま適用すれば良いとも限らない ドメインをコードにマッピングする
91. • 命名することにより、対象のスコープが決まってくるのではないか • 任意の境界の引き方ができる • コトバには経済性があるので、現場のコトバを使えば”そこそこ”はうまくい く可能性があるのではないか コトバに必然性はない
92. • 業務領域の中で同じコトバを使う言語ゲームを発見する • 適切な言語ゲームを発見し、システム上に境界を引く • チームで協力し新しい言語ゲームを作る • 新しく作った言語ゲームは使用しながら進化させる 言語ゲーム
93. 注釈と謝罪
94. わかりやすくするため/エンジニアリングに応用するために、都合よく解釈した り、表面的な説明しかしていなかったり、誤魔化している箇所がある。 よって、少しだけ注釈を加えたい。 注釈と謝罪
95. • 論考でいう「言語」は自然言語のことではない。理想的な人工言語のこと • 図の左側は「世界」というより「論理空間」というべきだと思われる 論理哲学論考
96. • 「語りえぬもの」とは例えば以下である ◦ 私（主体） ◦ 神、善悪 ◦ 論理形式、存在 • 少なくとも「語彙が増えれば世界が広がる」ようなものはではない 語りえぬもの
97. • “蛇”については、初めて聞く雛も意味を理解している • ア・プリオリであり、恣意性がないようにも思える • これを反論に使われると弱い（例として適切でなかったかも） シジュウカラ語の蛇はア・プリオリ？
98. • 「色」ではなく「質感」や「状態」を表していたという説もある ホメロスの色彩表現について
99. • 必ずしも生物学的な父親である必要はない • 世界の理不尽（自分が関係なくすでに定まっていること）を与えるものであ る • 例えば、近所のおじさん、姉、国家、などでも良い 父親による理不尽な境界
100. • それぞれの言語ゲームは家族のように似ていて共通部分を持つ ◦ ただし、全言語ゲームの共通部分（言語の本質）はない • 言語ゲームだけで明確に境界づけられたコンテキストを定義できるとは限 らない • 常にチームで話し、より良い境界を探し続けることが重要 家族的類似性
101. 実践・応用編
102. ◯はなんと命名する？ for ($◯ = 1; $◯ <= 100; $◯++) { if ($◯ % 3 === 0) { echo ‘Fizz’; } }
103. ◯はなんと命名する？ for ($i = 1; $i <= 100; $i++) { if ($i % 3 === 0) { echo ‘Fizz’; } }
104. • スコープが短ければ、名前は短く簡単なものでも良い • プログラマは「iはループイテレータに使われる」という言語ゲームを参加し ている 簡単なイテレータなら ”i”で十分
105. 読み上げて意味の通る 名前にする
106. 読み上げて意味の通る名前にする // cstmr=customerの略。コレはわからない！ $cstmrName = ‘Hoge’; // 略語だけど読み上げても意味がわかるからOK！ $url = ‘https://...’;
107. モデルを改良する最適な方法の１つは、話してみることだ。考えられるモ デルのバリエーションから生じるさまざまな概念を、声に出して構成して みる。荒削りな表現は聞けばすぐわかる。（中略） 単語やフレーズを使っていろいろ試しながら、モデリング作業に言語能力 を活用することがきわめて重要だ。 Eric Evans『ドメイン駆動設計』
108. 命名の機会を作る
109. ファクトリメソッド class Account { private function __construct(private float $balance) {...} public static function fromBalance(float $balance): self { return new self($amount); } public static function open(): self { return new self(0); } }
110. 再代入をしない // 良くない例 $price = 100; $price = $price * $fee; // 手数料加算 $price = $price * 1.1; // 消費税計算 // 良い例 $itemsPrice = 100; $priceWithFee = $itemsPrice * $fee; // 手数料加算 $priceWithTax = $priceWithFee * 1.1; // 消費税計算
111. おすすめの書籍
112. ドメイン駆動設計をはじ めよう 今日の内容は（あまり用語を使わないよ うにしたが）DDDに関する内容が多かっ た。 今日話したソフトウェア設計の部分をちゃ んと(?)学びたい方に。
113. ウィトゲンシュタイン、最 初の一歩 ウィトゲンシュタインの概略について高校 生でもわかるよう書かれている。 まずはウィトゲンシュタインの思想を少し 体験してみたい人にオススメ。
114. 言語ゲームの練習問題 言語ゲームについて実践的に考えてみ たい人へ。 理系の大学生への授業が元ネタなの で、エンジニアにとってもとっつきやすい 内容のはず。
115. 言語が違えば、世界も 違って見えるわけ 色の名前の話などは、これを参考にして る。 コトバの境界線あたりの話があまりピンと きていない、または、もっと深掘りしたい 方はこれから読むのもおすすめ。
116. 最後に
117. 6.54　私を理解する人は、私の命題を通り抜け――その上 に立ち――それを乗り越え、最後にそれがナンセンスであ ると気づく。そのようにして私の諸命題は解明を行う。（いわ ば、梯子をのぼりきった者は梯子を投げ捨てねばならな い。） 私の諸命題を葬りさること。そのとき世界を正しく見るだろ う。 ウィトゲンシュタイン著、野矢茂樹訳『論理哲学論考』 p.149
118. 皆さんと私が このセッションの内容を 投げ捨てられますように