ソフトウェアシステムについてルーマンの社会システム理論を使って考えてみた

ソフトウェアシステムと社会システムには密接な関係があって、そこでのソフトウェア開発システム(つまり開発者のエコシステム)の責任は重い。そういう分析の道具としてニクラス・ルーマンの社会システム理論が使えそう。

先にお断りしておきますけれど、誰得な文章ですw

ソフトウェア開発と、ルーマンの社会システム理論の片方または両方を知っている人じゃないと、何を言ってるか分からない内容かもしれません。いや、それ以前にぼくがナンセンスなことを言っている可能性もありますが(汗

では始めましょう。

最近この二冊をバイブルとして読みつつ、久しぶりに本格的なプログラミングを再開しようかと思ってます:

こういうソフトウェア開発方法論の本を読みながら思ったことを書きます。

これらのソフトウェア開発方法論に通底しているシステム観は、ルーマンの社会システム理論を連想させます。

  • システムの本質はコミュニケーションの連鎖のほうであって、オブジェクトではない。
  • システムにとってオブジェクトは環境。

といったシステム観です。

オブジェクト指向システムを、ルーマンのフレームワークで捉えるなら、まずは「バイナリー・コード」と「成果メディア」に注目してみます。

ソフトウェアシステムの成果メディアは「有用性」で、バイナリー・コードは入力の「妥当/非妥当」かな、と。

ルーマン社会システム論の「成果メディア」って「結局○○だよね」に当てはまるものですね。政治システムの権力、学問システムの真理、親密関係システムの愛、経済システムの貨幣(金)とかw

ソフトウェアって結局有用性ですよね?

バイナリー・コードは、機能システムが環境から何かを取り込む基準です。ソフトウェアシステムが環境(外部)から内部に取り込むものって妥当(valid)な入力だけですよね?

ソフトウェアシステムは社会システムの機能システム(部分システム)。したがって外部の「環境」である社会システムを参照できます。

オブジェクトは実世界に対応物を持ち、ソフトウェアシステムは世界の複雑性を縮減します。抽象化によって。

ソフトウェアシステムはソフトウェア開発システムと「相互浸透」しています。ソフトウェアシステムの複雑性を縮減するためにソフトウェア開発システムの複雑性が提供されますし、その逆もしかり。

その過程でシステム分化が起こり、サブシステムが生じることがあります。成功したソフトウェアシステムは、そうして肥大化や複雑化を避けますよね。

いわゆるモジュラリティ(「部品性」とでも訳すのかな)が高く、高凝集・粗結合なシステムアーキテクチャは、有用性を保ち続けることができます。

一方、肥大化して使いにくくなったソフトウェアは有用性を失います。アーキテクチャ上の失敗でそうなったりしますね。

ソフトウェアシステムとソフトウェア開発システムは相互浸透しています。また、ソフトウェアシステムと社会システムも相互浸透しています。(図解しないと分かりにくい?)

ソフトウェア開発システム(つまり開発組織)は間接的に社会システムのあり方に影響を与えています。しかし、ソフトウェア開発システムのあり方は、社会システムに規定されています。

ソフトウェアシステム、ソフトウェア開発システム、社会システムの相互浸透。この視座でレッシグの『CODE 2.0』の議論を考えると、彼の議論のなかでソフトウェア開発システム、つまり開発者のエコシステムについての分析が少ないことに気づきます。むー。

ソフトウェア開発システム、つまり開発者のエコシステムについての、とくにオープンソースに力点を置いた評論としては、エリックレイモンドの『伽藍とバザール』三部作が白眉です。第2部『ノウアスフィアの開墾』にジョン・ロックの所有権に関する議論が登場することはあまり知られてないかも。

この論文の題名に出てくる「ノウアスフィア(noosphere)」というのはアイデア(観念)の領域であり、あらゆる可能な思考の空間だ。ハッカーの所有権慣習に暗黙に含まれているのは、ノウアスフィアの部分集合の一つであるすべてのプログラムを包含する空間での、所有権に関するロック理論なんだ。だからこの論文は「ノウアスフィアの開墾」と名付けた。新しいオープンソース・プロジェクトの創始者がみんなやっているのがそれだからだ。

こういう相互浸透状態について考えるうえで、比較制度分析という道具は役立つかもしれません。ぼくは『コーポレーションの進化多様性』という本で、その鮮やかなワザに感銘を受けました。

多様性が高まりつつある世界において、ルール形成ゲームは、さまざまな次元、相互連関性を持つさまざまなドメインでプレイされなければならない。ルール形成のための単一の集権的メカニズムは、存在しえないからである。さまざまな実験、提案、デザインが私的慣行、公的論議をつうじて提案され、検証され、吟味され、選択されていく。

ぶったぎり

と、ここまで考えてみたものの......

ソフトウェアシステムと社会システムに関する議論なんて誰も興味なさそうだな......

とはいえ、アーキテクトとしては「開発行為の社会的責任」について考えることの責任感を感じるので、こういうことを考えるのは大事だと思ってます。

現代の社会システムにとってソフトウェアシステムの影響は無視できないほど大きいので、IT アーキテクトや情報アーキテクトを名乗る人が職業倫理として考えるべき問題なんじゃないかなーと。どうでしょう?

ぼくらが作るソフトウェアが、社会システムのありように大きな影響を与えてしまってるわけで。

ぼくは今後、ソフトウェアシステムと社会システムの関係について、ルーマンの社会システム理論という道具が使えそうな気がしてます。何か気づいたら、またシェアするつもりです。

追記:カフェ利用のルールづくりと自治と民度 - Memorandum by zerobase(2013年2月23日)

蛇足

『実践テスト駆動開発 テストに導かれてオブジェクト指向ソフトウェアを育てる』の著者らの「受け入れテスト」や「振る舞い駆動開発」 (BDD: Behavior-driven development) の思想は、心理学・哲学の BehaviorismCognitive Revolution に近い気もしました。

蛇足2

この議論の延長に、アレグザンダーのパターン・ランゲージと接点が見つかるだろうと予感してます。井庭崇先生の『ハイエク、ルーマン、アレグザンダーをつなぐ』のような視座で。

例えば、ソフトウェアシステムのアーキテクチャが市民・国民に与える影響について、市民・国民(ユーザー)がワークショップに参加して、パターン・ランゲージを通じたコミュニケーション(=ソフトウェア開発システム)によってアーキテクチャがデザインされていくとか。

『実践テスト駆動開発 テストに導かれてオブジェクト指向ソフトウェアを育てる』のシステム観って進化論的で分権的なところがハイエクを連想させますしね。

ハイエク、ルーマン、アレグザンダーの共通の関心事は「秩序」で、「ありえそうもない、驚くべき社会秩序が、なぜ可能なのか?」の原理を探究したわけですよね。

そう考えると『実践テスト駆動開発 テストに導かれてオブジェクト指向ソフトウェアを育てる』の著者らをはじめとするソフトウェア開発コミュニティの人々も、「どうすれば、バグの無い、環境に適応して成長・進化し続けるソフトウェアが可能なのか?」という「ありえそうもない秩序」の探究者なんですよ。

最初に巨大な設計をすること "Big Design Up Front (BDUF)" への(アジャイルコミュニティからの)批判って、ハイエクの設計主義批判と重なりますしね。

蛇足3

ゼロベースの管理会計システムを開発するよ』というブログを始めました。

参考文献

トラックバック(0)

トラックバックURL: http://zerobase.jp/mt/mt-tb.cgi/1172