常識に挑戦してますか。-心理的抵抗の緩和に向けて「和魂洋才」の奨め-秋山朋之2002/08/18 [初版] 2004/05/27 [改訂]
|
最近、 エクストリーム・プログラミング(eXtreme Programming：以降XP）を筆頭に開発プロセスの話題を多く聞きます。いよいよウォーターフォールモデルから「アジャイル」な開発モデルへ世代交代の期待が出来そうです。いままで、ウォーターフォールモデル以外の開発方法では「同期安定化プロセス」[1]がビジネスの世界で１人勝ちの成果をあげているのを横目で見てはいました。しかし、現実に携わるプロジェクトではウォーターフォールモデル以外の方法論の選択や実践が難しかったのです。開発プロセスの見直しをする事があっても、従来からの「常識」とされている手堅い方法をプロジェクト毎に部分的に工夫するという範囲でした。しかしプロジェクト遂行の方法論としてアジャイル・プロセスの導入タイミングはオブジェクト指向技術の普及と共にまさに機は熟した感があります。今ではウォーターフォールモデル守旧派の立場の方へも一般的に認知が進んだ方法論や適応事例を例示することが可能です。（あとは現場の行動あるのみですね。） 方法論詳細は随分紹介されていますので、ここではアジャイル・プロセスに踏み切る為の問題の１つ、従来の常識を変更するのに伴う「心理的抵抗」を緩和する為、（殆どの皆さんとその周りの方々が）共有していると思われる１つの「常識」に遡って考えたいと思います。
多人数で問題解決を行う場合、適切な作業分担の「常識」として「ベルトコンベア方式」のイメージがあります。T型フォードの成功例を誰もが連想します。そしてソフトウエアの開発においても、この常識を(安易に)そのまま持ち込んだモデルがウォーターフォールモデルといえるのではないでしょうか。プロジェクト管理者が工程管理を行い、システムエンジニア＞プログラマー（＞コーダー＞パンチャー）へと作業を分担する事が、効率の良く管理・制御された開発の「常識」とされています。 しかし自動車産業が生まれた一世紀も前の「ベルトコンベア方式」の考え方は、今でも工場生産の現場で現役で主役のままの「常識」なのでしょうか。改良されていたり、他の方式は考案されていないのでしょうか。もし他の方式があれば、その新しい「常識」を、アナロジー（類推）としてわれわれソフトウエア業界の開発プロセスへそのまま転用できるかもしれません。
上記の問題提起をしたのは、実は最近、新聞を読んでいると何故か気になるキーワードを散見するからです。「ベルトコンベア方式」の比較対象とされる「セル生産方式」です。
振り返って考え、セル生産方式はXP等のアジャイル・プロセスの説明に非常に相性良く「写像」出来そうで、且つ、逆も真なりが成立しそうです。
工場の生産管理には結構な歴史があるようです。工場の起源は18世紀フランスの兵器工場の辺りになるそうです。「分業システムの標準化」と言う意味では、テーラーが科学的管理法の原理（1911年）：作業標準について論じた論文を発表したのがさきがけとの事です。テーラーイズムとして有名です。 本論では、下記の二つの方式それぞれが、チームが携わる「分業システム」といえる点に着目します。
をメタファ(比喩)としてなぞらえ、それぞれの比較を試みます。
生産現場では、人が作業する作業ステーションを工程別に配置してラインとします。そして加工ラインは部品を加工します。組み立てラインは各加工ラインからの加工部品を組み立てます。（尚、便宜上、組み立てラインと加工ラインとしますが、加工ラインが次の加工ラインとなっている場合もあります。抽象化して前工程と後工程と読み替えて頂く事も可能です。） フォードイズムは加工ラインと組み立てラインの間を「押し出し方式」で行っていました。
しかし「押し出し方式」には問題がありました。各加工ラインの時間当りの加工個数は異なるので、組み立てラインへある部品は山のように送られて来たり、他の部品は手元にまったくないといった状況が起こり得ました。 酷似した状況は、ウォーターフォールモデルにも散見します。例えば、設計チームのシステムエンジニアから実装チームのプログラマへ大量のドキュメントが「押し出しされ」ますが、例えば
といった状況は経験したことがあると思います。対策はどうすべきなのでしょうか。
改善は可能かもしれませんが、本質に遡って問題に向き合っていないのではないでしょうか。
「後工程はお客様」という意識の上に、必要なモノを必要なタイミグで供給する、この方式を採用することでライン間の「仕掛在庫」を最適に保つことが可能になりました。 酷似したモデルを、アジャイル・プロセスに見て取れます。例えば、XPでは１２のプラクティスが唱えられていますが、中でも２つのプラクティスは「後工程引取り方式」になぞらえる事が可能です。
工程間には中間製品の仕掛在庫が必ず存在します。そして仕掛在庫は、不良在庫・死蔵品になるリスクがあるので、工程間の成果物の流れを見渡して「欠品なく最小限に保つモニタ」が常に必要です。 例えば、本日何枚仕様書を作成しましたと、生産性という数字を上げる為だけが目的で、いつ、どこの誰が必要なのか把握しない成果物を、右から左へ作るのは「つくりすぎの無駄」に分類できるのではないでしょうか。 往々にしてウォーターフォールモデルで、工程毎に分断されたチームの一員には「つくりすぎの無駄」という概念が欠落しているのではないのでしょうか。チーム内での作業のみを「部分最適化」しても、後工程を含めた「全体最適化」の視点が欠けていては仕掛在庫というムダの排除はままなりません。 トヨタイズムでは、「真の能率」と「見せかけの能率」は明確に分類します。今必要で「ない」ものを、手の余ったメンバが作っておくことは仕掛在庫を作っているだけの「見せかけの能率」向上です。これに対し、手の余ったメンバをその工程からはずし、仕掛かり在庫のたまった工程へ柔軟に配置する事は、「真の能率」の向上です。(勿論、「真の能率」向上には「多能工」化も一緒に進める事が必要となります。) 「手待ち」のメンバを「離れ島」から発見して「人集め」を行い、「仕事集め」をした上で「ムダ集め」をすることで「少人化」が可能とも説かれています。 そうした意味ではテスト駆動開発の採用は、顧客とプログラマの間でテストケースを作成するので、ウォーターフォールモデルでの後工程側が、「カンバン」を持っているといえます。そして必要な仕様が記述された「カンバン」は、無駄のない「清流化」したワークフローとして自然に最適化の仕組みが働きます。
ちょっと一見区別しくいのですが、「ニンベン」のある/なしには、その取り組み方に違いがあります。 フォードイズムは作業を機械化と標準化し「自動化」を進めました。しかし自動化が単なる高速化であると、何か一寸した異常が起きた場合に不良品の山を築いてしまいます。 酷似した状況は、ウォーターフォールモデルにも散見します。例えば、最終的な結合テストのフェーズは開発スケジュールのかなり後半にスケジュールされます。
一見、設計チームが成果物のフォーマットを標準化するなどして、実装チームと分業が自動化すると作業は高速化した様に感じます。しかし結合テストのフェーズで、実は仕様書が不良品の山だったので大変な思いをした経験のある方は決して少なくないはずです。 トヨタイズムは「自働化」を進めました。「ニンベンのある自動機械(automation with a human touch)は自動停止装置付機械ともいいます。機械に良し悪しを判断させる装置をビルドインされており、人間の知恵と管理の仕組みの追加をニンベンは意味します。自働化という考え方は、例え手作業のラインであっても徹底され、異常時には作業者がストップボタンを押しライン全体を停止させることができます。ラインが停止すると「あんどん」と呼ばれる表示版が点灯し、管理者・監督者は異常確認・原因への対策を最優先のプライオリティで復旧作業を行います。又、他にも不良品を出さない為に冶工具・取付具に工夫を施した「ポカヨケ」等もあります。まさに「にんべん」に係わる工夫がワークフローの中に組み入れられています。 酷似したモデルを、アジャイル・プロセスに見て取れます。例えば、XPの２つのプラクティスは「自働化」になぞらえる事が可能です。
テストファ-ストの原則やｘUnit等によるテストの自「働」化は、機械に良し悪しを判断させる装置をビルドインすることと相似です。開発者がチェックインの前にxUnitテストを心がけることは「ポカヨケ」の実践で、また継続的インテグレーションでマスタビルドが壊れた場合のチームが行う対処は、まさに「あんどん」に相似です。
如何でしょうか。アナロジは単なる言葉の言い換えの遊びかもりれません。しかし私たちはベルトコンベア方式に代表されるフォードイズムとウォーターフォールモデルの開発との間のアナロジについては無意識・無条件にそのまま受け入れるていないでしょうか。もしそうであれば、トヨタイズムとアジャイル・プロセスの間に無理なくアナロジが共有可能な形式知として成立すると思うのは著者だけでしょうか。 また、フォードイズムでは官僚的なイメージと、機械の都合に人が合わせざるおえない時代の進め方という印象が拭えません。逆にトヨタイズムでは「人ならではの能力を十分発揮させる仕組みとして自働化は人にやさしい」といった印象を受けます。こうした点はXPの，「プログラマは人間である」という温かな視点による思想が全体を通して流れていることとの間に共通点を見出させます。
人は、工作機械やベルト・コンベヤーの稼動率を上げる事が至上命題になると、「真の能率」について熟慮することを止ざるおえません。担当した工程の機械に使われて、「見せかけの効率」を目標管理にしてしまいます。 例えば
そうした時代に構造化設計とウォーターフォールモデルは唱えられました。例えば、「ソフトウエア工場」という発想はフォードイズムを参考にしていたのかもしれません。「 計画と実行の分離
」に重きが置かれた時代、フィードバック系のネットワークが切断されている点も、皮肉な事に相性がよかったのでしょうか。ともあれ、選択肢に広がりのない、限られた時代にはウォーターフォールモデルはそれなりの効果と実績を上げてきました。 いまではそれどころか分析・設計で抽出した概念を型システムとして「コンパイラにクラス宣言」してチェックさせる事もオブジェクト指向言語で当たり前に行われ、その事がコンピュータ・リソースの問題になることはありません。その上、開発者がｘUnitを動作させテストを行うローカル環境を「各自で」構築することも可能な程、コンピュータ・リソースは潤沢です。また、開発プロジェクトでネットワーク上にバージョン管理システムを導入して、頻繁にマスタービルドを作成して継続的インテグレーションをするコンピュータ・リソースの確保も容易に出来ます。 まさに「人ならではの能力を十分発揮させる仕組み」を開発プロセスに組み込む環境は整いました。しかしトヨタイズムの「人にやさしい自働化」に相当する改善を、ウォーターフォールモデルままの心構えで望めるでしょうか。 現在のボトルネックは、コンピュータ・リソースではなく、人がいかに共同・分担を進めて問題解決するかの方法の改善が問題です。顧客の要件を、優先度をつけた上で如何に分割/分類し、どの順番で短期間でテスト・検証して顧客の確認まで済ませるかが問われています。その解決策の一つとして、アジャイル・プロセスの開発を検討する価値は十分にあります。（勿論、まだまだプロジェクト毎にカスタマイズを試行錯誤する努力の余地も多い訳ですか。） 先ずは、プロジェクト管理者が発想を転換して、各工程（分析・設計・開発・テスト）の各成果物は（次のフェーズが開始されるまでは、）あくまでただの「仕掛在庫」でしかないと認識すべきではないのでしょうか。成果物などという名前がいけません。ましてや決してプロジェクトの「進捗」を表す成果指標ではありません。仕掛在庫は「カンバン方式」の例をあげるまでもなく最小にすべきで、次の工程にいつ流せるのかが重要です。管理者はライン・バランシングの気配りが必要なのではないのでしょうか。その上で在庫量が各工程間でバラツキがある事が「リスク」と認識する必要があるのではないのでしょうか。 開発の効率は、仕掛在庫の総和ではなく、成果物の鎖（チェーン）で考える必要があります。仕掛在庫が滞留するボトルネックを発見し、そこへのリソース投入を強化すれば全体の流量を上げることができます。全体を看ずに部分的に生産性をあげても、全体としては（工程間に中間製品状態の仕掛在庫を滞留させて）むしろ効率が下がるだけでなく、プロジェクトがハイ・リスクな状態になることになりかねません。あくまで「必要数＝生産量」でなくてはなりません。ボトルネックがシステム全体の生産能力を決めるのだから、他の工程はボトルネック工程に従属して作ればよいのです。[4]（例えば、「分厚すぎる「ドキュメント」 がいい例だと思うのは私だけでしょうか？） つまりトヨタイズムの本質は工程間の成果物の「流れ」に着目します。仕掛在庫は「作りすぎの無駄」です。工程間で欠品があっては困りますが、どこかの工程に仕掛在庫が集中して滞留しないように「生産の平準化」をはかります。要件を、機能やストーリーといった単位にどう分割して、それをどの順番で次の工程へ流すのかをスケジュールする事と共に、各工程間の「仕掛在庫量」も十分に監視・コントロールする必要があるのではないのでしょうか。
知らず知らずに刷り込まれた「常識」という贅肉にいつも疑問を持てるか。というのは大抵の人や組織が年を重ねる毎に保守的になることを考えれば、「これは大きな命題だなあ。」と最近ひしひし感じます。 その上で、（中国の躍進と比較されて、、日本の製造業の凋落ぶりを耳にする機会が多い訳ですが、それでも、）「セル生産方式」の話などを聞くと、世界を席捲した組織に「常識に挑戦する遺伝子は残っているんだな。」と実感します。振り返り、日本のソフトウエア産業などは、まだまだそこから学ぶ点が多いのではないのかと感じる訳です。ソフトウエア産業はその開発技術を例に考えても、残念ながら英語圏から技術導入している黎明期の産業であることを意識せざるおえません。 しかし本稿では、日本人技術者の生産現場から生まれたトヨタイズムに注目して、アジャイル・プロセスに相似なのでないかと問題提起を試みました。もしそうあるならば、本来、アジャイル・プロセスこそ我々にあった開発の進め方なのではないでしょうか。[2] ウォーターフォールモデル守旧派の皆様、そろそろ製造業では「２０年前に捨てられた実践」となった常識に見切りをつけてもよろしいのではないのでしょうか。先ずは積極的に代替手段の活発な提案を精査して、「西洋かぶれ」の卒業を目指しましょう。その上で「和魂洋才」からはじめようではありませんか。 常識を「創造的破壊」するのは自分たちの手に委ねられているはずです。組織や集団は勿論、開発プロセスについても年齢があり、発達をとげ、しだいに硬直への途を進むことは避けられません。本稿が開発プロセスの常識へ挑戦する為の「跳び箱の踏み切り」になれば幸いです。
[1] マイクロソフト・シークレット 勝ち続ける驚異の経営 日本経済新聞社
[2] XPもRUPといったアジャイル・プロセスも英語圏から技術導入には違いありませんね。
[3]「設計は実装に依存しない。」
[4] トヨタイズムとは、差異もあるわけですがＴＯＣの「ドラム・バッファ・ロープ」の考え方とも着眼点が近似していると思います。
[参考文献/参考URL]
ObjectClub ML : 参考にさせていただいております。 |
ご指摘頂いた皆様、ありがとうございました。さらに推敲を重ねてよい文章に「カイゼン」していきたいと思います。