はじめに

　既に「クリティカルチェーン」が発売されて、この本の中でソフトウェア開発について言及されているようです。私は「クリティカルチェーン」をまだ読んでいないので、現実のソフトウェア開発と比べて、どこが同じであるのかどこが異なるのか、を指摘することはできません。ですが、その分、純粋な意味でスループット会計と現実のソフトウェア開発とを比べることができると思います。
　ここでは、各種のアジャイル開発手法（XP、SCRUM、FDD）や、ISO9000などの品質システムとを見比べ、「ザ・ゴール」で示されている制約理論と、スループット会計（在庫、作業費用、スループット）とを合わせて考えていきます。

設計・製作・試験という工程

　まず、ソフトウェア開発工程を「設計」、「製作」、「試験」という３つの工程に分割して考えます。アジャイルソフトウェア工程では、この３の工程はひとつのサイクルと考えられています。また、最近のソフトウェア開発では、大規模開発であっても完全なウォーターフォール方式は無理と考えられて、ある程度のフィードバックやイテレーションが考慮されたスパイラル方式に移行しつつあります。
　『ザ・ゴール』の中で示されるような単純なラインと表せるような作業は、ソフトウェア工程ではほとんどあり得ない、少なくとも中小規模の開発では不可能である、というのが現状だと思います。

ウォーターフォール方式再論

　仮に、ソフトウェア開発工程が、通常の製造ラインのように流れ作業的にできるとすれば、次の図のようになります。

　ウォーターフォール方式のようなライン作業では、手戻りはほとんど考慮されません。たとえば、ソフトウェア開発では、コーディング時（製作時）に実装が難しすぎる、あるいは、実装が不可能、矛盾している、ということが分かったときには、設計に立ち返って、もう一度設計をやり直すこととは多いと思います。ですが、工場の生産ラインのようなウォーターフォール方式では、設計のときに製作時に問題になりそうな部分はすべて除去していこう、という方式なので、作業の流れてとしての設計から製作の矢印はあるのですが、逆向きの製作から設計への矢印はほとんど考慮されていません。
　ここで、「ほとんど」考慮されていない、という言葉を使うのは、生産ラインのようなウォーターフォール方式であっても、ある程度の手戻りは発生するためです。たとえば、工場のオートメーション式の生産ラインであっても、実際に部品を組み立ててみたらうまく組み合わせることができなかった、ということは発生し得ます。そのときには、生産ラインを一旦中止して、設計に立ち返ることになります。もちろん、実際の工場では、生産ラインを中止すれば莫大な損失が発生するであろう、ことは容易に想像できるので、まず、そのようなことはありません。詳しくはわかりませんが、試験的にラインを動かしてみて、部品の精度をチェックしたり、何台か試験的に製品を作ってみてできあがった製品の品質をチェックしたりすると思います。ハードウェア製品の場合には、動く動かないが明確になっているものが多いので、手戻りが発生するか否か（品質管理）は比較的基準が安定しています。ですが、複雑なハードウェアの開発は、ソフトウェア開発の場合には、オートメーション化された機械の安定度＝それぞれの工程の安定度は、それほど安定しているとは言えません。当たり前な話ですが、現在のソフトウェア開発は人の手でコードを打ち込んだり、人が試行錯誤を繰り返しながら開発を進めているために、個人差もあれば実装するときの難易度もさまざまになります。
　このため、各種アジャイル開発手法のように、設計・製作・試験を一体化させたイテレーション開発が主流になりつつあります。　何故、アジャイル開発手法がよいのか、はさておき、ソフトウェア開発工程の問題点をはっきりさせるために、「手戻り」や「イテレーション」について、もう一度ウォーターフォール方式を使ってもう少し詳しく調べてきます。

製作工程に注目

　たくさんの問題があるで、ここではひとつの工程について注目してみます。ひとつの工程に注目することによって、ソフトウェア工程とスループット会計（『ザ・ゴール』で説明されている制約理論）との対比が楽になると思います。

