2002/08/18 [初版]
2003/2/15 [改定]
最近、 eXtreme Programming (以降XP）や Rational Unified Process （以降RUP）といった開発プロセスが話題です。いよいよウオーターフォールモデルからスパイラルモデルの開発プロセスモデルへ世代交代の期待が出来そうです。ウオーターフォールモデル以外の開発方法では「同期安定化プロセス」[1]がビジネスの世界で１人勝ちの成果をあげているのを横目で見てはいました。しかし、現実に携わるプロジェクトではウオーターフォールモデル以外の方法論の選択や実践が難しかったのです。開発プロセスの見直しをする事があっても、従来からの「常識」とされている手堅い方法をプロジェクト毎に部分的に工夫するという範囲でした。しかしプロジェクト遂行の方法論としてスパイラルモデルの導入タイミングはオブジェクト指向技術の普及と共にまさに機は熟した感があります。今ではウオーターフォールモデル守旧派の立場の方へも一般的に認知が進んだ方法論や適応事例を例示することが可能です。（あとは現場の行動あるのみですね。）
XPやRUPの方法論詳細はもう随分紹介されていますので、ここではスパイラルモデルに踏み切る為の問題の１つ、従来の常識を変更するのに伴う「心理的抵抗」を緩和する為、（殆どの皆さんとその周りの方々が）共有していると思われる１つの「常識」に遡って考えたいと思います。
多人数で問題解決を行う場合、適切な作業分担の「常識」として「ベルトコンベア方式」のイメージがあります。T型フォードの成功例を誰もが連想します。そしてソフトウエアの開発においても、この常識を安易にそのまま持ち込んだモデルがウオーターフォールモデルといえるのではないでしょうか。プロジェクト管理者が工程管理を行い、システムエンジニア＞プログラマー（＞コーダー＞パンチャー）へと作業を分担する事が、効率の良く管理・制御された開発の「常識」とされています。
しかし自動車産業が生まれた一世紀も前の「ベルトコンベア方式」の考え方は、今でも工場生産の現場で現役で主役のままの「常識」なのでしょうか。改良されていたり、他の方式は考案されていないのでしょうか。もし他の方式があれば、その新しい「常識」を、アナロジー（類推）としてわれわれソフトウエア業界の開発プロセスへそのまま転用できるかもしれません。
上記の問題提起をしたのは、実は最近、新聞を読んでいると何故か気になるキーワードを散見するからです。「ベルトコンベア方式」に比較対象される「セル生産方式」です。
調べてみると、一般に知られる「ベルトコンベア方式」及び、「セル生産方式」は、「生産管理」という分野に属したキーワードでした。そして、生産管理の世界では今も弛みない改善と革新がされているようです。
簡単に比較すると以下の違いがあります。
振り返って考え、セル生産方式はXPやRUPといったスパイラルモデルの説明に非常に相性良く「写像」出来そうで、且つ、逆も真なりが成立しそうです。
例えば、
ベルトコンベア方式は、「同一の物を効率よく繰り返し作る技術」とされています。
ウオーターフォールモデルは、その方法論として信頼を得た原流を辿れば、大型汎用機で主な言語がCOBOLを前提にした画一的なアーキテクチャの時代から発展してきました。又、システムエンジニア/プログラマー/コーダー/パンチャと職能として「単一技能工」が夫々の職能に応じだ専門性を持ちます。（パンチャは１分間に何文字入力できるとか）
セル生産方式は、「多品種少量生産に対応する技術」とされています。
スパイラルモデルは、ヘテロな分散システムで多様なOSと言語、ミドルウエアでのシステム開発へ対応する為のソリューションとして注目されています。又、オブジェクト指向分析・設計においてプログラマが、UMLを用いた設計からオブジェクト指向言語の実装までシームレスな成果物を要求されることは「多能工」に相似します。(例えばXPに、「システムエンジニア」何ていう言葉は出てこないですよね！システムエンジニア/プログラマ/コーダー/パンチャーの職能を含んだ多能工のことをプログラマと理解する事は自然ですね。)
工場の生産管理には結構な歴史があるようです。工場の起源は18世紀フランスの兵器工場の辺りになるそうです。「分業システムの標準化」と言う意味では、テーラーが科学的管理法の原理（1911年）：作業標準について論じた論文を発表したのがさきがけとの事です。テーラーイズムとして有名です。
本論では
標準化・単純化・専門化(３Ｓ)：1908年から1927年にかけて1550万台のＴ型フォードを量産した「ベルトコンベア方式」が有名。
ジャスト・イン ・タイム・システム等が有名。1980年代以降には日米貿易摩擦に発展する程、フォードイズムに対し成果を発揮した方式。先の「セル生産方式」は、エッセンスの一部分が派生・進化して固有名称が独り立ちしたといえます。
の二つの方式それぞれが、チームが携わる「分業システム」といえる点に着目します。そして先の「ベルトコンベア方式」と「セル生産方式」の例に準じて
をメタファ(比喩)としてなぞらえ、それぞれの比較を試みます。
生産現場では、人が作業する作業ステーションを工程別に配置してラインとします。そして加工ラインは部品を加工します。組み立てラインは各加工ラインからの加工部品を組み立てます。（尚、便宜上、組み立てラインと加工ラインとしますが、加工ラインが次の加工ラインとなっている場合もあります。抽象化して後工程と前工程と読み替えて頂く事も可能です。）
フォードイズムは加工ラインと組み立てラインの間を「押し出し方式」で行っていました。
しかし「押し出し方式」には問題がありました。各加工ラインの時間当りの加工個数は異なるので、ある部品は山のように送られて来たり、他の部品は手元にまったくないといった状況が起こり得ました。
酷似した状況は、ウオータフォールモデルにも散見します。例えば、設計チームのシステムエンジニアから実装チームのプログラマへ大量のドキュメントが「押し出しされ」ますが、例えば
といった状況は経験したことがあると思います。対策はどうすべきなのでしょうか。
改善は可能かもしれませんが、本質に遡って問題に向き合っていないのではないでしょうか。
トヨタイズムに習えば「原因」より「真因」をつかんで対処する必要があります。
具体的には加工ラインと組み立てラインの間を「後工程引取り方式」にしました。
この方式を採用することでライン間の「仕掛在庫」を最適に保つことが可能になりました。
酷似したモデルを、スパイラルモデルに見て取れます。例えば、XPでは１２のプラクティスが唱えられていますが、中でも２つのプラクティスは「後工程引取り方式」になぞらえる事が可能です。
工程間には仕掛在庫が必ず存在します。そして仕掛在庫は、不良在庫・死蔵品になるリスクがあるので、プロジェクトの遂行を通じて「欠品なく最小限に保つモニタ」が常に必要です。
生産の現場ではライン間の部品の搬送担当者をマテリアル・ハンドラといいます。
例えば、本日何枚仕様書を作成しましたと、生産性という数字を上げる為だけが目的で、その時点でいつ、誰が必要なのか把握できない成果物を、（実装のストラテジーをまったく考慮せず、例えば「設計は実装に依存しない。」[3]などとして）右から左へ作るのは「つくりすぎの無駄」に分類できるのではないでしょうか。
往々にしてウオータフォールモデルで、工程毎に分断されたチームの一員には「つくりすぎの無駄」という概念が欠落しているのではないのでしょうか。チーム内での作業のみを「部分最適化」しても、後工程を含めた「全体最適化」の視点が欠けていては仕掛在庫というムダの排除はままなりません。
トヨタイズムでは、「真の能率」と「見せかけの能率」は明確に分類します。今必要で「ない」ものを、手の余ったメンバが作っておくことは仕掛在庫を作っているだけの「見せかけの能率」の向上です。これに対し、手の余ったメンバをその工程からはずし、仕掛かり在庫のたまった工程へ柔軟に配置する事は、「真の能率」の向上です。(勿論、「真の能率」向上には「多能工」化もセットとなります。)
一方、スパイラルモデルでは顧客とプログラマ、プログラマとプログラマの間ではテストケースを作成する側が、「カンバン」を持ったマテリアル・ハンドラの役割を担っているといえます。後工程が必要な仕様の「かんばん」を持っていけば「全体最適化」は、誰が計画するでもなくワークフローの仕組みとして自然に最適化の仕組みが働きます。
ちょっと一見区別しくいのですが、「ニンベン」のあるなしには取り組み方に違いがあります。
フォードイズムは作業を機械化と標準化し「自動化」を進めました。しかし自動化が単なる高速化であると、何か一寸した異常が起きた場合に不良品の山を築いてしまいます。
酷似した状況は、ウオータフォールモデルにも散見します。例えば、最終的な結合テストのフェーズは開発スケジュールのかなり後半にスケジュールされます。
一見、設計チームが成果物のフォーマットを標準化するなどして、実装チームと分業が自動化すると作業は高速化した様に感じます。しかし結合テストのフェーズで、実は仕様書が不良品の山だったので大変な思いをした経験のある方は決して少なくないはずです。
トヨタイズムは「自働化」を進めました。「ニンベンのある自動機械(automation with a human touch)は自動停止装置付機械ともいいます。機械に良し悪しを判断させる装置をビルドインされており、人間の知恵と管理の仕組みの追加をニンベンは意味します。例えば、自働化という考え方は手作業のラインでも行われ、異常時には作業者がストップボタンを押しラインを停止させることができます。ラインが停止すると「あんどん」と呼ばれる表示版が点灯し管理者・監督者が異常確認・原因対策を最優先に徹底して行います。他にも不良品を出さない為に冶工具・取付具に工夫を施した「ポカヨケ」等、「にんべん」に係わる工夫がワークフローの中に組み入れられています。
酷似したモデルを、スパイラルモデルに見て取れます。例えば、XPの２つのプラクティスは「自働化」になぞらえる事が可能です。
テストファ-ストの原則やｘUnit等によるテストの自「働」化は、機械に良し悪しを判断させる装置をビルドインすることと相似です。開発者がチェックインの前にxUnitテストを心がけることは「ポカヨケ」の実践で、また継続的インテグレーションでマスタビルドが壊れた場合のチームが行う対処は、まさに「あんどん」に相似です。
如何でしょうか。アナロジは単なる言葉の言い換えの遊びかもりれません。しかし私たちはベルトコンベア方式に代表されるフォードイズムとウオータフォールモデルの開発との間のアナロジについては無意識にそのまま受け入れるていないでしょうか。もしそうであれば、トヨタイズムとスパイラルモデルの間に無理なくアナロジが成立すると思うのは著者だけでしょうか。
また、フォードイズムでは官僚的なイメージと、機械の都合に人が合わせざるおえない時代の方式の印象が拭えません。逆にトヨタイズムでは「人ならではの能力を十分発揮させる仕組みとして自働化は人にやさしい」といった印象を受けます。こうした点はXPの，「プログラマは人間である」という温かな視点による思想が全体を通して流れていることとの間に共通点を見出させます。
工作機械やベルト・コンベヤーの稼動率を上げる事が至上命題になると、人は「真の能率」について熟慮することを止ざるおえません。担当した工程の機械に使われて、「見せかけの効率」に目標管理された状態になります。
振り返りソフトウエア開発も、希少な資源であったコンピュータ・リソースに係る費用と、開発者の人件費の関係は1970年代から大きく変わっています。昔にさかのぼれば開発者はコンピュータの都合に合わせて使われていました。
例えば
そうした時代に構造化設計とウオータフォールモデルは唱えられました。例えば、「ソフトウエア工場」という発想はフォードイズムを参考にしていたのかもしれません。「 計画と実行の分離
」に重きが置かれた時代、フードバック系のネットワークが切断されている点も、皮肉な事に相性がよかったのでしょうか。ともあれ、選択肢に広がりのない、限られた時代にはウオータフォールモデルはそれなりの効果と実績を上げてきました。
しかし今では開発チームがコンピュータ・リソースを潤沢に使うことが可能です。
例えば、「プロトタイプ宣言が可能な言語」での開発で机上デバックをする人は殆ど見かけません。机上デバックの大半は単純な書き間違いチェックに費やされる事も多く、しっかり型保証を行う言語の「コンパイラ」でその作業の大半を代替できます。（そうでない場合はリファクタリングが必要なケースではないでしょうか。）
いまではそれどころか分析・設計で抽出した概念を型システムとして「コンパイラにクラス宣言」してチェックさせる事もオブジェクト指向言語で当たり前に行われ、その事がコンピュータ・リソースの問題になることはありません。その上、開発者がｘUnitを動作させテストを行うローカル環境を「各自で」構築することも可能な程、コンピュータ・リソースは潤沢です。また、開発プロジェクトでネットワーク上にバージョン管理システムを導入して、頻繁にマスタービルドを作成して継続的インテグレーションをするコンピュータ・リソースの確保も容易に出来ます。
まさに「人ならではの能力を十分発揮させる仕組み」を開発プロセスに組み込む環境は整いました。しかしトヨタイズムの「人にやさしい自働化」に相当する改善を、ウオータフォールモデルままの心構えで望めるでしょうか。
現在のボトルネックは、コンピュータ・リソースではなく、人がいかに共同・分担を進めて問題解決するかの方法の改善が問題です。顧客の要件を、如何に短期間でテスト・検証して顧客の確認まで済ませるかが問われています。その解決策の一つとして、スパイラルモデルの開発を検討する価値は十分にあります。（勿論、まだまだプロジェクト毎にカスタマイズを試行錯誤する努力の余地も多い訳ですか。）
先ずは、プロジェクト管理者が発想を転換して、各工程（分析・設計・開発・テスト）の各成果物は（次のフェーズが開始されるまでは、）あくまでただの「仕掛在庫」でしかないと認識すべきではないのでしょうか。決してプロジェクトの「進捗」を表す成果指標ではありません。仕掛在庫は「カンバン方式」の例をあげるまでもなく最小にすべきで、次の工程にいつ流せるのかが重要です。その上で在庫量が各工程間でバラツキがある事が「リスク」と認識する必要があるのではないのでしょうか。
開発の効率は、仕掛在庫の総和ではなく、成果物の鎖（チェーン）で考える必要があります。仕掛在庫が滞留するボトルネックを発見し、そこへのリソース投入を強化すれば全体の流量を上げることができます。全体を看ずに部分的に生産性をあげても、全体としてはむしろ効率が下がることになりかねません。あくまで「必要数＝生産量」でなくてはなりません。ボトルネックがシステム全体の生産能力を決めるのだから、ボトルネックに合わせて作ればよいのです。（例えば、 分厚すぎる「ドキュメント」 がいい例だと思うのは私だけでしょうか？）
つまりトヨタイズムの本質は工程間の成果物の流れに着目します。仕掛在庫は「作りすぎの無駄」です。工程間で欠品があっては困りますが、どこかの工程に仕掛在庫が集中して滞留しないように「生産の平準化」をはかります。要件を、機能やストーリーといった単位にどう分割して、それをどの順番で次の工程へ流すのかをスケジュールする事と共に、各工程間の「仕掛在庫量」も十分に監視・コントロールする必要があるのではないのでしょうか。
知らず知らずに刷り込まれた「常識」という贅肉にいつも疑問を持てるか。というのは大抵の人や組織が年を重ねる毎に保守的になることを考えれば、「これは大きな命題だなあ。」と最近ひしひし感じます。
その上で、（日本の製造業の凋落ぶりを耳にする機会が多い訳ですが、それでも）「セル生産方式」の話などを聞くと、世界を席捲した組織に「常識に兆戦する遺伝子」は残っているんだなと思うわけです。振り返り、日本のソフトウエア産業などは、まだまだそこから学ぶ点が多いのではないのかと感じる訳です。ソフトウエア開発技術は残念ながら英語圏から技術導入している黎明期の産業であることを意識せざるおえません。
しかし本稿では、日本人技術者の生産現場から生まれたトヨタイズムに注目して、スパイラルモデルに相似なのでないかと問題提起を試みました。もしそうあるならば、本来、スパイラルモデルこそ我々にあった開発の進め方なのではないでしょうか。[2] ウオーターフォールモデル守旧派の皆様、そろそろ製造業では「２０年前に捨てられた実践」となった常識に見切りをつけてもよろしいのではないのでしょうか。先ずは積極的に代替手段の活発な提案を精査して、「西洋かぶれ」の卒業を目指しましょう。その上で「和魂洋才」からはじめようではありませんか。
常識を「創造的破壊」するのは自分たちの手に委ねられているはずです。組織や集団は勿論、開発プロセスについても年齢があり、発達をとげ、しだいに硬直への途を進むことは避けられません。本稿が開発プロセスの常識へ挑戦する為の「跳び箱の踏み切り」になれば幸いです。
[脚注]
[1] マイクロソフト・シークレット 勝ち続ける驚異の経営 日本経済新聞社
同期安定化プロセスの特徴は、毎日のビルドと中間目標の設定で、言い換えるとXPの「継続的インテグレーション」や「小さなリリース」に相当します。これが1995年当時から組織的に実践されていたことに驚きを隠せません。
[2] XPもRUPといったスパイラルモデルも英語圏から技術導入には違いありませんね。
XPの生みの親、Kent Beck氏がトヨタイズム影響を受けているのか、大野耐一氏の文献に目を通した事があるのか、といったことは興味があります。又、トヨタ生産方式のジャスト・イン ・タイム・システムに比較されるTOC （Theory of Constraints；制約理論または制約条件の理論）の影響を受けているのかも機会があれば聞いて見たいですね。TOCの方が英語圏では豊富な資料があるのかな？
[追申] XP＆アジャイルプロセスセミナー に参加しました。公演の中で本人が 大野耐一 氏の名前や、小説「 ザ・ゴール 」を紹介していました。
[3]「設計は実装に依存しない。」
いやいや、構造化設計ベテランの業務SEさん、従来の常識はそうでしたけれども根本的な再認識が必要なのでは？
オブジェクト指向設計にのぞむに当たり、「言語は思考を制限する。」（言語相対仮説 {サピア・ウォーフ仮説]）事を認識して、そこ点を設計の「宣言的側面」に積極的に取り入れる、発想の転換が必要ではないのでしょうか。
言語相対仮説は、学者の間では議論の分かれる「仮説」扱いらしいのですが、「プログラミング言語C++」の中で、Ｂｊａｒｎｅ Ｓｔｒｏｕｓｔｒｕｐが序章で引用されていた事がとても印象に残っています。
もし、開発が既存の膨大なフレームワークを「再」利用して進めるメリットを得たいとします。その場合、名詞(≒Class)と、動詞(≒Method)を拡張（派生クラスの作成とメソッドのオーバーライドを）して問題記述（システムの記述）を行うことになります。その過程でフレームワーク（≒言語体系）には、自ずと守るべき枠組みの「制約（≒型システム）」がある事を知る必要があります。設計はその制約の実装に依存「すべき」です。再利用の恩恵を受けたいのであれば、その事を謙虚に受けれ学ぶ姿勢が必要なのではないのでしょうか。
（例えば、犬が飛ぶ。/机が歩く。が、コンパイルエラーになる枠組みを守った拡張の設計が必要。設計は実装に依存しないので犬も飛べた方/机も歩いた方が、便利なんじゃない。といっで許されるのでは構造化設計と変わりありません。）
[参考文献/参考URL]
状況のインターフェース 金子書房トヨタ生産方式 -脱規模の経営を目指して- 大野耐一 タイアモンド社
空間・技術・分業システム再編成としての標準化 川床靖子
-アメリカの部品製造工場におけるトヨタ生産方式の導入-