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

スポンサーリンク

派生問題:全体最適化は如何にして可能になるのか

アレグザンダーの「パターン・ランゲージ」に由来する「デザイン・パターン」や「アーキテクチャ・パターン」をはじめとした様々な「共通言語」は、日、様々な「専門家」や「識者」などによって語られ続けられたことによって、<共通言語化>の<非共通化>というパラドックスが派生した。元来、建築において、アレグザンダーの「セミラティス構造」や「無名の質」を追求する姿勢は、<人為>と<自然>の区別を導入していたことで、パラドックス化を余儀無くされていた。そしてこのことは、様々なパターン、イディオム、スタイルなどのようなそれ自体が共通ではない「共通言語」が醸し出す不自然さが現代でも物語っている。

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

一方、初めから人工物設計に注力していたハーバート・サイモンの人工科学・経営学は、「満足化の原理」、「限定合理性」、そして「不確実性の吸収」などといった理論武装によって、現状をより好ましい状況に変えようとする営みを「設計」概念として一般化することで、逆に設計の方向付けを提示できる者が専門家や識者に限定されることを回避できる発想を提供していた。

とはいえ、サイモンの経営学から観れば、「パターン・ランゲージ」や「デザイン・パターン」などのような「共通言語」は、実はマッチポンプとして社会的に受容され続けていることが判明する。様々な「共通言語」が過剰に存在している状態が「共通言語」の意思決定を必要とし、様々な「共通言語」の意思決定が「共通言語」の過剰性を助長するという意味で、これらの「共通言語」は、解決不可能なパラドックスとして結実することにより、<反事実的>に、「規範」であるかのように、社会的に受容され続けることを可能にしている。

共通言語」それ自体の共通性が瓦解した状況は、アーキテクチャ組織システムの「全体最適化(total optimization)」を追求してきた者たちにとってはスキャンダルだ。全体最適化が成功すれば、あるいは「共通化」された開発プロジェクトが実現するかもしれない。しかし、アーキテクトたちをはじめとした専門家による全体最適化という構想は、パラドックスを招いてしまう。

アーキテクトが設計するシーンを思い浮かべてみよう。例えばある企業に属するアーキテクトが他社のAPIとのマッシュアップを前提としたシステム設計するというのは、GoogleやAmazonのようなプラットフォーマーたちのクラウドサービスがデファクトスタンダードになっている日としては、想定し易いシーンだ。一人のアーキテクトに設計できることには限りがある。人的なリソースとしての限界や注意力の限界は、どのような設計でも付き纏う問題だ。だがこうしたクラウドサービスを利用すれば、既成のプラットフォーム上に予め配置されたコンポーネントを援用することで、少ないコストで品質の高いシステム実装することが可能になる。

他社のAPIを前提とした設計に着手するアーキテクトにとって、連携する他社のAPIがアーキテクトの設計対象となるのか、対象外となるのかは、明確に区別できない。仮にAPIを設計対象に位置付けて、そのAPIの内部まで含めて俯瞰できたとしても、そのAPI自体がまた別のAPIを呼び出しているとすれば、システムの「全体」を遡及するというのは無理な話になる。いわゆる「システムシステム(System of Systems)」というのは、はっきり言えば複数形で、それは「ブラックボックス(Black Box)」の複合体なのだ。この意味では、アーキテクトがシステムの「全体」を観察することや、まして「全体最適化」を達成することは、不可能だと言える。だとすれば、アーキテクトは「全体」の設計を断念するしかない。

問題解決策:規制要因としてのアーキテクチャ

アーキテクチャの「全体」の設計を断念しなければならないという認識が社会的に普及した時、その埋め合わせとして要請されるのは、法である。法システムは、社会システム免疫機能として、アーキテクチャ設計の派生問題として生じ得る闘争矛盾を先取りして主題化する。それにより、法的問題領域の解決策として、法的なコミュニケーション展開しようとする。このことは、憲法学者ローレンス・レッシグが記述した「アーキテクチャ(Architecture)」の理論が社会科学の領域で広く受け入れられていることからも、よくわかることであろう。

レッシグはまず、2000年前半の時点で既に、インターネットの反権力的な機能を早々と否定していた。歴史的には、まだSNSのようなサービスが賑わっていなかったころになる。丁度ヒッピー文化を継承した1970年代のフェルゼンシュタインやウォズニャック、そしてネルソンらを筆頭としたハードウェア/ソフトウェア・ハッカーたちの対抗文化が凋落して決着が付いた直後に挙げられたために、テクノロジー主体の反権力的な運動の効力の低下を指摘する主張は、ある程度説得力が帯びていた。

インターネット象徴される分散型ネットワークはもはや、中央集権的な統制に対して自由を可能にしている訳ではない。この観点から出発したレッシグは、情報社会における統治権力的な支配の様相をリベラリズムの視点から論じることになる。

メタ規制要因としての法

レッシグによれば、アーキテクチャとは、人間の行動や社会的な秩序を規制する機構を意味する。レッシグは様々な規制要因と比較することで、このアーキテクチャの概念を特徴付けた。レッシグによれば、アーキテクチャは、規範(Norm)、法律(Law)、市場(Market)と相互に影響し合いながら機能する。これらは、教育による規範の内面化、厳罰化による統制、価格操作による選好の方向付けによって社会的な秩序を機構化する。その中でも法は、規範、市場、そしてアーキテクチャを規制する「メタ規制要因(meta-regulator)」として機能している。

確かに法は、社会の全体を規制している訳ではない。法の影響が及ばない領域では、主に法以前に存在していた規範が、規制要因として機能する。規範は、例えばマナーや慣習、私的なルールとして個人の選択に影響を与えている。その一方で市場は、価格を巧みに設定することによって、消費者たちの「流動的選好」を方向付けていく。この意味で市場も、個々人の行動の選択肢を予め規制している。