　あなたがプログラマである、と考えてみてください。ここではウォーターフォール方式ですので、プログラマは、設計工程から設計書を受け取ります。設計書は従来どおり、たいていの場合は、紙に印刷されたものです。ただし、電子文書も可です。UML図を貰ってもいいでしょう。必要なものは大体揃っているとします。
　製作工程のあとには試験工程が待っています。製作工程では、テストフレームワークを使って単体試験を実施しているかもしれまん。それとも、だいたいのコーディングだけすませて試験工程にプログラムを渡しているだけかもしれません。ですが、製作の方法や品質はさておき、製作工程では試験工程に渡せるだけのプログラムを作ることが目的です。
　試験工程では、製作工程から渡されたプログラムを試験します。プログラムが完璧に動作し、完璧に設計書に沿った作りになっていれば問題はありません（実際には、完璧なものでも生産ラインには、ある影響を与えます）。ですが、何らかのプログラムミス、何らかの機能漏れ、時には仕様変更も含めて、「プログラムが正常に動いていない」というバグが発生します。
　実際のソフトウェア開発では、製作工程で矛盾が発見されれば設計側に再設計をお願いすることになるし、試験工程でバグが発見されれば製作工程に戻してプログラムを修正していきます。そうでないと製品が完成しません。
　ですが、ここでは更に問題を簡単にするために、工程と工程の間のバグや不具合を「不良品」として考えてみます。工場の生産ラインの場合には、不良品の部品は直すことなく捨てられてしまいます。不良品を減らすために、最近では品質管理（QC）やシックスシグマという考え方が導入されています。これと話のレベルを合わせるために、仮にソフトウェア開発工程でも不良品が出たら直すことなく捨てしまう、という流れを考えます。

　生産ライン方式で、ソフトウェア工程を見た場合、不良品が発生する箇所は３箇所になります。ひとつめは、製作工程内で発生する不良コードです。これは試行錯誤を繰り返したときに捨てられたコードであったり、製作工程の中でリファクタリングをした結果いらなくなったコードなどを示します。ふたつめは、設計と製作との間で発生する、不良品です。仕様書の間違った記述や、矛盾した記述は、正しい製作を行うためには障害となりますから、不良品として弾いておきます。みっつめは、製作と試験の間で発生します。プログラマが設計書どおりにコーディングしたつもりであっても、なんらかの原因でバグが発生します。プログラマが意図的にバグを埋め込まない限り、製作工程内部では、判断しようもない不良品が、プログラムが出来上がったあと、つまり製作と試験の間にできてしまいます。実際には、試験前のちょっとした動作確認で判断できるものと、試験工程で項目を潰しながらでてくる不良品との違いはありますが、ここではそれらをひっくるめて不良品として考えてみてください。

工場の生産ラインと比較

　このソフトウェア工程を、工場の生産ラインと比べてみます。設計、製作、試験、という３つの工程と、そこから出てくる不良品を生産ラインと比べてみると次のようになります。

　生産ラインでは、とあるひとつの工程（Ｂ工程）に注目してみます。Ｂ工程の前にはＡ工程があり、工程の後ろにはＣ工程があります。たくさんの工程が数珠つながりになって、全体の生産ラインを支えています。ここでも、不良品がでる箇所をみると、工程と工程の間に不良品が発生することがわかります。Ｂ工程で使われる部品の品質チェックは、Ｂ工程を動かす前に行われますし、Ｂ工程がきちんと正しい完成品を作ることができたかどうかは、Ｂ工程が終わったあとに品質チェックが行われます。
　工場の生産ラインでは、Ａ工程とＢ工程の間で発覚した不良品や、Ｂ工程とＣ工程の間で発覚した不良品は破棄されます。Ｂ工程がオートメーションの機械であったり、上限が決まっている流れ作業であった場合には、不良品が増えるということは即ち作業効率が落ちる、単位あたりの作業で生産される合格品の数が減るということになります。『ザ・ゴール』にありますが、これを「生産性」と呼び、生産性は量と質の両方が掛け合わされた数値で出しています。つまり、オートメーションの機械の場合には、たくさんの完成品を作っても粗悪品が多ければ駄目、逆に高品質にこだわり過ぎて単時間当たり生産数が減っても駄目、質と量とのバランスがよくなければ生産性が高い、とは言えない、ということです。

