世の中がリードタイム短縮の方向に向かう中で、製品開発はもとより、さまざまな分野で計画のあり方に工夫が求められるようになりました。
ところが多くの人たちが、なんの工夫もせず、闇雲にこの問題に取り組んできました。工夫を伴わない無理なアプローチはここかしこに軋轢を生みます。
そのひとつが、設計部門と生産部門のいがみ合いでした。
これでは問題が解決するどころか、新たな根深い問題を引き起こしてしまいます。
3部構成の初回である前回は、皆さんに問題の輪郭をつかんでいただきました。
2回目である今回は、問題解決に焦点を当てます。
設計部門と生産部門のいがみ合いは、要求仕様が確定しないことに困惑する設計者たちの、自分たちの立場を守ろうとする保身の意識が起点となっていました。
開発プロジェクトの早い段階に要求仕様を確定できればよいのですが、最近の製品はハードウェアとソフトウェアが複雑に関連し合っている上に、ユーザーの目が肥えた市場では顧客の要求にトレードオフが発生しやすく、要求仕様を確定するのは至難の業です。要求仕様の確定は、前倒しどころか、どんどん後ろにズレ込むのが普通です。
このような状況を前に、私は決まって設計部門と生産部門の代表者に集まってもらいます。現場の事情に詳しいリーダー格の人たちも交えて、徹底的に議論します。
集まるタイミングは、プロジェクトが本格的に始まる前です。
お互いの立場や不満の原因を洗いざらい共有するには、このタイミングが一番だからです。プロジェクトが始まってしまうとさまざまな問題が発生し、それを繰り返すうちに、お互いが相手の部門を牽制するようになってしまうからです。
私は質問します。
「生産部門は、どのような情報が手元にあれば、足の長い部材を手配することができるのですか」
「すべてを確定できているわけではない状況下で、リスクを抑えつつ、生産部門が必要としている情報を設計部門が提供する方法はないのでしょうか」
「生産部門は、入手したそれらの情報をいつ、どのように活用し、何を成し遂げるのですか」
「万が一、生産部門に先出しした情報に変更が発生した場合、変更管理上の工夫で、スピード感を持ってそれに対処することはできないのでしょうか」
そして最後にこう問います。
「設計部門と生産部門は、このようなテーマについて徹底的に議論したことはありますか」
多くの場合、答えは“ノー”です。
今回は製品開発、その中でも特に一品受注型の製品開発を例に話をしています。
とはいえ皆さんも周りをよく見渡してください。量産型や繰返し生産型の製品開発であっても、上流と下流のいがみ合いは珍しいことではありません。
ＩＴの分野でも、大規模なウォーターフォール型のプロジェクトでは、要求仕様が確定しないままに設計、実装、追加開発やカスタマイズへと押し出されるように進み、後半になって致命的な手戻りが発生しています。このしわ寄せの大半は下流工程を担当するチームに負担として圧し掛かり、その結果、彼らはデスマーチへと突き進むことになります。
事業開発においても同様です。
上流で戦略が固まらないままに業務設計や組織設計へと進み、いざ業務システムを導入する段になって事業計画上の欠陥が表面化することは珍しくありません。その結果、現場部門は寝る間もなく働き続けることになります。
それもこれらは、もとはと言えば、工夫なく無理やりに期間短縮を図った結果です。
話を戻しますが、私が説明したようなやり方は、一般的にはコンカレントエンジニアリングと呼ばれています。
次回は、コンカレントエンジニアリングと、その本質を握るフロントローディングについて話しをします。
★★★ 概念化.com を立ち上げました ★★★
★★★ ぜひ、お立ち寄りください ★★★
