ソフトウェア開発とTOCとXPについて、今現在の理解をまとめてみた。同じ課題に対して出所は違うのに同じ結論に至る、というのは本質を外していない証左でもある、のだろうか。

---

TOC（Theory Of Constraints）は1970年末にイスラエル人物理学者エリヤフ・ゴールドラット博士が開発した生産管理用ソフトOPTに端を発するマネジメント理論である。元々は工場の生産管理の改善をテーマとして考え出されたものだが、その方法論は「人間が介在するシステム」の問題解決の本質を射抜いたものであったため、現在ではプロジェクト管理やサプライチェーン、また企業戦略やマーケティング、人事といった幅広い分野で利用されるに至っている。

詳しい内容については右に挙げた「ザ・ゴール」に譲るとして、TOCの主張は大雑把に言えば以下の様なものである。

「システムの抱える様々な問題は、ほとんどの場合１つまたはごく少数の制約条件が根本の原因となっている。
これを取り除く、または最大限に活用することでシステムの成果（スループット）は飛躍的に向上する」

いくら問題が山積みで複雑に見えても、それらの因果関係を整理してみると実は問題の根っ子は同じである、という主張だ。
ある根本原因をルートにツリーの様に連鎖が広がり、複雑な様相を呈している。一見為すすべがないようにも思えるが、根本はひとつであり、それを対処すれば問題は解決する。逆に根本の原因に対処しない限り、「枝葉」である表面上の問題にいくら対処しても問題は最終的には解決しない、というわけだ。

この様に、システムに存在する問題の論理構造を分析し、根本原因を見つけ、それに集中的に対処する。これがTOCのマネジメント理論である。

ソフトウェア開発、ウオーターフォール、TOC

で、ソフトウェア開発にTOCの理論は適用できるのか。

TOCはその出自からして元来は工場のような「プロトタイプを元に同一の製品を大量に生産し出荷する」システムに対するソリューションである。
対してソフトウェアやサービスといった製品は、そのプロセスのほとんどが「唯一無二のプロトタイプを制作する」作業である。
それぞれの本質は大きく異なっており、これらを同じ方法論で解決しようとすることは基本的には困難を極める。工場的な大量生産向けのノウハウをプロトタイプ的なソフトウェア開発に適用しようとして世界中のあちこちで現在進行形で破綻しているのがウオーターフォールモデルだ。

ではTOCもまたソフトウェア開発には適用できないのか？そうではない。TOCの本質は、因果関係を持つあらゆる問題をハンドリングできる包括的な理論であり、プロトタイプ的モデルにも問題なく適用することができる。

スループットの概念

TOCを理解する上で重要なのは「スループット」の概念である。一般的にはネットワークの回線速度がどのくらい出ているかなどといった場合に使われる言葉だが、ここでは「システム全体として目標に対して生み出せた成果」といった概念を表している。システムに設定された目標に対してどれくらい成し遂げられたか？例えば会社であればシステムの目的は「利益を出すこと」であり、スループットは「どのくらい利益を出せたか」ということになる。

ごく当たり前のことのように思えるが、システムを考えるにあたってスループットは驚くほど無視されている場合が多い。その最も分かりやすい例は「縦割り」と言われる官僚型組織構造とそのマインドセットだ。縦割りの組織の場合、それぞれのユニットは自分の仕事を100％実行することだけを考える。自分の担当箇所を過ぎれば、その先がどうなるかは知ったことではない。ハンコを押した書類が次の担当者のところで片端からシュレッダーに掛けられていようとも、それは自分の責任ではないのだから。こういった「責任の分割」は、自らの担当分についての強い責任感を生み出す一方で、システム全体の結果に対する責任についての免罪符という救いがたいマインドセットもまた同時に生み出す。

TOCは問題解決の端緒からスループット指向へのパラダイムの変換を促す。上記のようにシステムに対するこれまでの一般的な問題解決方は分析思考を中心としたものであり、それはつまり全体を細かい要素に分けそれら１つ１つを検討し、悪い部分があれば置き換えるという発想である。一般的なQC（Quality Control）による改善活動はこの考え方を基本にしたものだ。つまり不具合が起きている箇所を修正し、全ての箇所が100％になれば結果も100％になるという考え方である。

