21世紀の品質保証体制の構想

(2007/1/8 掲載、1/11更新)


1.)90年代に何が起きたか

 かつて1970〜1980年代に「品質」は日本の工業製品の代名詞でした。欧米諸国にとって、安価で品質の良い日本の製品は驚異だったのです。それがモトローラ社において『6シグマ』を生み出す背景となったし、ヨーロッパにおいて『ISO-9001』を引き出すきっかけになったのです。『CMM』でも、当時の日本の企業が持っていたプロセスが参考にされています。ある意味では、世界は日本の「品質」を目標にしてきたといっても過言ではありません。

 それが今日、日本の工業製品の品質に赤信号が点滅しているのです。単に他国に追いつかれたという状態ではありません。今まで確保していた品質のレベルが落ちているのです。それもソフトウェアが原因とは限らりません。ソフトが原因のものが多いことは確かですが、ハードの設計や製造のプロセスも狂いだしています。

 実際、私が買った日本製のオーディオのアンプはコンセントに繋いでも電源すら入らなかったし、リモコンはアンプとCDプレーヤーの両方とも、あるタイミングで操作をするとフリーズします。今や無傷の製品を探すほうが難しいかも知れないのです。いったい90年代に何が起きたのか? あの「品質」はどこにいったのか? 

 これといった資源を持たない日本が国を維持していくには「製造」しかありません。アジアの金融拠点として立国する道もあったのですが、対応のミスからほとんどその可能性は断たれてしまいました。でも、今日のような品質の状態では、「製造」で国を建てることが難しくなります。

1.1)80年代の成功と失敗の原因を知る

 90年代の問題を探る前に、80年代の成功の原因とそれが90年代に崩壊することになる背景について考えてみることにします。

 80年代の世界の製造技術は未熟であったために、粗悪品も多く出回っていました。その中にあって、日本は製造技術を磨き上げることで、日本製品の品質を半ば神話のレベルにまで引き上げたのです。発明とか開発というレベルでは、まだまだだったのです。コストを下げるためには品質も無視できません。品質が悪ければ歩留まりが低下し、結局はコストアップに繋がってしまいます。

 当時の日本の企業は、「デミング賞」「技能オリンピック」をターゲットにして技術に磨きをかけてきました。品質保証部門を確立して、そこで評価技術や判定技術を習得することで「品質」を確保してきました。ただし、そこで行われていたのは最終製品の段階でのテストの強化による品質保証であって、上流の設計プロセスからの品質保証ではなかったのです。その結果、テスト工程での作業の負荷が増大し、作り直しなどの手戻り作業の増加を招いています。それでも当時の為替のレートがコストの増加を吸収したと思われます。85年のプラザ合意によって翌年には160円に高騰するのですが、それまでは1ドルが240円でした。

 こうした事情も日本の品質を支援する形になっていましたが、最大の問題は、上流プロセスを改善しないまま最終工程での品質保証に偏ったことであり、品質保証部門には、設計などの上流プロセスに精通した人材を確保せず、最終のテスト工程で品質を確保する方法に依存していたことです。このことが、90年代に入って日本の企業を取り巻く環境が変化したときに、対応できなくなった主要な原因と考えています。

1.2)90年代以降の市場の要求の変化にどのように対応したか?

 このように80年代までの日本の工業製品の品質は表面的に高い評価を得ていたものの、その内側には脆弱さを内包していたと考えています。

 90年代に入って、市場の要求が「品質」から「納期の短縮」に変化しました。80年代に品質の要求を満たす方法が一応確立しました。プロセスを安定させることと、いくらかの冗長を加えることで品質は安定します。その結果、品質だけでは差がつかない状態となり、市場は品質以外のテーマでの「差別化」を求めてきたのです。供給側が過剰な状態にあるかぎり、この種の競争はとどまることはありません。

 本来であれば、納期の短縮要求に対応できるようにそれまでのプロセスを変更すべきだったのですが、このとき、日本の経済は「バブル期」の真っ最中で、多くの職場には大量の新規雇用者があふれていました。主要な大手の電器メーカーでは1年に4000〜5000人もの新卒を採用していたくらいです。

 日本の企業は、ソフトウェア部門に限らず、もともとプロセスを適切な形で表現する方法も持っていなかったし、ましてや要求に合わせてプロセスを自在に“設計する”という発想もない状態で、最終のテスト工程での品質保証のプロセスもほとんど“固定”していたのです。そこで、プロセスを改善する代わりに、一人の作業分担を小さくして、並行作業によって期限の短縮要求に対応する方法を採ったのです。

 ソフトウェアでいえば、当時のコンピュータの性能や、ソフトウェアの規模も今ほどには大きくはなかったことで、人の投入で対応できたものと思われます。ただ、この対応方法は、その後の「コスト削減」要求に対して大きな障害となってしまいました。しかも、「バブルの崩壊」という状況も重なって、コスト削減要求は相当に厳しいものとなって被さってきました。

 さらにアジアの各国は、90年半ばに発生したアジアの通貨危機(1997年)を乗り切ったあと、それまでの部品の供給基地という立場から、完成品の供給基地として立ち上がったことで、「コストの削減」要求が一層強まったのです。実際、その後の10年の中で、アジア各国は黒字体質を確保するまでになっています。そのことは、昨年12月19日、タイの株式市場で起きた15%もの大幅な暴落が、わずか1日で回復したことの背景となっているのです。

 このような市場の要請に対して、日本の多くの組織は、プロセスの改善を伴わないままの社員のリストラ「アウトソーシング」によって対応しました。そして、2000年以降のさらなるコスト削減要求に対しては、インドや中国のソフトウェア企業を使った「オフショアリング」で対応したのです。アウトソーシングはほとんどの場合「丸投げ」となっており、オフショアリングも、その方向に向かおうとしています。その結果、社内のソフトウェア開発組織や品質保証組織が弱体化し空洞化したし、今も進行しているのです。

 この間、90年代以降も品質向上の要求は市場から発信され続けているのですが、結局、日本の開発組織のプロセスの改善は的を外したまま効果を上げていません。それは、先進国の中でも一向に生産性が上がらないという結果になって現れています。

 2000年以降、CPUの能力やメモリー容量の大幅な向上に伴って、新たな設計技術も求められています。しかしながら日本の製造業に於ける設計部隊は、この10年間アウトソースやオフショアの発注作業が中心に進めてきたことで、自分たちでアーキテクチャの設計を含めた「ソフトウェア・エンジニアリング」全般を通した作業は行われていません。そのため、新たな市場の要求に対して対応方法が限界に近づいていて、機能の大幅な革新を伴った状態での品質などのQCDに対する要求の変化に対応できない可能性があるのです。

1.3)プロセスを固定する過ちを犯した

 日本の80年代後半からの品質向上の取り組みかたをもう少し詳しくみてみよう。

 多くの組織では、市場からのQCDの要求に対して適切にプロセスを変化させないまま、人海戦術や「丸投げ」といった表面的かつ軽率に対応してきました。ソフトウェア開発においては、新規開発と派生開発とでは要求は全く違います。さらに個々の「要求」の内容も毎回違っているのです。たとえば、今回は“試行”が必要な機能が含まれたり、業界の規格に合わさなければならない要求が入ったり、開発メンバーも前回とは違ったりします。もちろん、納期などの期間の要求も異なるでしょう。このようにそれぞれのプロジェクト毎に要求は変化し、それに合わせてプロセスも変化させなければなりません。

 ところが、日本のほとんどの組織ではプロセスを固定した状態で対応してきた。プロセスを“定義”するということを“固定”すると解釈したのでしょう。おそらく、製造ラインのプロセスの考えに捕らわれたものと思われます。
 製造ラインの方は、試作ラインで確立したプロセスを固定することで、そのプロセスを流れる製品の品質を安定させる方法でよかったのです。だが、ソフトウェアの開発は製造ラインのプロセスと全く異なるにも関わらず、安易に製造現場のプロセスの考え方が持ち込まれたようです。“メーカー”という事項もあってハード出身のマネージャーが多かったことも、影響しているかも知れません。

 もう一つの原因としては、DFD(Data Flow Diagram)やPFD(Process Flow Diagram)のような合理的にプロセスを表現し、変化させたプロセスを安定させるためのツールを持っていなかったことも考えられます。DFDは構造化分析の中で広く普及したプロセスの表記法で、欧米ではこの表記法を使って「作業」が表現されています。実際に、CMMやその他のプロセスを定義する「標準」では、DFDが広く使われています。しかしながら、日本ではこのような表記法を使って作業を表現されているところはほとんどないでしょう。(PFDは、私がこのDFDを使いやすくアレンジしたもの)

 もう一つの問題は、「ISO-9001(93年版」)への取り組みのなかで起きてしまいました。製造プロセスの定義ということであればそれほど問題はなかったのですが、これをソフトウェアの開発に適用しようとしたところで問題が起きてしまいました。

 先にも触れたように、プロセスは納期を含めた要求にマッチするように変化させ、実際に実行される前にシミュレーションなどで安定させるべきところを、当時のISO-9001は、工場単位に「1つのプロセス」が求められたために、Maxのプロセス〔いわゆる万能プロセス)を定義し、ここれをそのまま使用するか、現場で“適当に”調整して使う方法が採られたのです。その結果、ここでもプロセスの“定義”が“固定”に繋がってしまいました。

 2000年版のISO-9001では、プロセスの多様性が認められていますが、現実の組織でではこの面での対応は大きく変化していないように見受けられます。たとえば、“テーラリング”という行為も、Maxのプロセス定義から削除する方向で対応しようとしているようですが、そこに設定されているプロセスは、すべて“必要な”プロセスに見えるために、この方向からの調整はうまくいかないと思われます。その上、“定義書”中心でPFDもない状態では変化させた状態を安定させる方法がありません。

 PFDのようなツールがあれば、“Mininum”のプロセス定義に対して、今回の要求から判断して不足しているプロセスや必要なプロセスを付け加えることができるし、その方が無駄のないプロセスを作ることが出来るのです。
結局、ほとんどのソフトウェアの開発組織では、変化する要求に対応できるプロセスを作ってこなかったことで、プロセスを“自在に設計するスキル”を失ったのです。

1.4)デミング賞にみる日本の品質の変化

 「デミング賞」は、80年代までの日本の品質への取り組みの象徴でした。実際、当時の「デミング賞」は日本企業のための「賞」の感すらありました。そこから「Made in Japan」「Japan as No.1」へと繋がったのです。しかしながら、2001年以降で「デミング賞」を受賞した日本企業はわずか4社しかありません。さらに、2002年と2004年は受賞企業はゼロだという。(日経ビジネス2006.11.13「品質の復習」より引用)

 その背景として、製造拠点が海外に移されたり、アウトソーシングやオフショアリングによって、国内で設計や製造する機会が減り、それに呼応するかのように「デミング賞」に取り組む企業が減少したことが考えられます。もともとソフトウェア企業や、ソフトウェアの開発部門には「デミング賞」に取り組もうというところはほとんどありませんでした。

 このように「デミング賞」への取り組みが下火になった背景には、70年〜80年代のQC活動やTQCの取り組みにおいて上流プロセスを巻き込まなかったために、設計のやり直しに繋がるような手戻り作業が多く発生し、「人海戦術」「肉弾戦」によって対応してきたことへの反動があると考えられます。

 また、90年代後半からのM&Aの日常化で、経営の優先課題が「品質」から「収益」や「株主対応」へと変化したことも、「デミング賞」のような活動が下火になった要因と考えられる。実際、大企業においては2000年以降の株主への配当が大幅に増えているのに対して、従業員への賃金の形での分配は減少しています。そして、皮肉にも「株主要求」に応えて収益を優先的に配当に回したはずなのに、実際は品質を棄損したことで企業価値を下げてしまう結果となっているのです。

 今の日本の製造業の品質レベルでは、そしてこのまま品質を奪回する取り組みが行われなければ、早晩、新興国に追いつかれることは火を見るよりも明らかです。その時点で、日本の製造業は衰退する危険があるのです。

