連載
» 2006年02月17日 12時00分 公開

ソフトウェア開発をちゃんと考える(3):口に出す前に考える、「システムって何?」

われわれは日常的にたやすくシステムという言葉を使ってしまうけれど、システムって何だ? システムズ・エンジニアって誰だ? 「最近システムがよく落ちるんで困るっすよ」ってどーゆーことだ?。

[山田正樹,メタボリックス]

 システムとは相互作用する複数の要素の集合。だから太陽系もシステムだし、会社もシステムだし、計算機もシステムだ。仏教的にはあらゆるモノはほかのモノとの相互作用においてのみ存在するわけだから、(仏教的世界においては)あらゆるモノはシステムということになる。とはいっても、例えば地球、月、太陽というたった3つのモノの(古典)力学的相互作用にさえ、厳密な一般解はないといわれているくらいで、カンタンではないのもシステムとゆーやつの特徴だ。

 この複雑で厄介なシステムを「エンジニアリング」的に相手にして、飯を食っているのがわれわれシステムズ・エンジニアである。じゃあ、こんなものをどうやって相手にすればよいか。大きく分けて2つのやり方がある。1つは要素還元主義という立場で、どんな複雑なシステムでも要素に分解して、その個々の要素について知を極めれば、システム全体についても分かるだろうと考える。いかにも乱暴だけれど、このやり方が効果を上げる場合もある。もう1つは全体主義(注)という立場で、システム全体の構造を表す1つのモデルを作り上げれば、個々の要素がどう働くかも分かるだろうと考える。


注:もちろん政治的な全体主義とは何の関係もない。ホーリズム:wholismである


 さて、われわれ「システムズ・エンジニア」はどんなシステムとかかわっているのだろう? もちろんわれわれが作ろうとしているソフトウェア・システムそのものが複雑なシステムだ。そしてどんなソフトウェア・システムも何らかの現実のシステム(ビジネスとか、遺伝子解析とか)を対象としてそれを仮想化(シミュレート)するものだから、それもわれわれの重要な関心事だ。さらにソフトウェア・システムを作ろうとしているわれわれ自身(開発者もお客さんもユーザーも含まれるだろう)が複雑なシステムになっている。そして、さらにさらに、これらソフトウェア・システムと現実対象としてのシステム、われわれ自身という3つのシステムが相互作用しているのが、ソフトウェア・エンジニアリング・システムということになる。あー、ややこし。

ALT

 ということを考えたうえで、じゃあ、われわれはシステムをどうやって相手にしているだろうか? われわれは要素還元主義者か? 確かに古典的なソフトウェア開発プロセスでは、仕事をWBS(Work Breakdown Structure:作業分解構造)に、これから作るモノ(Artifact)をモジュールにどんどん分解していって、その最小単位のタスクやモジュールをきっちり予定どおりにこなしていけばプロジェクト全体もうまくいくだろうと考える。

 その一方で、全体主義者はシステム全体を貫く唯一の原理(アーキテクチャ)を求めてUMLモデルを描き続ける。いやまぁ、UMLでなくてもいいんですけど。あるいはプロジェクトを成功させるための組織論を求めて、さまざまな組織構成を試し続ける。たいがいの売り物の「方法論」とはこのようなものだ、といっても過言ではない(かもしれない)。

 そこで、果たして複雑なシステムを要素還元主義か全体主義で相手にできるのだろうか? と問うのが「逆システム学」(金子勝、児玉龍彦、岩波新書、岩波書店、2004)である。分野はソフトウェアではなく、経済学(市場)と生命科学だが、むしろここにはソフトウェアに近しい何かがあるような気がする。

 逆システム学が取る方法はシステム全体をつかさどる原理の探求でもなく、システムを要素に分解してから組み立て直すのでもなく、環境や仕組みがちょっと変化したときにシステムとしてどのような変化が起きるかを見ることから、システムを解明し、制御しようとするやり方だ。あいまいだけれど、とてもプラクティカルなやり方といっていい。そしてそのときに「多重フィードバック」なるものと、それが作られていくプロセスに着目する。

 例えばプロジェクトの終了日が迫っているにもかかわらず、成果物が不足しているとしよう。要素還元主義の立場から考えるとこうなる。成果物が足りない→成果物を作る人が足りない→人を増やせばよい→成果物が増えるはず。

ALT

 ここではシステムは個々の成果物と個々の人に分解されているから、人が増えることがシステムに及ぼす影響は無視されている。しかし実際に人を増やすとこうなる。

ALT

 これ(「人を増やしても仕事は進まない、むしろ遅れる」)はブルックスの法則と呼ばれていて、この業界では大昔からよく知られている(でも生かされることはめったにない)。この辺りの事情は「ワインバーグのシステム思考法」(G.M.ワインバーグ、共立出版、1994)などを読めばよく分かる。システムを制御しようとして、目先の数字をいじると大抵は状況が悪化するのである。システムには要素間に自明でない複雑な依存関係があるからだ。

 じゃあ、その複雑な依存関係を解明して、開発プロジェクトを1つの原理に基づくモデル化しようとしても、多分うまくいかないだろう。もしかしたら開発プロジェクトはあるカオス力学系なのかもしれない。でもそんなことをしている間にプロジェクト期間は終了して、顧客は開発プロジェクトのカオス・モデルではなく、成果物をよこせといってくるだろう。それにたとえそんなモデルができたとしても、そのモデルを見た開発者は自分たちの振る舞いを変えてしまうかもしれない。そうしたらモデルは何の意味もない。

 問題は仕事をこなすためにかえって仕事を増やすというフィードフォワード・ループをシステムに付け加えてしまったことだった。逆システム学が、そしてワインバーグがいうのは、多重フィードバック・ループをシステムの中に作りなさいということだ。それではこの課題(ブルックスの法則)に対処するためにはどうすればいいのだろうか?

(1)目先の目標を付け焼き刃的に追いかけても意味はない(むしろ逆効果)

 インフルエンザにかかったときに解熱剤を使うようなものだ。熱は下がるかもしれないけれど、インフルエンザを治すことはできない。熱が出ていることにはそれなりの理由があるはずなのだから、その原因をたどってそのもとを断たなければならない。トヨタ式にいえば5W1H(5階層原因 - why - をさかのぼって、それに対処 - how - する)だ。

(2)できるだけ多様で短いフィードバック・ループを多重に掛ける

 実際に仕事ができているかどうか、作ったものが顧客の満足を得るものかどうかは例えば1〜2週間ごとに機能をリリースすることによってフィードバックが得られる。これによって、納期の1カ月前に慌てふためくことはなくなるだろう。それでも対応できない場合のために、少しずつ人を増やしてその様子を見たり、早いうちに顧客とスコープ(要求の範囲)について話し合えるような回路を作っておくことができるかもしれない。

 そして、これらを実現するためには、納期2週間前に始めても仕方がない。多重なフィードバックを組み込むためには時間がかかる(歴史性がある)のである。そのためには経験を積み、プロジェクトを育てる(多分複数のプロジェクトにまたがって)必要がある。ワインバーグに倣(なら)って「文化を創る」といってもよいかもしれない。

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