製造業における品質というのは、多くの場合は生産工程におけるブレのことをいいます。Wikipediaにによるとシックスシグマとは、次のようなもの。
6σの状態とは、ある製品組立工程の品質特性値が正規分布に従うと仮定するならば、6σの外に出る確率は、100万分の3.4である。すなわち、ある工程では100万個製品を組み立てて3.4個のばらつき(不良品)が生じる。「100万回作業を実施しても不良品の発生率を3.4回に抑える」ことへのスローガンとしてシックス・シグマという言葉は使われ、定着していった。
システムでの生産とはランタイム
ではシステムでいう生産工程はどこのことでしょうか?ふつうは実装と思われがちですよね。でも、製造業における生産とは「同じ作業を繰り返し行うこと」という前提があります。だからこそ、そこで不良品が出る割合を抑えようと考えるのです。では、システムでいう生産工程とはどこか。それは、いわゆるランタイムのことを指すと考えることができます。メソッドで呼ばれて答えを返す。何回も何回も同じことを繰り返します。
こう考えるとシステムでは生産工程で不良品が発生することは基本的にあり得ません。デジタルというのはそういうものです。
システムに不良品は存在しない
何が言いたいかというと製造業で使われている品質向上のメソッドをシステム開発の実装工程に持ってくると、実はうまく適用できない可能性があるということです。いや、品質向上に限りません。製造業の生産工程に関するあらゆるノウハウについて疑問を持つべきなのです。
システム開発は情報産業に属しています。情報産業の特徴は情報のデジタル化です。デジタル化された情報はスケールフリー、スモールネットワークなどの特徴をもつようになり、いわゆる製造物とはまったく異なるものです。これは意外に忘れられがちなことです。製造のメタファーが強すぎるがゆえに、その呪縛から逃れられない。「このシステムは不良品だ」という言葉は奇妙なのです。だって、そのシステムの「優良品」は存在しないのですから。
法則がなければシミュレーション技術は使えない
では、システム開発は製造業に学ぶことができないのか。製造業でも繰り返さない作業があります。それが設計行程です。製造業の設計工程の品質向上策は役立つでしょうか。
製造業の設計工程で最も効果を上げたのがCADなどの設計技術です。これはシミュレーション技術です。シミュレーションは生産前に出来上がりを確認するための有効な手法です。高機能になれば各パーツの耐性や剛性を計算することで重力や衝突に耐えられるかまで確認することができます。
CADで使うモデルは世界の物理法則を表現しています。ユークリッド幾何学とかニュートン力学とか、ようは理想の世界を作りだしています。その理想の世界が使えるのは現実世界との誤差が小さいのです。だからこそ、ある値に保たれているかどうかといったテストが可能になります。
一方、システム開発で扱うのは情報です。情報をモデル化したものはCADのモデルとは意味が違います。なぜなら、情報には唯一の法則が存在しえないからです。情報は解釈によって違う。同じ言葉でも人によって受け取り方が違うのは当たり前ですね。こうしたモデルでは値を利用したテストを行うことができません。どんな値だと問題なのかが機械的には分からないのです。
話がそれますが、単体テストがコードによってしか行えないのはテスト対象コードが一般的な尺度で検査することができないからです。OK/NGが人間にしか分からないから、それぞれのコードごとに値をエンジニアが決めていかないといけない。静的メトリクス分析やカバレッジが有効ですが完璧ではないことは有名でしょう。
ようはシステム開発でのモデルは、その情報の受け取り方の誤差を調停する道具としてしか使えないのです。
設計通りに作れないのが当たり前
じゃ、システム開発で品質を上げるためにはどうしたらいいのか。これにはまったく新しい視点が必要だと思っています。少なくとも「設計通りに不良品を作らないことが品質の高さ」という呪縛からは逃れないといけない。
明確なのは「仕様や設計に矛盾がないことはありえない」ということです。実装してみて分かる矛盾は必ずあります。そのフィードバックをなるべく早い段階で行うことが重要です。そもそも設計通りに作れないのが当たり前なのです。
皆さん、仕様変更も設計書の変更も普通にやってますよね?「それじゃ実装できない」って。それは、すごく正しいことなのです。
長くなったので、この続きはまた。

コメント (2)
シックス・シグマの紹介でそこだけ引用するのはどうかと思う。
(まあ、そこがキャッチーな部分ではあるので取り上げたいのは分かる)
影響力のあるブログなんでだから、取り上げるのならもっとまともに取り上げて欲しい。
>システムでの生産とはランタイム
その論の組み立ては個人的には納得できなかった。製造業のパラダイムに(他の建築業のパラダイム然り)
むりやり押し込んでから、「では、システム開発は...」だと、いつまでたっても前進できない。
他のパラダイムを否定するわけでも無視したいわけもないのだが、引きずる必要はまったくないと思う。
>ようはシステム開発でのモデルは、その情報の受け取り方の誤差を調停する道具としてしか使えないのです。
残念ながら現在はそうですね。成熟度としては5段階評価で1ぐらいで、成熟すればシュミレーション技術は
使えるものと信じています。オントロジー,形式仕様記述,RDF,OWL,SPARQL... この辺りブレークスルーが進めば成熟度が上がっていくと期待しています。
>設計通りに作れないのが当たり前
それをあなたが言っていいの?身も蓋もないよw
品質のスコープを宣言してから論を展開するとよいと思いました。
私も最近、まじめに品質について考えているからこそ、気になって思わずコメントを書いてしまいました。
回転の速い頭をさらに高速回転させて、品質についてブレークスルーしてもらいたいと思っています。
期待しています。
投稿者: さやべえ | 2007年12月16日 00:10
日時: 2007年12月16日 00:10
さやべえさん、コメントありがとうございます。品質のスコープを宣言せよとの指摘、そのとおりです。「工業のパラダイムを引きずるな」というのはまったく同意見。
>設計通りに作れないのが当たり前
言っていいと思いますよ。身も蓋もなく本当のことですから。では、その精度を上げるためにはどうしたらよいか、というのが解決の道だと思っています。
ブレイクスルーするアイデア、ぜひ一緒に考えてください。
投稿者: yusuke | 2007年12月16日 16:18
日時: 2007年12月16日 16:18