アーキテクチャは、これらの規制要因と同様に、やはり人間の行動を規制する。ただしその方法は若干異なる。アーキテクチャは、基本的に物理的な環境や技術的な環境を構築することによって、人々の行動を方向付けていく。だがそうした環境は、人間にとって「自然」であるために、あまり意識されない。それは自明な環境として潜在化している。例えば特定の規範で行動を規制するのであれば、その規範が含意している道徳や価値を内面化させる必要がある。市場で行動を規制する場合は、市場のルールを教育しなければならない。しかしその一方でアーキテクチャによる規制は、こうした内面化や教育を必要としない。アーキテクチャはあくまで人間の行動を無意識のうちに規制する。

ここでいう規制というのは、制約条件を設けているというよりは、むしろ方向付けを与えていると捉えられる。例えば閾下知覚を用いたアドテクノロジーもまた、レッシグ的なアーキテクチャの一種として位置付けられるだろう。アーキテクチャの具体例は、我々の身の回りに遍在している。例えば立ち入り禁止区域を設けるのであれば、立ち入りを禁じるマナーやルールを設定して、それを守るように内面化させるよりは、乗り越えることのできない壁を設置した方が効率的であろう。高い壁は、その境界を侵犯させないための環境を構築する。それが人々の自明な規制要因となる訳だ。

法律への着目

こうしたアーキテクチャによる規制要因を前にしても、レッシグの着眼はメタ規制要因である法律に向けられている。アーキテクチャによる規制を法律で規制することにこそ、レッシグの目論見があると言っても良い。もとより法律は、他の規制要因を超越した存在であるというよりは、むしろ他の規制要因と相互に影響し合う関係にある。アーキテクチャも例外なく、その設計次第では、法律を方向付けるだろう。しかしながらレッシグは、あくまで法律による規制の重要性を論じる。その姿勢は、言わばハッカーたちの無政府主義とは逆行する論調を生み出している。

ハッカーたちが制作したパーソナル・コンピュータやLinux、WWWのようなテクノロジーは、中央集権的な統治権力を無力化する潜在能力を持つと期待されていた。しかしレッシグは、この自由度を最初から否定する。自由度を否定している訳だが、しかしレッシグは自由をむしろ讃えている。レッシグが追究したのはその自由が如何にして可能になるのかだ。

アーキテクチャコンピュータに固有の特徴ではない。だからこそそれは容易に覆されてしまった。アーキテクチャの「コード(code)」を変えれば、言論の自由や表現の自由を可能にしてきた匿名機能を無効化することも可能になる。プライバシーを保証してきた個人情報の保護機能を無効化することもできるようになってしまう。

それ故、企業や政府をはじめとした専門組織は、コンピュータを一般市民には扱い難い専門技術として活用することになった。企業はユーザーの個人情報を追跡し易くなるようにコードを組み替えた。そして政府は、情報がむしろ中央へと集約していくように、アーキテクチャ設計するべく仕向けるようになった。

レッシグがインターネットの脱中心化作用を否定していながらも、インターネット上の自由を擁護する立場を表明しているのは、この関連においてだ。アーキテクチャによって方向付けられた人々は、自由に行動していると錯覚する。だがその行動は、既得権益側には好都合に働くように仕向けられている。アーキテクチャは支配者と被支配者の差異を隠蔽しながら、表面的な自由を描いている。

だからこそレッシグは、アーキテクチャ上での自由を保障するためには、むしろ憲法学的な立場による統治権力の強制的な介入が必要になると主張した。つまり市民側と統治権力側の社会契約とは何かを見直すと共に、自由とは何かを見直すべきだという訳だ。そうした反省の機会を強制的に設けない限り、人々は自由を見つめ直そうとはしない。だからレッシグの自由に対する姿勢は逆説的でもある。とりわけアーキテクチャで市場を独占的に支配する企業に対しては、憲法に基づいた政府による規制を強めなければならないという。特定の専門組織によるアーキテクチャの支配こそを規制すべきだと彼は言う。さもなければ、インターネットの自由は守られない。

アーキテクチャ設計を市場に任せていては、企業によるアーキテクチャルな支配を強めてしまうばかりだ。こうした視点から、レッシグは、そのコード設計段階で政府が介入していかなければならないと説く。そのために重要となるのは、それぞれの専門分野の交流だという。コード設計できるアーキテクトと法律を知る法学者が合意のためのコミュニケーションを繰り返していかなければならない。

自由の制度化というパラドックス

しかしこの自由に対する逆説的な姿勢から提示された主張は、やはりパラドックスを招いている。それは、「自由」という概念を正統性によって「制約」する主張だ。

レッシグの主張を皮肉に読み取るなら、我々がインターネットの自由を実現するためには、まず政府という専門組織に依存しなければならないことになる。だがこの視点は、パーソナル・コンピュータを開発したハードウェア・ハッカーやLinuxの設計に携わったUnixハッカー歴史を等閑視する視点に過ぎない。彼らハッカーに倣うなら、政府に依存することに必然性は無いということになる。むしろ彼らなら、インターネットの自由を可能にするアーキテクチャは如何にして設計し得るのかを問うだろう。

問題解決策:マネジメントとガバナンスの区別

そうなると、「全体」の「統一」へと背伸びするよりも、むしろ個々の「部分」を担うプロジェクトマネジャーやソフトウェア・エンジニアによる自律的な開発に望みを託す方が利巧なのかもしれないという発想に辿り着く。つまり、「マネジメント(Management)」ではなく「ガバナンス(Governance)」を実践するということだ。

こうしたボトムアップ的な発想から生み出されるのは、アーキテクトが「統一」した指針とは別様の指針によって設計された「様々な」システムだ。そこには「差異」がある。つまり、「統一」的な指針と「様々な」指針との「差異」だ。この「差異」を「統一」することは不可能だろう。厳密に言えば、この「差異」があるからこそ、アーキテクトたる設計者たちは「様々な」仕様実装の選択可能性を共有することができている。逆にもし仮にあらゆる開発者が万人普遍の「統一」的な指針によってアーキテクチャ設計してきたとするなら、アーキテクチャ進化可能性は厳しく制約される。例えば自由奔放なハッカー倫理からラディカル・イノベーションが発生する可能性も失ってしまうだろう。