　生産性を高めるためのひとつの方法は、生産量を高めることです。同じ質であれば、生産量が多いほうが、生産性が高くなります。工場の生産ラインでは、量を多くするために高価な機械を導入したり、人員を増やしたりします。ソフトウェア開発で言えば、製作工程の生産量を多くするために、高価なツールを導入したり、プログラマを増員したりします。
　おそらく、ソフトウェア技術者の方はみなさん経験があると思いますが、プログラマを２倍にしたとしても生産量は２倍になりません。『人月の神話』にもありますが、プログラマを２倍にすると、プログラマ同士のコミュニケーションの量が増えてしまって、生産性が２倍にアップするわけではありません。たとえば、５人で４ヶ月の工程を終える仕事であっても、１０人で、２ヶ月半では終わりませんし、２０人で１ヶ月で終わるものではありません。極端な話で言えば、２０人月の仕事は、６００人のプログラマを集めても１日で終わるわけではない、ということです。
　では、何故、プログラマを大量に投入したところで生産性はアップしないのかというと、先に「コミュニケーション量」という言葉を使いましたが、ソフトウェア開発では単純な流れ作業では済まない部分があるためです。ある程度の規模のアプリケーションになると、ひとりで作業をすることは不可能になります。納期という作業期限もあるために、複数人で作業分担をすることになります。おそらく、それぞれのプログラマが一切コミュニケーションを取らないでも、同じ品質のものができるようにアプリケーションを機能分割していけば、人月の等価変換は可能かもしれません。しかし、実際には、クラスの振る舞いを協議したり、メソッドの使い方や動きを調節するために、なんらかのコミュニケーションを行い、製品の品質を上げていかなければなりません。それぞれのプログラマが好き勝手に動いて出来上がるわけではない、協調の部分が必要になります。
　このために、量と質を求めてはじめて生産性が出る、と考えられます。

生産性をアップするということ

　『ザ・ゴール』をもとにして、生産性をアップするシナリオをみていきましょう。アレックス達は、ボトルネックになる機械の前に品質チェックを持ってきました。この変更は、ボトルネックになる機械の生産性（量と質）が一定であれば、その機械に供給される部品が粗悪品であれば、機械が止まる確率が増えるし、機械が製品を作っても品質チェックではねられてしまうためです。機械の時間は、生産ライン全体のスループット（キャッシュバック）を決定する貴重な資源です。その資源に対して、無駄な作業をさせることは極力避けなければなりません。

　事前にＢ工程（機械）に投入するための品質をチェックして不良品をより分けておくことによって、高価な機械を無駄に動かすことがなくなります。Ｂ工程は、一定の品質と一定の生産量を保って、一定の生産性で製品を作っていきます。
　この生産性をアップする方法をソフトウェア開発に置き換えてみましょう。
　Ａ工程は、そのまま「設計工程」に置き換えられます。注目するＢ工程は「製作工程」です。ソフトウェアの製作工程では、Ｂ工程（機械）とは異なり一定の生産性を保つことはできませんが、一番人員が投入されてコストがかかっているために高価な部分、という点では工場の生産ラインと同じとみなす事ができます。
　試験工程は、実際には製作工程でできあがった製品を試験するためですが、ここではＣ工程とみなしておきます。

