設計部門の課題と原因分析(その1)

更新日

投稿日

【設計部門の課題と原因分析 連載目次】

 前回、『設計部門における仕組み構築の道のりは、ゴールに向かう一本道ではなく、いくつものルートがある山登りと同じである』と解説しました。これは、製品、技術、設備、設計者などが設計部門ごとに固有であり、現時点の開発の仕組み(登山のスタート地点)は、どの設計部門をとっても同じものは存在せず、ゴール(頂上)までのルートも設計部門によって違うものになるからです。だからこそ、ルート選択そのものが目標達成のために重要な要素となります。

 従って、ツールやシステムのメーカー、又はベンダーが提示するゴールと導入プランにしたがって仕組みを構築することは、大きなリスクを抱えることを意味します。目指すべきゴールが高ければ高いほど、固有の綿密な登山計画を立てる必要があるはずです。完全には人任せにできないはずです。

 それでは、図20を使って登山計画を立ててみることにしましょう。最初にやることは、スタート地点(設計部門の現状)を正確に特定することです。そのためには、図20 に示すようにプロジェクトの工数分析を行い、課題を整理することが有効です。事例としてあげている設計部門の課題は次のように整理できます。
 
       R&D
                  図20.設計部門での製品開発プロジェクトにおける工数の使い方

 繰り返し実施する試作が同時作業となっており、設計の時期に直前の試作の評価を並行実施しています。そのため、設計も評価も中途半端です。開発試作は4ヶ月間程度のかなりの工数を使う作業ですが、開発試作依頼や顧客対応など、様々な作業を設計部門が請け負っています。そこで、本来の構想設計がおろそかになっています。2Sという試作期間にもっとも多くの工数がかかっており、設計作業、評価作業ともに最大の工数が必要になっています。一時的な設計者増員は困難であり、そのため、設計者の負担は大きなものになるでしょう。

 開発期間を通じて、設計作業、試作関連作業、評価作業が同時に実際されており、開発の状況把握やマネジメントは容易ではありません。どうしても、完成度の確認は開発の最後になってしまい、修正の際に大きな手戻りが発生します。

 ここであげた課題を解決することなしには、...

【設計部門の課題と原因分析 連載目次】

 前回、『設計部門における仕組み構築の道のりは、ゴールに向かう一本道ではなく、いくつものルートがある山登りと同じである』と解説しました。これは、製品、技術、設備、設計者などが設計部門ごとに固有であり、現時点の開発の仕組み(登山のスタート地点)は、どの設計部門をとっても同じものは存在せず、ゴール(頂上)までのルートも設計部門によって違うものになるからです。だからこそ、ルート選択そのものが目標達成のために重要な要素となります。

 従って、ツールやシステムのメーカー、又はベンダーが提示するゴールと導入プランにしたがって仕組みを構築することは、大きなリスクを抱えることを意味します。目指すべきゴールが高ければ高いほど、固有の綿密な登山計画を立てる必要があるはずです。完全には人任せにできないはずです。

 それでは、図20を使って登山計画を立ててみることにしましょう。最初にやることは、スタート地点(設計部門の現状)を正確に特定することです。そのためには、図20 に示すようにプロジェクトの工数分析を行い、課題を整理することが有効です。事例としてあげている設計部門の課題は次のように整理できます。
 
       R&D
                  図20.設計部門での製品開発プロジェクトにおける工数の使い方

 繰り返し実施する試作が同時作業となっており、設計の時期に直前の試作の評価を並行実施しています。そのため、設計も評価も中途半端です。開発試作は4ヶ月間程度のかなりの工数を使う作業ですが、開発試作依頼や顧客対応など、様々な作業を設計部門が請け負っています。そこで、本来の構想設計がおろそかになっています。2Sという試作期間にもっとも多くの工数がかかっており、設計作業、評価作業ともに最大の工数が必要になっています。一時的な設計者増員は困難であり、そのため、設計者の負担は大きなものになるでしょう。

 開発期間を通じて、設計作業、試作関連作業、評価作業が同時に実際されており、開発の状況把握やマネジメントは容易ではありません。どうしても、完成度の確認は開発の最後になってしまい、修正の際に大きな手戻りが発生します。

 ここであげた課題を解決することなしには、目標の開発効率2倍を達成することは考えられません。したがって、この課題を解決する対策を検討することが、目標達成のための登山ルートを検討することになります。

 次回は、観測できた課題一つひとつを分析して課題の根本原因を明らかにし、次に、その原因を除去するための対策検討を解説します。
 
 

   続きを読むには・・・


この記事の著者

石橋 良造

組織のしくみと個人の意識を同時に改革・改善することで、パフォーマンス・エクセレンスを追求し、実現する開発組織に変えます!

組織のしくみと個人の意識を同時に改革・改善することで、パフォーマンス・エクセレンスを追求し、実現する開発組織に変えます!


「技術マネジメント総合」の他のキーワード解説記事

もっと見る
テクノロジー事業に必要な戦略とは 新規事業・新商品を生み出す技術戦略(その2)

        ビジネスにおける戦略書というと、最もポピュラーなものとして「経営戦略書」が挙げられます。 ...

        ビジネスにおける戦略書というと、最もポピュラーなものとして「経営戦略書」が挙げられます。 ...


イノベーションの創造 普通の組織をイノベーティブにする処方箋 (その136)

  【この連載の前回:普通の組織をイノベーティブにする処方箋 (その135)へのリンク】 失敗の金銭的コストを低減する方法について解説し...

  【この連載の前回:普通の組織をイノベーティブにする処方箋 (その135)へのリンク】 失敗の金銭的コストを低減する方法について解説し...


自社の強みとは 『価値づくり』の研究開発マネジメント (その23)

   前回は、オープンイノベーションを成功させるためのビジネスモデルの必要性を解説しました。今回は、自社の強みの設定について議論したいと思...

   前回は、オープンイノベーションを成功させるためのビジネスモデルの必要性を解説しました。今回は、自社の強みの設定について議論したいと思...


「技術マネジメント総合」の活用事例

もっと見る
人的資源マネジメント:インダストリー4.0 を追いかけるその前に(その2)

 前回のその1に続いて解説します。   4. 開発・製造リンクによる製造性評価    少し具体的な例を紹介したいと思います。図...

 前回のその1に続いて解説します。   4. 開発・製造リンクによる製造性評価    少し具体的な例を紹介したいと思います。図...


マトリクス体制での品質保証2 プロジェクト管理の仕組み (その31)

 前回のマトリクス体制での品質保証1に続いて解説します。品質計画は、製品開発に必要となる手順やリソースが誰によっていつ適用されるかを明確にした個別製品の開...

 前回のマトリクス体制での品質保証1に続いて解説します。品質計画は、製品開発に必要となる手順やリソースが誰によっていつ適用されるかを明確にした個別製品の開...


設計部門とリスク管理(その1)

【設計部門とリスク管理 連載目次】 1. リスク管理とは目標達成までのシナリオ作成 2. コンティンジェンシープランの注意事項 3. リスク管理...

【設計部門とリスク管理 連載目次】 1. リスク管理とは目標達成までのシナリオ作成 2. コンティンジェンシープランの注意事項 3. リスク管理...