ハッカー倫理に準拠した人工知能のアーキテクチャ設計 | Accel Brain - Part 6

ハッカー倫理に準拠した人工知能のアーキテクチャ設計

Accel Brain; Console×

もともと建築学の用語であった「アーキテクチャ(Architecture)」という概念は、多方面で参照されて再記述されたことにより、抽象の度合いを高めることになった。今やアーキテクチャという概念の「定義」に関する統一された認識は得られない。この概念に言及するには、何らかの形容詞を付加させることで意味を限定する必要がある。

ソフトウェア・エンジニアやアーキテクトが「ソフトウェア・アーキテクチャ(Software architecuture)」と呼んだ場合、それによって指し示されるのは、専らエンジニアが開発するソフトウェアやコンポーネントのアーキテクチャとなる。だがソフトウェア工学との関連では、この他にも無数のアーキテクチャ概念が遍在している。ソフトウェア・アーキテクチャソフトウェア・アーキテクチャとしての意味を保持するには、他のアーキテクチャ概念との「差異」が如何にして成り立つのかを確認しておかなければならない。

人工知能研究の領域でも、とりわけ機械学習の一種である「深層学習(Deep Learning)」の研究領域では、「深層アーキテクチャ(Deep Architectures)」という概念が取り沙汰にされている。その内部のアルゴリズムが「制限ボルツマンマシン(Restricted Boltzmann Machine)」や「自己符号化器(auto-encoder)」のようなデータサイエンス特有の様々な仕様で記述されている分、それぞれの層の入出力インターフェイスが未定義で可変的であるという差異はあれど、複数の階層分化した水準の各層における命令フェッチや命令デコードをはじめとしたベクトル演算処理がパイプラインとして結合されているCPUとしてイメージできる点では、深層アーキテクチャコンピュータアーキテクチャと概念的によく似ている。

アーキテクチャ」は、社会科学系の研究者たちや文系教養人の口からも発せられる用語である。例えば憲法学者ローレンス・レッシグが記述した「アーキテクチャ(Architecture)」の理論は、社会学や権力論をはじめとする社会科学の領域で広く受け入れられている。「アーキテクチャ設計(Architecture Design)」と述べた場合、ソフトウェア・エンジニアやアーキテクトにおいてはソフトウェアのオブジェクト指向設計に連なる諸々の設計ノウハウが連想される。その一方で社会科学系の研究者たちは、この用語から整備をはじめとする社会の制度設計を連想する。しかしその割に、そうした研究者たちは、自身が対象としている同じ「社会(Gesellschaft)」の内部に位置するはずのソフトウェア開発の現場に対して、取り立てて取り上げるほどの貢献を果たしていない。

アーキテクチャ」という用語は、エリク・エヴァンスらを筆頭とした「ドメイン駆動型(Domain-driven)」の開発者たちが好んで使用するような「共通言語」ではなくなっている。この用語は、様々なドメインにおいて、異なる意味で用いられている。ドメイン駆動型の開発が無力と化すのは、「共通言語」という言語が全く以って共通していないというパラドックスに直面した場合である。彼らが如何に境界を設定した上で確保した「文脈(context)」の中で「ユビキタス言語(Ubiquitous Language)」を語ったとしても、ユビキタス言語は、それ自体ユビキタスではないのである。

デザインパターン(Design Pattern)、アーキテクチャパターン(Architecture Pattern)、スタイル(Style)、イディオム(idiom)などのように、「共通言語」を物語る概念は多数散見される。これらは過去のエンジニアたちの経験則を言語化することで共通認識の得られ難いという問題を解消する点で機能的に等価だが、機能的等価物が多過ぎる状況もまた一種の問題として設定できる。何故なら、無数の選択肢は視野狭窄を招き、選択負担を増大させるからだ。

しかし、こうしたパターンやフレームワークなどといった「共通言語機能を有した概念に接する場合、注意しなければならないのは、そうした「共通言語」が<反事実的>に再利用され続けているという「歴史」だ。パターン、スタイル、イディオムなどといった諸概念の散乱した状況は、「共通言語」そのものの非共通性物語っている。とても「共通言語」の設定に成功しているとは言えない。しかし、それにも拘わらず、デザインパターンアーキテクチャパターン、あるいはフレームワークなどといった概念は、恰も追従すべき「規範」であるかのように選択され続けている。