全体最適化は失敗しなければならない/失敗を目的化してはならない

したがって我々は、専門家としてのアーキテクトが全体最適化のための設計を敢行すべきだという前提には、条件付きの部分肯定しかできない。その部分肯定というのは、「全体最適化問題視されなければならない」が、同時に「その解決は失敗しなければならない」ということだ。そしてまた、「全体最適化は失敗しなければならない」のだが、「その失敗を目的化してはならない」ということも、この部分肯定は含意している。

全体最適化の失敗によって「全体」の進化や革新の可能性がむしろ切り拓かれるのならば、アーキテクトは喜んで「部分」の設計者に留まるだろう。この謙虚な姿勢により、アーキテクト個人の人的リソースや注意力の限界は突破され得る。

だが謙虚であることを履き違え、失敗せざるを得ないこの全体最適化の宿命を冷笑的に捉える訳にはいかない。全体最適化を最初から積極的に失敗に終わらせるだけでは、「部分最適化(suboptimization)」ばかりが進むことになる。それでは企業を構成する各部署や従業員のそれぞれが「様々な」指針で最適な手法を採ることになる。歯車が噛み合わなくなることで、逆に生産性が下がる。顧客の要求に応じた安定的なシステムを生産することも困難になる。

「全体」の設計者を自称する「部分」の設計者を自称する「全体」の設計者を自称する……アーキテクト

全体最適化の失敗が逆に「全体」を進化させる可能性を切り拓く一方で、全体最適化の強行が逆に「部分」の選択可能性を制約してしまう危険があるのならば、もはやアーキテクトは自身の「設計」概念そのものをパラドクシカルに定式化し直さざるを得ない。得てして全体最適化を敢行するアーキテクトは、「全体」の設計者を自称する「部分」の設計者を自称する「全体」の設計者を自称する・・・アーキテクトであるしかなく、その「統一的な」指針とはパラドックスによってのみ成り立つ。

パラドックスこそが、全体最適化の全体像に他ならない。

統一性の欠如という状態で統一された状態

このパラドックスを前提とするなら、政治や司法の専門家による統一的な指針によってアーキテクチャ制御するというのは、あまりにも閉塞的な提案だ。その類の提案が限界に直面する運命にあることを確認するには、<差異>と<統一性>を区別し、双方の「差異」を観察するだけで事足りる。

例えば「統一モデリング言語(Unified Modeling Language:UML)」は、クラス図やシーケンス図やアクティビティ図やコミュニケーション図など、それまで個々の設計者が不統一な文法で描写していたモデリング技術を共通の文法によって統一するために企画されたモデル表記法だ。

確かにモデリング技法を熟知した設計者同士であれば、UML設計に統一性を与えてくれる。しかし、UMLを知らないエンジニアが加われば、モデリングの統一性は瞬く間に消滅することになる。

ユースケース図やユースケース記述、アクティビティ図程度であれば、読み手にモデリングリテラシーを要求することはほとんどない。だからある程度の認識の差異は防ぐことができる。しかしその他の詳細クラス図、複合フラグメント付きのシーケンス図、選択疑似状態付きのステートマシン図などといった具合に、より専門性が高いモデルとなれば、伝達の可能性は低く見積もらざるを得ない。ましてそうしたエンジニアにUMLの図示を要求することなどできはしないだろう。

パラドックスとしてのアーキテクチャ

「統一性」というのは、ある一定の集団内部での<部分的な統一性>に過ぎない。一度外部を観察すれば、「集団で統一が図れている」というのは井の中の蛙の錯覚であることがわかる。全体最適化が「統一」によって成されなければならないのだとすれば、それは失敗する。だとすれば我々は、「<統一性>はあり得ない」という前提によって、全体最適化へとアプローチしなければならないのかもしれない。だがこの主張を展開するや否や、それ自体が<統一性>ではないかとの疑念が、直ちに浮上する。クレタ人のパラドックスの如く、この主張が「自己論理的(autologisch)」に適用されると、この主張は自己自身に反論する結果になる。私が正しいのならば、私は間違っており、私が間違っているのならば、私は正しい、という訳だ。

したがって我々は、全体最適化への着眼点を次のように見直すべきだろう。全体最適化は集団全体の<統一性>を目指している。だがそれは、原理原則としての指針によってではなく、パラドックスとしてのみ設計され得る。パラドックスこそが、アーキテクチャの<統一性>となる。

問題再設定:全体最適化のパラドックス

この全体最適化パラドックスは、<全体像の設計>を敢行する立場にあるアーキテクトたちが<設計の全体像>を認識し切れる保証は無いと同時に、仮に<設計の全体像>を追求したところで<全体像の設計>が完成する保証は無いという、一種のアイロニーを前提としている。いわゆる「べき論」好きを苛立たせる論調で、ある意味では醒めている。

全体を設計する者は、その<全体>の内部に自己自身も含まれているということを弁えなければならない。例えばテクノロジーや組織システム全体最適化を唱えるならば、その最適化の指針や規則を自己自身にも適用し、「自己論理的(autologisch)」にならざるを得ない。しかしこう考えるや否や、全体の設計者はパラドックスに陥る。繰り返すように、クレタ人が自らを嘘吐きであると述べているようなものだ。

この全体最適化パラドックスは、解決することは不可能だろうが、解消することならば可能だ。つまり、問題を解決するのではなく、無害化し、不可視化することによって、等価機能主義的に解消することはできる。その方法として、ここでは全体最適化との関連から言及されていた設計されるべき「全体」という概念を<エンジニアリング的全体性>と<ブリコラージュ的全体性>の差異によって「区別」して観よう。

問題解決策:<エンジニアリング的全体性>と<ブリコラージュ的全体性>の区別

この「区別」は、もともとメディア論者シェリー・タークルが、マッキントッシュをはじめとした「パーソナル・コンピュータ」を参照しながら導入した「区別」だ。「ブリコラージュ(Bricolage)」という概念自体は、文化人類学クロード・レヴィ=ストロースから輸入されている。レヴィ=ストロースは<エンジニアリング的全体性>を近代の計画的な設計の対象として位置付ける一方で、<ブリコラージュ的全体性>を前近代的な「ものづくり」の指針として説明している。

