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