バブル期を経た我が国製造業は、優秀なスーパーエンジニア候補生の大幅減少以外に、人材育成面でも大きな問題を生じさせていた。上で挙げたフツーのエンジニア達の質がそれ以前に比べ大幅に低下してしまったのである。そしてこれも大きな問題であり、この部分での的確な手当も必要だ。設計エンジニアの例でこの問題を追ってみる。
バブル期以降、我が国の設計部署は、集中的に設計工数を投入して、短期間で開発を仕上げる態勢に移行した設計部署が多かった。それ以前には、一機種を担当する設計チームは、大がかりな機械製品でも、開発リーダが末端まで十分にマネージメントできる頭数の範囲での、人員構成が一般的だったはずだ。当然製品構造が簡単な場合の設計チームの構成人員は少なく、業種によっては、一人の設計者が数年掛けてじっくり製品を造成させる様な方式を、採っていた製造業も少なくはない。
そして、開発リーダのマネージメントの下、ある程度まとまった範囲を受け持つ様な、余り細分化がなされていない、大きな括りでの装置分けがなされ、されにそれぞれの装置リーダの下、各装置担当設計者が、補助設計者達を指導しながら、目的の開発を進めるパターンが一般的であった。設計の質的には、それほど激しい開発競争でもなかったため、階層構造の設計チーム内でその設計品質を高めながら、時間を掛けて製品開発を醸成させるやり方だったはずである。
ところがバブル期、新しい製品を作って市場投入をすれば飛ぶように売れる時代が来た。「とにかく一刻も早く商品を市場投入しろ」これが多くの製造業でのトッププライオリティーとされるようになると、従来から続いていた開発のやり方が大きく変わった。
多くの製造業で設計部署を見渡すと、上記したような節操のない人員削減を行っていない限り、このバブル期に採用したメンバーがウジャウジャ居る。「次々と押し寄せる開発案件を、次々とこなして行くためには、頭数を増やすしかない」。「経験の少ない設計者を、短期間で戦力化しなければならない」。「一人がマスターすべき範囲を狭めれば、促成栽培は可能か？」。とこのような模索を行った当時の設計マネージャーは少なくはなかったはずだ。
その結果多くの設計部署で、全体の仕事を細分化して一人の担当範囲を狭め、横一列に並んで、自分の担当範囲を脇目もふらずに、仕事を進める開発パターンが定着していった。確かに熟練度の低い設計者達を、短期間で戦力化するには有効な方法だ。また人海戦術で開発期間（設計作業期間）を縮めるにも有効な手段だったと思う。（図参照）
しかしこのような開発パターンの定着は、本当に強い体制の企業力を持たせるという側面から見た時には、決して良い方法では無かった。
確かに開発期間が短いということは、旬な商品を的確にマーケットに投入していくためには、必須の条件だ。ただ、それだけの目的で、人海戦術を繰り返し、垂れ流し的に膨大な費用を使い続けても良いのかと言えば、多くの読者諸君はＮＯと答えるだろう。
それでは企業として、稼げなくなるからだ。民間企業は、利益を出してなんぼの組織だ。利益が出なければ話にならないはずだ。そのためには期間を縮めると同時に、当然の事として、開発のコストも下げなければだめだと言うことである。
後もう一つ、このような態勢を取った結果、多くの製造業で人材の育成や技術の継承に問題を生じさせた。このような仕事を通じて育った設計者達は、機械全体を見渡すことができない、単機能的設計者に、多くの場合陥ってしまうからだ。このやり方では、スーパーエンジニアとして育つことが叶うであろう資質を持った者でも、本人の意識がよほど高くなければスーパーエンジニアに育つことは難しい。
私が設計思考展開手法を提唱し始めた理由の一つは、スーパーエンジニアに育ちそびれた人材の再育成や、単機能設計者に陥った設計者達が、お互いの意志を理解し合いながらチーム設計を、円滑且つ高品質に進める道具としての活用がその動機であった。
本筋から言えば、バブル期より前の仕事の進め方に戻せばよいのだが、多くの企業が置かれている状況が、特に開発の時間軸という観点で視たとき、それを許さない。良くないと分ってはいても、バブル期以降に定着した開発体制を取らざるを得ない状況にそのほとんどが置かれている。設計思考展開は、このやむ得えない態勢下で、設計者達に広い範囲の設計項目を考えさせたり、設計者同士が的確に意志を伝え合う手段として、その活用を提唱しているわけだ。
そして、上で述べたよう、スーパーエンジニア以外のフツーのエンジニア達にも、確実な仕事をして貰わなければならない。しかしバブル以降の仕事のさせ方が原因で、上記したような、多くの欠陥エンジニアを生んでしまった。幸いなことに私の提唱する設計思考展開手法は、このようなエンジニア達でも、三人寄れば文殊の知恵を生み出す道具として用いることができる。また製品開発過程で行う様々なチェックポイントで、この設計思考展開手法を用い設計思考内容をビジュアル化してやると、複数の目による、愚かなケアレスミスや思い違いを、排除する道具として用いることができる。要するにチームとしての設計力、組織としての技術力をあげ、私が言う人材力確保の第一歩とすることが叶うのである。
本題から外れるが、開発のコストについても補足する。
私が言う開発のコストを下げると言うことは、製品開発段階から製品として市場に投入され、その製品の商品寿命が尽きるまでの全ての期間を通して、その開発に関わる全てのコストを指す。だから発売直後から設計変更を繰り返すような、問題を後でダラダラ垂れ流す部類の開発をもって、開発そのものの直接費用を減らしても、それではコストを下げたとは言わない。
当然の事だが、十分な商品性を持って、よく売れる旬な商品の開発が仕上がり、それが販売され十分な収益が得られるまでの、トータルのコストが下がらねば話にならないからだ。
一般的な製造業の場合、開発が完璧な形でそのゴールに至るまでには、様々な紆余曲折を経る事が普通だ。開発に関わるメンバー達の見込み違いや判断ミス、そしてつまらないケアレスミスや手抜きなどがその大きな原因だ。そしてこの紆余曲折は、対象商品の開発コストを結果として押し上げることになる。私が上で述べた“開発のコストを下げる”と言う意味は、しつこいようだが、これら紆余曲折までを含め、且つ発売後に発生する後ろ向きの費用も含め、全てのコストを下げろと言うことだ。
次を読む