変幻する実行可能知識 23

場 I

かつて, 大昔, ソフトウェアとはあるデータ (例えばローン金額と利率と期間) を入力すると, それに対応する何らかのデータ (例えば毎月の支払額) が出力される, というものであった. 1970年代の計算機科学の教科書の例題はこのようなものが多い. これは初期のソフトウェアは数学的な「函数」(今は「関数」と書くけれど, もともと「函数」, つまり「数の箱」の謂いであった) をメタファとしているからだ. それが証拠に今でもいくつかのプログラミング言語では, アルゴリズム記述の単位を関数と呼ぶ (最近はメソッドなどという曖昧な, 甘ったれた考え方がはびこり, お嘆きの読者諸賢もおられるやもしれぬ:-).

今でも, あるレベルでソフトウェアを見れば, その一つ一つは関数と見なすことができる. しかしそういう関数が集まってできるソフトウェア・システムの全体を単純に関数と考えるのは難しい場合が多い. あるデータを入れれば, あるデータが出るのは同じといえども, 入力と出力の関係はそれまでの歴史 (経緯) や状況, 蓄積されたデータ, ユーザの振る舞いなどに大きく依存しているからだ.

ひるがえって, 今度はソフトウェアを作る過程を考えてみよう. 一部のベンダやユーザはソフトウェア開発とは「要求というものを入れると一定期間後に完成されたソフトウェアが出てくる箱」と考えているフシがある. もちろん「正しい」ソフトウェアを得るためには「正しい」要求を入れてやらなければならない. 要求の正しさが向上すれば向上するほど, 要求の精度が上がれば上がるほど, 出てくるソフトウェアの正しさも向上する (ハズだ). かくして, 正しく, 精度の高い要求を獲得するために労力を惜しまない, 要求至上主義が成立する. 「さぁ, 後は作るだけだ」

要求至上主義が成り立つためには次の二つの条件が必要になる.

• 要求を明確に表現する言語を持っている
• 表現された要求は状況や出力などによって影響を受けない

もちろんこれらの条件が成り立つ場合もある. ローンの支払額の計算は多分そうだ. 自然言語を使っても, 形式的な言語を使っても要求はかなり明確に表せるだろう. 利率などのパラメタは状況によって変化するとしても, アルゴリム自体が変わる可能性は低いし, このソフトウェアを使ってみたら要求が変わってしまった, ということは考えにくい.

しかし, 現実的な多くの案件では話が違ってくる. まず要求を明確に表現する言語がない. たいていは自然言語 (日本語) の積み重ねとUMLのような半形式的言語の自然言語的 (つまりいい加減な:-) 利用で何とかしているのではないだろうか. 少なくとも単一の形式的言語でシステム全体を (プログラムそのものよりも低いコストで) 記述できるというのは幻想に過ぎない.

また, ほとんどのユーザは自分たちの要求 (のようなもの) が形となったシステムが動くのを見て, 実際に動かして, 自分たちが本当には何が欲しかったのかを徐々に理解し, 言葉にできるようになっていく. つまりソフトウェア開発という「函数」では, 入力が出力の影響を (強く) 受けるのである. それだけではない. 「要求」は時間の経過によって, 状況の変化によって, 人間の思いつきやらによって大きな影響を受け, 変化する. 要求 -> システムという単純な図式の裏には実はこんな込み入った点線が張り巡らされているのである.

そもそもこんな点線が技術的にあり得なかった20年前ならば, フィードバックの弱さ, 時間的 遅れの大きさが幸いして系は比較的安定していた. しかし今やこの点線は社会的な要請と技術的な進化によって, 実体化してきてしまったのである. このような系では, 要求を確定しよう, 要求の精度を上げようとすればするほど, 要求は不確定になる (要求の不確定性原理). 要求を完全に記述しようとすると, それは実際にシステムを作ることと結局変わらないことになる (要求の不完全性原理).

何がまずかったかといえば, それは要求とシステムを結ぶ右矢印 → に違いない. ソフトウェア開発とは何かを入れると何かが出てくるものではないのだ, 多分. そこで → を = に置き換えるとどうなるだろう.

左辺の要求, 右辺のシステムを結ぶ「=」は, 要求をシステムに一方通行的に変換する働きではなく, 要求とシステムの動的な平衡を取る働きを表している. 例えば要求が少し増えたら, システムも少し増やす方向に働く. 要求が少し変わったら, システムも少し変える方向に働く. 逆にシステムを少し変えることによって, 要求が少し変わることもある. その代わり, 一度に大きく要求やシステムを変えてもそれに追随することは難しい. 同時に「=」自身も変化していく.

もっと具体的にいえば, ここでの「ソフトウェア開発 (=)」とはユーザの「要求のようなもの」を「動くもの」にする, 動的で, 継続的な過程だ. 例えばユーザと週に一回の要求確認ミーティングを開くことがあるだろう. たいていは次の週までに前回のミーティングの内容をまとめて, Wordの文書にして, 承認を得る. しかし, それを繰り返しても「=」の立場からは何の進展もない. その代わりに, 次の週までにミーティングの内容を一部でも不完全でもいいから, 動くシステムとして (注), ユーザに見て, 使ってもらう, というのが「=」のやり方だ.

注: そのためには, それに適した実現化の道具と方法が必要になる. 例えば Ruby, Groovy, Scheme, Smalltalkのような動的な言語, Ruby on Rails, Grails, Seaside, Kahuaのようなフレームワーク, ワークフローやビジネス・ルール, フォームなど領域ごとに適した記述言語, アジャイルな方法論, コード共有のためのSubversion, 知識共有のためのWikiWikiなどなど.

要求はWordの文書ではなく, コード (プログラム, 形式的言語!) として記述されている. ユーザは自分たちの「要求 (のようなもの)」を実際に (不完全だけれども) 目の前に実体化して見ることができる. 「ほんの少しの要求」と「ほんの少しのシステム」だ. この二つが完全にバランスすることはない. この二つを (前向きに) 平衡させようという努力が, 「=」の立場のソフトウェア開発なのだ. 「=」はその役割上, 十分に薄く, しなやかに働かなければならない.

「=」は要求とシステムの間だけではなく, システムと運用や保守との間にも同じように成り立つだろう. つまりこの過程はシステムを納品して, 本番稼働させて終わりではなく, このシステムが使われ続ける限り続く. この「=」のことを別の言い方で「場」と呼ぶ. 次回以降では「場の論理とマネジメント」(伊丹敬之, 東洋経済新報社, 2005), 「生命知としての場の論理」(清水博, 中公新書, 中央公論社, 1996) などに依りつつ, ソフトウェア開発における「場」を考えていきたい.

2007.05.14
山田正樹 (メタボリックス)