　そうすると、工場の生産ラインにおける部品の事前チェックは、設計書のレビューにあたることがわかります。品質システムなどでは、設計書のレビュー時に目標項目数を定めて設計の品質を上げることに注力していますが、ここで言う「事前チェック」としてのレビューは、「製作工程でトラブルを起こすような設計書を排除しておく」という意味合いになります。生産ラインの場合には、事前の部品チェックは、高価な機械の時間を無駄にしないために、不良品をあらかじめチェックします。これをそのままソフトウェア開発工程にあてはめると、「高価な製作工程の時間を無駄にしないために、不良品である設計書をあらかじめチェックする」という言い換えになります。
　この言い換えが現実に正しいかどうかは別として、もうひとつのチェックも見ていきます。
　製作工程から出てきたプログラムは試験工程によりテストをしていきます。しかし、このテストにもいろいろなレベルがあり、出来上がったプログラムがまったく動かないというレベルから、動きが微妙に試験仕様書と異なるレベルまで様々なものがあります。
　生産ラインで、Ｂ工程からＣ工程に製品が引き渡されるときに、品質のチェックを行います。いままで行われてきた成果物のチェックですが、Ｂ工程の事前チェックをしていない場合には、Ａ工程の不良品までも含み、Ｂ工程自体の不良品も含んでいます。ですが、Ｂ工程に入る前に部品の事前チェックをしておくと、Ｂ工程の後ろの品質チェックではＢ工程自体の不良品のみに変わっていきます。
　同じことをソフトウェア開発工程でみてみると、製作工程で出来上がった成果物（プログラム）を、試験工程に渡す前に事前にチェックしておくほうがよい、とも考えられます。試験の前に、試験をするという一見すると二重チェックをしているように見えますが、この事後チェックは、製作工程の成果物に対してチェックを行う、という視点になります。試験工程では、設計書や試験仕様書とつき合わせてプログラムがそれらに沿って動作するのかをチェックしていきますが、製作工程の事後チェックは、次の工程＝試験工程がスムーズに動くことを目的としてチェックします。たとえば、普段おこなわれていることですが、プログラムのコンパイルが通ること、プログラムのざっとした動作確認をしておくこと、細かな異常系よりも正常系の動作確認を先に行うこと、など経験的におこなっているいくつかの事前チェックが既にあります。

　この事前チェックの仕組みを、あらわしたものが次の図になります。

　黒い線は、ウォーターフォール方式のソフトウェア開発工程で行っているフィードバックの仕組みです。設計工程の最後では、設計書のレビューを行い製作工程に渡すための完璧な設計書を目指します。同様に製作工程では、試験工程に渡す前にコードレビューなどを行いプログラムの品質を高めていきます。この視点は、工程の最後に品質チェックをするという視点になります。ですが、ソフトウェア開発工程も生産ラインのように一定の制約条件があり、製作工程に対する効率は一定限度よりもアップしないと考えた場合、ボトルネックの工程の前に部品チェックを行い不良品がボトルネックに渡される率を減らすことが生産性のアップにつながるように、製作工程の前では、製作側の視点から設計書のチェックを行い、不良品＝設計書の不備を見つけ出し、設計工程へフィードバックをかけたほうが、生産性があがるということになります。
　同じことは、試験工程にもあてはめることができます。製作工程でできあがったプログラムは単体試験やコードレビューを行って試験工程に移るわけですが、製作側の視点からいくらレビューを繰り返したとしても、試験工程の生産性アップにはほとんどつながりません。むしろ、試験工程の視点から、プログラマをチェックし、実際に試験を行う前に試験に耐えうるかどうかの事前チェックが必要になる、であろうということになります。試験工程において、事前チェックとは具体的にどのようなことなのかは、これから考えていきます。

フィードバックという考え方

　もう一度、ウォータフォール方式を眺めてみます。先の不良品の話や、事前チェックと事後チェックの必要性を組み入れるとウォーターフォール方式は、次のようなフィードバックの仕組みが必要になります。

　事前チェック・事後チェックの矢印をひとつにまとめて書き、前の工程に不良品のフィードバックを行います。不良品を受け取った前工程は、不良品の量の分だけ作成しなければいけません。たとえば、生産ラインでは次の工程のために部品を100個作成しなければならない、とします。次の工程で、10個の不良品が検出されて、90個の部品しか使えない場合には、前の工程に新しく10個の部品を作成してほしいと要求します。そして、はじめて次の工程では、正常な100個の部品を使って製品を作れることになります。同じように、製作工程で発覚した不良品＝設計ミスは、設計工程に戻されます。設計工程でミスが正された後に、再び製作工程に設計書が渡ってくることになります。
　しかし、実際にフィードバックを考えてみるとよくわかりますが、前工程だけではすまない場合があります。アプリケーションの試験を行ったとき、バグが発生する原因は、コーディング自体のミスであったり、設計上のミスであったりします。あるいは、顧客からの要件を分析したときに漏れが出ていたり、矛盾がでてきたりすることもあります。
　ソフトウェア開発工程を規定する SDM という方式に、「段階的に規定された設計工程の中で、対応する試験工程の仕様書を作成する」という方針があります。実際のプロジェクトでは、さまざまな理由により、この方針に忠実に従うことは難しいのですが、この設計と試験の対応を図にすると次のようになります。