対してTOCの視点が置かれるのはシステム全体のスループットである。細部を個々にとらえるのではなく、要素要素の互いの関係に着目し、全体の結果を変えるためにはどこを変えるのが最も効率的か、という包括的な視点からのアプローチである。極論を言えば、それぞれの要素のパフォーマンスが100％である必要はないのだ。例を挙げてみよう。ここにＡ⇒Ｂという仕事の流れがあるとして、Ａに可能な最大の仕事量が２００単位、Ｂのそれが１００単位であったとしたら、Ａがそのポテンシャルを100％発揮してもＢの前にバックオーダーの山が積みあがるばかりでシステム全体としての結果は一向に向上しない。つまりこのシステムは、Ａがどれだけ頑張ってもＢのポテンシャルである１００単位を超えるスループットを出すことはできないのである。そこでシステム全体のスループットを向上させるためには、Ｂの仕事っぷりをなんとかしなければいけない、ということにある。

フィードバックが根本問題

ソフトウェア開発は一般に以下のフローをとる。

要件定義⇒仕様設計⇒実装⇒テスト⇒製品

見ての通りこのフロー自体はウオーターフォールモデルのそれそのものである。ただし、ソフトウェア開発がウオーターフォールモデルに収まらない最大の理由は、製品から仕様設計への、ときには製品から要件定義へのフィードバックが頻繁に発生する点にある。ウオーターフォールモデルの示すフローは、ソフトウェア開発のフローのいわば静的なスナップショットに過ぎない。

ソフトウェア開発においてこのフィードバックが発生するのは、システムを構成するユニットが人間という不確定な存在であるという事実に起因する。もし要件を完璧に定義し、仕様を完璧に設計し、実装を完璧に行なうのであれば、本来テストすらが不要なはずだ（プロセスの中にテストが存在するということ自体、フィードバックが必然であるということを表している）。
人間という不完全な存在が、バグのある実装をし、要件を見落とした仕様を書き、そしてふと思い立っては要件を追加したくなる以上、ソフトウェア開発においてはいかなる種類のフィードバックもその存在を必然として受け入れるほかないのだ。

TOCの場合、曲げられない事実は事実としてその存在を容認する。その前提に立った上で、最もスループットを出すにはどうしたらよいか、を考える。
はっきり見えているのは「ソフトウェア開発でボトルネックになるのはフィードバックの対処である」という事実だ。それも、製品⇒要件定義といった「遠い」フィードバックほど対処が困難である（実装された機能に「やっぱここはこうしたいなあ」とか言われてキレる、といった話は枚挙に暇がないだろう）。
もっともこの認識自体は新たな発見でも何でもなく、ウオーターフォールモデルもこの認識を前提として構築されたモデルである。ただ、ウオーターフォールモデルの場合は「いかにすればフィードバックが起こらなくなるか」という解決を求めたために、「フィードバックは必ず発生する」というソフトウェア開発の本質と矛盾し破綻を来たしてしまったのだ。

TOCとXPのプラクティス

いかにフィードバックを効率よく行なうか、がソフトウェア開発におけるコア問題である。
では実際それをどのように実現したらよいのか？

実は既にソフトウェア開発に対するTOC的な解決メソッドはいくつか提唱されており、その１つがXP(eXtreme Programming)である。XP自体はTOCと直接関係は無いが、その目指すところは「ソフトウェア開発の効率を極限まで追及する」であり、「物事の本質を捉える」ことを突き詰めた結果、TOC同じ結論に辿りついたという見方もできる。
そのXPのプラクティス（メソッド）を以下に幾つか挙げ、「いかにフィードバックを効率よく行うか」という視点から見てみることにする。

• １つのチーム(Whole Team)

  「１つのチーム」は「顧客も設計や開発の現場に同席し打ち合わせに参加する」というものである。そのものズバリ、実際の開発の状況をより直接的に顧客にフィードバックすることを目的としたものである。文章で進捗状況報告書やら仕様修正指示書やらをやりとりするぐらいなら、直接目の前で状況を伝えた方が早い、という話である。また、もしそれですむのであれば不要な書類を作成する必要もなく、そこにかかる労力も削減され、情報の伝達もより速やかに行なうことができる（書類作成されるまで状況がさっぱり分からないといったことが起こらない）。もっとも直接的であり、もっとも効果的なプラクティスである。
  このプラクティスは別段顧客に限らず、プロジェクトに関係するメンバー全員に当てはまることである。単なる例として挙げるなら、仕様書を待ってテスト仕様書を作り、作ってる間に仕様が変わったからと文句を言うくらいなら最初から品質管理部門の人間がプロジェクトに参加していれば良い、という話である。

