変幻する実行可能知識 15システム I - 要素還元主義でもなく有機的全体主義でもなく我々は日常的にたやすくシステムという言葉を使ってしまうけれど, システムって何だ? システムズ・エンジニアって誰だ? 「最近システムがよく落ちるんで困るっすよ」ってどーゆーことだ? システムとは相互作用する複数の要素の集合. だから太陽系もシステムだし, 会社もシステムだし, 計算機もシステムだ. 仏教的にはあらゆるモノは他のモノとの相互作用においてのみ存在するわけだから, あらゆるモノはシステムということになる. とは言っても, 例えば地球, 月, 太陽というたった三つのモノの (古典) 力学的相互作用にさえ, 厳密な一般解はないと言われているくらいで, カンタンではないのもシステムとゆーやつの特徴だ. この複雑で厄介なシステムを「エンジニアリング」的に相手にして, 飯食っているのがわれわれシステムズ・エンジニアである. じゃあ, こんな厄介なものをどうやって相手にすればよいか. 大きく分けて二つのやり方がある. ひとつは要素還元主義という立場で, どんな複雑なシステムでも要素に分解して, その個々の要素について知を極めれば, システム全体についても分かるだろうと考える. いかにも乱暴だけれど, このやり方が効果を上げる場合もある. もう一つは全体主義 (注) という立場で, システム全体の構造を表すひとつのモデルを作り上げれば, 個々の要素がどう働くかも分かるだろうと考える.
さて, われわれ「システムズ・エンジニア」 (えーと, 「アーキテクト」だっけ?:-) はどんなシステムと関わっているのだろう? もちろんわれわれが作ろうとしているソフトウェア・システムそのものが複雑なシステムだ. そしてどんなソフトウェア・システムもなんらかの現実のシステム (ビジネスとか, 遺伝子解析とか) を対象としてそれを仮想化 (シミュレート) するものだから, それもわれわれの重要な関心事だ. さらにソフトウェア・システムを作ろうとしているわれわれ自身 (開発者もお客さんもユーザも含まれるだろう) が複雑なシステムになっている. そして, さらにさらに, これらソフトウェア・システム, 現実対象システム, われわれシステムの三つのシステムが相互作用しているのが, ソフトウェア・エンジニアリング・システムということになる. あー, ややこし.  ということを考えた上で, じゃあ, われわれはシステムをどうやって相手にしているだろうか? われわれは要素還元主義者か? 確かに古典的なソフトウェア開発プロセスでは, 仕事をWBS (Work Breakdown Structure, 作業分解構造) に, これから作るモノ (Artifact) をモジュールにどんどん分解していって, その最小単位のタスクやモジュールをきっちり予定通りにこなしていけばプロジェクト全体もうまくいくだろうと考える. その一方で, 全体主義者はシステム全体を貫く唯一の原理 (アーキテクチャ) を求めてUMLモデルを描き続ける. いやまぁUMLでなくてもいいんですけど. あるいはプロジェクトを成功させるための組織論を求めて, さまざまな組織構成を試し続ける. たいがいの売り物の「方法論」とはこのようなものだ, といっても過言ではない (かもしれない). そこで, はたして複雑なシステムを要素還元主義か全体主義で相手にできるのだろうか? と問うのが「逆システム学 - 市場と生命のしくみを解き明かす」(金子勝, 児玉龍彦, 岩波新書, 岩波書店, 2004) である. 分野はソフトウェアではなく, 経済学 (市場) と生命科学だが, むしろここにはソフトウェアに近しい何かがあるような気がする. 逆システム学が取る方法はシステム全体を司る原理の探求でもなく, システムを要素に分解してから組み立て直すのでもなく, 環境や仕組みがちょっと変化したときにシステムとしてどのような変化が起きるかを見ることから, システムを解明し, 制御しようとするやり方だ. 曖昧だけれど, とてもプラクティカルなやり方と言っていい. そしてその時に「多重フィードバック」なるものと, それが作られていくプロセスに着目する. 例えばプロジェクトの終了日が迫っているにもかかわらず, 成果物が不足しているとしよう. 要素還元主義の立場から考えるとこうなる. 成果物が足りない -> 成果物を作る人が足りない -> 人を増やせばよい -> 成果物が増えるはず.  ここではシステムは個々の成果物と個々の人に分解されているから, 人が増えることがシステムに及ぼす影響は無視されている. しかし実際に人を増やすとこうなる.  これ (「人を増やしても仕事は進まない, むしろ遅れる」) はブルックスの法則と呼ばれていて, この業界では大昔からよく知られている (でも活かされることは滅多にない). この辺りの事情は「ワインバーグのシステム思考法」(G. M. ワインバーグ, 共立出版, 1994) などを読めばよく分かる. システムを制御しようとして, 目先の数字をいじると大抵は状況は悪化するのである. システムには要素間に自明でない複雑な依存関係があるからだ. じゃあ, その複雑な依存関係を解明して, 開発プロジェクトをひとつの原理に基づくモデル化しようとしても, 多分うまくいかないだろう. もしかしたら開発プロジェクトはあるカオス力学系なのかもしれない. でもそんなことをしている間にプロジェクト期間は終了して, 顧客は開発プロジェクトのカオス・モデルではなく, 成果物をよこせと言ってくるだろう. それにたとえそんなモデルができたとしても, そのモデルを見た開発者は自分たちの振る舞いを変えてしまうかもしれない. そうしたらモデルは何の意味もない. 問題は仕事をこなすためにかえって仕事を増やすというフィードフォワード・ループをシステムに付け加えてしまったことだった. 逆システム学が, そしてワインバーグが言うのは, 多重フィードバック・ループをシステムの中に作りなさいと言うことだ. それではこの課題 (ブルックスの法則) に対処するためにはどうすればいいのだろうか? (1) 目先の目標を付け焼き刃的に追いかけても意味はない (むしろ逆効果)インフルエンザに罹ったときに解熱剤を使うようなものだ. 熱は下がるかもしれないけれど, インフルエンザを治すことはできない. 熱が出ていることにはそれなりの理由があるはずなのだから, その原因をたどってその元を断たなければならない. トヨタ式に言えば5W1H (5階層原因 - why - を遡って, それに対処 - how - する) だ. (2) できるだけ多様で短いフィードバック・ループを多重にかける実際に仕事ができているかどうか, 作ったものが顧客の満足を得るものかどうかは例えば1~2週間ごとに機能をリリースすることによってフィードバックが得られる. これによって, 納期の1ヶ月前に慌てふためくことはなくなるだろう. それでも対応できない場合のために, 少しずつ人を増やしてそのようすを見たり, 早いうちに顧客とスコープ (要求の範囲) について話し合えるような回路を作っておくことができるかもしれない. そして, これらを実現するためには, 納期2週間前に初めても仕方がない. 多重なフィードバックを組み込むためには時間がかかる (歴史性がある) のである. そのためには経験を積み, プロジェクトを育てる (多分複数のプロジェクトにまたがって) 必要がある. ワインバーグに倣って「文化を創る」といってもよいかもしれない. |