　『Software People vol.2』などで紹介されていますが、ソフトウェア開発工程をいくつかの層に分けます。左にある工程が前工程であり、右にある工程が後工程になります。前後の工程をつなげるものは、設計書と試験仕様書の関係になります。一番上の層には、顧客の要件があるので、最後に製品ができあがった段階で、次のバージョンの開発や、実際に使われているアプリケーションに対して意の市場からのフィードバックになります。最近、WEB ページで行われている、製品アプリケーションへの意見聴取はこれにあてはまると思います。
　XPのひとつのプラクティスであるテストフレームワーク「xUnit」は、一番下にある層のコーディングと単体試験によるイテレーションになります。
　V字型に工程を進めるとウォーターフォール方式になりますが、SDM 方式のように階層を分けて、右から左へのフィードバックの仕組みを作ると情報の流れが少し違ってきます。
　では、先の事前チェック、事後チェックを含めて、ひとつ前の工程に不良品を出せるような流れを図に加えてみます。

　大きな流れとして、要件→設計→製作→試験→製品という流れは変わりませんが、一方通行ではなくて逆向きの流れがたくさんあります。この逆向きの流れは、事後チェックであれば、それ自身の工程の視点で成果物が正しくできていることをチェック、事前チェックであれば、部品がその工程に悪影響を及ぼさないかどうかのチェック、同じ階層へのフィードバックは、同階層の前工程でできたインプットに沿って下階層から正しいアウトプットが出てきているかどうか、をチェックしています。
　具体的に、設計、製作、試験の各工程について詳しくみていきます。

設計工程のフィードバック

　設計工程では、顧客からの要件を分析して設計書としてまとめていくことが目的になります。SDM や ISO の工程区分では、設計工程をいくつかの階層に分けていますが、ここでは説明を簡単にするためと、根本的に設計という作業自体が分割しずらいために、ひとつの工程としてまとめています。
　少し詳しく言えば、顧客の要件を分析する人＝アーキテクトと、UML などを使いながら実装の立場から要件を設計書として書き起こしていく人との違いは、あまり明確ではないと筆者は考えています。端的に云えば、開発規模や顧客の要求する専門領域（ドメイン分析あるいはインテグレータ）の違いにより、ソフトウェア開発を行う際の実作業としては分割しづらいと思われるためです。
　話を元に戻すと、設計者は、顧客の要件をよく理解して、それがどのように実装できるのかを分析していきます。顧客の要件が曖昧であれば、設計者は顧客に質問を繰り返すことによって、顧客がどのようなものを望んでいるのかを引き出していきます。また、顧客の要件に矛盾あるとこの段階でわかれば、顧客に訂正を求めます。これが、設計工程の事前チェックになります。実際に、詳しい要件分析を行ったり、たくさんの設計書を書き起こす前に、あらかじめ不明な点を明らかにしていったり、矛盾をなくしていけば、設計工程自体は比較的にスムーズに行えることが想像できます。
　当然、全てのチェックを行うことは難しく、実際に要件分析や設計作業を行わなければ明確にならない部分はたくさんあります。しかし、顧客の要求する項目をまるでチェックすることなく、顧客の言うがままに設計作業を開始することは、もともと無駄であった要件までを含めて作業することに他なりません。ある程度のチェックを済ます＝設計工程に支障のない程度のチェックを行う、というトレードオフの感覚が必要になります。

インプット	顧客からの要件
アウトプット	製作工程へ引き渡すための設計書試験工程へ引き渡すための試験仕様書
事前チェック	設計書を作成できる要件が顧客から提示されているか？
事後チェック	顧客からの要件に従って設計書が作成されているか？顧客からの要件に従って試験仕様書が作成されているか？
フィードバック	製作工程の事前チェックで、不良の発生試験工程の事前チェックで、不良の発生

