この記事は「岩手県立大学とか、岩手の人たち Advent Calendar 2022」の12日目です。
私自身は岩手県立大学とは関係がありませんが、岩手県出身かつ岩手県立大学発のかっこいいベンチャー 株式会社Defios のファンです。株式会社おもしろテクノロジーという会社もやっています。
記事の概要
- 12月なのでクリスマスの抽象化を試みます
- ソフトウェア工学・オブジェクト指向(OOA, OOD, OOP)の観点で記事を書いています
- 哲学や知識科学の領域ついても自分の理解している範囲で触れます
- クリスマスという概念はプログラミング言語よりもあいまいなため
- 専門家ではないので話半分で聞いて下さい。あくまでも自分の理解です。
- 間違っていたら指摘してください
また、クリスマスについて書いていますが宗教的な意図はありません。
3000字程度の記事なのでだいたい3分くらいで読み終わるはずです。
以下、コンテンツになります。興味のある方は読んでみてください。
僕のクリスマスとあなたのクリスマス
クリスマスといえば何を最初に思い出すだろうか、私はクリスマスというと私の友人のエピソードが思い出される。クリスマスに男連中で旅館へ行き、エッチなサンタクロースに遭遇したというものだ。ただこのクリスマスは私の友人を中心とした周辺にのみ共有されるものであり、これを見ている大部分の人間には存在しない経験である。一方、あなただけが経験をしており、私の中にはないクリスマスも存在しているだろう。
そして、「サンタさんからプレゼントをもらった」「クリスマスにケーキを食べた」といったような大部分の人間に共通する経験も存在すると考えられる。
概念の形成
経験に基づくクリスマスの概念はどのように生まれたものだろうか。
当たり前であるが生まれたばかりのころ、我々にクリスマスの概念は存在しない。
人間として社会の中で生活をする、意思決定をする経験を経てそれぞれのクリスマスの概念が形成されていく。
前述の通りそれぞれの概念は各人固有の要素と重複する要素を持つ。それを集合とあらわすと以下の図のようになる。
友人が旅館で体験したクリスマスが大多数の人間に共通しないことや、子供がプレゼントをもらうことが共通なクリスマスであることは直観的に理解できる。
つまり、我々(少なくとも私)は「これは世間一般的なクリスマスだよね」「これって仲間内の話だよね」ということを自分の理性を使って分類[1]をしている。
クリスマスの成功と失敗
果たして、自分の理性と分類は信用に足りうるものだろうか。
自分が考える共通のクリスマスの領域が間違いなくすべての人間によって共通であるとは言えないはずである。自分の考える共通のクリスマスは自分が考えるあなた(他人)のクリスマスによって成り立っている。
また、言語・文章として共通の認識ができていても、その文章によって知覚していることは一致するとは限らない。
ここでクリスマスを複数人で実現するときのことを考えてみる。何もコミュニケーションを取らない状態で「じゃあクリスマスやるから12月24日に集合な!」としたときに、クリスマスを実現することはできるだろうか?それはそれで楽しいだろうが、無秩序な、カオスなクリスマスになるだろう。(そもそも集合できない可能性が高い)
ここで共通の認識が取れたクリスマスが成功、カオスなクリスマスが失敗であると定義したとき、失敗するクリスマスに存在するのは曖昧さである。(ここでは曖昧さを不確実性と表現する)
このクリスマスを成功させるために、取れる手段としては「LINEで連絡する」「Webでやることを調べる」などが挙げられるがこれらはすべて不確実性を削減する行為と考えられる。エンジニアリング組織論への招待[2]によると
「曖昧さ」を減らし、「具体性・明確さ」を増やす行為が「エンジニアリングとは何か」という答えでもある
とあり、「LINEで連絡する」という行為もこのクリスマスの実現においてはエンジニアリング(工学)のための手段の一つであるといえる。
なお、これらの行為をいくらとったとしてもゆらぎが一切存在しない真のクリスマスは達成できないことにも留意が必要である。
しかし、真のクリスマスでなければクリスマスは成功しないということではない。
つまるところ、現実的に成功といえるレベルになるまで不確実性を減らすことがエンジニアリングの役割である。
クリスマスの抽象化・モデリング
長々と書いてきたが、抽象化・モデリングをすることでクリスマスを実現させようということがこの記事の趣旨である。
抽象化
不確実性の削減という観点で抽象化について考えてみる。
抽象(化)とは
経験されたもののなかのある特性に注目してこれを取出し,ほかを捨てること
これは、不確実性が存在する共通のクリスマスにおいて、その領域を減らすことで不確実さを減らそうという試みである。領域を減らし本質を抽出することで、それを他人と共有するときに伝達する必要がある情報量は減る。共通のクリスマスのすべての情報を伝えることは記憶としても時間としても現実的ではないが、対象を抽象化をすることで 上手に 伝えることができるだろう。
また、クリスマスにおいて必要となる情報は目的によって異なる。サンタクロースについて考える場合は、プレゼントについての情報が必要になるし、KFCがクリスマスについて考えるときにはチキンの在庫とオペレーションについての情報が必要になる。抽象化される情報は目的によって異なることを理解する必要がある。
モデリング
今回のケースにおいてモデリングとは、対象を文字ではなく図や構造として記述することと考える。
人間は対象のすべてを認識できない。そのため人間は対象を抽象化をしてモデリングをする。いわゆるオブジェクト指向はモデリングの方法・考え方のことであるオブジェクト指向は"システム化の対象となる領域を自然に写像した分析・設計モデルが作りやすい"と考えられており[4]、それに従ったモデルを記述することで人間が直観的に対象を理解することができると考えられる。
また、それに関連したUMLはUnified model Languageの略であり読んで字の如く統一されたモデル記法のことである[4]。複数の人間が記法についてのルールを共有されることで、対象への理解を深めることができる。これらの活動すべてが不確実性が減少するために寄与している。
実際にやってみる
せっかくなので今回は「サンタさんが子供にプレゼントを渡す」ということをモデリングする。クリスマスにおいてはサンタさんが親であるかどうかについて古来から議論が続いていることで知られている[要出典]。私はサンタさんは親であるという立場を持つ不在派の立場にあり、今回サンタが親であることをより明確に記述することで、我々の認識を強固にしたのちに、発展形、新たなクリスマス、クリスマスイノベーション を起こして産業に貢献することを目標とする。
目的の理解
抽象化・モデリングをするためには目的を理解する必要があるため、今回のクリスマスに求めらている要求を整理する。ここでは、クリスマスの利用者から見える機能要求と、機能に依存しない非機能要求の2つを作成する。
- 機能要求
- 子供がサンタさんからクリスマスプレゼントを受け取れること
- 非機能要求
- サンタさんが親であること
モデリングする
本来であればこれ以外にも必要な情報やプロセスはあるが、記事にしている都合上省略し、今ある情報をもとにモデリングをする。
今回はクラス図を作成した。
機能要求より、サンタにはプレゼントを購入し渡す機能を搭載した。近年のあれこれに配慮して紐づく要素はすべて"0..*"と表現している。(察せ)
また、非機能要求より、Santa Clausクラスを抽象クラスとし、Parentクラスで継承した。Sant Clausは存在しないので実態を持つことは絶対に許されない。そして子クラスであるParentクラスはプレゼントをどう購入するか、どう与えるかの実現方法について委任されている。車で買いに行くなり、トナカイに乗るなり、靴下に入れるなり煮るなり好きにしてよい。
なお、オブジェクトの継承に関しては抽象化に関連させて実世界を記述するという目的の他に、プログラミングの際のコード量を削減するという目的もある[6]ことに注意をする。
まとめ
今回はふざけながらも、哲学っぽい概念からシステムの設計までの考えをまとめてみました。こういう考え方にハマれる人はこの記事の参考文献も楽しめるはずです。興味があれば読んでいただけると仲間が増えたみたいな気持ちで私も喜びます。
みなさまも良いクリスマスライフを!
え、クリスマスを一緒に過ごす人がいない、クリぼっち...?
そんな人は今すぐぼっち・ざ・ろっくをみるんだ!
ギターの録り音が最高で最高だ!
https://bocchi.rocks/
↑ドメインがイケメンすぎる
参考文献
野中郁次郎, 竹中弘高,『[新装版]知的創造企業』,東洋経済新聞社,2020,p39-44
広木大地,『エンジニアリング組織論への招待 不確実性に向き合う思考と組織のリファクタリング』,技術評論社,2018,p11
コトバンク-ブリタニカ国際大百科事典 小項目事典「抽象」,URL, 2022/12/12
玉井哲夫,『ソフトウェア工学の基礎』,岩波書店,2004,p52 p129-130
Kalil Stemmler, 4 Principles of Object-Oriented Programming, URL, 2022/12/12