先ほどのエントリを最後にしようと思っていたのですが、トヨタ信奉への違和感へのnakagomeさんからのコメントが秀逸だったので。
自動車産業の製造というのは、金型作った後にやることで、何千、何万という製品を、殆ど機械的に複製することを指す。これは、ソフトウェア産業でいえば、コンパイルやビルド、または媒体コピーなどに相当するものだ。しかし、ソフトウェア産業で製造と呼ばれるのは一般に、原始コードを書いたりすることなどを指している。自動車産業でいえば、むしろ金型を作るまでの部分に似ている。デザインの延長であって、知的で創作的で、かつ技芸的な要素の色濃い作業なのだ。
これを行灯で何とかしようとすることをナンセンス以外になんと形容できようか。
この問いかけは真剣に考えるべきことです。確かに製造業における品質向上や効率化は確実に先を行っていますし、積み重ねられてきた実績も大きい。でも、それがITにおいても同じか、というのは違うことだと感じます。
製造業の品質がブレの許容であることは品質についての気づきで、効率化を突き詰めると中央集権型に陥ることはSIerにあるべき組織とはで紹介しました。短絡的に品質は効率を求めると、どうしても製造業のメタファーが邪魔になりITとしての視点が薄れているように思われます。
ではIT、局所的にはシステム開発が品質向上や効率化を行うとしたらどうすればいいのか。
結果論めいたことでいえば人月を超えるということにつながります。情報財は農業の田んぼや製造業のラインと異なり、スケールフリー（無限にシェアできる）なのです。
「デジタル化された情報財」は共有されたがっている。だから共有できるように作ってあげなくてはいけない。SIの一品生産が不毛なのはデジタルのスケールフリー性を無駄にしているのから。
そこから抜け出したければ、なるべくコモンズ（共有財）にしていかなくはいけない。そして、ラストワンマイルだけを自分たちで組み立てる。すべてを自分たちでつくる能力ではなく、他人の能力も巻き込んで、それを組立ててサービスとして提供する能力が求められているのです。
ここにおける品質や効率の議論は非常に興味深いものです。目の前の作業をいくら早く正確にしても意味がない。逆に世界規模で考えて共有可能なものにならないといけない。そのほうがスケールするから。例えばStrutsの品質や効率をどの視点で考えればいいのか。
コモンズなんかで儲けられるのかって？そんな人は栗原さんが邦訳したオープンビジネスモデル 知財競争時代のイノベーションをご覧あれ。いくらでも事例が載っていますよ。特許の意味が変わってきたことがよくわかります。知財をどうマネージメントするかを考えるというのは、グローバルな俯瞰した視点でこの情報に価値があるのかを考えること。とても大事なことです。
この転換を理解できるかどうかで仕事の質が大きく変わります。レバレッジが効く仕事というのは、どの視点に立っているかで決まるのです。世界中の人と未来に渡って共有できるのか。
それにしても、もう沢山の本が出ているのですよ。似たようなこと言っている人はいくらでもいる。IT業界の人が、一番ITリテラシが低いのではないかと思ってしまいます。
でもね、ITに近い人は強いはずなんです。情報をどう扱うべきかをきちんと理解している人。そういう人が、もっともっと現実の世界で活躍できないと。手を動かして作ろう、そして新しいことを創ろう。2008年、変化をもっともっと楽しまないと！
 | オープンビジネスモデル 知財競争時代のイノベーション (Harvard Business School Press) ヘンリー・チェスブロウ Henry Chesbrough 諏訪 暁彦 翔泳社 2007-11-20 by G-Tools |
コメント (2)
「自動車製造業の製造工程はソフトウェア開発のビルド工程に相当するので、それを参考にすることはあまり意味がない」というのには違和感を感じます。
ソフトウェア開発の文脈でトヨタ生産方式を取り上げている方々は、あくまでも「ソフトウェア製造＝自動車のデザイン工程」というのを理解したうえで、適用可能・効果がありそうなものを部分的に取り入れているのだと考えています。
今手元にトヨタ生産方式の本がないので不正確かもしれませんが、確かトヨタでは月別で生産台数指示が決定されて、それに基づいて組み立てが行われるという記述があったと記憶しています。これをソフトウェアに適用すれば、あるリリース（1ヶ月のタイムボックス等）に含める機能セットがまず決定されるということに相当すると思います。
次に生産目標にしたがって組み立てを行い、それに必要な部品の生産指示が「かんばん」として前工程に送られます。これを強引に解釈すれば、例えば機能セットを確認するための機能テストを作成し「このテストに通るものを作ってくれ」と前工程に指示を出すことに相当するのではないかと考えられます（全ての機能をテストによって完全に定義できるというかなり非現実的な前提ですが）。この場合「かんばん＝機能テスト」となります。
これを繰り返していくと、自動車であれば細かいパーツの生産指示に行き着き、ソフトウェアの場合はユニットテストを通すためのコード断片の作成へと逆伝播していく……というモデルが考えられます。
かなり強引・非現実的な理想モデルではありますが、トヨタ生産方式をソフトウェアの開発工程で生かす道もあるのではないかと考えています。もっとも自動車製造の場でないと意味がないようなものもいろいろあった気はしますが。
私の解釈が間違っていたらすいません。
投稿者: Lizy | 2008年01月01日 03:08
日時: 2008年01月01日 03:08
Lizyさん、コメントありがとうございます。
おっしゃる通り、トヨタ生産方式を参考にすることに意味がない、というわけではありません。
トヨタ生産方式から学ぶべきことが手法（カンバンなど）だと思ってしまうのは視野が狭いのでは、という問いかけです。
製造業とソフトウェア開発はまったく違うという前提に立つことで新しい示唆が得られないのか？「トヨタのカンバン方式」ぐらいプロセス化された手法がIT業界で作れないのか？
トヨタ生産方式に注目するのであれば、手法に効果があるとか適用可能かという以前に、トヨタ生産方式自身が体系化されるに至った組織の在り方や取り組みにもっと注目をしていくべきだと思います。
投稿者: yusuke | 2008年01月01日 20:01
日時: 2008年01月01日 20:01