　設計工程が終わった後には、レビューを行うことで顧客の要件を満たすような設計書が仕上がったことを確認します。ウォーターフォール方式では、すべての設計書は製作工程に引き渡す前に完璧に仕上げることが必要なのですが、それは不可能である、とみなさんは経験的に知っていると思います。レビューをどれけ繰り返しても、製作工程あるいは試験工程で設計書の不備が見つかるのは仕方が無いことです。この不完全性を補うためにも、レビューの後にもフィードバックを受ける仕組みが必要になります。これが、製作工程の事前チェックによるフィードバックになります。
　同様に、試験工程からのフィードバックも必要です。現実問題として設計工程時にすべての試験仕様書を書き上げることは難しいと考えられます。いくつかの大雑把な試験項目をあげることはできますが、必ず漏れが出てきますし、途中で発生する顧客からの仕様変更や製作工程からフィードバックにより試験仕様書は必至です。このためにも、実際に試験を行う試験工程からのフィードバックは必要になると考えられます。
　ただし、設計工程のアウトプットに、試験仕様書を加えることには異論がある読者が多いと思います。実際 SDM 方式では、試験仕様書は試験工程で作ることになっています。このあたりの違いは、もう少し後で調節していきます。

製作工程のフィードバック

　基本的に製作工程では、インプットは設計工程から仕様書を受け、製作工程でプログラミングと単体試験を行い、完成した製品を試験工程に引渡します。単体試験を製作工程として含めるかどうか、にはいろいろな意見があると思いますが、ここでは XP のテストフレームワークのように、少なくとも関数単位＝モジュール単位での動作チェックを行ったあと、モジュールを組み合わせた機能単位、それぞれの機能を組み合わせたアプリケーション単位、更に複数のアプリケーションの統合を試験工程として行う、という考え方をしています。製作工程の短いフィードバックと、試験工程からの比較的長いスパンでのフィードバック分けています。

インプット	設計書
アウトプット	試験工程へ引き渡すためのプログラム（単体試験済み）
事前チェック	設計書からプログラムが作成できるか？
事後チェック	設計書に従ってプログラムが作成されているか？設計書に従ってプログラムが作成が可能か？（設計書の妥当性）
フィードバック	試験工程の事前チェックで、不良の発生試験工程で、不良の発生（プログラムの妥当性）

　製作工程では、設計工程より設計書を受け取り、この設計に従ってプログラムコードを作成します。プログラムコードは、単体試験（ユニットテストの利用）をクリアして、一定の品質を持つ成果物として試験工程に引渡しを行います。
　先にも書きましたが、設計工程でレビューを繰り返しても一定以上の精度を上げることが難しくなります。UML などの上流工程用のツールを使えば、ある程度の精度を上げることができるかもしれませんが、経験的に「実際に作って動かして」みないことには、よくわからない問題（性能問題やプログラミング技術の問題など）が出てくるのは仕方が無いことです。
　製作工程を一種のボトルネック＝一番価値の高いコーディングマシンと考えて見ます。すると、設計書を製作工程に引渡したときに、設計書の質が悪い場合にはコーディングマシンの効率が悪くなります。設計書の質が原因でコーディングの効率が悪くなったり、手戻りが発生しては、プロジェクト全体のスループットが落ちてしまいます。これを避けるためには、製作工程から設計工程のフィードバックが大切になります。実際にコーディングをする前に、本当にプログラミングが可能であるかどうか、を製作側から設計書をチェックします。製作工程の事前チェックでは、机上の空論でしかない設計や、難しすぎる設計を排除することが目的です。
　もうひとつのフィードバックは、製作工程の中で随時、設計書をチェックしていく仕組みが必要になります。コストの高い製作工程では、コーディングを阻害するような設計書はスループットに多大な影響を与えます。製作工程のスループットは、直接プロジェクトのスケジュールに影響を与えるので、ここの改善は大きな効果があります。よって、設計に対する積極的な改変（設計書に対する突っ込み）を要求し続けることが必要になります。
　製作工程のアウトプットは、プログラムになりますが、試験工程で行われる試験に達するための品質が必要になります。たとえば、単体試験を行わないプログラムを、そのまま試験工程に引き渡しても、たくさんのバグ票と共に再び製作工程に戻ってきてしまうだけです。ひとつの工程でイテレーションと、製作と試験工程で繰り返されるイテレーションのサイクルとはかなり異なります。当然、製作工程のみで繰り返されるサイクルが早いのですから、サイクル＝単体試験を行い一定の品質を保つことが工程間のスループットを増やすことになります。
　しかし、設計から製作工程への流れで、過剰な品質保持には時間がかかるのと同じように、製作から試験工程の流れでも、高品質すぎる成果を出そうとすると時間がかかりすぎます。製作工程では、単体試験に集中することでモジュール単位の品質を上げ、それ以上の試験は実際の試験工程に引き渡すことになります。

