ものづくり戦略とソフトウェア品質

記事をお読みいただく前にお知らせがある。インターネット書店のアマゾンで『組込みソフトエンジニアを極める』の 「なか見！検索」ができるようになった。

「なか見！検索」とは、アマゾンのWEBサイト上で書籍のページをぱらぱらめくったり、書籍の中身に対して全文検索できるサービスである。（アマゾンのWEBサイト内でアカウント認証していることが条件になっている）

このサービスは著者にも便利なサービスだ。たとえば「状態遷移」について書いたところを探したいなと思ったら、「なか見！検索」の検索バーに“状態遷移”と打ち込んでリターンキーを押せば、11ヶ所で使っていることがわかる。是非、こちらで試してみて欲しい。

さて、今回のテーマは『ものづくり戦略とソフトウェア品質』である。9月14日、15日、東京お台場のTFTビルで日科技連主催の－ソフトウェア品質シンポジウム－が開催された。このシンポジウムでは何人もの著名な方々が講演されているが、特に印象に残ったのが、広島市立大学情報学部教授 大場充先生の「ソフトウェアのテストと品質保証」と、東京大学大学院経済学研究科教授 兼 ものづくり経営研究センター長 藤本隆宏先生の「ものづくり論とソフトウェア－組織能力とアーキテクチャの視点から－」の2コマだ。

大場先生はソフトウェアテスト・品質保証の専門家で、米国IBMや日本アイ・ビー・エムで培われた実践的なソフトウェア品質保証の話をしてくれる。藤本先生は日本の製造業を生産の現場を中心に調査し、日本の製造業（特に自動車製造）の組織論、ものづくりの優位性について研究されている。

お二人の代表的な著書は大場先生は『ソフトウェアプロセス改善と組織学習―CMMを毒にするか?薬にするか?』、藤本先生は『日本のもの造り哲学』などがある。

大場先生も藤本先生もそれぞれちょっとだけ面識があり、ソフトウェア品質シンポジウムが始まる前にプログラムをチェックしておいて講演を聞きに行った。そこでおもしろい発見をした。今回のソフトウェア品質シンポジウムで別々のコマで発表された専門分野のまったく違うお二人が二人とも偶然アリストテレスの話をしたのだ。

大場先生は講演の中で、アリストテレスは物質（実体、存在するもの-Substance-）とは何かを考え、その量的側面と質的側面を分けて考えようとし、量的な側面を表現する言葉として現在の英語の Quantitiy（質量）に相当するギリシャ語を用い、その対立する概念である質的な側面を表現する言葉として「様態」に近いことばを造り、そのことばがラテン語の Qualitas 、英語の Quality の語源となったと語った。

アリストテレスの哲学における「質」は、日本語で言えば「様態」に近い概念で、「ものが存在している様子」を表し、たとえば、水と氷のように水の「液体状」と「個体状」の様態の変化を明確に区別したいという意図から「質」という概念と、それを意味する言葉を創りだしたと大場先生は言った。

ここからがおもしろいのだが、藤本先生はご自分の講演で、大場先生と同じようにアリストテレスを引用して、「アリストテレスはものの中に真意が宿っていると考え、ものは“質量”と“形相”が合体したものであり、“形相”とは品質と設計情報に分離される」と語った。

アリストテレスが物質を表すためにに Quantity（質量） とは異なるもう一つの概念を考え、大場先生はそれを“様態”から Quality（品質）へ変化したといい、藤本先生はそれは“形相”であり、品質＋設計情報であると言った。

藤本先生の話では、ものづくりの結果できあがった“もの”には設計者の意図が含まれており、ものを手にしたユーザーはパッケージなどから設計者がものに埋め込んだ設計情報を推定しているとのことだった。藤本先生は壇上でミネラルウォーターのパッケージを示してこの情報も設計情報の一部であると説明していた。

【藤本先生の講義スライドから引用】

－ものづくり現場発の戦略論とは－

広義の「ものづくり」・・・　人工物に託して、設計情報＝付加価値を創造し、転写し、発信し、お客に至る流れを作り、顧客満足を得ること。「ものをつくる」ではなくむしろ「ものに（設計情報を）つくり込む」

ものづくり現場に偏在するものは何か？　実はモノではない。設計である。

したがって、「ものづくり現場発の戦略論」とは、高度5メートルの世界（ものづくり現場）に偏在する「設計情報」にこだわり、製品・工程の設計のありかたを虚心坦懐に観察することから出発し、そこから組み立て直す戦略論である。

[1] ものづくりの組織能力 = その企業特有の「設計情報の流し方のうまさ」
[2] アーキテクチャ = その製品・工程の設計情報がもつ構想（設計思想）

【引用終わり】