1.5)品質軽視の代償

 90年代に入って日本経済は、バブル崩壊によって大ダメージを受けました。多くの企業は、必死なって収益を上げるために“もがき”ました。その中で、「プロフィットセンター」とか「コストセンター」の考え方が広がり、品質保証部門は「コストセンター」と認識されました。つまり、収益に繋がるような売上げを上げない組織ということです。本来、品質保証は出荷後の損の発生を抑え、間接的に利益を上げる組織ですが、当時の品質保証は上流を包含しなかったことで、損失の削減効果が限定されたことも「コストセンター」の波に飲み込まれ、リストラの対象となってしまったと考えられます。

 こういう事情もあって、90年代以降、品質管理技術者の育成を怠ったことで、品質のトラブルが続出するようになりました。当時は最終製品に対するテストが中心だったのですが、上流の設計技術に精通した人を確保していなかったために、CPUなどの性能アップに伴って増加する機能に対して効果的なテストの対応ができなかったことも主たる要因と見ています。

 その他に、当時の品質保証体制からは、要求の仕様化を初めとする設計から実装までのプロセスの保証が放置された状態で、不純なプロセスで作られたソフトウェアにはバグが至る所に残されています。そのような状態に対してテストが適切に対応できなかったことも要因として上げられます。
 幸いにも、2000年を過ぎてソフトウェアのテスト技術者の交流の場が作られましたが、それまではテスト技術者はプロセス改善の取り組みや設計技術者との交流の場から取り残されていました。

 90年に入っての品質に対する意識の低下は、日科技連が開催する「品質管理セミナーベーシックコース」(延べ30日コース)の受講者の変遷からも読み取ることができます。日経ビジネスの記事によると、1980年代には、このコースを受けた人が年間1000人以上いたのに、2003年度には年間152人に減少しているという(日経ビジネス2006.11.13「品質の復習」より引用)。この数字は、日本企業における品質意識の低下を物の見事に表しています。

 日本の製造業が品質を軽視し始めたことの象徴がもう一つあります。フィリップB.クロスビー著の『クォリティ・マネージメント』(原題:Quarity is Free)という文献があります。既に絶版になっているので正確に言えば“文献があった”というべきかもしれません。この文献は、1979年に出版されたもので確かに古いかも知れませんが、今読んでも全く見劣りしない内容です。80年代の日本企業の品質保証部門の担当者にとってはバイブルの一つになっていたはずです。それが絶版になっているのです。

 このことをあるクライアントで私の窓口になってくれている人に話したところ、彼は早速社内のネットを検索してこの本が図書として確保されていることを確認しました。でも、図書室で探しても見当たりまっせん。そこで担当者に確認したところ「段ボールの中を調べて見てください」ということでした。そこで段ボールのフタを開けて探したところ、その中からこの本を発見したのです。彼はこの本を職場の本棚に移しました。この段ボール箱は、“10年間1回も借り出されなかった本”ということで、まもなく処分される予定だったのです。まさに間一髪のところでセーフだった。同じことが他のメーカーにも起きていると思われます。日本の組織の中で「品質」は誰も興味を示していないということです。「品質保証部門」があるのにです。

 これは品質に対する「傲り」なのか、それとも「軽視」なのか。あるいは、もはや「品質は問題ない」という「誤った認識」か。それとも、目先の収益を上げるために「コストセンター」にはリソースを投入できないという考えなのか。アウトソーシングやオフショアリングで、外部のソフトウェア企業に“丸投げ”したとしても、製品の最終責任は発注側にあるのです。

 バグのネタを仕込んだのは、外部のソフトウェア企業だとしても、そんなことは言い訳にもなりません。そのソフトウェア企業を選んだのは発注側の企業(多くはメーカー)であり、最終的に品質を保証できなかったのも、発注側のメーカーでなのです。そして結局は巨大な損失を計上しているのです。

 90年代のバブル崩壊後の売上げ減少に対応するために目先の利益を優先した対応が、此処にきて、かえってコストが嵩んでいることに気づくべきなのです。

1.6)不用意なアウトソーシング

 バブル崩壊後の企業の対応が軽率だったことが、その後の対応を難しくしています。売上げの減少とそれに伴って利益が大幅に減ったことで、多くの企業は赤字決算となった。当時、大手企業のトップは、「売上げが増えなくても利益を出せる体質」に転換すべく、リストラという人員削減に取り組んだ。そこでは、「コストセンター」の視点から売上げや利益を上げない組織を削減したり、要員の配置転換やリストラが推進されました。早期退職制度によって、大量の社員が退職したし、この中には、品質保証部門や社内教育の部門も含まれています。

 「固定費の削減」という目的のために、ソフトウェアの開発も外注化、アウトソーシングが盛んに行われた。確かに、人件費が外注費に変わることで財務諸表上では変動費に移ったのですが、100%子会社であるかぎり、連結決算では何も変わらないのです。

 ソフトウェアの外注化の一環として、ソフトウェアの開発部門の分社化が盛んに行われました。分社化することで、ソフトウェアの開発にかかるコストと利益が見えるようにすることも狙いの中に含まれています。しかしながら、今までは要求の仕様化から最後のテストまでを1つのプロジェクト・リーダーの手の中でコントロールしてきたものが、分社することによって、「外注管理」の対象となり、発注側で作成した要求仕様の出来栄えの稚拙さが、その後の外注先の作業を混乱させたのです。これに輪をかけたのが、分社した外注先では適切な設計プロセスを作れない状態は変わらず、結果的には分社によってほとんど何も改善されませんでした。プロセスの変更を伴わないままでは、このような結果になるのは当然なのです。結局、この取り組みによって、当初期待されたコストダウンは実現しなかったのです。

 2000年に入って、インドのソフトウェア企業が台頭してきたことで、アメリカをはじめ世界の企業はインドをオフショア先として活用し始めました。これを見て日本の企業も早速オフショアリングに切り替えたのですが、もともとアウトソーシングでの失敗が、プロセスの設計が出来なかったことと、適切な要求仕様が書けなかったことにあって、その失敗の原因が何も改善されないままオフショアリングに切り替えたため、当初はことごとく失敗しました。

 アウトソーシングもオフショアリングも、それ自体が間違った選択というわけではありません。「もっとも適切な場所で作る」というのは、市場の要求でもあり、時代の一つの選択肢でもあるのです。ただ、アウトソーシングもオフショアリングの要求が「コスト削減」にあるのであれば、コストの優位性はそれほど長期間続くことはないとおもわれますので、ここでの本来の姿は、自社の優秀なソフトウェアエンジニアの技術と雇用を確保しながら、外部調達できる作業を切り分けて人件費の削減を達成することが必要になります。そのためには、まずは現状のプロセスを表現し、設計技術を失わないようにアウトソーシングやオフショアリングを組み合わせた時のプロセスに組み建て直し、そこから外部に出すことのできるプロセスを切り出す、という作業が必要だったのです。

 しかしながら、現状はそのような状態になっていません。その原因は、発注側がそれらの選択肢を活用できるシステムになっていなかったということであり、全体として合理的なプロセスが設計出来ていなかったことにあります。もともと、自分たちで開発していたときに、合理的なプロセスを持っていなかったために混乱していたのであり、そのことで手戻り作業が減らず、収益を悪化させていたのです。そのプロセス(といえるものは存在しないのだが)を改善(変更)しないまま、アウトソーシングやオフショアリングを使おうとしたために混乱したのです。

 それでも、オフショア先のソフトウェア企業が、日本の企業の体質に合わせたプロセスを作ってきたことで、オフショアが回りはじめました。いわゆる「ブリッジSE」がその一つの方法です。日本の企業との間に入って、自ら要求をヒアリングして仕様を取りまとめたり、日本側の変更要求を仲介したりする役目です。こうすることで日本の企業のプロセスはそのままでも、オフショア先の作業に影響を与えないで済むわけです。

 この結果、要求の仕様化技術から設計技術まで全部が社外に流出してしまいます。というよりも、発注側の日本の組織ではこれらの技術が無くてもオフショアが可能になったのです。言い換えれば、日本国内では「ソフトウェア・エンジニアリング」に関するこれらの知識や技術を習得する必要が消えたのです。この場合、発注側に残るのは、発注を仲介する役と納品時の最終製品に対するテストプロセスだけです。

 ただ、アウトソース先やオフショア先のソフトウェア企業の開発能力が高く、品質を織り込む設計技術があれば、結果として納品されるソフトウェアの品質は確保できます。でもそのようなソフトウェア企業は必ずしも多くはありません。現状では、かなりの数のソフトウェア企業は上流である設計プロセスを保証できていないために、納品される製品の品質は悪く、その後で大幅な手戻り工数が必要となってコストアップを招いているのです。

 いずれにしても、日本の企業がこうした安直なアウトソーシングやオフショアリングに手を染めたことで、日本の組織自身が上流プロセスの品質を保証する必要性が消滅しました。そして、オフショア先のプロセスの品質保証能力が低いままで、その上さらに国内の技術力が空洞化するという状態に陥ろうとしているのです。

 現時点では、アウトソーシングやオフショアリングを活用する最大の狙いは「コストの削減」と考えられます。もちろん、技術的な面でのアウトソーシングやオフショアリングというのも考えられるのですが、件数としては僅かだろうと思われます。海外企業のコストの優位性というのは、アウトソーシングやオフショアリング先の経済が拡大する中では、コストの優位性はそれほど長くは続かないと思われます。

 その理由として考えられるのは、今のような大量の発注が続けられることで相手国の経済発展が進行し、それに伴ってエンジニアの賃金が急上昇するし、オフィスなどの賃貸料も上昇していきます。たとえば中国企業における自動車の開発をみていると、日本が20〜30年かけて発展してきたものが、これらの新興国では5〜7年で達成しているように思われます。また、相手国との関係では、為替レートの上昇圧力(相手国に対しては円安方向)も確実に存在するので、そんなに遠くない時期に、コストの優位性は薄れることが予想されます。

 海外のコストの優位性が薄れたときには国内回帰の方法も考えられるのですが、現実には、ソフトウェアに関する技術力や開発力が空洞化したあとであり、アウトソーシングやオフショアリングによるコストの優位性が崩れたときは、既に国内回帰が不可能な状態になっている可能性があることにも考えに入れておく必要があるでしょう。

1.7)PLやPMにおいて過剰責務が発生

 先にも触れたように、90年初めのバブル崩壊後、市場のコスト削減要求に対して多くの企業は無節操なリストラを実施した。運悪く、このとき市場は品質要求の他に納期の短縮要求を発していました。本来なら、それまでの開発プロセスを見直し、要求仕様などの上流のプロセスに重点を移すことで、それまで盛んに行われていた手戻りプロセスを減らしたり、テストケースの作成プロセスと並行させたりすべきだったのですが、現実にはプロセスの改善を伴うことなく人件費の削減のためのリストラを実施したことで、残された人の作業の負担を増やすことになった。

 事前にプロセスを自在に設計し表現するスキルを習得していなかったことも、PLやマネージャーの作業を単純に増加させる結果に繋がってしまいました。その時点では、増加する作業に対してただ「時間を投入」して対応するしかなく、リスク管理やサイズ見積りなどのプロセスも省かれたのです。当然、このような状況の中ではPLやマネージャーは疲弊し、効果的なプロセスを考え出すこともできず、ずるずると品質が低下することになったのです。

 その結果、リストラによる収益の改善が一時的なものでしかなく、直ぐに品質の低下に伴う手戻り工数の増加からコストアップします。そうなると収益を確保するために、さらに仕事の量を増やす方向に動いたのです。本来なら、踏みとどまって品質を向上させる取り組みをすべきところが、それでは、直ぐに収益に繋がらないと考えたのか、安直に売り上げを増やす方向に動いた。90年代の初めから、ずっとこのパターンから抜け出すことができないようです。

 そこで売上げが増えたとしても品質問題が根本的に解決していないので、必ずしも収益の増加に繋がらりません。それどころか、品質問題が表面化して企業の信用問題にも発展し、利益を吹き飛ばす程の大きな損失が発生しています。こうしてPLやマネージャーの負担が増加し、現場のエンジニアも一緒に疲弊するという負のサイクルが成立するのです。これが、今日の状況です。
 
 本来なら、納期の短縮要求を含めて、市場の要求にマッチしたプロセスに組み替えて改善すべきところなのです。たとえば市場の要求は新規開発ではなく派生開発を求めているのに、ほとんどの組織で使用されているプロセスは、「新規開発もどき」のプロセスになっています。これでは求められている期限に完成しません。また、機能要求にばかり気を取られて、「納期」もプロセスに対する立派な要求であることにも気づいていません。これらは派生開発に特化したプロセスを導入すべきことに気づいていないためのミスマッチなのです。

 プロセスが要求にマッチしていないのですから、そこに多くのバグが織り込まれてしまうのは当然です。リストラの結果、一人のPLやマネージャーが担当するプロジェクトが増えているのに、その上、バグが頻発しているのですから開発現場の人たちが疲弊するのは当然です。

 まずは、PFDのようなツールを使って実際のプロセスを表現し、今回の要求に対応した合理的(機能面と経済面)なプロセスと成果物の連鎖を構築することです。それによって、外部のソフトウェア企業を使って、アウトソーシングやオフショアリングに切り出せるプロセスの範囲も見えてくるし、スケジュール管理に於ける作業のデータの入力の催促や、構成管理の変更の確認、各種計測データの収集や計算など、派遣の事務職のような補助要員で対応可能なプロセスも見えてくるのです。実際、PLやマネージャーの仕事の中に、こうした派遣の事務職で対応できることが3割以上は含まれていると思われます。

 目先の利益のために補助要員も含めてぎりぎりまでリストラした結果、残ったPLやマネージャーの仕事を増やしたのです。逆に、補助要員でも対応できるプロセスを切り出して派遣社員に任せることで、PLやマネージャーの時間を浮かせ、その時間を使ってさらにプロセスを改善する方法を考えるべきなのです。そうすることで派遣社員のコストぐらいは容易に稼ぎだすことが出来るはずです。そうして、斬新的に収益の改善が続くようなサイクルを確立すべきなのです。

 たとえば、要求仕様をUSDMの表記法で表すことで、レビューではコメント記入用に「1列」を用意して事前配布し、その列に各自のコメントを書き込んでもらえば、レビュー前に各自のコメントを集めて整理する作業はあっという間に終わるし、その後の変更の確認も簡単にチェックできます。さらに、事前に十分に仕様化することで、設計プロセス以降での仕様の調整作業は大幅に削減されるし、評価グループにおけるテストケースの設計作業と並行できることで、テストケースの内容を設計者に公開する方法も選択できるのです。実際にこうした対応で、従来比で2〜3割の工数は削減できるのに、このように成果物の構成を変えて生産性を改善するような対応は全く行われていません。いや、疲弊したPLやマネージャーにはそれを考える余裕すらないのかもしれません。もしかすると、長く思考を止めた状態を続けたことで、既に思考力や想像力を失ってしまった可能性も否定できないのです。

 実際、90年代後半以降のIT革命の中でどれだけの作業が効率化したでしょうか? 現実には、PCはソースコードを入力し、コンパイルしたり、ソースコードのレベルでテストを行ったりする他には、単に文書を作成するための紙とペンに変わる道具にすぎず、それ以上の効果を発揮していないのです。

 インターネットや社内ネットがここまで普及しているにも関わらず、いまだに「週1回」の進捗会議の場に集合したところで、各自の作業の“状況”確認が行われています。しかもこれを30年前から続けている。そこには「ITの恩恵」などとはほど遠い世界があるのです。最初にPFDに基づいてプロセスを設計し、そこからスケジュールを引き出し、あとは各自が、自分のスケジュールに沿って作業を進め、その結果を毎日ツールに向かって入力すれば、各自の作業の状況は、いちいち集まらなくてもPLやマネージャーのPC上で確認することができるのに。

 各種の成果物レビューで対象となる成果物は、相変わらずレビュー当日の会場での配布だし、いまだに「紙」でやっている。印刷する時間、そこにコメントを書き込んだことで後で改めてPCに入力する時間、事前に読む際に「サーチ」が使えないために思い当たるページを探し回る時間がムダなのです。そうして探しきれなかった箇所がバグとなってさらに多くの時間を浪費するのです。これが「21世紀の仕事」の姿ですか? こんな状態をいつまでも続けていると、今にまともなPLやマネージャーがいなくなってしまうでしょう。