試験工程のフィードバック

　ウォーターフォールの試験工程では、製作工程で作成されたプログラムを試験していきます。試験仕様書は、設計工程で用意されたものや、試験工程独自で設計書から書き起こした試験仕様書を使うことになります。不具合があれば、製作工程の部員に引き戻して、プログラムを直して貰います。そして、再試験を行いひとつひとつの試験項目をクリアしていくことになっています。
　ですが、次の図を見てください。サイクルを重視した３工程では、試験工程から設計工程へのフィードバックも必要になります。たとえば、試験工程でユーザインターフェースが意外と悪いことがわかったり、技術的に無理があってスムーズなプログラムの動きができていないかったりします。また、顧客が試験工程に参加することによって、機能要件に合わないプログラムを試験しているかもしれません。これらを解消するために、試験工程から設計工程へフィードバックを行い、設計から直すことによって、より顧客の要件に沿ったプログラムに書き直すことが必要になります。

インプット	試験仕様書、プログラム
アウトプット	完成されたプログラム
事前チェック	試験項目がある程度クリアできる目処が立っているプログラムか？
事後チェック	顧客の機能要件を満たしているプログラム化？顧客による第三者確認
フィードバック	顧客要件を満たさない項目に関しては設計工程へ差し戻すプログラムの不具合は製作工程に差し戻す

　ウォーターフォール方式では、試験工程はスケジュールの一番最後に配置させられてしまうために、前工程へのフィードバックが難しい位置にあります。実際に試験項目をこなす中で、明らかに顧客の機能要件を満たしていない不具合に対しても、スケジュールの関係からそのままにしてしまうことがあります。スケジュールを延期しなければ、機能要件を満たすことができない、しかし、スケジュールを延期することは顧客は許さない、というジレンマに陥ることがたびたびあります。この場合、それぞれが妥協点を見出してしまい、機能要件をある程度削ってしまったり、スケジュールを延期していくつかの機能要件を満たすように頑張ったりしてしまいます。
　しかし、スケジュールを延期した場合にはキャッシュバックが延期することになり、顧客自身の投資回収期間が延びてしまったり、他のプロジェクトに影響を与えてしまいます。逆に機能を削除してしまったり、機能を落としてしまったりすると、市場の競争力が減ってしまいます。どちらにせよ、スケジュールに縛られた安易な決断が、長期的な損失につながってしまいます。
　試験工程からのフィードバックを許すことによって、最終的な成果物の品質を安定させることができます。このフィードバックが、機能削減やスケジュール延期につながらないようにするためには、試験工程を、設計や製作工程と同時期／同時進行を許す必要があります。かつ、最終的な成果物をフォローアップするために、「プロジェクトバッファ」（『クリティカル・チェーン』より）という考え方が必要になります。このあたりは、「週40時間という見積もり」で議論していく予定です。

サイクル式のソフトウェア開発工程

　さて、これらの３つの工程（設計／製作／試験）と、顧客の機能要件、最終的な成果物＝製品をつなげてみると、次のようなサイクルがみえてきます。トポロジー的には先のV字型の階層を横にすると同じ形になっています。
　主に右廻りのサイクル（青い矢印）が、主な流れになります。この流れがスループットをあげるための推進力です。逆廻りのサイクル（オレンジの線）が、不具合品／フィードバックの流れになります。不具合品はスループットを下げる要因ですが、ある程度のフィードバックはスループット自体をあげるための補助要因にもなります。２つの工程の間における小さなサイクルと、すべての工程を含めたプロジェクトのサイクルが大切になります。大きな青い線のサイクルの流れ＝プロジェクトのトルクを考えていきます。

　これがサイクル式のソフトウェア工程です。具体的なスループットはトルク（回転数）を上げることによって、プロジェクト自体の品質を上げることが可能になります。
　次に、それぞれの工程に対して具体的な部分効率化と、プロジェクト全体のスループットを考えていきます。

... to be continue.