結果を出すリーダーは大雑把な情報や未確定の情報の扱いが上手い（1/3）
世の中がリードタイム短縮の方向に向かう中で、製品開発はもとよりさまざまな分野で計画のあり方に工夫が求められるようになってきました。
これからの話は、皆さんにとって、とてもリアルな問題です。
ところが、一般論として説明したのでは、この問題の本質はうまく伝わりません。
そこで今回は、製品開発プロジェクトをイメージして話を進めることにしました。
エンジニアリングに携わったことのある方なら「そうそう、その通りだよ」と頷いてくださるはずですが、そうでない皆さんにも話の内容が伝わるよう、できるだけ工夫して説明します。
では、さっそくはじめましょう。
3部構成の初回である今回は、皆さんに問題の輪郭をつかんでいただくことにしました。
一品受注型を例にとると、製品開発は「要件定義→設計→部材手配→製造→試験→出荷」の順に進むのが一般的です。川の水が上流から下流に流れるようにプロセスが進むことから、このような開発スタイルはウォーターフォール型と呼ばれます。
最近では、ユーザーニーズに着目して開発スピードアップをアップするアジャイル型の開発スタイルが台頭してきましたが、重厚長大な製造業では、いまだにウォーターフォール型の開発スタイルが主流です。
ところが、そんな彼らにもリードタイム短縮の要求は突き付けられています。
私が設計者をやっていたのは30年以上前のことですが、そのころは、開発フェーズの切れ目のたびに厳格なDR（デザインレビュー）が行われていました。これに合格しなければ次のフェーズに進むことはできません。要件定義のDRを通過して設計が始まり、設計のDRを通過してはじめて部材手配が許されるといった具合です。
当時は、DRをきっちりと実施することが成功のカギだと考えられていました。
しかし、構成品によっては足の長いものもあります。このようなやり方では、必然的に開発リードタイムは長くなってしまいます。
時は流れ、以前のようにきっちりと段取りを踏んでいたのではお客様の納期要求に応えられなくなりました。
こうなると、要求仕様が固まる前に設計を開始し、足の長い構成品を先行手配しなければ納期には間に合いません。しかし、このやり方はリスクを伴います。要求仕様に変更が生じれば設計には手戻りが発生し、最悪の場合、手配した構成品は廃棄せざるをえなくなります。
そんな結果になろうものなら、真っ先にやり玉に挙げられるのは、上流を任されている設計部門です。
そこで問題が発生します。
設計者たちは自らの身を守らんとして、要求仕様が確定するまでは設計情報を下流に流そうとはしません。
ところが、部材手配を担う下流の生産部門はそれを待ってはいられません。
これを機に設計部門と生産部門のいさかいが表面化し、さまざまな場面でいがみ合いが発生するようになります。私が自動車の設計をやっていたころでも、既にこれに似た状況はありました。
製造業のお客様を多く抱えている私は、このようないがみ合いの場に立ち会うことは少なくありません。
こんないがみ合いを日常的に続けていたのでは、リードタイム短縮どころではありません。
そこで次回は、問題解決に焦点を当てます。
★★★ 概念化.com を立ち上げました ★★★
★★★ ぜひ、お立ち寄りください ★★★