1.8)繰り返されるリコール

 実際、PLやマネージャーが時間に追われて適切に対応しきれなかった結果、バグが多発しているのです。たとえば、自動車のリコールの状況を見てみよう。(以下のデータは日経ビジネス2006.11.13「品質の復習」より引用)

 2005年の1年間にトヨタが127万台のリコールを発生させたし、2004年度の1年間で国産車全体で700万台のリコールが発生しているのです。さらに、2006年度は9月までの半年間ですでに300万台のリコールが発生しています。(これらのリコールで失った手戻りコストは、おそらく500〜1000億円に達するのではないかと思われます。)
もちろん、これらのリコールはすべてソフトウェアが原因というわけではありません。2001〜2005年に発生したリコール案件が1008件あり、その分類は、
 a)性能の未達成=5%
 b)設計に起因するもの=60%
 c)製造作業に起因するもの=27%
 d)製造設備や部品管理に起因するもの8%
となっていますが、この内のa)とb)を合わせた65%は、要求仕様の不備と要求にマッチしないプロセスが実施されたことが原因と推測されます。

 携帯電話の端末のトラブル(リコールにならなかったものも含めて)も一向に減っていません。2006年度前半だけで該当端末は約2000万台に達しているという(日経ビジネス2006.11.13「品質の復習」より引用)。1台当たり1万円のロスとして、2000億円の損失です。実際には原価はもっと高くついているでしょう。こんなことでは、いつまでも利益は出てこないし、利益を確保するために能力以上の仕事をしなければならないという「負のスパイラル」から抜け出すことができません。

 世界では、既に携帯電話の値段は100ドル以下の段階に入っていて、これに対抗するために、結果的にはもっと安いコストの国へのオフショアが求められるでしょう。ただし、発注側に成功するプロセスを持っていない状態では、オフショア先で作られたソフトウェアの品質が悪く、納品後に改めて多くの工数を投入して改修作業が必要になります。オフショア先も発注側企業を選択してきます。これがまたPLやマネージャーの作業を圧迫し、さらに品質が低下するという「負のスパイラル」に陥ることになります。緊急事態というのは、事前に計画することも、作業の優先管理やリスク管理もパスされてしまいます。場当たり的な作業の繰り返しからは、何も学習されないのです。単に時間と費用を浪費するだけです。

2.)21世紀の品質保証のあり方

 第1部では、90年代以降の間違った対応が、今日の日本の企業の混乱の背景にあることを説明してきました。混乱の多くはソフトウェアの領域で起きているのですが、製造のプロセスも混乱していることもまた事実です。組織全体がおかしくなっているのです。

2.1)従来の品質保証の限界

 21世紀に入って日本の企業が製造する製品やシステムが、CPUの性能アップやメモリーの大容量化の伴って大きく変化しています。たとえば「マルチコア」のCPUは、これまで複数のCPUやDSPチップなどを使って実現していた機能を、1つのCPUで実現できる状況を作り出しました。当然、一つのCPUで作動するプログラムのボリュームが大きくなり、それだけバグが入り込む余地が増えます。メモリーチップの容量が大幅に増えたことも、プログラムを集積できる状況を後押ししています。

また、新しい機能を実現する方法として、ソフトウェアに依存する比率も高くなっています。適切なプロセスを導入しなければ、これらの要因に起因してバグが発生する可能性も増えてしまうのです。新しい機能が増えたことでテストケースも増大することになります。ところが、全体としての開発期限は抑えられているために、テストの工数も圧迫されるのです。

 従来の「設計作業に入らないと仕様は抽出できない」という発想に基づいた要求仕様では、評価グループとしてまともなテストケースを準備する工数を確保できません。そこにある要求仕様では「振る舞い」も良く見えないし、「仕様」だって漏れているのです。設計しながら仕様を抽出するというのですから、際どい仕様が書かれていないのは当然なのです。しかも設計者が途中で仕様を加えているのですから、評価グループで事前に作られるテストケースはまともなものは作れません。

 このような状況では、従来の品質保証のような最終製品の段階でのテストや、製造現場での出荷検査に依存した品質保証では対応しきれません。そのため、バグは多発しリリース毎に市場でトラブルとなって噴き出すのです。バグによる手戻り工数も、終わってみれば全体の半分にも達することも珍しくないのです。

 要求仕様の作成や設計などの上流工程からプロセスと成果物を保証する体制が必要になってきているのです。そこでの保証は、要求にマッチした機能的かつ経済的に合理的なプロセスと成果物の連鎖が構築できていることを保証することと、それが適切に実施されていることを保証することです。

 もちろん、事前に計画したプロセスやスケジュール通りに進行することはほとんどありません。現実は常に予想の範囲を越えるものです。実際の進行の中で分かったことや新しい事態に基づいて事前のプロセスやスケジュールを変更することも必要で、その変更のプロセスも適切に行われたことを保証することになります。

 同時に、機能の増加に伴って増える傾向にあるテストケースも、増加を抑制する方策を講じなければなりません。テストケースの設計も、そうした抑制策も、事前にプロセスが設計され、品質保証体制の中でそれを保証することになります。

2.2)予防からの品質保証

 評価部門での「テストで品質を上げる」という従来の品質保証の発想は、工場などの出荷検査の発想に近く、その結果、確かに出荷された製品の品質は確保できるかも知れませんが、出荷できなかった製品が大量に発生してしまいます。その方法で対応できるのは製造プロセスのミスであって、仕様の漏れや設計ミスは対応できません。それにも関わらず、80年代の日本の品質保証ではこの方法をとったことで、手戻り作業となって現場を圧迫したのです。

 ソフトウェアの開発においては、「テストで品質を上げる」という発想は通用しません。最終段階のテストでは欠陥を指摘(発見)するだけであって、テストで必ずしも品質が向上するわけではないのです。品質保証の観点でのテストで発見されたバグは、基本的にはすべて改修しなければ出荷できません。単純な実装プロセスのミスであれば簡単に修復できますが、設計や仕様の間違いとなるとそれなりの工数が必要になるし、改修の過程で他の部分を傷つけてしまうこともあります。

 ソフトウェアの場合、「品質」のほとんどは仕様化のプロセスや設計プロセスで織り込まれる性質をもっており、実装プロセスで織り込まれる部分はほんのわずかしかありません。その場合も、設計者(グループ)によるテストでほとんど発見され、品質保証部門のテストまで残ることは僅かです。

 たとえば、以下のような品質特性は「設計」プロセスの中で織り込まれます。
  パフォーマンス
  操作性
  メモリー効率
  移植性
  保守性
  堅牢性


 これらの品質特性は、関連する仕様との整合性が確保されている必要があるし、適切なデータ構造を選択されなければ実現しないことも多いのです。そのため、評価部門でのテストでバグとして発見された場合、簡単には改修できないのです。とはいっても時間が迫っているという圧力から変更制御プロセスを無視して改修作業をやってしまうために、出荷後にトラブルとなって帰ってくるのです。

 したがって、少なくともソフトウェアの場合は、評価部門におけるテストだけで品質を保証するのではなく、上流の仕様化プロセスの段階から品質を織り込むという考え方に切り替える必要があります。そうでないと、増加する機能にテストが対応できなくなります。もちろん、最終段階でのテストが不要になるわけではありませんが、上流のプロセスでの保証能力が向上すれば、最終段階ではいわゆる品質保証の観点からのテストに絞り込むこともできる可能性があり、全体の工数削減に威力を発揮します。

 上流のプロセスからの品質保証という中には、「テストケース設計」のプロセスも含まれます。そのためにも、「テストケースを設計する」プロセスに引き渡す「要求仕様書」の内容が問われるのです。従来からの「詳しい仕様?は設計作業に取り掛からなければ抽出できない」という考え方を認めたのでは、「テストケースを設計する」プロセスはまともには実行できないことになります。その結果、テストケースの品質が低下し、テストの結果も保証できなくなってしまいます。

 品質保証の基本は「不良品を次の工程に流さない」ということです。言い換えれば、「欠陥を含んだ成果物(中間成果物)を次のプロセスに流さない(渡さない)」ということです。先に触れたフィリップB.クロスビー著の『クォリティ・マネージメント』(原題:Quarity is Free)という文献にも、このことは明記されていますし、大学の「品質保証」の教科書にも、「次工程はお客さん(と思え)」という表現があることは数年前に確認しています。

 にもかかわらず現実には、この品質保証の原則をまったく無視した状態で作業を進めています。80年代に「品質要求」を達成する際に上流工程を巻き込まなかったことや、90年代の納期の短縮要求に対して「人海戦術」で対応しているうちに、この「不良品を次の工程に流さない」という大原則は省みられなくなってしまったようです。

 私が成功した最大の要因は、最初の成果物である「要求仕様書」のプロセスと成果物を変えたことであり、PFDというツールを使って、この成果物を入力する「次工程」(次プロセス)を明確にしたことにあります。これによって、「次工程に良品」を渡すことができたのです。現役当時の私には、クロスビーの『クォリティ・マネージメント』という文献の存在を知る由もなかったのですが、私の取り組みは「理に適った」ものであったということです。

2.3)失敗をプロセスで解決する

 人は誰でも失敗します。失敗しない人はいません。私も、この世界に入って最初の3年は失敗の連続でした。ほとんどすべて失敗していたといってもよいくらいでした。その後1年間のブランクをおいてこの世界に復帰したあと、過去の失敗を繰り返さないための工夫を繰り返してきました。

 これまで多くの組織で失敗に対する対応を見てきました。ほとんどの組織で、失敗に対する対応方法は担当者の中で考えられるだけで、対応方法そのものが事前に公開されることはありません。組織が求めているのは対応の結果だけです。それがあ優れた対応方法であったとしても、ノウハウとなって担当者の中に留まるだけで組織の知恵になっていません。その証拠に、人が変わることで同じ過ちが繰り返されてきました。

 海外の企業に発注したものがことごとく失敗するのも見てきました。なぜ同じ失敗を繰り返しているのかと思って、ある人に事情を聞いたところ、前のプロジェクトで失敗した人はその担当から外れて別の人が新たに担当になっていました。その時、前任者から失敗しない方法を引き継いでいないために、新任者もまた同じ失敗をしているのです。こうしてその組織では次々と同じ失敗を繰り返していました。「彼はうまくできない」という烙印を押すだけで、「失敗をプロセスで解決する」という発想がないのです。

 外注管理の失敗だけでなくバグなどの品質問題も、すべてプロセスにその原因を求めることができます。一般に、
  必要なプロセスが省かれた、
  不十分な状態で実施された
  プロセスと成果物が適切に連鎖していない