タークルの着眼:インターフェイス価値

タークルの論考は、1980年代から2000年代にまで遡る。まだパーソナル・コンピュータハッカーたちがいたころから、「サイバースペース」といった概念が持ち出された頃の話になる。

タークルはコンピュータ人間精神状態の関連性を集中的に論じており、「ユーザー・インターフェイス」が人間の価値観を強く方向付けていることを指摘していた。タークル自らが提唱する「インターフェイス価値(interface value)」という概念によれば、コンピュータのユーザーは「ユーザー・インターフェイス」を介してコンピュータと接触している以上は、もはやハッカーやエンジニアたちとは違って、コンピュータの内部には見向きもしなくなるという。

インターフェイス価値とは、コンピュータのユーザーがそのユーザー・インターフェイスの背後で作動しているプログラムアルゴリズム存在を想定せずに、スクリーンこそが全てであると信じる機能主義的な態度を意味する。

ブリコラージュ

だがハッカーのように、むしろその背後を遡及するような設計者たちは、この態度とは無縁だ。少なからず演出されたスクリーンこそが全てだとは考えないだろう。

タークルによれば、それでもインターフェイス価値を生み出したのは、アップル社のマッキントッシュという極めてハッカー倫理的な思想から産み出された産物であった。アイコンを利用したデスクトップから始まるサイバースペース上では、「世界を弄繰り回すこと」が価値になる。

この関連からタークルは、文化人類学者クロード・レヴィ=ストロースの「ブリコラージュ(Bricolage)」概念を引き合いに出した。彼女がブリコラージュを再評価したのは、インターフェイス価値を形成するには「可視化(visualization)」が重要になってくるからだ。

ユーザー・インターフェイスを利用するユーザーは、既定の規則に束縛される訳ではない。ユーザーは、シミュレートされた「サイバースペース」上で、自由にその世界を弄繰り回すことができる。そうして遊んでいくうちに、その世界との相互行為によって、ユーザーは何が如何にして動作するのかを学ぶ。

レヴィ=ストロースによれば、ブリコラージュは、人類史上普遍的な思考であるという。それは野性的で、自然思考形式を指す。

ブリコラージュとは、もともと限定された持ち合わせの雑多な素材ツールを組み合わせることによって、直近の状況において必要なツールを造ることを意味する。そうしたツールは、「設計図」によって計画的に製造されている訳ではない。大抵の場合それは、以前造ったものの何の役に立つのかわからないと思いつつ残して置いていたものの組み合わせとなる。それは偶然の産物でもある。まして、「目的」を志向して設計されている訳でもない。そうした目的とは無関係に蒐集された事物同士の結合によって、ブリコラージュは成立する。

ブリコラージュの製作者は、そうした諸々の素材の様々な「差異」を参照することによって、本来それらの素材が根差していた個々の目的や用途とは別様の関連から、それらの素材を「再利用」する。それは恰も建築家のクリストファー・アレグザンダーに由来するGoFのデザイン・パターンのようだ。オブジェクト指向的にコンポーネントを「再利用」するということは、設計者がそのコンポーネントを当初の目的とは別様の問題の解決において活用するということを意味している。

近代的なエンジニアリングにおける設計との差異

一方、近代的なエンジニアの設計ブリコラージュ的ではない。タークルも述べているように、それは「計画者(Planners)」のやり方だ。エンジニアは全体的な計画としての設計図に準拠する。彼らがツールの製造に用いる「部品」は、そうした「グランドデザイン(Ground Design)」に即して機能や有用性が一義的に決定付けられてしまっている「部品」だ。

もとよりその決定者となるのは、専門組織であろう。そうした「部品」の価値は専門家によって規定されてしまっている。一方、ブリコラージュの製作者は、そもそもの計画から「区別」されてしまっている。そこに一義的な機能や有用性は無い。それは別のあり方でもあり得る。ブリコラージュの「部品」は、「まだ他の何かに役立つのではないか」という発想によって蒐集された「断片」をその時々の状況に応じて臨機応変に活用される。

ブリコラージュは臨機応変で迅速果断な設計を可能にする。このことはコンピュータと関連付けることでより明瞭になる。

コンピュータメディアにおいてシミュレートされた世界で、ユーザーは、ディスプレイに表示される形象(Image)で構成された様々なツールを利用する。コンピュータはユーザーの操作に即答してくれる。この相互行為の反復が、その世界の学びを可能にしてくれる。そうした相互行為もまた、在り合わせの形象の組み合わせによって成り立っている。

だから、もとよりコンピュータインターフェイス上の相互行為ブリコラージュ的な製作は相性が良い。たとえブリコラージュ的な製作が場当たり的な設計に思えても、タークルはその成り行きを一歩一歩評価していけば良いと考えている。

問題解決策:<プロセス>と<結果>の区別

<エンジニアリング的全体性>と<ブリコラージュ的全体性>の区別を導入することによって、アーキテクトによる全体最適化が陥るパラドックスから如何にして脱却し得るのかを問わなければならない。

ブリコラージュを前提とした場合、近代的な計画者としてのグランドデザイナーは不要になる。むしろこの概念に依拠すれば、近代的な計画者たる「主体」概念を葬り去ることもできるのだから、<全体像のデザイン>においてクレタ人の自己言及のパラドックスに陥る「主体」も気にせずに済むということになる。これによりこのパラドックスは、解決する必要は無くなり、不可視化され、無害化される。このパラドックス問題となるのは<エンジニアリング的全体性>に肩入れした場合だけの話となり、<ブリコラージュ的全体性>を採り入れた場合には「解消」できる問題となる。

しかし、このパラドックスから脱却するための方法として導入された新しい「区別」は、また別のパラドックスを顕在化させるだろう。所詮ある問題を隠蔽すれば、別の派生問題を発見してしまうものだ。

ブリコラージュ概念は野性的で自然思考形式であるとするなら、この概念は<野性的で自然であること>と<近代的で計画的であること>との差異に依拠せざるを得ない。