• 短期リリース (Small Releases)

  「短期リリース」は製品が完成途中でも構わないのでできる限り多くビルドしてリリースする、というものであり、そのまま直接的に「フィードバックのサイクルを極限まで短くする」ことを目的としている。いくら顧客が１つのチームに入っていても、情報が全然もたらされないのであれば意味が無い。頻繁なフィードバックが行なわれてこそ前述の「１つのチーム」プラクティスもその効果を発揮する。
  また短期リリースの対象は、製品に限定する必要もない。要件や仕様書といった類の情報も、完璧な物を完成することを待たず頻繁にリリースすればよいのである。製品も、要件も、仕様も、人間は完璧な物を作れるわけではない、という真理に基づいたプラクティスである。

• ペアプログラミング (Pair Programming)

  「ペアプログラミング」は、乱暴に言えば２人で１つの作業をしましょう、というものだ。２人で机を並べて、ではなく、１つのPCに２人でかかれ、である。当然キーボードもマウスもモニタも１つ。１人は見てるだけ、ツッコミを入れるだけ、である。
  ペアプログラミングは印象的にもドラスティックなプラクティスであるが、その本質もまた印象以上にドラスティックである。
  これはつまり、実装に対するフィードバックを極限まで効率化するにはどうしたらよいか？を考えた結果、実装者の横に常にレビュアーを置いて、実装する傍から即ゼロ時間でフィードバックを行なうべきという結論に達した結果なのだ。またその効果のみならず、時間消費効率の最大化（一人でプログラミングしてるとサボりがち）、実装の理解の効率化と分散化によるリスクヘッジ（そのコードを知ってる人間が一人だけでその人がいないとさっぱり分からない、といった状況を無くす）といった副次的な効果も生み出している。

• テスト駆動開発 (Test Driven Development)

  「テスト駆動開発」は単にテストを先に定義すればよい、というものではない。テスト駆動開発は何のために行なうのですか、と聞かれて正しく答えられるだろうか。テスト駆動開発は、リファクタリングのために行なうのである。つまりリファクタリングによってコードが変更された場合、その変更の正当性を確認するのに時間がかかっていては（例えばいちいち品質管理部門のチェックを行うなどしていては）コード変更に対するフィードバックまでが遅くなってしまうため、正当性の証明書類をテストという形で動的に用意しておくことで効率の良いリファクタリング（ひいてはフィードバック）を行なうことがテスト駆動開発の真の目的である。
  よって、テストは簡単に実行できるものでなければ意味が無い。テストの実行自体に時間がかかるようなやり方ではテスト駆動開発の意味がないのである。また、テストはその対象となる部分の要件に見合った粒度でなければならない。例えば「こういうキーワードで検索したらこういうアイテムが結果として返ってくれ」とだけ要件が定義されている部分についてのテストだったら、それだけをチェックすれば良く、「検索窓の横幅は120pxに収まる」とかそういう細かい仕様のテストは設定する必要がないどころか逆に害悪となる。
  

これらのプラクティスを実践する上でもっとも大切なことは、手段と目的を混同しないということである。プラクティスはプラクティスのために行なうのではなく、あくまで「フィードバックをいかに効率よく行えるか」という目的を実現する手段に過ぎない。従ってプラクティスが上手く行なえないような状況でも無理やりプラクティスを実践することを第一義とするようなことでは、本質を外している。

例えば「１つのチーム」を実現しようとしても、実際には顧客は地元に張り付きっぱなし、開発陣は東京、といった状況がありうるわけで、そこで無理やり毎週１回地元詣でを行なったところでコストはかかるしその上結局週１しか会えないし、で成果は上がらないだろう。この場合であれば、プラクティスの本質としては同一場所に肩を並べることを最優先するのではなく、情報の鮮度を合わせることを優先すべきだ。

このような手段と目的の混同は、ウオーターフォールモデルや旧来のソフトウェアプロジェクトマネジメント論が等しく陥ってきた罠である。課題の本質は何か？という疑問文を常に忘れてはならない。また逆にその点だけ押さえておけば、型に嵌めた方法論が必須となるわけでもない。TOCやXPといった概念はパラダイム自体の提示なのである。