ことが失敗の原因です。時には、今回の要求に対して不要なプロセスが実行されたり、不適切なプロセスを実行したことで成果物が繋がらない、という状態になることもあります。

 90年代の後半にCMMが普及したことで、バグなどの原因をプロセスに求める動きが広がりました。そこでは、プロジェクトの終了報告書の中で「円グラフ」で原因プロセスの分布が表現されています。ここまでは良かったのですが、原因プロセスを特定する意味を理解していないために、円グラフで表現するだけで終わっているのです。でも、原因プロセスを特定するだけでは何も解決しません。円グラフにするのは、原因を取り除くための取り組みのプロセスを絞ったりするための分析であるにも関わらず、多くの現場ではここで止まっているのです。

 厳密な意味で、原因は一つひとつのバグに固有です。そのため、たとえば「仕様漏れ」を防ぐ方法はありません。「データ構造の選択ミス」を防ぐ方法もないのです。あるのは、個々の仕様漏れのケースに対しての対応策です。大事なことは、まだバグとなっていないときに気づいたりして未然に防ぐことができる仕組みやルールを構築することです。

 たとえば、仕様漏れが生じた原因が、条件のところで“ペースト作文”で8つも並べたことで、条件に加えるべき変数が他にあったことに気づかなかったとすれば、“ペースト作文”に制限を加える“ルール”を制定し、それを「要求仕様作成ガイドライン」のところに明文化することが必要なのです。

 あるいは、上位要求を表現する際に、「振る舞い」の表現が中途半端に扱われていたことで、入力方法が限定されてしまい、もう一つの入力方法があることに気づかなかったというのであれば、振る舞いの表現のサンプルを作ったり、気づきを誘うようなキーワードを見つけたり、グループのパターンを増やすことで対応しやすいように、要求仕様のテンプレートを改良したりします。

 データ構造として「リスト構造」が選択されなかったことがパフォーマンスを満たさなかった原因というのであれば、リスト構造を推奨するときの要件とその対応を設計のガイドラインに掲載したり、場合によってはデータ構造そのもののレクチャーを全員に実施するような対応が必要かもしれません。

 さらに、これらの事例をトレーニングのカリキュラムやテキストに反映して、一定期間の中で全員がこれらのテキストを使ったトレーニングを受ける仕組みにすることも有効です。ここまで「原因にさかのぼる」ことで、要求仕様を作成している最中に仕様モレの危険に気づいたり、設計作業の中で適切なデータ構造を選択したり組み合わせることができるのです。

 こうした対応の結果、上流プロセスので品質保証が実現するのです。

2.4)経営者の決断が品質を変える

 もう一つ、21世紀の品質保証体制を構築するポイントとなるのは、企業のトップが高品質の製品を作ることを優先することを認識し、行動することです。
特に、最近の企業経営者は「M&A」に脅えているのか、株主に迎合しすぎである。ファンドの形で外国人株主が増加し、高配当を要求していることも背後にあると考えられます。実際、2000年以降の配当性向の倍率と給与等への分配率の変化を見比べたとき、従業員を軽視していると言われても反論できないのではないかと思われます。いまだに日本のデフレが止まらない原因の一つがここにあると考えています。

 確かに、会社が存立するのは株主がいるからです。株主が資本を引き上げれば立ち所に会社は消滅します。でも、製品を作ったりその品質を保証するのは株主ではありません。社員(従業員)です。社員の働きによって得た利益の一部が配当として株主に還元されるのです。

 そして企業のトップは、その経営能力が問われます。経営能力とは、社会が求める製品やサービスを提供し、そこから確実に収益を上げる能力のことです。一時的ではなく、継続してその収益を上げるには、優れた製品であることや優れたサービスであることが求められます。そして優れた製品の中には優れた「品質」が含まれるのはいうまでもありません。その品質と利益は現場の人たちの働きによって達成できるのです。品質が悪ければ、手戻りコストが嵩んで収益を圧迫します。場合によっては、損失の方が大きくなってしまうし、社会的に信用を失えば、事業を継続することすら難しくなり、結果的に株主資本の価値を棄損することになります。この状況の中で経営能力が問われるわけです。

 90年代を通じて企業の株の持ち合いを解消する動きが進みました。株の持ち合いによって株主資本が塩漬けになることや、「安定株主」という立場でお互いに相手企業の経営に口を挟まないという暗黙の了解のようなものが形成され、経営者に対する適正な評価を妨げるといったことが、持ち合い解消が進んだ理由です。

 この結果、放出された大量の持ち合い株を市場で取得する動きが表面化しました。ちょうど「0金利」ということで「金余り」の状態も重なり、大量の資金が投資ファンドに流れ込みました。それが「物言う株主」となって経営者の行動を監視する存在となったのです。場合によっては、企業の発行株式が市場で買い占められたり、株主構成が変化して新しい株主からトップの交代が求められたりしました。それでも、トップの経営者としての評価に基づいているのであれば何も問題ないありません。資本主義の正しい姿でもあるのですから。

 企業の株主構成や経営のトップが変わっても、特殊なケースを除けば、優れた製品やサービスを提供し続ける現場の社員の役割は従来のまま継続します。いや、株主が代わり、企業のトップが交代した方が現場のエンジニアたちは今まで以上に良い仕事が出来るかもしれないのです。

 同じ状況でも、社員と経営者とでは捉え方が違います。日本の経営者のほとんどは、プロの経営者としての資質を身に付けていないといっても過言ではありません。それぞれの企業の中で“成果”を出してきた人が多く、その中で担ぎ上げられた結果として、最終的に企業のトップに就いているというケースがほとんどです。オーナー会社以外は、ほとんどはこのタイプと考えられます。したがって、他の会社では“トップ”として通用しないことが多いのです。

 そのため現経営者はM&Aを恐れています。企業買収によってその役を解かれることは、経営者としての立場を失うことに繋がる可能性があります。分かりやすく言えば、他に出番がないかもしれないということです。現経営者が必要以上に株主の顔色を窺う背景には、このような恐怖があるものと私は見ています。プロの経営者としての技術と自覚が有れば、必要以上に株主の顔色を伺う必要はないはずです。

 日本の多くの企業は、90年代のバブル崩壊以降の不用意なリストラによって、80年代に獲得した品質のレベルすら失ってしまいました。そして、2000年に入って企業(特に製造業)のトップは必要以上に株主の顔色を伺うようになったことで、トップとしての判断を間違えたのです。収益の多くを、プロセスを改善し、生産性と品質を向上させるための取り組みに回すべきだったのを、株主への配当に回してしまいました。それが、最近の日本の製品の品質の背景と考えています。

 品質の低下に伴って、売上げの減少や手戻りコストの増加によって収益を圧迫したとき、プロセスを見直して品質を回復するように対応すべきだったのを、安直に利益を確保するためにコスト削減を狙って、売上げを上げない部門を縮小したり、アウトソーシングやオフショアリングに向かったのです。その結果、ますます現場から「品質」を織り込む設計技術やテスト技術が空洞化してしまいました。そうして品質保証部門のバイブルだったクロスビーの文献が、10年間誰も読まれない状態を作ったのです。

 確かにリストラや低賃金の外部のソフトウェア企業を使うことで、直近の収益は上がるでしょうが、5年というレンジで企業の将来を見たとき、人材の疲弊技術の喪失産業基盤の空洞化といった取り返しのつかない状態になってしまう危険性は否定できません。時代的背景という観点から、ある程度の海外企業との役割分担は必要ですが、それによって今までの技術を失うのでは本末転倒と言わざるを得ません。今すぐにでも改めないと将来の選択肢をなくしてしまいます。

 企業のトップは今すぐにでも「品質」に舵を切る必要があります。当面の配当方針を株主に説明して、収益の過半をシステムやプロセスの見直しに投入し、上流のプロセスから一環して品質を確保する技術や仕組みを手に入れる必要があります。トップが決断すれば直ぐにでも実現するはずです。

 もちろん、そこには「トップの交代」が必要になるかも知れません。昨日まで株主の顔色を窺っていたトップが、今日から従業員の方に向きを変えることは難しいでしょう。だったら、直ぐにでもトップを交代すべきです。そうでなければ、日本の企業は競争力を失って沈没してしまいます。今のような品質レベルでは、数年の間に簡単に追いつかれることは明らかです。

 島国の日本としては、簡単に追いつかれないような品質レベルを確保しなければ、そこで働いている多くの従業員は行き場を失ってしまいます。彼ら従業員は、この先20年、30年と働かなければならない人たちです。住宅ローンも残っているし、小学生や中学生の子どもだっています。トップのようにいつでも退役できる状態ではないのです。トップのまずい判断によって、彼らの人生は成り立たなくなるです。企業のトップは従業員の人生を握っていることの責任を自覚して経営すべきです。

 トップが「品質」に舵を切るということは、
  ・必要な人材予算を確保し、
  ・「品質」に対する教育環境を整え、
  ・「品質」の視点からの技術者教育を見直し、
  ・品質保証部門の役割の見直しや体制の整備、さらに組織内での位置づけを見直し、
  ・社員の品質に対する意識改革の先導役とし、
  ・品質向上に繋がる取り組みに対する支援やその評価の仕組みを確立する
ことである。これらは、トップが一歩踏み出せば実現するものばかりです。

 もしかすると、企業のトップも従来の品質に対する考え方を改める必要があるかもしれません。多くの組織では、品質を向上させるにはコストがかかると認識されています。それは前にも触れたように、従来の日本の品質保証は最終工程のテストの段階で不具合を発見しているからで、そこで発見されたのでは、大幅な手戻りコストがかかってしまうのは当然です。

 クロスビーの文献には、「品質コストとは、ものごとを正しく行わないことから発生する費用です」と書かれている。「最初から仕事を正しく行うこと」ことによって、余分な品質コストをかけずに品質は確保できるというのが、この本の趣旨です。だから原題が「Quality is Free」(品質はタダ)となっているのです。

 従来、最終の工程でのテストで対応していたのを、上流の要求仕様の作成プロセスから対象にすることで、クロスビーが主張するところに持っていけるのです。言い換えれば、80年代の日本の品質保証の取り組みは間違えていたということです。今こそ、「21世紀に通用する品質保証の体制」を構築すべきときです。

 企業の収益は、このような取り組みの結果として得られるものであるという認識を共有する必要があり、大学などの教育界も早急にこの方向に沿ってカリキュラムを再編成すべきです。そうでなければ、日本の若い世代が活躍できる「場」を失うことになります。それは、「日本」を過去の国歴史の中の国にしてしまうことに繋がってしまいまう。私としてはそれを黙認するわけにはいきません。

2.5)新しい品質保証体制の提案

 もともと品質保証部門は、開発・設計部門とは独立した存在でないと機能しません。品質保証部門は製品の最終責任を負うと同時に、その判断は組織のトップに対して責任を負います。そのことは当時の日本の企業も認識していました。だからほとんどの企業では、品質保証部門は開発や設計部門から切り離されていたし、今もその形は残されていると思います。

 位置的にはトップに近く、製品を出荷するかどうかの最終判断は、品質保証の部門長の責任と判断で行われていましたた。80年代、工場から製品を積み込んで出荷しようとしているトラックの前に両手を広げて、「出荷を許可した覚えはない」と立ちはだかった“武勇伝”は、各所に残されているはずです。これが、ある意味では80年代の日本の品質を確保していたのです。

 ただしこのときは、上流のプロセスを巻き込まなかったことで、90年代の市場の要求の変化やバブル崩壊に伴う収益構造の変化に対応できず、品質保証部門の組織縮小を食い止めることができませんでした。当時の責任者にとっては、内蔵をえぐられる程の屈辱だっただろうと想像しています。そして、品質保証のスキルを持った多くの有能な人材が企業を去ったのです。

  (組織図)

 日本の企業が21世紀の世界にかつての製造業で生き残っていくには、もう一度「品質」を取り戻す必要があります。もちろん、かつての失敗を反省し、今度は最上流の要求仕様を作成するプロセス、あるいは、計画書の中で「要求にマッチしたプロセスを設計する」プロセスから保証することが必要です。

 そのために品質保証部門の組織として以下の3つの活動隊を持つことをお勧めします。
 「SQA部門」
 「製品評価部門」
 「判定委員会」

以下にこれらの活動部隊について簡単に説明します。

