dotkuwaの日記： エージェントの「創造性」

経済学では、
プリンシパル＝エージェント関係（－かんけい、principal-agent relationship）とは、
行為主体Aが、自らの利益のための労務の実施を、他の行為主体Bに委任すること。このとき、
行為主体Aをプリンシパル（principal、依頼人、本人）、
行為主体Bをエージェント（agent、代理人）と呼ぶ。
中略
プリンシパル＝エージェント関係において、エージェントが誠実に職務を遂行しているか否かを
逐一監視するには、プリンシパルは多大な労力を払わねばならない
（ウィキペディア日本語版 プリンシパル＝エージェント理論 より）
ですが、
システム開発の世界では、
・設計者が行為主体Aで、（言われたままにやる）プログラマーが行為主体Cで、
・その仲立ちをする人間が行為主体Bと
なりますが、大抵は、
・エージェントが誠実に職務を遂行している事を当てにしてよい。
　（エージェントが誠実で無い様に故意に行動しても、儲けにならない）
という美風が有ります。技術関係の褒められる点です。
　
けれども、
・エージェントは、委任された範囲内で「創造性」を発揮する。
・その「創造性」とは、自分の思いつきで自分にとって素晴らしい状況になる様な
　指示
で、
・往々にして、システム開発全体をとん挫させる元となる
というのも事実です。
　
行為主体Bには行為主体Aやそのバックから、一定の権限を付与されていて、
その範囲での決め事は、最大限尊重しなければならないが、その「創造性」が
開発を破綻に陥れる事が多いからです。なぜなら、
・その「創造性」とは、自分の思いつきで自分にとって素晴らしい状況になる様な
　指示
だからです。
　
経済学では、利益を抜く事がエージェンシー問題なのに対し、システム開発では、
「価値を創造してしまう」事がエージェンシー問題です。
それもこれもシステム開発には第一原理が無く、行為主体Aの思惑と違う「正しい」
考え方が無数に有り、その内1つを自分が自由に選ぶ事で、行為主体Bが満足を
得る代わりに、システムがとん挫するという理屈です。
　
そういうことは行為主体Aになってからすべきです。

むしろ主体Cが

[Anonymous Coward]

主体Bの委任されている範囲って結構狭くないですか？
設計までAだとミドルウェアや言語の選定ぐらいしかできないような。
あるいは依頼とは関係ない、開発環境(大きな意味での)とか。

主体Cだと例えば、勉強を兼ねて最新の方法論に基づいて記述してみて誰も読めなくなるとか、
あるいは逆に古い方法論のせいでシステム全体に影響出まくりとか。