藤本先生は、ものの価値は設計情報の価値であり、企業はお客様の方向に設計情報を流す流れを作ることが大事であり、設計情報の流れから無駄を省くことが必要だと言っていた。そして、トヨタ自動車はこの設計情報の流れをできるだけ早く無駄なくするということに集中しており、実際に効果を上げているという。

このような組織能力(Organization Capability) と流れを早く無駄なくするアーキテクチャを構築するには組織としての統合力が必要であり、分業しすぎずに全体が見えている必要があるとのこと。そして、最適化された組織能力(Organization Capability) は他の組織には簡単にまねすることができない。

組織の特長とアーキテクチャの組み合わせを間違えるとあっという間に組織能力を下げ、市場競争力を下げてしまう。藤本先生はIBMの歴史について、昔IBMの組織能力とクローズドのメインフレームアーキテクチャは相性がよかったが、オープン・サーバーのアーキテクチャを採用したことで組織能力との相性が悪くなり、この分野の業績を悪化させた例を挙げていた。

ひとつのブログ記事で藤本先生の考えを語り尽くすことは不可能なので、今回はモノの価値と顧客満足と品質との関連に絞って書きたいと思う。

「ソフトウェア品質とは何か」の記事で、「品質とは、顧客要求を満たし満足させる程度」であると書いた。『組込みソフトエンジニアを極める』の第4章 －品質の壁を越える－では、「組込み製品の価値」には 顕在的価値(Real Value）と潜在的価値（Potential Value）の2種類の価値があると書いた。（冒頭の図）

顕在的価値は簡単に言えばカタログスペックとして掲載されるような機能や性能であり“魅力的な品質”を表す、潜在的価値とは品質の中でも“当たり前品質”と呼ばれるようなものである。

大場先生は一般にソフトウェア品質の定義としてよく引き合いに出される ISO9126 の6つの品質特性「機能性」「信頼性」「使用性」「効率性」「保守性」「移植性」は品質に関するひとつの View であり、時代の流れによって品質に対する考え方は変遷しており、“魅力的な品質”と“当たり前品質”といった日本的な価値を重視した考ええ方もあるのでISO9126 の6つの品質だけが品質の定義だとは思わない方がよいと言っていた。

“当たり前品質”は良いからといって評価につながらないことが多いが、悪い場合には企業自体の悪い評価に直結する可能性が高い傾向がある。

さて、藤本先生が語る「ものづくりの競争力」には次のような流れがある。

・ものづくり組織能力（問題解決、改善能力。ジャストインタイム。フレキシブル生産）
　↓
・裏の競争力（生産性、コスト、生産リードタイム、開発リードタイム、開発生産性など）
　↓
・表の競争力（価格、性能、納期、ブランド、市場シェア、お客の満足度）
　↓
・収益力（会社のもうけ、株価）

藤本先生は「アリストテレスはモノを質量と形相に分け、形相は品質と設計情報のことである」と言った。上記のものづくり競争力の流れの最初の2つは設計情報に関係し、後の2つが品質に関係する。

「ものの品質が顧客要求を満たし満足させる程度」であるなら、それは顕在的価値（魅力的な品質）と潜在的価値（当たり前品質）の2つに分解できる。

設計情報（付加価値）を創造し、モノに転写し、発信し、ユーザー至る流れを作ると顧客満足を得ることができる。

・設計情報がモノの価値を生み出し最終的に顧客満足につながる。
・設計情報をモノに転写するときに品質が生まれ、品質が価値を生み出す。

この話は、組込みソフトエンジニアにとっては朗報と言える。ソフトウェアは設計情報の固まりだ。メカやエレキのようにQuantitiy（質量）の要素がないので、100%設計情報であり、その設計情報が顧客満足を高めることに直結する。また、顧客満足の度合いである品質は設計情報を転写するときに生まれるため、ソフトウェアの場合はソフトウェアエンジニアによってのみ品質が作り込まれる。

部品の歩留まりや、寸法のずれ、生産、組み立て効率などの要素がないので、ソフトウェアエンジニアの能力がストレートにモノの価値や品質を作り上げる。

逆に言えば商品の価値や品質を下げる要因がソフトウェアにあった場合、もとをたどると設計情報そのものが悪かったか、それとも設計情報を転写するときに問題があったのかどちらかになる。部品や生産の仕方などに責任を押しつけることはできないので、全部組込みソフトエンジニアに戻ってきてしまうのだ。

組込みソフトエンジニアが設計情報そのものを質を高め、設計情報を転写するときの品質を高めると、企業の組織能力、競争力、収益力が高まる。

組込みソフトエンジニアが技術を磨いてよい設計情報を作り上げ、設計情報を転写する際に品質を作り込むことができれば勝ち、設計情報自体もたいしたことがなく、設計情報を転写する際の品質も低ければ負けということになる。誰のせいにもできない。

やりがいもあるし、いい加減にしたときのしっぺ返しも強い。因果な商売である。