「SQAまたはPPQA部門」
 「SQA」はCMMによって広く知られた活動組織で、個々のプロジェクトにおいてプロセスと成果物を保証します。活動としては、プロジェクトで考えられたプロセスと成果物が実際の要求にマッチしているか審査し、その後、承認されたプロセスが予定通りに実行されて、想定していた成果物をきちんと生み出していることを審査し保証します。

 また、私が勧めるこの組織にはいわゆる「SEPG」の活動も取り込んでいます(一般には、「SQA」と「SEPG」は担当者や組織を分けていることが多いようですが、私は2つの“機能”が存在するだけで、人を分けるとは解釈していません。以降、単に「SQA」と呼ぶときには「SEPG」機能を含んだものと読み取ってください)。

 実際、SQAの担当者はSEPGとしてのスキルを持ち合わせていることが望ましいのです。その理由は、プロジェクト計画書の中でPFDを使って表されたプロセスが、今回の要求にマッチしていることを確認するには十分な設計のスキルが必要になるからです。彼自身がPFDを使ってプロセスを設計し成功した経験がなければ、今回のプロジェクトの特徴を読み取って、そこで必要なプロセスが設計されているかどうかを見抜くことはできません。

 CMMに取り組んでいる多くの組織では、プロセスを審査する立場のSQAの担当者が、いわゆる評価部門出身で十分な設計の経験がないために、プロジェクト計画の段階でプロセスの内容を審査していないと思われます。せいぜい、機械的な“チェック”で済ましているのではないでしょうか。計画段階でプロセスの合理性を検証できていない以上、その後のプロセスの審査や、プロセスの変更の判断も形式的なものにならざるを得ません。当然、その影響として、現場には“過剰”な工数が投入されることになります。

 本当に、上流から品質保証を実現するには、組織の中での設計の成功者を確保する必要がありますが、多くの場合、設計部門の責任者は、そのような人を離したがりません。したがって、ここに企業のトップの意志を見ることができるのです。設計技術やテスト技術、さらにプロセスに精通した人を確保することで、SQAの活動が単なるプロセスの「監査」から脱却することができ、本来の上流から下流までの品質保証の体制を構築するための最大の条件をクリアできるのです。

 プロセスの審査の対象には、「検証可能性の視点から要求仕様をレビューする」プロセスや、「テストケースを設計する」プロセス、「テスト環境を整える」プロセス、「テストケースに沿ってテストを実施する」プロセス、「バグを再確認をしてツールに登録する」プロセスなどの評価部門のプロセスも含まれるので、SQAの担当者としては、設計部門と評価部門の両方の出身者が必要になります。それぞれの部門において豊富な経験を持った人材を確保することが、21世紀の品質保証体制を構築するための必須条件になるのです。

 また、設計と評価の優れた人材をSQA担当者として確保することで、新しい品質保証の活動も可能になります。たとえば、SQA活動に「4つの機能」(次項の「SQA活動」を参照)を持たせることで、総合的な品質保証体制を構築しやすくなるのです。

「製品検査部門」
 これは従来からあった機能テストなどの最終検査部門です。多くの組織では、品質保証部門にはこの組織だけが残されていると思われます。活動としては基本的にはそれと変わりません。いわゆる、製品レベルの機能テストケース作成とテストの実施によって、出荷できるレベルにあるかどうかの判断をします。この最終判定は、この後に述べる「判定委員会」に委ねる方法もあります。

 この他には、機能レベルのテストエンジニアとしての立場から、望ましい「設計者テスト」へのコンサルティングや、テストケースが膨張しないための設計や実装方法を指導したり、設計グループとの連携を進めることで、納期の短縮やコストの削減などの市場の要求にトータルで対応する基盤を確立することが必要になる。

「判定委員会」
 これは、従来の品質保証部門にはない組織です。ここでの主な活動は、
  a)SQA結果やテスト結果の判定
  b)SQAの中で発見したベストプラクティスの評価と収集
  c)プロセスの逸脱や組織ルールの逸脱に関するエスカレーションの判定と実施
  d)パワーハラスメントや特定のメンバーに対する過剰責務状態の判断と告発

 d)を除いてはCMMの取り組みの中で実施しているはずですが、多くの組織では、CMMの活動が組織の中で独立していて従来の品質保証活動と一体化していないようです。そのため、現場にはそれぞれの組織から活動の指示や要請が発せられることになり、現場の人たちの負担を増やすことも起きています。

 本稿で提案しているのは、CMMの活動と従来からの品質保証活動を一体化して、新しい品質保証活動の体系を構築しようというものです。CMMは上流からのプロセスを保証する活動であり、その領域は、これまで日本の組織が行ってきた品質保証活動にとって扱われていない部分です。これら2つの活動がお互いの強みを活かすことで、上流から最後の出荷判定までのすべての範囲のプロセスと成果物の品質を保証する体制を築くことができるのです。

 このような品質保証活動は、明らかに「損失の発生を予防する」ところに力を発揮します。つまり、この組織は売上げは上げないが、ここでの活動によって損失を減らすことができ、最終的に「利益」を上げることになるのです。

 これまで多くの組織は、このような活動を主体とする組織を持たなかったことで、売上げを上げるものの、直ぐその後から大きな損失も上げていたのです。企業の低い営業利益率がそのことを物語っています。そして、目減りした利益を挽回するために、さらに売上げを上げようとして、組織のキャパシティを越えた仕事を持ち込んでしまい、そのことでPLやマネージャーが疲弊し、雑になったプロセスによって品質を低下させ、さらに収益構造を悪化させるという悪循環に陥ったのです。

 ここで必要なのは、売上げを上げるための仕事を増やすことではなく、損失を減らすための取り組みなのです。そのためには、本稿で提案するような、CMMのSQA活動やSEPG活動と一体化した新しい品質保証体制が必要なのです。

 かつて「コストセンター」と揶揄されたのは、品質保証部門に設計などの上流プロセスに精通した人材を確保しなかったことに原因があり、一体化した新しい品質保証の体制によって、90年代以降の混乱の中で、「コストセンター」というレッテルを貼られて大きく傷ついた品質保証部門に対する認識を変えさせるチャンスでもあります。

 今、CMMが広がりを見せているときに、クロスビーが主張する「上流から下流まで」の本来の品質保証のあり方を取り戻さなければ、日本の製造業は蘇るチャンスを失うことになるでしょう。

2.6)SQA活動の拡張

 ここでいう「SQA活動」は、上流のプロセスとそこで生み出される中間成果物から保証するための活動であり、基本的にはCMMが提案するSQA活動を想定しています。ただし、日本に於けるSQA活動(CMMIではPPQAと呼ぶ)では、ほとんどの場合、設計の経験者をSQA担当に配置していません。日本のCMMでは、設計の経験者の役割は「SEPG」であって「SQA」ではないと思い込んでいる節がありますが、私は、この考え方を否定する立場をとっています。機能を分けるだけで担当者を分けることは間違いだという考え方です。

 設計の経験を持たない状態でSQA活動を行おうとすると、機械的なプロセスのチェックにしかならないし、計画段階でのプロセスの設計も、かつての「ISO-9001」の時のように「組織の標準プロセス」を持ち込むだけになって、プロジェクトにおいて要求にマッチしたプロセスを自在に設計する機会が奪われる危険性が高くなります。

 確かに、テーラリングの場面でSEPGの担当者が出向いて指導することは可能ですが、それで承認されたとしても、SEPGの関与がそれだけだと、その後の運用の中でのプロセスの変更や、逸脱状態の“程度”の判断などへの対応がスムースに運ばないことが容易に想像できます。実際には、その都度SEPGの出番になるでしょう。だったら、SQAの担当者に豊富な設計の経験があることで、通常のSQA活動の中で発見した逸脱状態の“程度”や、必要なら逸脱状態から回復するためのアドバイスもその場でできるでしょう。

 このような意味から、私は、SQAの担当者には設計部門の最高の人材を当てることを求めているのです。企業のトップの意志があれば実現するはずです。

 具体的なSQAの活動としては、プロジェクト計画作成の段階からプロセスを審査し、適切に設計できたプロセスに対して適切に実行できるように支援することが主たる活動です。もちろん、ここにはテストプロセスも含みます。

 このほかに、私は、SQA活動の中に以下の活動を含めることを勧めています。
  「4つの機能」
  「スキル認定」
  「過剰責務状態の情報収集と監視」

 「4つの機能」とは、簡単にいえば、
  「ミツバチ機能」
  「ペースメーカー機能」
  「ブレーキ機能」
  「コンサルティング機能」
である。

 たとえば「ミツバチ機能」によって、SQA活動の中で発見したベストプラクティスを他の組織に適合するように調整して普及を促進します。同じ企業の中でも、扱う製品が異なったりすれば、他の部門で活用され成功しているプロセスでも、そのままでは使えないことが多いのです(これが現場レベルで水平展開できない理由です)。他部門のプロセスを取り入れるには、成果物の一部を変更したり、プロセスをそれに合わせる調整が必要になりますが、現場のPLやエンジニアには、必ずしもそのスキルが十分ではありません。それをSQAの担当者がカバーするのである。

 また、多くの組織では、ちょっとした取り組みによってある程度の効果を得ると、そこで取り組みを止めてしまうことが多いものです。もともと、プロセスの改善などに取り組んだ動機は、バグや仕様変更の多発、納期限に間に合わないという問題状況の中で何とかしなければ、というところに起源を持っています。そのため、それらの「問題」が解消すれば、取り組みの動機を失うのです。

「ペースメーカー機能」は、このように取り組みの動機を見失ったときに、データなどを使いながら、まだ改善の余地があるところを指摘し、そこに取り組みむことの意義を説明して動機づけをすることです。この支援によって、トラブルが解消しても取り組みを継続することの意味を知り、改善の取り組みの楽しさを知ることもできるのです。

「ブレーキ機能」は、事前に承認されたプロセスに対する逸脱状態が限度を超したまま作業を続けることを防止したり、まともな計画が策定されていない状態でプロジェクトが承認されることを防いだり、PLや一部の人に過剰な負荷がかかっている状況を告発して改善に導くことです。損失の発生を未然に防止する重要な活動でもあります。実際にある組織では、プロジェクト計画の段階でSQAの承認がなければスタートできない仕組みを実現しています。

