XPの欠陥修正フィードバック・ループを分析する：ソフトウェア開発をちゃんと考える（4）

前回（「口に出す前に考える、『システムって何？』」）で紹介した「逆システム学」は、経済や生物にとって重要なのは「多重で階層的な、開かれたフィードバック制御」なのであって、要素還元論でも全体的原理主義でもないのだ、という話だった。

» 2006年04月12日 12時00分 公開
[山田正樹，メタボリックス]

　個が最適に動くから全体としてうまく動くのではない。システム全体が個を制御するのでもない。個とシステムの間に「多重で階層的な、開かれたフィードバック制御」という領域があり、それこそが逆にシステムを形作っているのである。そしてそれは多分ソフトウェア開発でも同じであろうと考えた。でも正直なところ、これだけじゃあ、どういうソフトウェアを開発すればいいのかよく分からない。そこでこの問題をもう少し掘り下げて考えてみることにした。

　例えば、典型的なウォーターフォール型開発プロセスでは、プロジェクトを駆動するのはプロジェクト初期に立てた要求仕様（何を作るか）とプロジェクト計画（どうやって作るか）である。先に進んでどんどんモノを作っていきたい気持ちを抑え、ここでじっくり正しい要求仕様と計画を作り込めばプロジェクトはうまくいくはずだ。

　プロジェクトの調節機能とは、「要求仕様／計画」と「実際の成果物／進ちょく」の差が生じたらその差を解消するようにプロジェクトを変える（機能の）ことだ。だから欠陥が目標より多かったら欠陥を修正すればよい。納期に間に合わなくなったら（工数が不足してきたら）人を増やせばよい（工数を増やせばよい）。

　これはフィードバック制御の一種だが、少々乱暴な制御であることも事実である。欠陥の修正だけですべての工数を食いつぶし、人を増やしてさらに納期を遅らせるというのは、よくある結末である。フィードバック制御さえあればいいというわけではない。「いい」フィードバック制御と「悪い」フィードバック制御があるのだ。その差はなんだろうか？

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

  • テスト・コードを書き、
  • テスト・コードを実行し、
  • テストが成功するように実装コードを書く

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

　もう少し長いサイクルでは（ループ2）、

  • モジュール（クラスとか）をチェックインし、
  • ほかのモジュールと統合し、
  • 機能テストを実行し、
  • 期待した機能テストが通るように修正する

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

　さらにこの上に（ループ3）、

  • 対象とするストーリを決め、
  • タスクに分解し、
  • タスクを実行し、
  • ストーリを実現できているかチェックする

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

　一番長いサイクルは（ループ4）、

  • 計画ゲームを行い、
  • ストーリを決め、
  • ストーリを実現し、
  • 受け入れテストをパスするかチェックする

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

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

　そして、これらのループには「他人」を巻き込む仕掛けがある。例えば、ループ1ではペア・プログラミングの相手が、ループ2、3ではソース・コードの共同所有のプラクティスやビルド結果の通知などによってプロジェクト・メンバー全員が、ループ4ではプロジェクトのステークホルダ全員が、これらのフィードバック・ループに巻き込まれてしまうようになっている。

　その結果、あるループは、巻き込まれた人の別のループにリンクしていく。それによって開発プロセス自体のダイナミックな変更が可能になる（例えば、工数が足りなければストーリを見直していくつかを落とすとか、機能を浅くするとか。典型的なウォータフォール型開発プロセスの例では、納期遅れの問題はプロジェクト内で解決するしかなかったから人を増やさざるを得ないのだった）。

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

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

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

　XPのフィードバック・ループの1つの原点がプログラミング言語の弱点をカバーするためのものだったとして、それがいまのXPに成長した最大の要因だったのかどうかと考えると……、残念ながら話はそんな簡単ではない。続きはまたの機会に……。

「ソフトウェア開発をちゃんと考える」バックナンバー

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