だがこの「区別」自体は、近代化が発生しなければ獲得できなかった。「文化人類学」も「メディア論」も、「パーソナル・コンピュータ」も「設計」概念も、近代の学問や工学の発展無くして得られるはずが無かった概念だ。近代の限界を近代の「超克」によって解決しようとすれば、それ自体が近代的な営みとして観察されてしまう。同様に、ブリコラージュを作為的に近代的な計画者たちの設計と対比させたところで、それ自体が近代的な計画によって導入されなければ、我々の近代的な職業としてのシステム開発との関連付けが困難になる。

このパラドックスに対して、タークルのメディア論は素朴過ぎる。

このブリコラージュパラドックスに対する脱パラドックス化方法として提案できるのは、至って単純な区別、すなわち<プロセス>と<結果>の区別を導入することだ。

確かに、<ブリコラージュ的全体性>が形成されるまでの<プロセス>を考えるならば、それが近代的な計画としての設計とは無関係ではないという意味で、パラドクシカルな結論に至るだろう。しかし、そこに至る<プロセス>はどうあれ、<結果>として形成されつつある<ブリコラージュ的全体性>が見受けられるのならば、我々はそれを静観するべきだろう。

それは、近代的計画概念に依拠する設計者のトップダウンな全体性秩序ではなく、恐らくはボトムアップ的な秩序形成となる。

複雑系科学の用語を借用するなら、それは「創発」であり、一見してトップダウンな計画とは非連続な「不意打ち」にも思えるだろうが、全体の設計者のパラドックスに対して活路を見出すポテンシャルを秘めているはずだ。

派生問題:アーキテクチャ中心設計の加速的な実践は如何にして可能になるのか

上述した<プロセス>と<結果>の区別を導入した場合の派生問題は、<結果>が得られるまでの間に顕在化する。ここでいう派生問題とは、ボトムアップ的な秩序形成による創発的な進化が実現するまで、「共通言語」の非共通性全体最適化パラドックス脱パラドックス化し続けることは、如何にして可能になるのかという問題だ。

確かに、<結果>が得られるという信頼が形成されているのであれば、この問題が顕在化する可能性は低い。しかし、<結果>が得られるまでの<プロセス>がリスクヘッジの連続であるのなら、コストやデメリットの観察による期待外れは避けられないだろう。趣味のプライベートな開発でもない限り、大抵の開発プロジェクトは投資対効果に準拠している。<結果>が得られる保証が無い場合、アーキテクトは脱パラドックス化の機会すら得られない。

したがってアーキテクトは、「共通言語」の非共通性全体最適化パラドックス脱パラドックス化し続けると共に、尚且つ投資に対する効果を目に見える形で提示しなければならない。言い換えれば、アーキテクチャ中心設計に伴う派生問題は投資対効果の「速度」の問題であると言える。

問題解決策:ラショナル統一プロセスの実践

一つの問題解決策として挙げられるのは、IBMが定式化した「ラショナル統一プロセス(RUP:Rational Unified Process)」だ。このRUPは、ソフトウェアの開発プロセスの一種で、開発組織における各担当者の役割や責務の割り当てを実施する際の体系的な方向性を提示してくれる。RUPは、エンドユーザーの要求に応じた高品質なソフトウェアをスケジュール通りに納品するのは「如何にして可能になるのか」を記述している。

尤もRUPは、「全てこの通りにせよ」といった固定的な開発プロセスを意味する訳ではない。RUPの開発プロセスは、アーキテクチャ・パターンデザイン・パターンのようなパターン・ランゲージ(Pattern language)の如く、一般的で抽象化された方法論になっている。RUPをそのまま社内の開発プロジェクトに適用することも確かに可能だが、通常RUPの応用者たちは社内の状況やプロジェクト固有の事情、あるいはメンバーのスキルや知識の水準に応じて適切に使い分けている。

そのためRUPは、「拡張可能」で「再利用可能」な開発プロセスとして発展してきた。RUPを援用した場合の開発プロジェクトでは、その状況に応じて、RUPによってデフォルトで規定されている成果物の幾つかを削除する場合や、必要であれば追加する場合もある。つまり、RUPは厳格な「手順書」や「マニュアル」を押し付けるものではない。そうではなく、現実の開発プロジェクトに応じて拡張されることを想定した開発プロセスになっている。

RUP漸進的(Incremental)な開発となるユースケース駆動(Usecase-Driven)開発と反復型(Iterative)の開発となるアーキテクチャ中心設計(Architecture-centric design)を中心に構成されている。前者はソフトウェア要求定義を実施する「方向付けフェーズ」に、後者はアーキテクチャ設計を実施する「推敲フェーズ」に、それぞれ対応している。

問題解決策:アーキテクチャ中心設計とユースケース駆動型開発の区別

RUPではソフトウェア要求定義の段階からユースケース図やユースケース記述を利用することでシステム要求を俯瞰する。開発計画や開発プロセスはユースケース単位で実施される。ユースケースは複雑・複合的なシステムの諸要素を有意味機能として纏め上げることを可能にする。システムの諸要素の間には関連や重複も含まれる。しかしそれらはモデルに基づいて追跡可能性を担保できるため、システム全体最適化パラドックスは回避できる。
アーキテクチャ中心設計とは、アーキテクチャインターフェイス仕様設計することを重視した設計思想に他ならない。このことはRUPアーキテクチャ設計で言及すべき「アーキテクチャ(Architecture)」概念を注意深く観察することで判明する。

3つのアーキテクチャ概念

RUPにおける「アーキテクチャ(Architecture)」とは、主にソフトウェア・アーキテクチャを指す。それは重要なコンポーネント間のインターフェイスを介した相互作用の構成意味する。この意味アーキテクチャは、次の三つに区別できる。