「コンサルティング機能」は、現場の人たちの取り組みの相談に乗ったり、その状況の中でリカバリー方法をアドバイスしたりすることです。要求仕様の書き方や、計画書の書き方なども、実際のプロジェクトの中に入って、具体的に指導することも重要です。SQAの担当者は、単にプロセスを“監査”するのではなく、うまくいく方法を指南する役割も負うべきです。だからこそ、現場の人たちは彼らSQAのアドバイスを受け入れるのです。
(「4つの機能」についてのもう少し詳しい情報は私のホームページの「プロセス改善活動の勘所」の中の「SQAの活動」を参照してください http://homepage3.nifty.com/koha_hp/process/Proc.Square/Proc.Square.SQA.htm

 「スキル認定」いうのは、組織のメンバーのスキルを認定する活動のことです。SQAの普段の活動の中で、たとえばベストプラクティスを発見したり、うまい考え方や実際にうまく実施できているケースを目にすることになりますが、それは、それぞれのプロジェクトのメンバーのスキルに触れる機会でもあります。つまり、SQAのメンバーは、組織のメンバーのスキルをその目で確認できる立場にあるのです。

 ここでの認定方法の特徴は、単にそのことを“知っている”というだけでなく、実際にうまく“活用できる”状態にあることを認定することを求めています。設計やテストに精通したSQAが客観的に見て判断することで、客観的なスキルデータを収集することができるのです。

 そこで、ソフトウェア技術者のスキル情報をこの「SQA部門」に置くことで、スキルの情報を逐次更新することができます。さらに、SQAがこれらの情報を保有することで、プロジェクト計画書の審査においても、適切なメンバーが確保されているか、あるいはどのようなテーマのトレーニングが必要か、ということも分かるので、プロジェクトのリーダーやマネージャーに進言することもできます。

 スキル情報の更新方法としては、SQAの活動の中で入手した情報で更新する方法と、プロジェクトの終了の時点で、PLからメンバーの「スキル認定申請」を発し、SQAの方で審査する方法があります。(スキルの把握については項を改めて触れることにする)

 最後の「過剰責務状態の情報収集と監視」というのは、90年代以降のリストラによって、PLや一部のエンジニアに過剰な負荷がかかっていることが多い。彼らは「仕事だから」ということで頑張っているのですが、それが度を越しているケースも少なくありません。そのため、鬱病などの症状を発して戦線からの離脱を余儀なくされ、そのことが他のPLやエンジニアに更なる負荷をなって苦しめているのです。ある意味では、倒れるまでこの状態から開放されないということも起きています。

 このような状態を放置したままでは有能なエンジニアやPLを失うことになります。離脱したPLやエンジニアの中には、ソフトウェアの世界に見切りをつける人も少なくありません。もちろん、長期的にも企業の株主利益にも反しますし、日本の国益にも反するものです。さらに、今の時代では、離脱した当人も、次の仕事が見つかるとは限りません。その場合、いわゆる「ワーキング・プア」の状態に堕ちてしまう危険もあるのです。ここから「自殺」という形で人生を終えるケースも少なくないと思われます。

 限度以上に負荷がかかっている状態を改善できなかったことで、一人の人生が狂ってしまうのです。これは、「組織の犯罪」であり、これを防ぐことが出来なかった上級マネージャーの犯罪でもあるというのが私の考えです。組織上の“パワー”を背に、一人の人の人生を破綻に追い込むことは認められるものではありません。

 今日では、「パワー・ハラスメント」(通称、パワハラ)という概念が日本にも定着しつつありますが、「セクシュアル・ハラスメント」と違って、パワハラを防止するための組織は現時点では定義されておらず、現在の日本の組織はこの状態を防止できないのです。

 SQAは、日常活動の中でプロジェクトの様子をチェックしていて、PLや個々のエンジニアの限度を超えているかどうかの判断もできます。また、コンサルティング機能によって、いろいろな相談ごとに乗ったりしているので、その活動の中で「パワハラ」を扱うことができます。さらに、企業のトップにエスカレーションする手段も持っていますので、ソフトウェア開発の世界に於いては現時点では適任と考えています。逆に言えば、このような問題を防止するために、組織はこのSQAの活動を活用すればよいのです。

2.7)設計部門との連携

 品質保証部門が、プロジェクトの計画プロセスから品質を保証するためには、単なる“監査”とか“審査”として関わるだけでなく、あるべき姿を求めて設計部門との連携が必要になります。

 プロセスはいつまでも同じでは済みません。要求が変化する以上、プロセスも変化させる必要があります。要求の変化に対応するためのツールも出てくるでしょうし、そのツールを使った場合はプロセスも変化することになります。チーム編成もいつも同じではない以上、プロセスもいつも同じではないのです。

 設計部門の人も要求に対応するために斬新なアイデアを出すかも知れません。毎日、現場の作業の中で工夫が求められている中にいる人は、いろいろなアイデアを考えつくものです。そこでは、品質保証部門の人では考えつかないものも少なくないはずです。

 また、世界では要求や仕様を発見することにフォーカスした要求開発の研究も進められていますし、設計技術も日進月歩の状態であるります。これらの技術が変われば、当然その部分のプロセスや成果物も変化します。すべてのプロジェクトのプロセスを一斉に変化させることはリスクが高くなりますが、特定のプロジェクトで試行してみて、その効果を確認したうえで、組織内に展開すればよいでしょう。実装プロセスも、自動生成の技術が発達すればプロセスは大きく変化するし、計測の方法や基準も変えなければなりません。

 SQA担当者が外部のカンファレンスや交流会などで活動する中で、自社でも使えそうな新しい方法を入手することがありますが、品質保証部門の中では試行する機会は少ないと思われます。そこで、設計部門と連携ができていれば、実際の適当なプロジェクトの中でそれらの方法を取り入れるための方策を講じることができます。特に、品質保証部門からの提案や情報に対して、率先して試行してくれる設計部隊が存在することが望ましいのです。試行などで取り組んだときの効果や方法に関する情報をSQAの方で収集することで、他の部門にも適用できるように改良を加えることもできます。

 こうした連携がないと、SQAなどの組織で用意したプロセスを“標準”として押し付けることになるか、設計の現場でこれらの“押し付け”を無視するかの何れかの状態になってしまいます。前者は、それらのプロセスは早晩、時代の要求を反映しない状態に陥って、90年代に起きた品質保証部門と同じ運命をたどることになります。

 後者の場合は前者よりも悪く、何も改善しない状態です。もちろん、品質保証部門と設計部門は反目し続けることになるでしょう。今までほとんどの組織では、設計部門と品質保証部門は、必ずしも連携してこなかったと思われます。時には、反目しあってきたくらいです。それは組織として不幸なことであり、21世紀では、そのような状態では競争に勝つことは無理でしょう。

2.8)ドブに捨てたコストの把握

 そこで行われた作業は、“その時点では”現場の人にとってはすべて“必要な作業”という認識です。同じことを2度繰り返しているわけでもありません。運悪く評価部門で発見されたバグを改修する作業も“必要な作業”と認識されているのです。

あるいは、「こまかな仕様は設計作業を進めていかないと抽出できない」と思っている限り、設計作業の途中で認識された仕様によって、既に実現方法まで考えられた部分を作り直す作業は、無駄な作業とは認識できないのです。でも、この認識のままでは状態は今後も改善しません。

 PFDなどのツールを使って、ゴールに到達する最小のプロセスを組み立てられるようになって、初めて、「このバグの改修作業」は無駄な作業であったと認識できるようになります。つまり、それが無駄な作業であると判断できるには、それよりももっと上手くできる方法を知っていることが前提となるのです。私がここで提唱する品質保証部門(SQA部門)が十分な設計の経験者を確保することで、組織的にこの判断ができるようになるのです。

 問題が一向に減らない原因の1つに、各プロジェクト、あるいは製品(バージョン)毎にコストを把握していないことも考えられます。実際に行われた作業と、そこで費やした工数やコストを集計し、さらに手戻り作業を特定し、そこから必要であった作業と無駄であった作業を切り分けて分類します。もちろん、このとき「こうすればこの作業は必要なかった」というように「代わりの方法」が見えていることが必要です。

 出荷後に発生したトラブルも、現場の人たちには「飛び込み作業」となって割り込んでくる。このときの作業が必ずしも分類して集計されていないことが多いようですが、これは組織が明確なルールを作ることで、集計は比較的簡単に徹底できます。トラブルへの対応作業は、終了時に報告書の様な形でデータが残されることが多く、そこに投入した工数を記入することは難しくないからです。

 これらの「手戻り工数」は、単に月単位で集計するだけでなく、製品単位に集計する手段も確保しておく必要があります。特に、出荷後のトラブルは、その製品のプロジェクトは一旦終了しているので、そのままではプロジェクトの工数に集計できません。そのため、単純に月単位の工数で集計されているだけのケースも少なくないようです。でもこれでは、どの製品、どのバージョンの手戻り工数だったのかが見えなくなるし、1年前に終了した派生バージョンのどのプロセスに問題があったのかも検討できません。

 この種のトラブルは、しばしば決算月をまたいで発生するのと、トラブル対応の費用の計上が別勘定でひとまとめになっている可能性があるために、多くの組織では、実際に行われたプロセスにさかのぼってきちんと実コストの検証がなされないままになっていると思われます。

2.9)時代の要求を追跡する仕組み

 設計部門の人も、新しい設計技術を追跡し入手するでしょうが、彼らは通常は納期のある仕事を担当しているため、設計技術以外の情報まではなかなか収集に手が回りません。そこで、SQAの担当者が、外部との情報交換などの活動によって他社の動きを知ったり、カンファレンスに参加したり、雑誌などのニュースから、新しい「時代の要求」をキャッチすることも重要でなのです。

 時代の要求をキャッチするには、技術系の雑誌に限定しないで、経済系の雑誌も目を通しておくこことは重要です。自分たちの作業におけるQCDの形で発生する要求は、必ずしも「技術」から発せられるとは限らないからです。

 もちろん技術動向の変化は、QCDに関する要求の主要なものです。デュアルコアのCPUの出現によって、複数のシステムで実現していたことを1つのシステムで実現するような要求が増えるでしょうし、CPUに依存しない言語で書かれたプログラムが増えることで、派生開発の中で「移植」「流用」の要求が増えることにつながるでしょう。

 とはいえ、QCDの要求は「技術」以外のところからも発せられることは確かです。たとえば「9.11同時多発テロ」の発生によって、セキュリティ関係の機能が強化されたし、六本木のビルで起きた回転ドアでの死亡事故によって、安全性に対する規格が制定されました。通常の機能の中でも、安全性を確保する方向に制御が働くように仕様の変更が求められました。あるいは1997年のアジアの通貨危機のあと、コスト削減の要求が強く発せられるようになりました。ある製品では、新興国の経済力が高まることで、海外向けの仕様が追加されることになったケースもある。

 このように、技術動向の変化以外の要因で、製品やシステムの要求が変化することも少なくないのです。そのため、日常の中で範囲を広げてアンテナを張っておく必要があります。そうでないと他社に出し抜かれることになるからです。

 ここでは、2段階のステップが必要になります、1段階目は、捉えた「市場の要求」の芽が自分たちに影響するかどうかを判断しなければならなりません。すべての市場の要求の芽が自分たちに影響するとは限らないからです。

 第2段階では、捉えた時代の要求の変化に応えるための技術や情報を収集する必要がある。もちろん、対応方法は自分たちで考え出すことも必要ですが、すでに世の中に提案されていたり、他社がそれに対応していたりするかもしれません。対応のスピードを考えたとき、設計グループと手分けして収集するほうが効率的です。

 そこで収集した対応方法や技術が自分たちの組織にとって有効な方法(手段)か、という視点から整理する必要があります。このとき、品質保証部門だけでは必ずしも判断しきれないかも知れないので、設計部門のメンバーと一緒に検討すればよいでしょう。使えそうな方法や技術であれば、そのあとで実際に試行する必要があるのですから。試行の結果がよければ、SQAの「ミツバチ機能」を使って、組織内に紹介したりコンサルティングをしながら展開を推進することになります。

 品質保証部門が日常的に設計部門と連携ができていれば、情報の交換はスムースに進められるでしょう。SQAの担当者が見つけたカンファレンスの中に、設計者にとって有益なテーマを発見したときは、速やかに設計部門に情報を流し、設計部門からの参加を促すのも良いでしょう。

2.10)スキルの把握とスキルアップ対策の推進

 最近は、「ITSS」や「ETSS」ということでエンジニアやPLのスキルを把握することが、一種の流行のようになっています。ただ、その際のスキル情報をどの組織が保持するかというところで異論があるようです。いちばん避けたいと思うのは、生のスキルデータを人事部門が保有することです。

 私が進めるのは、品質保証部門のSQA/SEPGグループで保有することである。もともと、通常のSQA活動によって組織内のリソースのスキルを把握する機会を持っている。そして、スキルデータとしては、少なくとも
 ・知っているレベル
 ・活用できているレベル
の2段階で把握したいところです。組織にとって欲しい情報は、その技術を実際のプロジェクトの中で「活用できる」人であるかどうかである。

 「知っている」レベルであれば、本人申請でも構いません。文献を読んで知っているとか、該当するセミナーや講演に参加したというだけでも構わないでしょう。しかしながら、「活用できる」レベルは本人申請というわけにはいかない。第3者が判断する必要がある。そしてその適任者がSQAの担当者なのです。豊富な設計の経験を持ったSQA担当であればその判断は可能です。だからこそ設計の最高の人材を確保することを勧めているのです。

 SQAがリソースのスキル情報を持っていることで、プロジェクト計画書の審査の段階で、今回のプロジェクトでの要求とメンバーのスキルとがマッチしているかどうかを判断できますし、SQAに対して事前にPLから候補者のスキルを照会することも可能です。さらに言えば、PLの選定そのものに対してもコメントできるのです。

 プロジェクトの要求とメンバーのスキルに不足があるときは、必要な時期までにある程度のレベルまで引き上げるための「トレーニング計画」を立てることになります。その判断をスムースにするにも、SQAに豊富な設計の経験者が必要なのです。

 本提案では、SQA部門にはトレーニング・コースも用意することを勧めています。その理由は、QCDに対する市場の要求は絶えず変化しており、その要求に応え続けるためには、人材の品質を引き上げる役割も一緒に負うほうが対応しやすいということである。

 SQA活動の中で入手した情報を元にして、トレーニングコースの中で使用するテキストも自在に調整できます。私自身、セミナーの資料はテーマによっては1年に数回改訂します。使用している最中にもっと分かりやすい表現やイメージしやすい表現に気がつくからです。自社で提供するトレーニング・コースのテキストですから、SQAが担当することでもっと現実的なものにすることができるのです。

 そしてSQAが実際にいくつかのテーマの講師を担当することで、「コンサルティング機能」もスムースに運ぶはずです。そのために、設計やテストの専門家を集めたのですから。しかも実経験をバックにして講師をすることで、さらにいろんなケースへの対応方法が彼の下に集まってきます。それを再びテキストに反映したり、「コンサルティング機能」や「ミツバチ機能」に活かすこともできます。

 もちろん、ソフトウェア・エンジニアリングの領域は広く、そのすべてのテーマに対して、自分たちSQA(品質保証部門)だけで対応することは難しいと思われます。テーマによっては、社内の設計者の支援を仰いだり、外部のコンサルタントや大学の関係者を集めることも必要になりますが、その対応もすべてSQA部内で計画すればよいし、そのために必要な予算は確保する必要があります。

 SQAが保持しているスキル情報の更新は以下の2段階で対応します。
 ・アセスメント活動から得た情報に基づいてスキルデータベースを更新します
 ・プロジェクト終了時にPLから出される「スキル申請」に基づいて審査し更新します