こうした<反事実的>に規範として期待され続けているノウハウや方法再利用する場合、我々はそれがある種の「形骸」として成り立っている可能性に注意を払うべきだろう。さもなければ、実際には何の効果もメリットも無いにも拘らず、「馬鹿の一つ覚え」の如く、無価値にそれを選択し続ける羽目になる。

歴史」を知る読者は、こうした「共通言語」の営みが建築学者のクリストファー・アレグザンダーに由来していることを直ちに想起されるであろう。アレグザンダーの「パターンランゲージ(Pattern Language)」に由来する「デザインパターン」や「アーキテクチャパターン」をはじめとした様々な「共通言語」は、今日、ソフトウェアの開発ノウハウなど知る由も無い社会科学系の研究者たちも含めた様々な「専門」や「識者」などによって語られ続けられたことによって、<共通言語化>の<非共通化>というパラドックスが派生している。

しかしそれでも、アレグザンダーに由来する<共通言語化>の営みや「共通言語」そのもの機能は、パターンランゲージデザインパターンに関して嬉々として語りたがる「専門」や「識者」を背景に、言うなれば「権威に訴える論証」によって、<反事実的>に、「規範」であるかのように社会システムに受容され続けている。

こうした状況に対して、以下の各記事では、まずはアーキテクチャアーキテクチャ設計歴史意味論を記述することで、「共通言語」の非共通性を浮き彫りにしていこう。アレグザンダーとそれに連なる「専門」や「識者」の嬉々に関しては、ハーバート・アレグザンダー・サイモンの「人工科学(Artificial science)」を対置することによって相対化することとしよう。

しかし、こうした無用な「規範」に止めを刺す上でより有力な手掛かりを提供しているのは、1970年代から現代まで続くハッカーたちの文化である。彼らの1970代後半までのハッカー倫理は、近代社会の社会構造に抵抗する思想の下に成り立っていた。その反権威主義的な思想に準拠した彼らの口から「権威に訴える論証」が出てくることは、まずあり得ないと期待できる。彼らは権威付けられた知識ではなく情報の接続可能性(accessibility)を重視するためである。

彼らの思想は、1980年代から徐々に、とりわけ金融工学との関連から、資本主義経済システムに融け込んでいくことになる。それは反近代的なハッカー倫理近代社会の内部に「再導入(re-entry)」する意味論的な変異であった。この金融市場社会構造ハッカー倫理歴史意味論を遡れば、<反事実的>に「規範」として安定化している「共通言語」の有象無象を一掃する手掛かりを抽出できる。

アーキテクチャ中心設計の社会構造とアーキテクチャの意味論

もともと建築学の用語であった「アーキテクチャ(Architecture)」という概念は、多方面で参照されて再記述されたことにより、抽象性の度合いを高めることになった。今やアーキテクチャという概念の「定義」に関する統一された認識は得られない。この概念に言及するには、何らかの形容詞を付加させることで意味を限定する必要がある。ソフトウェア・エンジニアやアーキテクトが「ソフトウェア・アーキテクチャ(Software architecuture)」と呼んだ場合、それによって指し示されるのは、専らエンジニアが開発するソフトウェアやコンポーネントのアーキテクチャとなる。だがソフトウェア工学との関連では、この他にも無数のアーキテクチャ概念が遍在している。ソフトウェア・アーキテクチャがソフトウェア・アーキテクチャとしての意味を保持するには、他のアーキテクチャ概念との「差異」が如何にして成り立つのかを確認しておかなければならない。

続きを読む

近代社会の社会構造とハッカー倫理の意味論

デザインパターン、アーキテクチャパターン、スタイル(Style)、イディオムなどのように、クリストファー・アレグザンダーの「パターン・ランゲージ(Pattern Language)」に由来する「共通言語」を物語る概念は多数散見される。これらは過去のエンジニアたちの経験則を言語化することで共通認識の得られ難いという問題を解消する点で機能的に等価だが、機能的等価物が多過ぎる状況もまた一種の問題として設定できる。何故なら、無数の選択肢は視野狭窄を招き、選択の負担を増大させるからだ。こうしたパターンやフレームワークなどといった「共通言語」機能を有した概念に接する場合、注意しなければならないのは、そうした「共通言語」が<反事実的>に再利用され続けているという「歴史」だ。パターン、スタイル、イディオムなどといった諸概念の散乱した状況は、「共通言語」そのものの非共通性を物語っている。とても「共通言語」の設定に成功しているとは言えない。しかし、それにも拘わらず、デザインパターン、アーキテクチャパターン、あるいはフレームワークなどといった概念は、恰も追従すべき「規範」であるかのように、選択され続けている。こうした<反事実的>に規範として期待され続けているノウハウや方法を再利用する場合、我々はそれがある種の「形骸」として成り立っている可能性に注意を払うべきだろう。「共通言語」のマッチポンプを脱パラドックス化するには、専門組織や専門家の専門言語への盲目的な追従を否定する観点が有用となる。この関連から利のある情報を提供してくれているのは、いわゆる「ハッカー倫理(Hacker Ethic)」に基づいた「対抗文化(Counter Culture)」の「社会運動(Social movement)」の事例である。この倫理は、機能する問題解決策の一つとして例示できる。

