- 追加された行はこの色です。
- 削除された行はこの色です。
メディア論的な意味での「アーキテクチャ」と、経営学的な意味での「アーキテクチャ」について、それぞれ解説する。
情報環境、メディア論的な意味での「アーキテクチャ」と、経営学的な意味での「アーキテクチャ」について、それぞれ解説する。
*情報環境としての「アーキテクチャ」 [#cd186db6]
*A.情報環境としての「アーキテクチャ」 [#cd186db6]
濱野智史は、東浩紀、ローレンス・レッシグらの議論を参照しつつ、アーキテクチャという語を「情報環境」の言い換えとして採用している。下記、濱野の文章より引用する（http://wiredvision.jp/blog/hamano/200705/200705231549.html）
濱野智史は、東浩紀、ローレンス・レッシグらの議論を参照しつつ、アーキテクチャという語を「情報環境」の言い換えとして採用している。下記、濱野の議論を要約する。（http://wiredvision.jp/blog/hamano/200705/200705231549.html）
>> 例えば、近年大きな問題となっている、飲酒運転の問題について考えてみましょう。常識的に、飲酒運転は、悲惨な事故を引き起こす「悪い」ことだと考えられています。教習所に入ると、たいていの場合、飲酒運転で人生が真っ暗になってしまった人のドキュメンタリー風ドラマを鑑賞し、この「飲酒運転＝悪」という考えを再確認するものです。レッシグは、こうした規制方法を「規範（慣習）」と呼びます。さらに、飲酒運転には、道路交通法という法律によって罰則が規定されています。しかもこの飲酒運転を行った者は、罰金が○円、免許資格の停止／剥奪を定める点数が○点、という形で「ムチ」が設定されています。この「ムチ」を受けてしまうのは大きな生活上の痛手になってしまうと判断し、人は飲酒運転という行為をしないように努めます。これが「法律」による規制です。
>> しかし、それでも飲酒運転をする者が絶えない。それは由々しき問題である。そう昨今では考える人が増えているように思われます。さらなる厳罰化が検討されていますが、それも果たしてどこまで有効なのかどうか。そこで現在、導入に向けて前向きに検討されているのが、「自動車にアルコールの検知機能を設置し、そもそも飲酒している場合にはエンジンがかからないようにする」という規制方法です。この手法を導入すれば、基本的に飲酒運転による事故は100%防ぐことができます（現実には抜け穴がたくさん開発されるでしょうが……）。この最後の規制方法が、レッシグの論じる「アーキテクチャ」に相当します。「規範」や「法律」という規制方法が有効に働くには、規制される側が、その価値観やルールを事前に「内面化」するプロセスが必要になりますが、「アーキテクチャ」は、規制される側がどんな考えや価値観の持ち主であろうと、技術的に（物理的に）その行為の可能性を封じてしまいます。そして東氏は、こうした「内面化」のプロセスが不要であるという点を、フーコーの「規律訓練型権力」と対比させつつ、アーキテクチャを「環境」と意訳することで、「環境管理型権力」という概念を構築しています
-1)任意の行為の可能性を《物理的》に封じてしまうため、ルールや価値観の内面化のプロセスが必要ない。
--アーキテクチャとは、法律のことでも、規範（慣習）のことではなく、行為そのものを原理的に制限してしまうような仕組みのことである。たとえば、「自動車にアルコールの検知機能を設置し、そもそも飲酒している場合にはエンジンがかからないようにする」という規制方法などがそれにあたる。「アーキテクチャ」は、どんな考えや価値観の持ち主であろうと、技術的・物理的にそこに従わせてしまうことが可能なものである。（東浩紀は、価値観の「内面化」プロセスを必要としないという点を、フーコーの「規律訓練型権力」と対比させ、「環境管理型権力」という概念を提示する。白田秀彰は、アーキテクチャによる法の実行を、一般的な法の実行形態と区別し、「法の完全実行」と呼んでいる。）
-2)さらにその規制（者）の存在自体を気づかせることなく、被規制者が《無意識》のうちに規制を働きかけることが可能
--このような「アーキテクチャ」を基盤にした権力装置の下においては、行為をコントロールされている側が、行為をコントロールしているものの存在自体に気づくことが難しくなる。たとえば、「マクドナルド化」（マクドナルドにおける客に対する工学的管理方法）と名指されている事態などは極めて気づくことが難しい。あるいは、DRM（電子著作権管理）技術や、CCCD、コピーワンスなどもこの例として挙げられる。
以上、アーキテクチャとは、人間によって作り替えてしまうことが可能な、行為の環境である。アーキテクチャ＝インターネットやVRの世界は、この数十年の間に急速に拡大を迎えてきている。「アーキテクチャ」の操作による、人間の行為・意識の変容といった事態は急速に深刻な事態として現れてきた。論争となっている際たる事例は、著作権論争にだが、アーキテクチャの構築／操作をめぐる最も先端をゆく世界の一つは間違いなくコンピュータ・ゲームの世界だろう。
同じく、濱野による「アーキテクチャ」という観点からゲームについて論じたものとしては、下記二点がある。
-濱野智史,2007,「第17回 「マリオカート」と「ニコニコ動画」の共通点」(『濱野智史の「情報環境研究ノート」』)
--http://wiredvision.jp/blog/hamano/200709/200709191451.html
-濱野智史,2008,「Googleを攻略せよ ―情報環境≒ゲームを通じた「学び」の可能性」(『未来心理』vol.12 モバイル社会研究所発行)
--http://www.moba-ken.jp/wp-content/pdf/vol.12_hamanosatoshi.pdf
*経営学的な意味での「アーキテクチャ」 [#mf1662fa]
手前味噌ながら、下記も同様の問題意識に基づくものである。
関連→モジュール化
-井上明人,2006,「第17回: オンラインゲームの現在 ―拒否されるゲームジャーナリズム―」『情報通信ジャーナル』所収
--http://www.glocom.ac.jp/column/2006/07/17.html
--(上記原稿の、没バージョン：http://www.critiqueofgames.net/senoue/2006/04/post_1.html ※瀬上梓名義)
*B.経営学的な意味での「アーキテクチャ」 [#mf1662fa]
藤本隆宏は、日本の自動車産業の競争力について論じる文脈の中で、「アーキテクチャ」の概念を「どのようにして製品を構成部品や工程に分割し、そこに製品機能を配分し、それによって必要となる部品間・工程間のインターフェイス（情報やエネルギーを交換する「継ぎ手」の部分）をいかに設計・調整するか」と位置づけ、i．モジュラー型（組み合わせ型）／インテグラル型（摺り合わせ型） ii.オープン（開）型 ／クローズ（閉）型のという類型を提示している。
-モジュラー型とインテグラル型（機能と部品の関係性、部品間の相互依存度についての分類）
--モジュラー型アーキテクチャとは、機能と構造（部品）の対応関係が一対一となっており、部品関係の相互依存性が低い設計物を指す。代表的なものとしては、IBM/360などが挙げられる（→関連：モジュール化）。一方で、インテグラル型アーキテクチャとは、機能と構造（部品）の関係が錯綜しており、特定の部品が特定の機能と一対一対応になっていないようなもののことである。代表的なものとしては、自動車が挙げられる。
-オープン型と、クローズ型（インターフェイス公開度合いについての分類）
--オープン型アーキテクチャとは、部品間を連結するインターフェイスについての規格が、個別の企業を超えて共有され、業界標準となっているようなものである。基本的にモジュラー型であり、代表的な事例としてインターネットのTCP/IPや、パッケージソフトとハードウェアの関係性などが挙げられる。一方で、クローズ型アーキテクチャとは、インターフェイスについての情報が、一つの社内で囲い込まれているような場合のことを指す。
上記の二分類×２のセットから、藤本は表１のようなマトリクスを作り、三つの類型がありうることを指摘する。
CENTER:表1：設計情報のアーキテクチャ特性による製品類型
||インテグラル ←|→モジュラー|
|クローズ&BR;（囲い込み）&BR;↑|クローズ・インテグラル|クローズ・モジュラー|
|↓&BR;オープン&BR;（業界標準）|-|オープン・モジュラー|
ゲーム産業においてこの三類型を当てはめると、おそらく以下のようになるだろう。
-1.クローズ・インテグラル
--一つの社内で、特定のゲームエンジン(ミドルウェア≒インターフェイス)を共有せずに、開発を行っていくようなソフトウェア開発スタイル。中・小人数によるアジャイル型開発のような場合には、その柔軟性の強さから強力に機能する場合があると考えられる。
-2.クローズ・モジュラー
--一つの社内で、ゲームエンジン(ミドルウェア≒インターフェイス)を共有しながらのソフトウェア開発。例えば、カプコンやEAなどが挙げられる。自社でゲームエンジンを開発する体力のあるような大手の開発会社での、大人数での開発には適したスタイルだと考えられる。
-3.オープン・モジュラー
--ゲーム業界全体で、ゲームエンジン(ミドルウェア≒インターフェイス)を共有しながらのゲーム開発。例えば、Unreal Engine3や、Doom Engineなどミドルウェア産業が強力に機能している北米のゲーム業界の状態は、この状況に近い（ただし、きわめて高価なミドルウェアであるためミドルウェアを「共有している」という状況とは違うだろう）。自社でゲームエンジンを開発する体力のない、中小のゲーム・デベロッパーが開発を行う際の業態としては適した状況だと考えられる。
--日本国内では、nScriptや、吉里吉里といったミドルウェアを公開ミドルウェアをベースに中・小規模開発を行っている美少女ゲームのノベルゲーム界隈などは、ほぼ完全な、オープン・モジュラー型であると言える。
--または、ゲームハード／ゲームソフトの分離、インターフェイス公開の状況も準オープン・モジュラー方式と言うべきだろう。とりわけ、プログラム仕様を公開してサードパーティによるゲームソフトの開発・販売を可能としていた、Atari VCS(Atari 2600)などは、ほぼ完全なオープン・モジュラー方式である。一方、任天堂やソニーなどハードメーカーによるソフトウェア販売の「許諾」を必要とするような方式は、準オープン・モジュラー方式と言うべきだろう。
----
参考
-濱野智史,2007,『濱野智史の「情報環境研究ノート」』「第1回 情報環境研究をはじめるにあたって」http://wiredvision.jp/blog/hamano/200705/200705231549.html
--東浩紀,2002-2005『情報自由論』http://www.hajou.org/infoliberalism/index.html
--ローレンス・レッシグ『CODE』（翔泳社、2001年）
-藤本隆宏,2003『能力構築競争 日本の自動車産業はなぜ強いのか』 中公新書
----
-記事[[:井上明人]]
-カテゴリ[[:概念]][[:開発]][[:産業]]
