一般に、民間企業は市場の要請に応えるべく活動しています。
言うまでもなく市場は何時の時代でも、
開発期間、 （→市場の投入時期）
製品品質、 （→製品の信頼性）
コスト （→製品の価格）
の３方から、それぞれ短縮、向上、削減を要求してきます。しかしながらそれは均質な要求ではなく、その時々の技術的背景や社会情勢などを受けて、ある時期は開発期間の短縮を特に強く求めたり、あるいは品質に対して強い要請を出してきたりします。
この種の市場の要請は、初期の段階では誰の目にも見えるというものではありません。しかも一つの要請は１０年前後の時間の波を持っており、注意して見なければ見えないかも知れません。
当然、その時々の要請に対してある程度応えることができなければ、市場に残ることは困難な状況になります。
開発期間に対する要請
バブルの崩壊に引き続いて平成不況に入った頃、市場は、開発期間の短縮とそれに連動する形でコストの削減に対して強い要請を出しました。それまで１年の開発期間を確保できていた案件が、１０カ月とか８カ月、時には６カ月に縮めるという要請が出されました。
ソフトウェア関連でも、企業の大規模なビジネス・システムでは、以前は２年という期間を懸け、延べ６００人月で１０億円もの巨費を投入してきたものが、９０年に入って、６カ月で延べ３０〜５０人月、総額２億円以下というレベルまで下がってしまいました。６カ月という期間が要求されたのは、企業の経済活動がスピードアップし、開発に１年という時間をかけていては、企業を取り巻く環境が変化してしまい、開発途中で次々と仕様の変更が発生してしまうからです。コストはその結果として引き下げられたものです。
ＲＡＤの効果
ソフトウェアの世界では、一般にこの種の市場からの要請に対して、開発モデルや開発手法、分析・設計手法といった「手法」で対応してきました。裏を返せば、そのような対応方法が広がったからこそ、市場は不退転の要求を出して来たわけです。
９０年の初めに出された市場からのこのような“とんでもない要請”も、根拠もなく出されたわけではありません。当時、ビジネス・システムでは、ＣＯＢＯＬの自動生成技術が進んでいたこと、ＣＡＳＥツールがある程度使える状態になっていたこと、そしてＲＡＤ（Rapid Application Development）という開発手法が提案されており、これらを組み合わせることで、この時の市場の要請は実現されたのです。当時のＣＯＢＯＬの自動生成率は、米国では９０％、国内でも上手く設計することで８０％ぐらいは確保できたはずです。つまり、既にＣＯＢＯＬはコーディングしない状態に入っていたのです。もはやビジネス・ソフトの分野では、１０年前の開発スタイルは全く通用しなくなりました。
この時の波は色々な製品にも波及していたことは言うまでもありません。パソコンをはじめ、いわゆる組み込みシステムと呼ばれるものは、殆どその要請を受けたはずです。そこでは、それまで１年の期間を確保していたものが、６〜１０カ月に期間の短縮が求められたものと思われます。
それを達成した企業（組織）もあれば、達成していない企業もあります。当然、後者はその分、収益を確保できていないはずです。
頑張りで対応した？
もし、開発期間に対する市場の要請が“１／１０”であったなら、もはや「頑張り」では通用せず、“プロセス”を変えて、それなりの開発手法を導入する以外に方法はなかったものと思われますが、現実は５０％〜２０％程度の要求に加減されたこともあり、多くの組織では、この種の開発手法を用いることなく、１日当りの作業時間を増やしたりして、要請を実現したところもあるものと思われます。したがって、そのような組織では以前と比べて作業がきつくなっているはずです。
品質に対する要請
最近では、この種の市場の要請は「品質」に向う動きを見せています。市場は、この１０年で開発期間の短縮とコストの削減についてはある程度手に入れました。そこで今度は品質の番です。その意味では、市場は欲張りです。休むことを知りません。
ＰＬ法、 ISO-900１／１４０００
わが国でも既にご承知のように、不十分とはいえＰＬ法が施行され、企業側も品質に対していくらか意識が高まっています。また昨年から広がりを見せている「ISO-9001」も、輸出企業を中心に、自社の品質向上に繋げようと積極的に取組みだしていますし、新たに「ISO-14000」も浮上してきました。「ISO-14000」は、本来は環境管理及び監査の国際規格ですが、間接的に品質に作用します。
ファミリーレストランも、一時の「安かろう、悪かろう」を反省し、値段はそのまま（安いまま）で、サービスを以前のレベルに戻したり、メニューも見直して、品質のレベルを上げることで客の呼び戻しに成功しています。世の中は「品質」を求めだしたと言うことです。
ソフトウェアの開発手法も、オブジェクト指向がすでにニュースにならない状態になり、１９８７年に公表された「Clean room 手法」が、その効果を見せ始めています。
ＧＥの動き
折しも、今年（１９９６年）の５月１１日の日経新聞によると、ＧＥが２０００年を目標に、欠陥製品を「１万分の１」に削減することに挑戦することが報じられました。そのコストの削減効果は実に１００億ドルと報じられております。
その取り組みの裏付けとして「６Σプログラム」という手法を導入することも併せて報じられています。「６Σプログラム」は１９８７年にモトローラ社が開発したものですが、ＧＥがこれに取り組むとなれば、世界は間違いなくこの方向で動き始めるでしょう。
このような市場の動きは、今や品質を大幅に改善する技術的背景が、ある程度揃ったということを意味しています。あとは、これらの手法をどのように実践に移すかと言う問題だけです。
今後、このような「手法」について幾つかの「実績」が公表されると、間違いなく市場は“不退転”の意志をもって「品質の要請」を出してくる筈です。
プロセスを変える
既に述べたように、前回の開発期間短縮の要請では、関係者の「頑張り」で達成できた部分もありますが、次の品質の要請に対してはこの方法は使えません。２０％作業時間を増やして、２０％品質が向上する根拠はどこにもありません。それどころか逆に品質が低下する可能性の方が高くなります。それに、前回の開発期間短縮の要請の際に、１日の作業時間を増やす方向で対応した組織は、既にその余力を無くしていることが考えられ、今回の要請には殆ど応えることは出来ない可能性があります。（実際には、前回と同じスタンスで取り組むことになるでしょう）
結局、品質の向上という新たな市場の要請に応えるには、開発プロセスそのものの改善以外に方法はありません。着実に開発プロセスのレベルを上げていくことです。
製造現場においても、要請が単なる品質の改善ではなく大幅なコストの削減を伴わなければならない以上、おそらく今までのような「ＱＣ活動」では間に合わないと思われます。
問題は、実際に市場がその要請を出すまで（１９９８〜２０００年ごろ）に、どうやってその「スキル」を組織が身に付けるかです。１年や２年で勝負がつくというものではないかもしれませんが、それでも１年や２年という時間の中で、確実に変化していかなければ、間に合わない危険があることだけは確かです。私としては、ＧＥが動きだした以上、この「幕」は２年以内に切って落とされるものと予想しております。
９３年度の日米の労働生産性の開きが、１００対１８２ということを考慮すれば、この遅れは市場を失うことに繋がる危険すらあります。
このような状況からも、スケジュールが上手くブレークダウンされ、正確に遂行・管理されることは、次代の要請に応じる体制を作る為の原点（出発点）として強く位置づけられることを期待します。
そして、そのうえで、品質に対するこの種の要請に応えるための総合的、根本的手立てを検討する「場」を設けられることをお勧めします。