第一に、インターフェイスを介して相互作用を実行する「サブシステム」である。このサブシステムには、クラス、コンポーネント、更に再帰的に下位のサブシステムが含まれる。第二に、各サブシステムを結び付ける「関連」だ。この「関連」は、主にクラスの関連、コンポーネント図のアセンブリコネクタ、コミュニケーション図のリンク表現される。そして第三に、各サブシステムを組み立てるための「制約」である。これは専ら非機能要件として観察される。

以上の区別から単純化すれば、アーキテクチャシステム構造意味している。ユースケースが機能に対応しているのに対して、アーキテクチャ構造に対応付けられる。アーキテクチャは、システム構造的な識別を可能にする「区別」の単位となる。ただしアーキテクチャ機能的にも把握される。RUPでは、アーキテクチャの内部よりもむしろ他のインターフェイスとの関連が重視される。アーキテクチャという概念で表わされる構造は決して静的ではない。それは相互作用図によって動的にも把握される。

このアーキテクチャ概念を前提とすれば、アーキテクチャ中心設計は、実はインターフェイス仕様設計を重視した概念であるということがわかる。それはアーキテクチャの内部環境というよりは、インターフェイスで接続され得る外部環境との関連において強調される。アーキテクチャの内部環境オブジェクト指向コンポーネント指向に基づき「ブラックボックス化」されて構わない。

漸進的な開発と反復型の開発の差異

アーキテクチャ中心設計とは、重要なアーキテクチャ・ドライバを可能な限り開発早期に確立させるべく、アーキテクチャを中心にして開発を進めるということを意味する。この設計は、漸進的(Incremental)な開発と反復型(Iterative)の開発の区別を導入することで特徴付けることができる。

ユースケース駆動で開発する場合、そのプロセスは漸進的(Incremental)になる。漸進的な開発は、新機能を積み上げていく方法意味する。この方法は、繰り返しの単位となるユースケースによってはソフトウェア構造が全く異なる場合や、相互依存関連が見受けられない複数のシステム同時開発に向いている。しかし各ユースケースが同様のソフトウェアに依存している場合、抽象化の余地が生まれる。そこでアーキテクチャ設計へと着眼が移る。

アーキテクチャ中心設計を採用した場合、そのプロセスは反復型(Iterative)になる。反復型の開発では、ソフトウェアの全体や部分に関して、最初は最低限のコンポーネントとして開発し、その後徐々に肉付けしていく方法を採る。アーキテクチャ中心設計では、ミッション・クリティカルな部分や複雑高度なソフトウェアについて、徐々に確認しながら肉付けしていき、コンポーネントブラックボックス内部を充実化していくことになる。

RUPの6つのベストプラクティス

RUPではソフトウェア開発における問題設定問題解決を手助けしてくれる6つのベストプラクティスが用意されている。

RUPで開発するアーキテクトやソフトウェア・エンジニアは、これらのベストプラクティスを自分が置かれている状況に応じて組み合わせることによって、その状況に応じた問題解決策を講じることができる。

6つのベストプラクティスは、以下のようなものとなる。

反復してソフトウェアを開発せよ(Develop Software Iteratively)

全てを最初から「定義(define)」することはできない。ウォーターフォール型のように、最初から全ての要件を抽出すべきだという教条は非現実的だ。

一方、反復型の開発ならば、要件定義にせよ設計にせよ、不確実性を考慮した対策を打つことができる。要件定義であれば、初期段階では基本的で重要な要件だけを抽出することに注力し、後々徐々に不確定な要件を抽出していくことができる。設計であれば、初期段階ではコアとなる重要なシステム部分の設計抽象化によって実践し、徐々にそれ以外の周辺的なシステム設計をコアとなるシステム部分に合わせて具体的に設計することができる。

この反復型の開発を採用する場合、小刻みにPDCAを回すことになるため、顧客や営業の要求が変更したとしても、全てを直線的に進めようとするウォーターフォール型に比して、柔軟に対応することができる。

要求を束ねよ(Manage Requirements)

利害関係者が多ければ要求の統一性や一貫性は無くなっていく。内容は不明確で、優先順位も判断し難い。そうした要求を満たすシステムを納品するためには、要求を収集し、文書化し、その変更を設計を見据えて追跡しなければならない。

そこで、ユースケース図やユースケース記述のようなモデリングを利用することで、ユーザーの振る舞いや役割と納品するシステム機能との関連を明確にする。これにより、システムが最終的にどのような機能をユーザーに提供すれば良いのかを判断できるようにする。

コンポーネントベースのアーキテクチャを利用せよ(Use Component-based Architectures)

ソフトウェアを再利用可能なコンポーネントとして部品化しておくことで、それらを組み合わせることで新たな一つのシステムを開発することが可能になる。ソフトウェアをコンポーネント化しておけば、それぞれのソフトウェアの再利用可能性が高まる。そうしたコンポーネントは、それ以後の開発で有用になるばかりか、変更も容易にする。

ソフトウェアを視覚的にモデル化せよ(Visually Model Software)

アーキテクチャコンポーネント構造や振る舞いを把握し易くするために、Unified Modeling Language(UML)により、視覚化されたモデルを用意する。システムを視認可能なモデルで抽象化して表現すれば、システム機能仕様を俯瞰し易くなる。そのモデルの文法や記法に基づけば、開発者たちが共通の理解を得られる。

ソフトウェアの品質を検証せよ(Verify Software Quality)

信頼性、機能性、アプリケーション性能、システム性能などのシステムの品質については、テストによって維持されなければならない。反復型開発では、システム開発の諸々の時期に、その都度品質目標を設定し、それを達成することが求められる。そのためには、頻繁なテストを繰り返すことになる。

ソフトウェアの変更を制御せよ(Control Changes to Software)

ソフトウェアに変更は避けられない。それは様々な時期に様々な理由から発生する。そうした変更を管理し、後から振り返って追跡できるようにしなければならない。さもなければ、いずれ現行システム仕様機能を把握できている開発者がいなくなり、後続する開発のコストやスケジュールに大きな影響を及ぼす。

RUPの動的構造

RUPの開発プロセスは基本的に4つのフェーズに区別されている。各フェーズではそれぞれ成果物とマイルストーンが設定されている。それぞれ簡単に確認しておこう。

  1. 方向付けフェーズ
  2. 推敲フェーズ
  3. 制作フェーズ
  4. 移行フェーズ