続きを読む

ラショナル統一プロセス(RUP)の社会構造とアーキテクチャ設計の意味論

アーキテクトは、「共通言語」の非共通性や全体最適化のパラドックスを脱パラドックス化し続けると共に、尚且つ投資に対する効果を目に見える形で提示しなければならない。言い換えれば、アーキテクチャ中心設計に伴う派生問題は投資対効果の「速度」の問題であると言える。一つの問題解決策として挙げられるのは、IBMが定式化した「ラショナル統一プロセス(RUP:Rational Unified Process)」だ。このRUPは、ソフトウェアの開発プロセスの一種で、開発組織における各担当者の役割や責務の割り当てを実施する際の体系的な方向性を提示してくれる。RUPは、エンドユーザーの要求に応じた高品質なソフトウェアをスケジュール通りに納品するのは「如何にして可能になるのか」を記述している。

続きを読む

オブジェクト指向のオブジェクト指向

オブジェクト指向を理解するには、前段階として、「オブジェクト指向分析(Object-oriented analysis)」で言及すべき「概念水準の観点(conceptual perspectives)」、「オブジェクト指向設計(Object-oriented design)」で言及すべき「仕様水準の観点(specification perspectives)」、「オブジェクト指向プログラミング(Object-oriented programming)」で言及すべき「実装水準の観点(implementation perspectives)」の差異を理解しなければならない。この差異は、二重の区別によって成り立っている。つまりオブジェクト指向分析とオブジェクト指向設計とオブジェクト指向プログラミングの区別と、概念水準(conceptual level)と仕様水準(specification level)と実装水準(implementation level)の区別だ。オブジェクト指向的なアーキテクチャ設計を担当するソフトウェア・エンジニアやアーキテクトは、言わば仕様水準の詳細設計や実装水準のプログラミングという活動そのものをブラックボックス化して観察しなければならない。我々は、オブジェクト指向を徹底すればするほど、非オブジェクト指向に対してすら寛容にならなければならないのである。もはやアーキテクチャ設計を敢行する我々にとって、例えばアラン・ケイのメッセージに耳を傾けることも、ビヨルネ・ストロヴストルップと共に『オブジェクト指向とは何か?』を論じることも、二次的な問題でしかなくなる。

続きを読む

投資としてのコストマネジメント

人件費の高い国で生活しているアーキテクトやデータサイエンティストにとって、最大の資産は自己自身である。こうした労働者は毎年1000万程度は収入を得る。言わばアーキテクトやデータサイエンティストは、自己自身の労働力を「証券」として指し示すことによって、企業から定期的に給与や報酬という「利払い」を受け取るのである。あらゆる証券と同様に、労働者は自己自身の現在価値を評価することができる。人間は、自らを「金融商品」として観察することができるのである。自己自身を「金融商品」と見立てる労働者にとって、「時は金なり(Time is money!)」は死活問題となる。我々は時間をコスト(cost)として支払うことで、その対価(performance)を得ている。この費用対効果(cost performance)はプロジェクトの様相に左右される。そもそも収益が期待できないサービスの開発であれば、そこに参入している労働者が得られる対価も期待できない。一方、専門技術や専門知識が高いアーキテクトやデータサイエンティストは、契約次第では、少ない時間的なコストの投資からより多くの報酬を得ることもできるであろう。いずれの場合も、「コストマネジメント(cost management)」は重要な問題となる。そのプロジェクトを管理するプロジェクトマネージャーの能力次第では、参入しているメンバーは、自己管理として、自ら支払うコストを管理しなければならない。

続きを読む

参考文献

  • Evans, E. (2004). Domain-driven design: tackling complexity in the heart of software. Addison-Wesley Professional.