後者の更新手段は、同時に「スキル申請」を書いたPLとしてのスキルの判定にも活用される。

 さらに、SQAがこうした前者レベルのスキルデータを保有することで、自社の長所と短所が見えることになります。個々のスキルデータの分析から組織全体で見たときのスキルの偏りなどが明らかになり、そこから組織的なスキルアップのカリキュラムを策定することができる。

 ここまでカバーすれば、品質保証部門は90年代の「コストセンター」ではなく、必要不可欠な存在になるはずでです。もっとも、「プロフィットセンター」が存在するには、どこかにそれを支えるための「コストセンター」が必要になります。もし「コストセンター」をすべて取り除いてしまったら、以前には「プロフィットセンター」だった部門の効率が低下するはずです。そのことを2000年以降の日本の企業が証明したはずです。

 90年代の品質保証部門では、「プロフィットセンター」を支え、さらに飛躍させるための「コストセンター」としては不十分な存在でしかなかったのです。

2.11)「人」の破壊を防止すること

 品質保証部門は、製品の品質だけを扱えば済むのではありません。「人」の品質も一緒に扱わなければ製品の品質を向上させるという目的を達成できません。そしてSQAはプロセスの品質を保証することを主たる責務としています。プロセスとは分かりやすく言えば「作業」であり、それは人の行為です。人の行為の品質を引き上げるには、必要な技術の習得の他に、「モチベーション」を高く保つことも重要になってきます。

 残念ながら多くの組織では、モチベーションを低下させることを無造作にやっています。そしてその行為を防止する仕組みを持たないし、それを担当する組織も持っていないのが現状です。品質保証部門の中にあるSQAの組織がこれを担当することで、リソースの破壊を食い止め、モチベーションの低下を防ぐことが出来ると考えています。

 もとより、品質保証部門は、製品の品質に責任を負う組織であり、SQA部門を併合することで上流のプロセスから最終製品の品質までトータルで品質保証ができる体制が整う。当然、そのために必要な権限も与えられており、その権限には、PLやエンジニアのモチベーションを下げる行為を排除することも含まれます。それを監視するのがSQA部隊であり、判断して裁定を下すのが「判定委員会」です。

 最終製品の品質は、
  ・要求に対して合理的なプロセス
  ・要求仕様書の出来栄え
  ・優れた組織力、人材、教育内容
  ・適切な設計・製造の技術、開発環境
  ・モチベーション
の合成によって実現します。(参考「情報処理」1995.5 「ソフトウェアプロセス評価の動向」)
この点について誰も反論はないでしょう。だが多くの組織は、この「モチベーション」を維持し、高める施策を講じていないし、そのための仕組みも持っていないのである。

1)過剰責務の問題
 日本のほとんどの組織は、90年代のバブル崩壊以後、プロセスを改善することもなく、無節操なリストラを繰り返すばかりです。そのため却って収益の低下を招き、それをカバーするために売上げを増やそうと過剰な仕事が現場のPLや一部の有能なエンジニアに降りかかってきます。リストラによって見かけのコストダウンは実現しても、そして直近の利益は確保しても、中長期的には生産性の低下や品質の悪化を招くことは明らかです。

 2007年の日本政府の目標の一つに「生産性の向上」が謳われています(日経新聞2007.1.4、太田経済財政担当相の談話)。

 この場合の生産性は「労働生産性」と思われます。労働生産性を高めるには、IT環境の効率的な活用やプロセスの改善によって労働時間を増やすことなく(労働コストを増やさないで)生産を増やすことによって実現します。たとえば私が提案しているXDDPによる派生開発では30%以上の生産性の向上は可能だということは確認できています。

 政府としてはこの実現方法については4月までに諮問会議でプログラムを作成することになっているようですが、おそらく分子の生産高(GDPのようなもの)はそれほど増えるとは思えないので、代わりに分母である労働者の数を減らす方向で実現しようと目論んでいるように思えます。本来なら、プロセスの改善が前提です。でも、過去の日本政府・経済界の行動の経緯からして90年代の過ちを繰り返す可能性が高いと考えています。

 また、最近話題になっている「ホワイトカラー・エグゼンプション」が、政府の「生産性の向上」の施策と繋がっている可能性も高いのです。年間収入の水準が400万円と低く設定されようとしているところが引っかかります。400万円というのは、ソフトウェア開発の世界で言えば、PLはもちろん、3年程の経験者の労働者はすべて含まれるはずです。資本生産性を固定した状態で労働生産性が向上すれば(一時的だが)収益が上がるのは当然で、その大半は配当に回されて外国人投資家を潤すことになるのです。

 こうした施策が実施されれば、ますます現場では過剰責務の状態が蔓延することになり、優秀な人材の喪失(流出ではない)やモチベーションの低下を招き、「品質」どころではなくなってしまいます。SQAはこの状況を監視し、限度を越えていると判断したときは警告を発します。それが改善されないときは「判定委員会」に持ち込んで判断を仰ぎ、状況によっては組織のトップに対してエスカレーションを行う。SQAは、こうした仕組みによって、現場のモチベーションの低下を防止する重要な役割を担うのです。

2)不当応援の防止
 SQAにはもう一つの重要な役割として「不当応援の防止」があります。PLやメンバーの創意工夫と頑張りによって予定よりも早く終了したとき、しばしば彼らの意志に反して遅れているチームへの応援に回されることがあります。彼らはその組織の中にあっては優秀なチームなのです。「不当応援」も1度ぐらいなら何とかなるでしょうが、これが2,3回続いたりするとモチベーションに影響します。

 上司であるマネージャーとしては、他のプロジェクトも期限内に終わらせることが求められているため、こうした対応になるのは心情的には理解できます。しかしながらこのマズい対応によって、この優秀なチームのメンバー(PLを含む)は、これ以降、予定よりも早く終わらせる工夫を停止してしまいます。実際、クライアントのPLから「2度と改善に取り組まない」と言われたことがあります。それも1件だけではありません。

 本来、彼らのプロジェクト計画は、組織によって承認されたもののはずです。もちろん現実には部門長はこの計画書を精査していないでしょうが、PLを中心として計画をまとめ、PFDを書いてサイズ見積りからスケジュールへと展開したのです。もちろんリスクもいくつか抽出し、その軽減措置も事前に捉えていたのです。そして実際にそれに沿って作業を実施したことで当初の納期限よりも10%ほど余して終了したのです。

 そこでは、リスク管理の効果からバッファとして確保していた工数がほとんどすべて余ったし、個々の作業も少しずつ余ったものが蓄積したものもあります。何よりもバグの発生率が大幅に改善したことで、テスト期間に確保していた工数も余りました。もとより、この計画は組織によって承認されたものである以上、こうして余った時間は、このプロジェクトのメンバーへの“褒美”とすべきなのです。彼らの勉強の時間に使われれば良いのです。

 ところが、現実にはこのメンバーを他の遅れているプロジェクトの応援に回してしまうことで、モチベーションは一気に低下するのです。何よりも、このような対応によって、「プロセス改善の意図」が正しく伝わらなくなるし、それを主導している「SQA」への信頼も消失します。先のPLから私に発した言葉は、「不当応援」によって私への信頼を消失させたことを物語っています。彼らとすれば、プロセス改善の意図は、自分たちの仕事を増やすための取り組みと受け取ってしまいます。実際、そのように認識しているマネージャーもいるのです。

 現場の人たちは、余った時間でもっと勉強したいと思っているし、自分たちの組織の将来を考えて、現行システムのアーキテクチャを再構築するために現状を調査したり、実際にあるべきアーキテクチャを考える時間に使いたいと思っているのです。そうでないと、このソースコードは1,2年後には維持できなくなる可能性があるからです。さらに、新しい CPUが出現したことで、自分たちのシステムにもその影響が及ぶだろうということは分かっているので、その準備をしたいとも思っています。そんなときに、遅れているプロジェクトに回ることを指示されたのです。モチベーションを低下させないことは容易ではありません。

 もちろん、遅れているプロジェクトを何とかしなければならないという事情も分かります。それなら、早く終わった人たちの信頼をつなぎ止めながら、説得する方法を考えなければなりません。あるいは、自主的に彼らの方から応援に回ることを申し出るような状況を作り出すこともできるでしょう。実際、「不当応援」の停止が実現している組織もあります。それによって、現場と部門長を含むマネージメントとの信頼関係を築くこともできています。

 ただし、これが実現するには、組織の責任者の理解と決断が必要になる。SQAの組織にそのようなこの状態を監視する役目を与えることや、現場のマネージメントに対して、モチベーションを落とさない対応を考えることを促したり、その方法を習得することを求めたりすることが必要です。

 そして、自身もときどき現場に降りて、そのような不満が溜まっていないことを確認しなければなりません。もちろん、そのような機会は多く作れないでしょうから、SQAとの連携を蜜にすることで現場の情報を把握することに勤めなければなりません。組織の責任者がそのような行動をとれば、プロセスの改善はスムースにいくでしょうし、そこに新しい責務と体制を備えた品質保証部門の活動が加わることで、コストをかけずに品質を向上させることもできるのです。

 これは、机上の空論ではありません、今すぐにでも実現できる方法です。最初にも書きましたが、私は5年ほど前からこの構想を持ってコンサルティングを進めてきました。この10年間に多くのクライアントでコンサルティングの機会を得ましたが、その中で、ここで紹介したことを断片的に実行してきたし、狙った効果を得ることもできています。「こうすれば実現する」というものを掴んできたわけです。だからこそ、ここに「21世紀の品質保証体制の構築」として、今まで温めてきた構想を公開するのです。

2.12)プロセス改善確認会議

 品質向上や市場の要求に対応するためのプロセスの改善などの取り組みは、最終的には組織全体の取り組みにならなければなりません。もちろん、それぞれの部門にはいろいろな事情があり、必ずしも他の部門と歩調を揃えることはできないかもしれませんが、取り組みの方向は揃っている必要があります。

 色々な事情で遅れて取り組むところは、先行して取り組んだところで採用した方法やその成果を学習することで、試行錯誤を減らしたりして取り組みの効率を上げることもできます。そのための情報交換の場として、取り組みの進行状況を確認するがこの会議の場です。

 この会議は、基本的には品質保証部門の主導で進めたいと考えています。そのために原則として品質保証部門の中で実施しますが、定期的には組織のトップの参加を求める必要があると考えています。

 会議の目的としては、たとえば
 ・プロセス改善活動を全社的な行動として展開するため
 ・各部門長やマネージャーが他部門の取り組み内容を知る機会を与えるため
 ・部門での取り組みの状況をトップが把握するため
 ・組織内での取り組みの状況知ることでマネージャーの行動の変化を促すため
 ・現場の取り組みを認識していないマネージャーの存在をなくすため
といったことになります。

 この会議では、最初に各部門での「長所/短所」を認識したり、それぞれの部門での事情を明らかにする必要があります。そこから、長所の展開方法やどのような短所の対応策を講じるかが、それ以降の課題となります。また、部門の事情によっては、対応が数ヶ月遅れることの承認や代案の提示などが求められることになる。

 そしてそれ以降の会議では、
 ・この間に取り組まれていることは何か?
 ・取り組みによって実際にどのような効果が上がっているのか?
 ・そこではどのような推進方法をとったのか?
といったことが報告され確認されることになります。報告の内容を飾るために現場に無理な対応が強いられていないかどうかは、SQAがチェックすることになります。

 また、この会議の中で、取り組みに対する「報償」を決める方法もあります。これまでの会議での報告内容やSQAからの報告を加味して、その期間の優れた取り組みをピックアップして、組織全体で称賛することはモチベーションを引上げるのに有効です。現場のプロジェクトでの成果が中心になりますが、上に挙げたような「不当応援」の回避が実現できている状況やリスク管理の成果など、マネージメントに対する評価も含まれます。特に、リスク管理や不当応援の回避のような“成果”として見えにくい部分がきちんと評価されることが大事で、これが表に見えるようになるというのは日常のSQAの活動の成果でもあります。

 社内カンファレンスの計画やその評価もこの会議で決めるとよいでしょう。もちろん、単発の社内カンファレンスだけを取り上げれば、必ずしもこのような会議を必要としないでしょうが、品質改善活動を組織全体に展開していく一環としての活動と捉えれば、品質保証部門が企画し実施するのが筋といえます。次回カンファレンスのテーマの選定やそこでの発表する内容の確認などは、この会議の性格にもマッチすると考えています。

 ただ、このような会議の推進は、ある程度改善活動が進んできた状況が見えてきたところで設置する方が安全かも知れません。そうでないと、一部の人にとっては、この会議が苦痛の対象になってしまう危険があります。したがって、この会議に報告したくなる状況が起き初めていることが望ましいタイミングといえるでしょう。