企画フェーズとしての方向付けフェーズ

RUPの方向付けフェーズ(Inception Phase)では、文字通り開発プロジェクトを方向付ける。開発プロジェクトの方向付けには必要十分条件がある。RUPではそれを次のように考える。

  • 何が解決されるべき問題なのか。その問題の影響は何なのか。
  • それは誰にとっての問題なのか。どのステークホルダーが問題の影響を被っているのか。
  • その問題を如何にして解決することが可能になるのか。そして如何にして解決するのか。

これらの問題設定と解決策によって、方向付けフェーズではその開発プロジェクトが投資に資するプロジェクトであるか否かを判断する。言い換えれば、投資対効果の合わない開発プロジェクトを早期に断念する時期でもある。そのためには、問題とその解決策を明示して、解決した際のメリットや効果を判断できるようにしていなければならない。

方向付けフェーズの狙い

このフェーズでは、ソフトウェア要求定義を契機として、多くのステークホルダーが関与することになる。しかし最終的には、誰にとっての問題を解決し、誰にとっての問題を解決しないのかを明確に区別する必要がある。全てのステークホルダーを救うことはできない。

これを前提とすれば、このフェーズで洗い出すべきなのは、投資対効果でシステムによる問題解決策を判断するためのユースケースのみで構わない。全てのユースケースを洗い出しても、その全てが投資対効果の判断に有用である訳ではない。この方向付けフェーズでは、言わばプロジェクトの「計画」を組み立てるのではなく、プロジェクトの「企画」を成立させることが狙いになる。

成果物(例)
  • 中核となるプロジェクトの要件、主要機能、主な制約に関する展望を記述したドキュメント。
  • 初期段階のユースケース・モデル(10%から20%は完了させる)。
  • 初期段階のプロジェクトの用語集(問題領域の必要に応じて記述する)。
  • ビジネスの文脈を含めたビジネス状況としての成功基準(収益、市場についての認識など)。
  • 初期のリスク評価。
  • フェーズと反復を示したプロジェクト計画。
  • 必要であればビジネスモデル。
  • 一つまたは幾つかのプロトタイプ。
  • マイルストーン達成の評価基準。
  • マイルストーン達成の評価基準

ここでのマイルストーンは、ライフサイクルの方針(Lifecycle Objectives)という用語に要約される。

  • 利害関係者がスコープ定義とコスト/スケジュールの見積もりに同意している。
  • 要求事項が、初期のユースケースによって忠実に明瞭化されて理解されている。
  • コスト/スケジュールの見積もり、優先順位、リスク、開発プロセスが信頼できる。
  • 開発された幾つかのアーキテクチャのプロトタイプの深掘り加減と射程範囲(Depth and breadth)が適切である。
  • 計画コストと実績コストを比較できている。
  • 問題分析フェーズとしての遂行フェーズ。
  • 問題分析フェーズとしての推敲フェーズ

RUPの推敲フェーズ(Elaboration Phase)では、問題を分析し、アーキテクチャの基盤とすべきアーキテクチャ・ドライバとなる部分を探査し、プロジェクト計画を制作し、プロジェクトの最大級のリスク要因を排除していく。

アーキテクチャ設計によるアーキテクチャに基づいた意思決定により、システムの全体像を俯瞰する。つまり、システムのスコープ、主要な機能要件と非機能要件を理解できるようにする。

更にこのフェーズでは、実行可能なアーキテクチャのプロトタイプを幾つかの反復によって開発する。その反復の度合いは、スコープ、リスク、あるいはそのプロジェクトの特異性によって異なる。

この取り組みを実践するには、開始フェーズまでに最低でも必要不可欠(critical)なユースケースを特定できていなければならない。

推敲フェーズの狙い

推敲フェーズに入り、漸くシステムの視点から分析していくことになる。方向付けフェーズで纏め上げた要求を実現する方法を考える。言い換えれば、設定した問題の解決が「如何にして可能になるのか」を追究する。RUPではこの追究をアーキテクチャを中心に進めていく。つまりこのフェーズの狙いはアーキテクチャ中心設計に他ならない。

成果物(例)

ユースケース・モデル(最低でも80%は完成させる)。全てのユースケースとアクターが特定されており、ほとんどのユースケース図は記述済みになっている。

  • 具体的なユースケースとは必ずしも直結していない非機能要件などのような要件が網羅された定義書。
  • ソフトウェア・アーキテクチャについての説明事項。
  • 実行可能なアーキテクチャのプロトタイプ。
  • リスク一覧とビジネス状況一覧の改訂版。
  • プロジェクト全体に資する開発計画書。これは反復型開発を前提としたスケジューリングになる。
マイルストーン達成の評価基準

ここでのマイルストーンは、ライフサイクルのアーキテクチャ(Lifecycle Architecture)という用語に要約される。

  • 製品の展望(vision)は安定しているか(stable)。
  • アーキテクチャはぐら付いていないか(stable)。
  • 実行可能なデモンストレーションによって、主要なリスクが対処され、解消されたことがわかるか。
  • 後の制作フェーズ(Construction Phase)に向けた計画は十分な精度で詳細化されているか。
  • 現在の開発計画は、現在利用しようとしているアーキテクチャを利用することで完成する。利害関係者は皆この現在の展望(vision)がに合意しているか。
  • 現在の計画コストと実績コストの投資対効果は許容範囲内にあるか。
「ベータ版」開発フェーズとしての制作フェーズ

RUPの制作フェーズ(Construction Phase)では、主に推敲フェーズで開発したコアとなる部分のアーキテクチャ以外の、周辺となるシステムを開発していく。「ベータ版」をリリースできる大勢に持っていくことが望ましい。

制作フェーズの狙い

制作フェーズの狙いは実装だけではない。変更要求を如何にして対処するのかも論点となる。

