16.multiplexed+hierarchical+open+feedback+loop

変幻する実行可能知識 16

システム II - 多重で階層的な開かれたフィードバック・ループ

前回紹介した「逆システム学」は, 経済や生物にとって重要なのは「多重で階層的な, 開かれたフィードバック制御」なのであって, 要素還元論でも全体的原理主義でもないのだ, という話だった. 個が最適に動けば全体としてうまく動くのでもなく, システム全体が個を制御するのでもなく, 個とシステムの間に「多重で階層的な, 開かれたフィードバック制御」という領域があり, それこそが逆にシステムを形作っているというわけだ. そしてそれは多分ソフトウェア開発でも同じだろうと考えたのである. でも正直なところ, これだけじゃあ, どういうソフトウェア開発をすればいいのか, よく分からない. そこで今回も続けて, もう少し掘り下げて考えてみることにしよう.

例えば典型的なウォータフォール型開発プロセスでは, プロジェクトを駆動するのはプロジェクト初期に立てた要求仕様 (何を作るか) とプロジェクト計画 (どうやって作るか) である. 先に進んでどんどんモノを作っていきたい気持ちを抑え, ここでじっくり正しい要求仕様と計画を作り込めばプロジェクトはうまくいくはずなのだ. この場合, プロジェクトの調節機能とは, 要求仕様/計画と実際の成果物/進捗の差が生じたらその差を解消するようにプロジェクトを変えればよい, というものだった. だから欠陥が目標より多かったら欠陥を修正すればよい, 納期に間に合わなくなったら (工数が不足してきたら) 人を増やせばよい (工数を増やせばよい).

確かにこれもフィードバック制御だが, 欠陥の修正だけですべての工数を食いつぶしてしまい, 人を増やせばますます納期が遅れるというのもよく知られた結末である. フィードバック制御さえあればいいわけではない. 「いい」フィードバック制御と「悪い」フィードバック制御があるのだ. その差はなんだろうか?

別の例を見てみよう. XP (エクストリーム・プログラミング) ではプロジェクトを駆動する単一の要求仕様とプロジェクト計画というものが最初からあるわけではない. じゃあフィードバック制御というものもないかというと, そんなことはない. むしろフィードバック制御の網が張り巡らされているといっていいくらいだ. 例えば欠陥に関する調節機能を見てみよう. いちばん短いサイクルでは (ループ1),

  1. テスト・コードを書き,
  2. テスト・コードを実行し,
  3. テストが成功するように実装コードを書く

というフィードバック・ループがある. このループはだいたい数分から数十分単位, プログラマ (ペア・プログラミングしている場合には二人, そうでなければ一人) に対して作動する.

もう少し長いサイクルでは (ループ2),

  1. モジュール (クラスとか) をチェックインし,
  2. 他のモジュールと統合し,
  3. 機能テストを実行し,
  4. 期待した機能テストが通るように修正する

というフィードバック・ループが, 先のフィードバック・ループの重なりの上にできている. このループはだいたい1~2時間から1日単位, プロジェクト・メンバ全員に対して作動する.

さらにこの上に (ループ3),

  1. 対象とするストーリを決め,
  2. タスクに分解し,
  3. タスクを実行し,
  4. ストーリを実現できているかチェックする

というフィードバック・ループ (イテレーション) がある. このループはだいたい1~2週間単位, プロジェクト・メンバ全員 (場合によっては顧客やユーザの一部を含む) に対して作動する.

いちばん長いサイクルは (ループ4),

  1. 計画ゲームを行い,
  2. ストーリを決め,
  3. ストーリを実現し,
  4. 受け入れテストをパスするかチェックする

というフィードバック・ループ (リリース) だ. このループはだいたい1~数週間単位, ユーザや顧客を含むプロジェクトのステークホルダ全員に対して作動する.

つまりXPでは欠陥修正のフィードバック・ループは四つのレベルに階層化されている. またこの中のいちばん長いサイクルは要求変更やプロジェクト速度見積もりのフィードバック・ループでもあるわけで, 欠陥修正のフィードバック・ループと多重化されているのだ. つまり欠陥修正のループは自動的に見積もりのループや要求変更のループとリンクしているので, 欠陥修正が多ければそれが見積もりに反映されたり, 要求変更を抑えたりすることになる.

そしてこれらのループには「他人」を巻き込む仕掛けがある. 例えばループ1ではペア・プログラミングの相手が, ループ2, 3ではソース・コードの共同所有のプラクティスやビルド結果の通知などによってプロジェクト・メンバ全員が, ループ4ではプロジェクトのステークホルダ全員が, これらのフィードバック・ループに巻き込まれてしまうようになっている. その結果, ループは巻き込まれた人の別のループとリンクしていく. それによって開発プロセス自体のダイナミックな変更が可能になる (例えば工数が足りなければストーリを見直していくつかを落とすとか機能を浅くするとか. 典型的なウォータフォール型開発プロセスの例では, 納期遅れの問題はプロジェクト内で解決するしかなかったから人を増やさざるを得ないのだった).

XPのこのフィードバック・ループは「多重で階層的な, 開かれたフィードバック制御」の例になっていると言えるだろう. 「多少間違いを起こしても大丈夫な制御 (「逆システム学」の言葉を使えば「セーフティ・ネットから始まるフィードバック」) か, 「間違いを起こさないことを前提とした制御」か, と言い換えてもいいかもしれない.

さて「多重で階層的な, 開かれたフィードバック制御」なるものが我々に役に立つとして, では次の問題はこうなる. 「多重で階層的な, 開かれたフィードバック制御」はどうすればできるのか? 逆システム学ではシステムを構成するひとつの理論があるわけではない, と考えるのだから, 都合のよいフィードバック・ループを最初から, あるいは後付けでシステムにはめ込むことはできないはずだ. ということは, 都合のよいフィードバック・ループができる過程もフィードバック・ループによるほかない.

XPのフィードバック・ループも理論や原理によって作られたものでは多分ない. いちばん最初はおもにSmalltalkプログラマの現場から生まれてきたものだろう. そこにはSmalltalkの弱点も一役買っているはずだ. なんと言ってもSmalltalkではどのオブジェクトにもどんなメッセージでも送れてしまう. ある変数に束縛されているオブジェクトがどんなメッセージを (意図通りに) 解するかは出たとこ勝負だ. さらにはシステム・ライブラリはおろか, メタオブジェクト (ある意味インタプリタと言ってもいい) さえいじれてしまうから, とにかく何かをいじったら, ちゃんと動くかどうかはその場で確認しなければ大変なことになる. 普通のプログラミング言語ならば「コンパイラさえ通れば, まぁ大丈夫だろう (本当はぜんぜん大丈夫じゃないけど)」というのがここでは通用しないのだ.

XPのフィードバック・ループのひとつの原点がプログラミング言語の弱点をカバーするためのものだったとして, それが今のXPへと育ったのはそれだけが原因ではなさそうだ. 続きはまたの機会に...

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

Comments