2.13)社内カンファレンス

 これまで述べてきた取り組みを組織の中に展開する方法として、まずは状況や方法、結果などを「知らせる」ことが必要になります。組織の規模が小さければ、簡単に機会を設けることもできるでしょうが、各地に開発組織が分散しているような企業の場合は、「社内カンファレンス」のような形で、広く活動を知らせる機会を設けることも必要になってきます。

 もちろんそれにはある程度のコストはかかります。だが、それによってモチベーションが高まったり、具体的な取り組みが広がれば、それくらいのコストは直ぐに回収できるはずです。90年代には、この種の活動も近視眼的なコスト削減の大合唱の中で消滅したところもありますが、私に言わせれば、役員の報酬を削ってでも実施すべき項目です。

 カンファレンスのテーマは、半年から1年前に知らされる必要があります。そのテーマはカンファレンスという場を使って、組織としての評価の主要ポイントという意味ですので、それによって、各部署での取り組みの方向性も決まってきます。もちろん、テーマは1つでなければならないというわけではありません。組織にとって必要と思われるテーマや、SQA活動の中で把握しているそれぞれの組織で取り組まれている状況から、その内容を公開したいということでテーマを選定するという方法もあります。テーマが早い段階で公開されることで、それぞれの現場のプロジェクトの中で、自分たちの今の状況にマッチしたテーマを選ぶことができるでしょう。

 発表の対象は自薦や応募の他にSQAからの推薦という方法もあります。自薦や応募の場合は、SQAが中心となって事前に審査することになりますが、その中の大部分は日常のSQA活動で見ていますので、その中から発表を勧めることが起きていてもよいでしょう。ただ、SQAの体制が整っていない段階では、組織内のすべてのプロジェクトを把握できていませんので、自薦の方が多くなるかも知れません。

 そうして発表された取り組みの中で、大きな成果を上げたものや、広く組織内に展開出来そうなものなど、組織としての貢献度を判断して表彰します。ここで“能動”で動いたことで優れた工夫が認められるようなものをしっかり見つけることが、SQAに対する信頼につながることと、現場に対して組織の意志や方向を示すことになります。こうしてモチベーションを引き上げ、技術や方法を組織内に展開することで高い品質を確保し、変化し続ける市場の要求に対応し続けるのです。

3.)CMMの活用

 ここで提案する「21世紀の品質保証体制」にはCMMの取り組みを前提としています。もちろん、CMMのレベル認証が必要だというのではありません。CMMで勧めているような取り組みが、新しい品質保証体制を構築するのに必要だという意味で“前提”としているのです。

 91年にCMMと出会って、私の経験の中でCMMを解釈し研究を進めてきました。CMMでいうところの組織の能力とは、組織の中で「点」として存在するスキル、その時点では「個人」や「チーム」の世界での成果に限られていたスキルや方法を、「面」としての組織全体に広げる手段によって、組織の能力となると理解したのです。

 そのとき、SQAの役割が重要であると考えるようになったのですが、そこに「能動」を引き出す仕掛けがあることに気づいたとき、CMMを1つの手段としてさらに大きな目的のために活用できるはずと考えたわけです。その先に出てきたのが、日本のかつての品質レベルを取り戻すためにCMMを活用できるのではないかということです。CMMには、80年代の日本の品質保証の弱点であった上流のプロセスから保証する仕組みがあるからです。そこから今回の構想がスタートしたわけです。

 ここでは、SQAを品質保証組織と合体させる以外の活用点と注意点について説明します。なお、ここでは「CMM」と「CMMI」をまとめて「CMM」として呼んでいます。

3.1)プロセスを保証する仕組みを活用する

 CMMは“目的”ではなく“手段”です。何のための手段かというところは、それぞれの組織で解釈が変化するかもしれませんが、最終的には経営指標を改善する手段です。

 また、品質を左右する最大の要素は「プロセス」です。最終ゴールに導くための合理的なプロセスと成果物の連鎖を構築することがもっとも重要なのです。

 たしかに要求仕様の出来栄えも大きな要素ですが、そのような要求仕様を作成するためにも、今回の要求の特徴を反映した「要求仕様を作成する」プロセスや、「今回の要求を展開するための最適な要求仕様の構成を決める」プロセスが機能面と経済面での合理性をもっていることと、それが適切に実行されたことが保証されることが必要です。こうしたプロセスを構築するのを指導したり“保証”するのが「SQA」や「SEPG」の活動です。

 CMMではプロセスと成果物を保証する仕組みが備わっています。しかもそこで扱うプロセスは、要求仕様書を作成するプロセスや、場合によってはその前の計画書を作成するプロセスまで対象にします。これこそ、従来の日本の品質保証活動の中で抜け落ちていた部分なのです。

3.2)「能動」の喚起と水平展開機能を活用する

 CMMの大きな特徴は、「肯定眼」を前提としていて、そこでは他人のプロセスや成果物の中で良いところを積極的に肯定するということです。それはCMMの中の以下の取り組みの中に見出すことができます。
 ・ピアレビュー
 ・SQA活動

このほかに「ポストモーテム」も、同様の姿勢を前提としています。 

「ピアレビュー」の本来の趣旨は、成果物に残された欠陥をみんなで見つけあうことですが、その際に「肯定意見」を出すことが重要になってきます。欠陥の指摘だけだと「肯定眼」が育たず、折角の優れた方法も組織全体に広がりません。「肯定眼」は「能動」と繋がっているのです。もっとも、日本ではこの部分は省かれていることが多いようですが、それは本来のピアレビューの趣旨に反します。そもそもCMMの思想に反すると考えています。

 お互いに肯定眼で成果物を見合うことで、(自分よりも)優れた方法を認識することができます。“認識”するということは、“認める”ということであり、“受け入れる”という行動に繋がるのです。肯定眼で優れた部分を認めたとき、次の瞬間には能動的にその良い方法を躊躇なく取り入れることができるのです。組織の誰かに言われて取り入れるのではなく、「肯定眼」によって優れたものを発見したことで、自主的に、能動的に取り入れることができます。そして能動で行動したときは、そこで遭遇する障壁は工夫によって破られるのです。

 この状態で、優れた方法やアイデアが組織内に広がることが理想なのです。ある意味ではSQAすら必要ないのです。もっとも、現実にはそこまで理想的には運びませんので、SQAが“能動”を仕掛けるのです。CMMでは、SQA活動の中で発見した「ベストプラクティス」を組織内に展開することになります。その役をSQAが担っているのですが、その前に現場の人たちが「肯定眼」を持ち合わせているからこそ、「受け身」にならずに取り入れることができるのです。

 現場の人たちが受け身になっているときは、取り組みの中で遭遇する「障壁」はすぐに「出来ない言い訳」となって玄関の前に積み上げてしまうのです。そうしていくつも積み上げておいて、その囲いの中では従来のやり方に戻っているのです。従来のやり方で成功する見通しは無いはずなのに。

 この状態は、“能動”や“肯定眼”を引き出さないかぎり、防ぐことはできません。ここで提案する21世紀の品質保証体制を構築するにも、この“能動”と“肯定眼”は不可欠なのです。これが組織の「ベース」にあることで、合理的で品質を高めることに効果的なプロセスを組織内に展開し、さらに全社的な品質改善の効果を得ることができるようになるのです。したがって、CMMの取り組みの中で、この「ベース」が敷かれていることで、21世紀の品質保証体制の構築が容易になるのです。

3.3)CMMとの連携に対する懸念

 このように、21世紀の品質保証体制を構築する上で、CMMは非常に重要な役割を担うことになるのですが、残念ながら、日本の大多数の組織に於けるCMMの取り組みは、必ずしも適切な状態で勧められてはいないと思っています。たとえば以下の2つの点で疑問を感じざるを得ません。

1)CMMの意味を取り違えている?
 CMMを仕様モレなどの現状の品質問題を解決してくれる方法、あるいは品質改善の方法と誤解しているケースを目にします。もちろん、合理的なプロセスを普及させることで、結果的には品質の改善が手に入りますが、CMMそのものは「合理的なプロセス」を提供しているわけではありません。

 合理的なプロセスは、それぞれ組織によって異なりますし、10年間合理的であり続けるとは限りません。ですから合理的なプロセスは、それぞれの組織の中で編み出す必要があります。CMMは、そこで編み出された合理的なプロセスを組織に展開し、維持し、改良するための手段を教えてくれているというのが私の認識です。

2)CMMの取り組み方を間違えている?
 CMMの取り組みが目的になっている状況もしばしば目にします。つまりレベルの認証が目的なのです。でも、CMMは“手段”であって“目的”ではありません。もちろん「レベル認証」は組織の今の状況の確認として活用することには問題はありませんが、それを目的にすることで誤った方向にいく危険があります。

 また、組織の中での取り組みの姿勢が“受け身”になっていて、能動を誘い出していないことも危険です。多くの組織では、いきなり「標準プロセス」が外(外部のコンサルタントなど)から提供されているようです。でもそのプロセスはその現場の誰も実践したことがありません。もしかすると、それを持ち込んだコンサルタントも実践したことがないかも知れないのです。

 じっさい、現状の要求仕様のあり方を放置したまま、いろいろな取り組みが課されたり、CMMとしての取り組みが、それまでのプロセスと置き換える形になっていないため、現場の人たちにとってはそのまま“負荷”になっているケースを多く目にします。

 このほかにも、CMMの取り組みを間違えていることで、ソフトウェア開発現場が疲弊する直接の要因になっているケースもあります。たとえば、
 ・要求仕様の構成や書き方を改善せずにCMMに取り組んだことで要件管理で破綻している
 ・負荷の増加から過剰責務の状態になったことで、取り組みの稽古や事前の準備が省かれている
 ・結局、最初の納期限の中で完成する目処が立たず、思考を停止させた状態が続いている
というような事が起きているのです。つまり、その組織では、CMMが現場の人たちの助けになっていないのです。

 もちろんこれはCMMが悪いのではありません。CMMの理解と取り組みを間違えたことに原因があるのですが、CMMへの取り組みがこのような状態のままでは、私が勧める「21世紀の品質保証体制」の中に取り込むことはできません。CMMそのものが現場の人たちに信頼されていないのですから、その中で重要な役割を担うSQAの信頼も失われているでしょうから、これを組み込んだのでは21世紀の構想は根底から崩れてしまいます。

 また、CMMの取り組みの中で、プロセスを自在に設計することなく、既成のプロセス(標準プロセス)をそのまま使ったりしている状況では、プロセスを自在に設計する能力が身に付いていないことが考えられます。21世紀に入って間もない今の時点でも多くの変化要因が見えています。プロセスを自在に設計するスキルが欠けたままでは、「21世紀の品質保証体制の構築」という構想に取り組むことは難しくなります。

 あるいは、レベル3という認証を受けていながら、PFDと一体でサイズ見積りに基づいたスケジューリングや進捗管理もできない状態の組織も何度も見てきましたが、この場合も、必要なプロセスを省いてしまうケースが多く、そこではCMMの取り組みの中で却って手戻り工数が増えていたりします。このケースも、現状のままでは私の勧める21世紀構想に取り組めない可能性があります。

 分かりやすく言えば、CMMが自分たちの中で何の効果ももたらしていないような状態では、21世紀の品質保証体制を構築するのに、CMMの取り組みと合体させることができなくなります。逆に、これらのことに注意してCMMに取り組むことで、従来の品質保証の仕組みと合体させることができ、上流のプロセスから最下流のプロセスまで一貫して保証することができるのです。

まとめ

 ここの揚げた構想は、単なる思いつきや“希望”を並べたものではありません。10年以上にわたって主に製造業を中心にプロセス改善のコンサルティングをしてきた中で、日本の製造業の実態が見えてきました。それは、私にとって背筋が寒くなるような思いをさせているのです。

 この状態を何とか改善し立て直す方法はないのか、ということでコンサルティングの場でいろいろな取り組みを勧めてきました。設計の経験者をSQAの担当者に充てたり、SQAの活動を主体にする方法や不当応援を回避する方法、SQAが計画段階でブレーキをかける方法、「オープンコンサルティング」という方法で効率良く組織内に広げル取り組みなどは、すべてこの構想の“部品”なのです。その意味で、多くのクライアントの皆さんからは惜しみない協力を頂きました。この場をお借りして深くお礼申し上げます。

今回の提案は、まだまだ内容的には不十分です。でも“完成”を待っていては間に合わない危険を感じていますので、ある程度の整合性が取れた状態になったと判断し、ここに公表に踏み切ったわけです。組織によってはこれだけの情報があれば取り組めると思います。

日本の製造業を残したい。いや残って欲しい、という思いは、私の勝手な思いかも知れません。その意味ではこのような提案を公開するのは傲慢かも知れません。でも、このまま日本の製造業が危機に陥るのを座して見送ることはできません。私1人で出来ることはほんの僅かです。でもこの提言がそれぞれの組織に届けば、私の願いの半分は達成したことになります。

以上。

 2007年1月
 「硬派のホームページ」主催者より