とりわけ新規事業などのような市場の不確実性と相対している場合、変更要求は避けられない。変更要求を当該反復のサイクル中に実施してしまうか、あるいは次の反復のサイクルに回すかを判断する必要がある。推敲フェーズが終わったからと言って、仕様変更が生じないとは限らない。

変更要求を当該反復サイクルで実施してしまうか、次の反復のサイクルに回してしまうかの判断基準となる観点として、次のような点を挙げられる。

  • その変更要求から設定し得る新たな問題は、方向付けフェーズで設定していた問題と関連しているか。
  • その変更要求から設定し得る新たな問題は、推敲フェーズで記述したシステム的な問題解決策によって解決可能であるか。
  • その変更要求を当該反復サイクルで実施した場合、所要工数は予算以内に収まるか。
  • その変更要求を当該反復サイクルで実施する程、優先順位を変えてまで早期解決を求める理由はあるか。
成果物(例)
  • 適切なプラットフォーム上で統合されたソフトウェア製品。
  • ユーザー・マニュアル(ユーザー向けの仕様書)。
  • 現在のフェーズに関する記録(ディレクトリ/ファイル一覧やPHP DocやJava DOCなどのようなレファレンス)。
マイルストーン達成の評価基準

ここでのマイルストーンは、初期運用能力(Initial Operational Capability)という用語に要約される。

  • 安定した製品をリリースできているか。
  • 利害関係者は皆ユーザーになるための準備をし始めているか。
  • 計画コストと実績コストの投資対効果はまだ許容範囲内にあるか。
過渡期としての移行フェーズ

RUPの移行フェーズ(Transition Phase)では、製品をユーザーに届けることが目的になる。

これは常に起こり得ることだが、一度製品をリリースすれば、ユーザーからの新たな要求を呼び起こし、新たな製品を開発することになる。新たな問題が発覚することも常にあり得る。Transitionは「移行」であると共に、「過渡期」でもある。

移行フェーズの狙い

UIやAPIを実装しても、それが「使えないブラックボックス」であっては意味が無い。実装した成果物が「使えるブラックボックス」になるように、必要に応じて操作マニュアルやAPI仕様書などを作成していく。

実施内容
  • システムが如何にユーザーの期待に反しているのかを検証する「ベータテスト」。
  • バージョンアップされる前の、改修前の旧システムとの並行運用。
  • 運用されているデータベースの切り替え。
  • ユーザーとメンテナンス・エンジニアの訓練。
  • 製品の市場、流通、セールス・チームへの共有。
マイルストーン達成の評価基準

ここでのマイルストーンは、製品のリリース(Product Release)となる。

  • ユーザーは満足しているか。
  • 計画コストと実績コストの投資対効果はまだ許容範囲内にあるか。

RUPの静的構造

RUPによって開発プロセスの構成要素を静的に整理する場合、次のような概念で開発プロセスを表現することができる。つまり開発プロセスとは、誰が(who)、いつからいつまでに(when)、何を(what)、そして如何にして(how)に行うかを表す概念に他ならない。RUPでは以下の対応付けでプロセスを表現する。

  • 誰が:ワーカー(Worker)
  • いつからいつまでに:ワークフロー(Workflows)
  • 何を:成果物(Artifacts)
  • 如何にして:アクティビティ(Activities)

開発プロセスを明確化するということは、これらの要素を明確化することを意味する。アクティビティ以外はプロジェクト計画や要件定義の時点で明らかになっていることが望ましい。

尚、ワークフローという概念については、下記の通り細分化される。

システム開発の核となるワークフロー
  • ビジネス・モデリング(Business modeling)
  • 要求と要件の定義(Requirements)
  • 分析と設計(Analysis & Design)
  • 実装(Implementation)
  • テスト(Test)
  • 移行(Deployment)
システム開発を支援するワークフロー
  • プロジェクト管理(Project Management)
  • 構成管理と変更管理(Configuration and Change Management)
  • 環境(Environment)

問題解決策:パラドックス駆動型開発

以上のようなRUPの詳細を前提とすれば、アーキテクチャ中心設計の加速的な実践は方向付けフェーズ、推敲フェーズ、制作フェーズ、移行フェーズというサイクルの高速回転によって可能になる。このサイクルは再帰的に循環する形式だ。つまり、方向付けフェーズの中にこの4つのフェーズが再帰的に立ち現れるように、フェーズの区別がフェーズの区別の内部へと再導入(re-entry)されている。

重要なのは、このサイクルを1回転させる度に、ベータ版的な成果物が出来上がるということだ。これが、上述した<プロセス>に対する<結果>であると言える。もとよりこの<結果>は制作フェーズのベータ版を移行フェーズという文字通り過渡期に提供できる<結果>に過ぎない。故に、<結果>として提示した問題解決策(Solution)に対する派生問題は避けられない。<プロセス>と<結果>の区別を導入することで顕在化したパラドックスは、確かにベータ版的な過渡期の成果物がデプロイされることによって、一時的に潜在化されるだろう。だがこのパラドックス問題として解決された訳ではなく、無害化され、不可視化され、解消されたに過ぎない。いずれ、隠蔽したパラドックスは回帰することになる。

しかし、RUPの開発プロセスは、こうした再パラドックス化に対して再度4つのフェーズの区別アーキテクチャ中心設計ユースケース駆動型開発の区別、6つのベストプラクティスの区別、あるいは静的構造と動的構造区別など、プログラムのライブラリの如く様々な区別を導入することで、パラドックス化した問題脱パラドックス化し続けることができる。この意味RUPのような反復型の開発プロセスとパラドックスの関係は相互に駆動し合う関係となる。つまり、パラドックスRUPの必要性を助長させる一方で、RUPの実践からまた更なるパラドックスが呼び起こされる訳だ。

我々はこの文脈においてまたしてもマッチポンプ的なパラドックスに遭遇してしまった。RUPのような反復型の開発プロセスは、パラドックスを派生させてはまた脱パラドックス化するという絶え間無い循環の中に根を下ろす。この循環は、反復型の開発プロセスによって招かれた「」循環であるのかもしれない。だがそれは反復型の開発プロセスを継続する上での必要「」なのである。

スポンサーリンク