オーストリアのインスブルック大学とカナダのウォータールー大学に所属する研究者らが発表した論文「Universal quantum computer from relativistic motion」は、アインシュタインの相対性理論の原理を応用した量子コンピュータの理論的基盤の確立に成功した研究報告だ。
アインシュタインの“特殊相対性理論”を使った量子コンピュータ、国際チームが設計に成功：Innovative Tech - ITmedia NEWS
量子コンピュータの研究は今まで主に地上の静止した環境で行われてきた。しかし最近では、衛星を使った宇宙空間での量子通信や、離れた場所にある複数のコンピュータを連携させる分散コンピューティングへの関心が高まっている。
アインシュタインの“特殊相対性理論”を使った量子コンピュータ、国際チームが設計に成功：Innovative Tech - ITmedia NEWS
こうした背景から、アインシュタインの相対性理論と量子力学を組み合わせた「相対論的量子情報」（RQI）という新しい研究分野が注目されている。
アインシュタインの“特殊相対性理論”を使った量子コンピュータ、国際チームが設計に成功：Innovative Tech - ITmedia NEWS
⇧ 私のような文系の人間からすると想像を絶する世界ですわな...
オブジェクト指向とは
Wikipediaによりますと、
オブジェクト指向（オブジェクトしこう、英: object-oriented）は、ソフトウェア開発とコンピュータプログラミングのために用いられる考え方である。元々は特定のプログラミングパラダイムを説明するために考案された言葉であり、その当時の革新的技術であったGUI（グラフィカル・ユーザーインターフェース）とも密接に関連していた。
明確な用語としては1970年代に誕生し、1981年頃から知名度を得て、1986年頃からソフトウェア開発のムーブメントと化した後に、1990年頃にはソフトウェア開発の総合技術としての共通認識を確立している。ソフトウェア開発における一つの標語のような扱い方もされている。
オブジェクトとは、プログラミング視点ではデータ構造とその専属手続きを一つにまとめたものを指しており、分析/設計視点では情報資源とその処理手順を一つにまとめたものを指している。データとプロセスを個別に扱わずに、双方を一体化したオブジェクトを基礎要素にし、メッセージと形容されるオブジェクト間の相互作用を重視して、ソフトウェア全体を構築しようとする考え方がオブジェクト指向である。
⇧ とありますと。
英語版のWikipediaの「オブジェクト（Object）」の説明を確認してみると、
Computing
- Object (computer science), a language mechanism for binding data with methods that operate on that data
- Object-orientation (disambiguation), in which concepts are represented as objects
- Object-oriented programming (OOP), in which an object is an instance of a class or array
- Object (IBM i), the fundamental unit of data storage in the IBM i operating system
- Object-orientation (disambiguation), in which concepts are represented as objects
⇧ 上記の内容が正しいと仮定した場合、
- オブジェクト指向（OO：Object-Orientation）
- in which concepts are represented as objects
- オブジェクト指向プログラミング（OOP：Object-Oriented Programming）
- in which an object is an instance of a class or array
で明確に区別されている。
なのだが、海外版のWikipediaでは、「オブジェクト指向（OO：Object-Orientation）」についてのページは用意されていないのだが、「オブジェクト（Object）」はというと、
Object (computer science)
In software development, an object is an entity that has state, behavior, and identity.
An object can model some part of reality or can be an invention of the design process whose collaborations with other such objects serve as the mechanisms that provide some higher-level behavior.
Put another way, an object represents an individual, identifiable item, unit, or entity, either real or abstract, with a well-defined role in the problem domain.
⇧ とあるように、ファジー過ぎて「認識齟齬」を抑制するのは厳しい状況でありますと...
日本語版のWikipediaの「オブジェクト指向（OO：Object-Orientation）」についての説明によると、
オブジェクト指向の来歴
オブジェクト指向プログラミングの発案
オブジェクト指向（object-oriented）という言葉自体は、1972年から80年にかけてプログラミング言語「Smalltalk」を開発したゼロックス社パロアルト研究所の計算機科学者アラン・ケイが、その言語設計を説明する過程で誕生している。
オブジェクト指向の中でケイはメッセージングという考え方を重視していたが、世間の技術的関心はクラスとインスタンスの仕組みの方に集まり、オブジェクト指向の解釈はケイの考えとは異なる方向性で推移していった。
⇧ とあり、Wikipediaの「メッセージング」の説明によると、
メッセージング (英: messaging) とは、データ交換および情報交換のことである。コンピュータ・システムにおいて、メッセージングと称するものは3通りある。
- コンピュータ・ソフトウェアと人との間で行われる通信。ソフトウェアと人とのメッセージングとしては、電子メールやインスタントメッセージ、ショートメッセージなどがある。
- コンピュータ・ソフトウェア同士で行われる通信。例としては、並列処理、オブジェクト指向プログラミング、プロセス間通信が挙げられる。
- コンピュータ・ソフトウェアとネットワークノード間での通信。現状では2のソフトウェア同士の通信（例えばウェブブラウザとウェブサーバの関係）を、ネットワークを介して行うものが主なアプローチであるが、今後はこれらのハイブリッドまたはネットワークノード同士での通信が主流となっていくものと予想される。一例をあげると、端末はネットワークに対してサービスを要求し、ネットワークは端末に対して端末が望む形でサービスを提供する、といった形態がある。サービス指向アーキテクチャ（SOA）における基盤のひとつとしての用語。以降、本項ではこれについて説明する。
⇧ とありますと。
「オブジェクト指向（OO：Object-Orientation）」における「オブジェクト（Object）」の定義がハッキリしないのだが、人間が「システム」の構造を理解をする上で役立つであろうという目的で導入されたと思われる。
というのも、、古典的な「コンピューター」の世界では、
- 0
- 1
の「2進数」の組み合わせで全てが表現できてしまうらしいので、「コンピューター」にとっては「オブジェクト指向（OO：Object-Orientation）」は何の意味も持たないからだ。
と言うよりも、「コンピューター」は、最終的には、
- 0
- 1
で全ての処理を行うらしいので。
ソフトウェア開発の設計とUML（Unified Modeling Language）とER model（Entity–Relationship model）の関係
Wikipediaによる「UML（Unified Modeling Language）」の説明では、
統一モデリング言語（とういつモデリングげんご、英: Unified Modeling Language, UML）は、システムの設計を視覚化する標準的な方法を提供する、汎用ビジュアルモデリング言語である。
ソフトウェア設計における種々の記法やアプローチを標準化するために開発された物で、1994年から1995年にかけてラショナルソフトウェアによって開発され、1996年まで同社によって追加開発が主導された。
多くの種類の図の標準記法を提供し、これらの図は振る舞い図、相互作用図、構造図に大別される。
1997年にはObject Management Group（OMG）の標準モデリング言語に採択され、以降、同団体によって管理されている。2005年にはISOとIECによってISO/IEC 19501として標準化され、最新版のUMLに合わせて定期的に改訂されている。
ソフトウェアエンジニアリングにおいては、大半の実務家がUMLを使用しておらず、代わりに非形式的な手書きの図を使用しているとされる一方で、それらの図はUMLの要素を含んでいる事が多いとされる。
⇧ とあり、少なからず「ソフトウェア開発」で利用されることがありますと。
「ダイアグラム一覧」のセクションを確認すると、
ダイアグラム一覧
UML図は、システムの静的な構造を描写する構造図と、システムの振る舞いを描写する振る舞い図に分けられる。振る舞い図はシステム内のそれぞれの振る舞いを描写するそれと、それぞれのインタラクションを描写する相互作用図に分けられている。
UML 2.0 以降では、14種類のダイアグラムがあり、それぞれの開発局面に応じて使い分けることができる。クラス図、アクティビティ図、シーケンス図が多用される。次いでコンポーネント図、ディプロイメント図、ユースケース図、ステートマシン図である。
⇧ とあるように、システムに落とし込む際に「モデリング」することで情報の関係性を整理・可視化することができますと。
昨今、こういった「モデリング」を行わないことが多いのかもしれませんが、「RDBMS（Relational DataBase Management System）」を利用しているシステムにおいては、
An entity–relationship model (or ER model) describes interrelated things of interest in a specific domain of knowledge. A basic ER model is composed of entity types (which classify the things of interest) and specifies relationships that can exist between entities (instances of those entity types).
In software engineering, an ER model is commonly formed to represent things a business needs to remember in order to perform business processes. Consequently, the ER model becomes an abstract data model, that defines a data or information structure that can be implemented in a database, typically a relational database.
⇧「ER図」を定義することになってくると思われる。
で、「データベース」とかが出てくると、
オブジェクト関係マッピング（英: Object-relational mapping, O/RM, ORM）とは、データベースとオブジェクト指向プログラミング言語の間の非互換なデータを変換するプログラミング技法である。オブジェクト関連マッピングとも呼ぶ。実際には、オブジェクト指向言語から使える「仮想」オブジェクトデータベースを構築する手法である。オブジェクト関係マッピングを行うソフトウェアパッケージは商用のものもフリーなものもあるが、場合によっては独自に開発することもある。
批評
オブジェクト関係マッピングは、オブジェクト指向と関係モデルのインピーダンス・ミスマッチ問題の対症療法にすぎないとも言われている。関係データベースの原則から見れば、オブジェクト指向はデータ操作には不十分であり、パラダイム全体として問題がある。現状のオブジェクト関係マッピングのマッピングは間違っているとも言われ、正しくは型 (定義域) とオブジェクトを対応させるべきとも言われている。
⇧ といったように、「データ」の「型」が異なる問題を解消するための機能が必要になってきますと。
関数型プログラミングもオブジェクト指向プログラミングもオブジェクト指向で解釈できる
ネットの情報を漁っていたところ、
『「オブジェクト指向（OO：Object-Orientation）」は必要なのか？』
という話は度々出てくるのだが、個人的な見解としては、
『無くてもシステムは作れるのかもしれないのだが、ほとんどのものが「オブジェクト指向（OO：Object-Orientation）」で解釈できるのだから不要と断ずる必要はない』
といったところですかね。
ちょっと前に「関数型ドメインモデリング」が話題になったことがあるのだが、
- ドメイン駆動設計（DDD：Domain Doriven Design）
- 関数型プログラミング
を併用するアプローチらしいですと。
Wikipediaによると、「関数型プログラミング」は、
関数型プログラミング（かんすうがたプログラミング、英: functional programming）とは、数学的な意味での関数を主に使うプログラミングのスタイルである。 functional programming は、関数プログラミング（かんすうプログラミング）などと訳されることもある。
関数型プログラミング言語（英: functional programming language）とは、関数型プログラミングを推奨しているプログラミング言語である。略して関数型言語（英: functional language）ともいう。
⇧ とありますと。
全ての関数が参照透過性を持つようなものを、特に純粋関数型プログラミング言語という。そうでないものを非純粋であるという。
関数型プログラミング言語の多くは、言語の設計において何らかの形でラムダ計算が関わっている。ラムダ計算はコンピュータの計算をモデル化する体系の一つであり、記号の列を規則に基づいて変換していくことで計算が行われるものである。
手続き型プログラミングとの比較
C 言語や Java 、 JavaScript 、 Python 、 Ruby などの2017年現在に使われている言語の多くは、手続き型の文法を持っている。
⇧ とあり、純粋な「関数型プログラミング言語」では無くても、「関数型プログラミング」のようなことを行うことはできますと。
試しに、Wikipediaの「JavaScript」について確認してみると、
JavaScript（ジャバスクリプト）は、プログラミング言語であり、HyperText Markup Language（HTML）やCascading Style Sheets（CSS）と並ぶ World Wide Web（WWW）の中核技術の一つである。
⇧ とあり、「プロトタイプベース」の設計で構築されたものらしいと。
Wikipediaの「プロトタイプベース」について確認してみると、
プロトタイプベース (英: Prototype-based) は、オブジェクト指向プログラミング（OOP）のスタイルのひとつであり、オブジェクトの生成に既存オブジェクトの複製を用いるスタイルを指している。これには直後にメンバを拡充するための空オブジェクトの複製も含まれている。このスタイルは、インスタンスベース（Instance-based）とも呼ばれている。これと対比されるOOPスタイルにクラスベースがある。
来歴
プロトタイプベースは、Smalltalkのクラスベース設計を平易化する試みから考案されたスタイルなので、Smalltalkの設計を知らないとそれが作られた理由も分からないものになる。ここではアラン・ケイが概略したSmalltalk設計の六項目を紹介して、クラスベースに関連する部分を和訳しておく。
⇧ とあり、基本的に「オブジェクト指向（OO：Object-Orientation）」であることが分かる。
条件付きではあるが、
- 関数型プログラミング
- オブジェクト指向プログラミング
は、どちらも「オブジェクト指向（OO：Object-Orientation）」で解釈できますと。
オブジェクト指向はチーム開発において設計の意図を共有する上で役立つ可能性がある気はする
で、何だかんだ言ったところで、プログラミングする上で、
- インプット
- 処理
- アウトプット
といった構造を理解する上で図解するとイメージし易くなる気がしており、図にするということは「オブジェクト」で思考していることになりますと。
また、
⇧ とあるように、
- 順接
- 分岐
- 反復
の3つの制御フローを理解する上でも、「フロー図」で図解した方がイメージし易いですし、「フロー図」にするということは「オブジェクト」で思考していることになりますと。
で、「設計」をする上で、様々な情報の関係を整理する上で、
- システム構成図
- システム関連概要図
など、全体を俯瞰できる図があると、各々の機能の役割がイメージし易くなりますと。
「オブジェクト指向」の「オブジェクト」をどう解釈するかなのだが、「設計」で何某かの図を作成するツールを利用する際に、各々の図は「オブジェクト」という扱いをすることが多いように思うので、「オブジェクト指向（OO：Object-Orientation）」で考えていくのが都合が良い気はする。
Wikipediaの情報が正しいと仮定すると、
オブジェクト指向の中でケイはメッセージングという考え方を重視していたが、世間の技術的関心はクラスとインスタンスの仕組みの方に集まり、オブジェクト指向の解釈はケイの考えとは異なる方向性で推移していった。
⇧ と言っていたり、
来歴
プロトタイプベースは、Smalltalkのクラスベース設計を平易化する試みから考案されたスタイルなので、Smalltalkの設計を知らないとそれが作られた理由も分からないものになる。ここではアラン・ケイが概略したSmalltalk設計の六項目を紹介して、クラスベースに関連する部分を和訳しておく
1. EverythingIsAnObject.（全てはオブジェクトである）
⇧ と言っていたりするので、「オブジェクト指向（OO：Object-Orientation）」は、人間が情報を整理する行為においては便利ということなのかしらね。
「個人開発」や「小規模」な開発においては、無くても何とかなるのかもしれないが、「チーム開発」においては、「オブジェクト指向（OO：Object-Orientation）」で「設計」の意図を可視化しておくことが良さそうな気はする。
まぁ、私は専門的に情報工学を学んだわけでもない文系人間なので、
- そもそも、「オブジェクト指向（OO：Object-Orientation）」の定義がハッキリしていないこと
- そもそも、ソフトウェア開発の工程や用語などの定義が統一されずハッキリしていないこと
- etc...
などなど、「ソフトウェア開発」において非効率な要因が枚挙に暇がないように思えて、「不要論」云々の議論の前に整理しないといけない情報がある気がしており、諸々をハッキリさせた上で議論しないと全く持って意味のない議論になると思うのよね...
何と言うか、
ローカルルールもしくは地方ルールとは、ある特定の地方、場所、組織、団体、状況などでのみ適用されるルールのことを指す。
⇧「ローカルルール」のようなものがあるのであれば、定義を明確にドキュメント化してくれないと、「暗黙知」を意識せざる得ないことに因る「認知負荷」のコストも上がりますしな...
そもそも、
カラスは4まで直感的に数えられると言われています。そして人間も直感的理解は同じく「4」が限界のようです。
米国マサチューセッツ工科大学（MIT）とカリフォルニア大学バークレー校（UCB）で行われた2022年の研究で、人間の数を数える能力は「数字に名前があるかどうか」に依存していたことが判明しました。
この研究によれば、数字に名前がない文化では数を数える能力が極めて限定されているといいます。
⇧ 上記サイト様によりますと、明示的に「名前」を付与しておくことは、「認知」を補助する上で効果があるようだ。
つまり、登場人物を整理する上で、何某かの実体として「名前」を付けておくのは都合が良いわけだ。
「文化人類学」の学者であった「クリフォード・ギアツ」氏は、日本だと「意味の網の目」という用語で有名らしい概念を生み出しとされているのだが、
Main ideas, contributions, and influences
Max Weber and his interpretative social science are strongly present in Geertz's work. Drawing from Weber, Geertz himself argues for a “semiotic” concept of culture:
Geertz argues that to interpret a culture's web of symbols, scholars must first isolate its elements, specifying the internal relationships among those elements and characterize the whole system in some general way according to the core symbols around which it is organized, the underlying structures of which it is a surface expression, or the ideological principles upon which it is based. It was his view that culture is public, because “meaning is,” and systems of meanings are what produce culture, because they are the collective property of a particular people.
⇧ とあるように、「認知」には「文化」の「バイアス」がかかるものであり、その「バイアス」のことを「意味の網の目」としているのだと思われる。
異なる「文化」における「空間」の「認知」における有名な逸話があって、
『目の前に「本棚」があるにも関わらず「本棚」を「認知」できない』
というものがある。
図解すると、
■文化A
■文化B
のような感じ。
「外界」の情報としては、同じ「物理空間」を見ているのだが、「文化B」に所属する人の「脳内」では「本棚」が「認識」されませんと。
この場合「文化B」では「本棚」という概念が存在しないため「本棚」という「境界」を「分類」できない、というわけだ。
目の前に広がる「空間」の構成の捉え方が「文化A」と「文化B」で全く異なってくるという事象が発生するということになる。
つまり、「分類」における「度量衡」は、「文化」によって千差万別ということになるので、複数人が「分類」について正確な「認知」を実現するには「認識齟齬」の無い「共通」の「ルール」が必要になって来るわけだ。
ちなみに、「文化人類学」はというと、
⇧ とありますと。
話が脱線しましたが、登場人物を整理する上でも「オブジェクト指向（OO：Object-Orientation）」は役立つ気はする。
「オブジェクト指向（OO：Object-Orientation）」の定義の粒度や適用範囲が難しいのだが...
結局のところ、我々は雰囲気で「ソフトウェア開発」をしている状態から完全に脱すことはできないので、ある程度の妥協が必要になって来るということは避けられないようだ...
だからこそ、「保守・運用」に皺寄せが行くことは致し方ないことだとは思うのだが、
DevOps（デブオプス）は、ソフトウェア開発手法の一つ。開発 (Development) と運用 (Operations) を組み合わせたかばん語であり、開発担当者と運用担当者が連携して協力する（さらに両担当者の境目もあいまいにする）開発手法をさす。
ソフトウェアを迅速にビルドおよびテストする文化と環境により、確実なリリースを、以前よりも迅速に高い頻度で可能とする組織体制の構築を目指している。
⇧「DevOps」を導入したところで、根本の問題である『雰囲気で「ソフトウェア開発」をしている状態』 から脱却しないことには意味が無い気はする...
毎度モヤモヤ感が半端ない…
今回はこのへんで。
